From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aaron M. Renn" To: Uncle George Cc: mauve-discuss@sourceware.cygnus.com Subject: Re: Java 1.2 Date: Thu, 25 Mar 1999 19:09:00 -0000 Message-id: <19990325211300.B13388@urbanophile.com> References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> <36FA6017.CEC9A956@voicenet.com> <36FA6017.CEC9A956@voicenet.com> X-SW-Source: 1999-03/msg00025.html 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aaron M. Renn" To: Uncle George Cc: mauve-discuss@sourceware.cygnus.com Subject: Re: Java 1.2 Date: Thu, 01 Apr 1999 00:00:00 -0000 Message-ID: <19990325211300.B13388@urbanophile.com> References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> <36FA6017.CEC9A956@voicenet.com> <36FA6017.CEC9A956@voicenet.com> X-SW-Source: 1999-q1/msg00041.html Message-ID: <19990401000000.jFrDODwBidyAukuO-We_BQNAuIytuucJS9HYYNuRlJ0@z> 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/