Re: Java 1.2

Re: Java 1.2

[Aaron M. Renn]

>Some of ur tests do not compile unde 1.2. whats the deal with posting
>patches directed towards 1.2
>compatability?

What in particular is not working and why is it not?

-- 
Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/

Re: Java 1.2

[Uncle George]

Why it is not - Spec for one function requires a try.
"gnu/testlet/java/io/StringWriter/Test.java" requires a try/catch in
sw.close();

The others appear to be a lack of the complete set of sql impliment's
functionality
.
"gnu/testlet/java/sql/Connection/TestJdbc10.java"
"gnu/testlet/java/sql/DatabaseMetaData/TestJdbc10.java"

ALSO running the tests present some interesting results. I ran these tests
on my non-comm port
of SUN's java/jdk.  Its interesting all the "ERRORS" that are related to
the character sets, as well
as some errors in java.text.DecimalFormat.

1) Who deceides what is correct for the character sets ?????
2) Who deceides what is correct for DecimalFormat.  ( documentation or
Current JDK1.2 implimentation?)
3) If there is something inconsistent, do u folks actually inquire ( make
out bug reports ) to sun for their opinion ? ( ie try it on a SUN's port ?
)

gat
BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - I do
not have access to SUN's testing facility. Since I cannot help with the
GPL/java ports, i believe I can still assist with Tests/and the writing of
them.

Aaron M. Renn wrote:

> >Some of ur tests do not compile unde 1.2. whats the deal with posting
> >patches directed towards 1.2
> >compatability?
>
> What in particular is not working and why is it not?
>
> --
> Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/

Re: Java 1.2

[Aaron M. Renn]

Uncle George (gatgul@voicenet.com) wrote:
> Why it is not - Spec for one function requires a try.
> "gnu/testlet/java/io/StringWriter/Test.java" requires a try/catch in
> sw.close();

This is probably a bug.
 
> The others appear to be a lack of the complete set of sql impliment's
> functionality
> .
> "gnu/testlet/java/sql/Connection/TestJdbc10.java"
> "gnu/testlet/java/sql/DatabaseMetaData/TestJdbc10.java"

These classes are specifically designed to test Java 1.1/JDBC 1.0
functionality.  Mauve will be able to test implementations at various
spec levels.  To test Java 1.1, we cannot have any 1.2 functionality.

You do bring up an interesting case.  I believe one assumption of the
test selection script is that Java 1.2 includes all Java 1.0 and Java 
1.1 tests.  For items such as these which test that interfaces are
defined correctly at a particular spec level, this assumption is not
valid.
 
> ALSO running the tests present some interesting results. I ran these tests
> on my non-comm port
> of SUN's java/jdk.  Its interesting all the "ERRORS" that are related to
> the character sets, as well
> as some errors in java.text.DecimalFormat.
> 
> 1) Who deceides what is correct for the character sets ?????

I'm not sure what you mean by character sets, but there are still some
unresolved errors being reported out of the java.lang.Character test.
It reports over 100 errors for the JDK implementation.  Part of this
is because we use the latest and greatest Unicode spec, while Sun
uses an outdated one.  Others may be bugs in the test script or the
Java implementation.

> 2) Who deceides what is correct for DecimalFormat.  ( documentation or
> Current JDK1.2 implimentation?)

I'm not familiar with the test for this class.  However, we should base
our tests on the documentation unless there is some reason to believe
it is wrong.  (A typo, for example).  Sun's implementation has bugs, and
we should not require bug for bug compatibility.

A certain level of compatibility is desireable though.  In gray areas
where the documentation does not specify a result - for example, the
various default date formats, or toString() results - it is useful
to emulate the JDK's output to match programmer and user expectations.

> 3) If there is something inconsistent, do u folks actually inquire ( make
> out bug reports ) to sun for their opinion ? ( ie try it on a SUN's port ?
> )

I always run my Mauve tests against Sun's implementation.  It really isn't
a good idea to have the person writing the code write the only test
program for it.  My test and my code might both reflect my mistaken
belief about the correct behavior.  A sanity check against the JDK is a good
idea.

I have not been logging bugs against Sun's implementation because quite
honestly I have not found any that haven't already been logged.  Plus I
doubt that Sun is interested in fixing bugs in JDK 1.1.5, which is what
is installed on my machine.

> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - I do
> not have access to SUN's testing facility. Since I cannot help with the
> GPL/java ports, i believe I can still assist with Tests/and the writing of
> them.

That would be excellent.  If you write anything, please send it to 
Anthony Green or Tom Tromey at Cygnus.  Patches to existing tests can
be posted to the list for now.

BTW: Anthony is on vacation right now, so don't expect to hear back 
from him on any emails for a couple more weeks.

-- 
Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/

Re: Java 1.2

[Tom Tromey]

>>>>> "Aaron" == Aaron M Renn <arenn@urbanophile.com> writes:

Aaron> You do bring up an interesting case.  I believe one assumption
Aaron> of the test selection script is that Java 1.2 includes all Java
Aaron> 1.0 and Java 1.1 tests.  For items such as these which test
Aaron> that interfaces are defined correctly at a particular spec
Aaron> level, this assumption is not valid.

I believe you can write a tags line like:

	// Tags: JDK1.1 !JDK1.2

and that will do the right thing -- include the test when 1.1 is
specified, but not when 1.2 is specified.

I don't know anything about java.sql and wouldn't be comfortable
making the change myself.

Aaron> I'm not sure what you mean by character sets, but there are
Aaron> still some unresolved errors being reported out of the
Aaron> java.lang.Character test.  It reports over 100 errors for the
Aaron> JDK implementation.  Part of this is because we use the latest
Aaron> and greatest Unicode spec, while Sun uses an outdated one.
Aaron> Others may be bugs in the test script or the Java
Aaron> implementation.

Yes, all three probably apply:

* Sun's JDK 1.0 and JDK 1.1 use an outdated Unicode spec.
  I think we should just let these remain errors.

* Sun's JDK 1.0 and 1.1 (haven't tried 1.2) have bugs in their
  Character implementation.

* I once wrote Sun and asked about the apparently self-contradictory
  documentation in the online 1.2 docs for Character.isLower.  Their
  reply is that the `Ll' rule applies and the rest is just expository.
  This means there is a bug in the current test suite (if you believe
  their reply, which I occasionally do not).
  I haven't had the time to look into this yet.

The Character tests are really the most problematic.  Sun's
documentation is lacking, and so I sometimes picked what I thought was
the most reasonable and useful behavior.  Perhaps we should just aim
for 1.2 compatibility (excluding whatever obvious bugs we might find).

>> 2) Who deceides what is correct for DecimalFormat.  ( documentation
>> or Current JDK1.2 implimentation?)

Aaron> I'm not familiar with the test for this class.  However, we
Aaron> should base our tests on the documentation unless there is some
Aaron> reason to believe it is wrong.  (A typo, for example).  Sun's
Aaron> implementation has bugs, and we should not require bug for bug
Aaron> compatibility.

Aaron> A certain level of compatibility is desireable though.

I agree.  There is a fair amount of gray in the picture, since Sun's
documentation isn't all that great (parts are better than others).

When writing new java.text tests (java.text has particularly poor
documentation), I've been trying to test things which are more or less
unambiguous.  I might have failed -- this, like everything, is up for
discussion, patches, etc.


For DecimalFormat, I ran my test cases against our implementation and
against JDK 1.1.6 (I think -- or was it 1.1.5?).  Feel free to report
specific problems!  I don't have JDK 1.2 yet.

Aaron> That would be excellent.  If you write anything, please send it
Aaron> to Anthony Green or Tom Tromey at Cygnus.  Patches to existing
Aaron> tests can be posted to the list for now.

Yeah, send them on out.  If you write more than a few, we'll see about
getting you direct cvs access.

Tom

Re: Java 1.2

[Tom Tromey]

>>>>> ">" == Uncle George <gatgul@voicenet.com> writes:

>> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha -
>> I do not have access to SUN's testing facility. Since I cannot help
>> with the GPL/java ports, i believe I can still assist with
>> Tests/and the writing of them.


Does anybody know if he would be prevented from contributing tests if
he had seen Sun's source code?  That might be a problem, but I really
don't know for sure.

Tom

Re: Java 1.2

[Christoph Toshok]

Tom Tromey wrote:

> >>>>> ">" == Uncle George <gatgul@voicenet.com> writes:
>
> >> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha -
> >> I do not have access to SUN's testing facility. Since I cannot help
> >> with the GPL/java ports, i believe I can still assist with
> >> Tests/and the writing of them.
>
> Does anybody know if he would be prevented from contributing tests if
> he had seen Sun's source code?  That might be a problem, but I really
> don't know for sure.

I wouldn't think that this would cause a problem.  Seeing the Sun source
code doesn't prohibit one from writing GPL/LGPL'ed subclasses, for
instance.

Chris

Java 1.2: DescriptorTest.java

[Uncle George]

It seems like this test  fails on 1.2 because of a missing "setClass" .
the class "java.lang.Object.class" has a getClass, but appears to be
missing a (required by  1.2 spec ) a corresponding "setClass"

Depending how how these tests are viewed,  SUN's  bean.PropertyDescriptor
caught this missing
method.  Maybe others should also?
gat


Test needs a class that has both  "setXxxxx" & "getXxxxx" to pass in 1.2

Java 1.2: DescriptorTest.java

[Uncle George]

It seems like this test  fails on 1.2 because of a missing "setClass" .
the class "java.lang.Object.class" has a getClass, but appears to be
missing a (required by  1.2 spec ) a corresponding "setClass"

Depending how how these tests are viewed,  SUN's  bean.PropertyDescriptor
caught this missing
method.  Maybe others should also?
gat


Test needs a class that has both  "setXxxxx" & "getXxxxx" to pass in 1.2

Re: Java 1.2

[Christoph Toshok]

Tom Tromey wrote:

> >>>>> ">" == Uncle George <gatgul@voicenet.com> writes:
>
> >> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha -
> >> I do not have access to SUN's testing facility. Since I cannot help
> >> with the GPL/java ports, i believe I can still assist with
> >> Tests/and the writing of them.
>
> Does anybody know if he would be prevented from contributing tests if
> he had seen Sun's source code?  That might be a problem, but I really
> don't know for sure.

I wouldn't think that this would cause a problem.  Seeing the Sun source
code doesn't prohibit one from writing GPL/LGPL'ed subclasses, for
instance.

Chris

Re: Java 1.2

[Tom Tromey]

>>>>> ">" == Uncle George <gatgul@voicenet.com> writes:

>> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha -
>> I do not have access to SUN's testing facility. Since I cannot help
>> with the GPL/java ports, i believe I can still assist with
>> Tests/and the writing of them.


Does anybody know if he would be prevented from contributing tests if
he had seen Sun's source code?  That might be a problem, but I really
don't know for sure.

Tom

Re: Java 1.2

[Aaron M. Renn]

Uncle George (gatgul@voicenet.com) wrote:
> Why it is not - Spec for one function requires a try.
> "gnu/testlet/java/io/StringWriter/Test.java" requires a try/catch in
> sw.close();

This is probably a bug.
 
> The others appear to be a lack of the complete set of sql impliment's
> functionality
> .
> "gnu/testlet/java/sql/Connection/TestJdbc10.java"
> "gnu/testlet/java/sql/DatabaseMetaData/TestJdbc10.java"

These classes are specifically designed to test Java 1.1/JDBC 1.0
functionality.  Mauve will be able to test implementations at various
spec levels.  To test Java 1.1, we cannot have any 1.2 functionality.

You do bring up an interesting case.  I believe one assumption of the
test selection script is that Java 1.2 includes all Java 1.0 and Java 
1.1 tests.  For items such as these which test that interfaces are
defined correctly at a particular spec level, this assumption is not
valid.
 
> ALSO running the tests present some interesting results. I ran these tests
> on my non-comm port
> of SUN's java/jdk.  Its interesting all the "ERRORS" that are related to
> the character sets, as well
> as some errors in java.text.DecimalFormat.
> 
> 1) Who deceides what is correct for the character sets ?????

I'm not sure what you mean by character sets, but there are still some
unresolved errors being reported out of the java.lang.Character test.
It reports over 100 errors for the JDK implementation.  Part of this
is because we use the latest and greatest Unicode spec, while Sun
uses an outdated one.  Others may be bugs in the test script or the
Java implementation.

> 2) Who deceides what is correct for DecimalFormat.  ( documentation or
> Current JDK1.2 implimentation?)

I'm not familiar with the test for this class.  However, we should base
our tests on the documentation unless there is some reason to believe
it is wrong.  (A typo, for example).  Sun's implementation has bugs, and
we should not require bug for bug compatibility.

A certain level of compatibility is desireable though.  In gray areas
where the documentation does not specify a result - for example, the
various default date formats, or toString() results - it is useful
to emulate the JDK's output to match programmer and user expectations.

> 3) If there is something inconsistent, do u folks actually inquire ( make
> out bug reports ) to sun for their opinion ? ( ie try it on a SUN's port ?
> )

I always run my Mauve tests against Sun's implementation.  It really isn't
a good idea to have the person writing the code write the only test
program for it.  My test and my code might both reflect my mistaken
belief about the correct behavior.  A sanity check against the JDK is a good
idea.

I have not been logging bugs against Sun's implementation because quite
honestly I have not found any that haven't already been logged.  Plus I
doubt that Sun is interested in fixing bugs in JDK 1.1.5, which is what
is installed on my machine.

> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - I do
> not have access to SUN's testing facility. Since I cannot help with the
> GPL/java ports, i believe I can still assist with Tests/and the writing of
> them.

That would be excellent.  If you write anything, please send it to 
Anthony Green or Tom Tromey at Cygnus.  Patches to existing tests can
be posted to the list for now.

BTW: Anthony is on vacation right now, so don't expect to hear back 
from him on any emails for a couple more weeks.

-- 
Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/

Re: Java 1.2

[Aaron M. Renn]

>Some of ur tests do not compile unde 1.2. whats the deal with posting
>patches directed towards 1.2
>compatability?

What in particular is not working and why is it not?

-- 
Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/

Re: Java 1.2

[Tom Tromey]

>>>>> "Aaron" == Aaron M Renn <arenn@urbanophile.com> writes:

Aaron> You do bring up an interesting case.  I believe one assumption
Aaron> of the test selection script is that Java 1.2 includes all Java
Aaron> 1.0 and Java 1.1 tests.  For items such as these which test
Aaron> that interfaces are defined correctly at a particular spec
Aaron> level, this assumption is not valid.

I believe you can write a tags line like:

	// Tags: JDK1.1 !JDK1.2

and that will do the right thing -- include the test when 1.1 is
specified, but not when 1.2 is specified.

I don't know anything about java.sql and wouldn't be comfortable
making the change myself.

Aaron> I'm not sure what you mean by character sets, but there are
Aaron> still some unresolved errors being reported out of the
Aaron> java.lang.Character test.  It reports over 100 errors for the
Aaron> JDK implementation.  Part of this is because we use the latest
Aaron> and greatest Unicode spec, while Sun uses an outdated one.
Aaron> Others may be bugs in the test script or the Java
Aaron> implementation.

Yes, all three probably apply:

* Sun's JDK 1.0 and JDK 1.1 use an outdated Unicode spec.
  I think we should just let these remain errors.

* Sun's JDK 1.0 and 1.1 (haven't tried 1.2) have bugs in their
  Character implementation.

* I once wrote Sun and asked about the apparently self-contradictory
  documentation in the online 1.2 docs for Character.isLower.  Their
  reply is that the `Ll' rule applies and the rest is just expository.
  This means there is a bug in the current test suite (if you believe
  their reply, which I occasionally do not).
  I haven't had the time to look into this yet.

The Character tests are really the most problematic.  Sun's
documentation is lacking, and so I sometimes picked what I thought was
the most reasonable and useful behavior.  Perhaps we should just aim
for 1.2 compatibility (excluding whatever obvious bugs we might find).

>> 2) Who deceides what is correct for DecimalFormat.  ( documentation
>> or Current JDK1.2 implimentation?)

Aaron> I'm not familiar with the test for this class.  However, we
Aaron> should base our tests on the documentation unless there is some
Aaron> reason to believe it is wrong.  (A typo, for example).  Sun's
Aaron> implementation has bugs, and we should not require bug for bug
Aaron> compatibility.

Aaron> A certain level of compatibility is desireable though.

I agree.  There is a fair amount of gray in the picture, since Sun's
documentation isn't all that great (parts are better than others).

When writing new java.text tests (java.text has particularly poor
documentation), I've been trying to test things which are more or less
unambiguous.  I might have failed -- this, like everything, is up for
discussion, patches, etc.


For DecimalFormat, I ran my test cases against our implementation and
against JDK 1.1.6 (I think -- or was it 1.1.5?).  Feel free to report
specific problems!  I don't have JDK 1.2 yet.

Aaron> That would be excellent.  If you write anything, please send it
Aaron> to Anthony Green or Tom Tromey at Cygnus.  Patches to existing
Aaron> tests can be posted to the list for now.

Yeah, send them on out.  If you write more than a few, we'll see about
getting you direct cvs access.

Tom

Re: Java 1.2

[Uncle George]

Why it is not - Spec for one function requires a try.
"gnu/testlet/java/io/StringWriter/Test.java" requires a try/catch in
sw.close();

The others appear to be a lack of the complete set of sql impliment's
functionality
.
"gnu/testlet/java/sql/Connection/TestJdbc10.java"
"gnu/testlet/java/sql/DatabaseMetaData/TestJdbc10.java"

ALSO running the tests present some interesting results. I ran these tests
on my non-comm port
of SUN's java/jdk.  Its interesting all the "ERRORS" that are related to
the character sets, as well
as some errors in java.text.DecimalFormat.

1) Who deceides what is correct for the character sets ?????
2) Who deceides what is correct for DecimalFormat.  ( documentation or
Current JDK1.2 implimentation?)
3) If there is something inconsistent, do u folks actually inquire ( make
out bug reports ) to sun for their opinion ? ( ie try it on a SUN's port ?
)

gat
BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - I do
not have access to SUN's testing facility. Since I cannot help with the
GPL/java ports, i believe I can still assist with Tests/and the writing of
them.

Aaron M. Renn wrote:

> >Some of ur tests do not compile unde 1.2. whats the deal with posting
> >patches directed towards 1.2
> >compatability?
>
> What in particular is not working and why is it not?
>
> --
> Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/