Re: Java 1.2

["Aaron M. Renn" <arenn@urbanophile.com>]

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/