* Re: Java 1.2
@ 1999-03-25 14:45 Aaron M. Renn
1999-03-25 16:29 ` Uncle George
1999-04-01 0:00 ` Aaron M. Renn
0 siblings, 2 replies; 16+ messages in thread
From: Aaron M. Renn @ 1999-03-25 14:45 UTC (permalink / raw)
To: Uncle George, mauve-discuss
>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/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 14:45 Java 1.2 Aaron M. Renn @ 1999-03-25 16:29 ` Uncle George 1999-03-25 19:09 ` Aaron M. Renn ` (2 more replies) 1999-04-01 0:00 ` Aaron M. Renn 1 sibling, 3 replies; 16+ messages in thread From: Uncle George @ 1999-03-25 16:29 UTC (permalink / raw) To: Aaron M. Renn, mauve-discuss 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/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 16:29 ` Uncle George @ 1999-03-25 19:09 ` Aaron M. Renn 1999-03-25 19:42 ` Tom Tromey 1999-04-01 0:00 ` Aaron M. Renn 1999-03-25 19:43 ` Tom Tromey 1999-04-01 0:00 ` Uncle George 2 siblings, 2 replies; 16+ messages in thread From: Aaron M. Renn @ 1999-03-25 19:09 UTC (permalink / raw) To: Uncle George; +Cc: mauve-discuss 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/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 19:09 ` Aaron M. Renn @ 1999-03-25 19:42 ` Tom Tromey 1999-03-27 3:38 ` Java 1.2: DescriptorTest.java Uncle George 1999-04-01 0:00 ` Java 1.2 Tom Tromey 1999-04-01 0:00 ` Aaron M. Renn 1 sibling, 2 replies; 16+ messages in thread From: Tom Tromey @ 1999-03-25 19:42 UTC (permalink / raw) To: Aaron M. Renn; +Cc: Uncle George, mauve-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Java 1.2: DescriptorTest.java 1999-03-25 19:42 ` Tom Tromey @ 1999-03-27 3:38 ` Uncle George 1999-04-01 0:00 ` Uncle George 1999-04-01 0:00 ` Java 1.2 Tom Tromey 1 sibling, 1 reply; 16+ messages in thread From: Uncle George @ 1999-03-27 3:38 UTC (permalink / raw) To: mauve-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Java 1.2: DescriptorTest.java 1999-03-27 3:38 ` Java 1.2: DescriptorTest.java Uncle George @ 1999-04-01 0:00 ` Uncle George 0 siblings, 0 replies; 16+ messages in thread From: Uncle George @ 1999-04-01 0:00 UTC (permalink / raw) To: mauve-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 19:42 ` Tom Tromey 1999-03-27 3:38 ` Java 1.2: DescriptorTest.java Uncle George @ 1999-04-01 0:00 ` Tom Tromey 1 sibling, 0 replies; 16+ messages in thread From: Tom Tromey @ 1999-04-01 0:00 UTC (permalink / raw) To: Aaron M. Renn; +Cc: Uncle George, mauve-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 19:09 ` Aaron M. Renn 1999-03-25 19:42 ` Tom Tromey @ 1999-04-01 0:00 ` Aaron M. Renn 1 sibling, 0 replies; 16+ messages in thread From: Aaron M. Renn @ 1999-04-01 0:00 UTC (permalink / raw) To: Uncle George; +Cc: mauve-discuss 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/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 16:29 ` Uncle George 1999-03-25 19:09 ` Aaron M. Renn @ 1999-03-25 19:43 ` Tom Tromey 1999-03-25 21:21 ` Christoph Toshok 1999-04-01 0:00 ` Tom Tromey 1999-04-01 0:00 ` Uncle George 2 siblings, 2 replies; 16+ messages in thread From: Tom Tromey @ 1999-03-25 19:43 UTC (permalink / raw) To: Uncle George; +Cc: Aaron M. Renn, mauve-discuss >>>>> ">" == 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 19:43 ` Tom Tromey @ 1999-03-25 21:21 ` Christoph Toshok 1999-04-01 0:00 ` Christoph Toshok 1999-04-01 0:00 ` Tom Tromey 1 sibling, 1 reply; 16+ messages in thread From: Christoph Toshok @ 1999-03-25 21:21 UTC (permalink / raw) To: tromey; +Cc: Uncle George, Aaron M. Renn, mauve-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 21:21 ` Christoph Toshok @ 1999-04-01 0:00 ` Christoph Toshok 0 siblings, 0 replies; 16+ messages in thread From: Christoph Toshok @ 1999-04-01 0:00 UTC (permalink / raw) To: tromey; +Cc: Uncle George, Aaron M. Renn, mauve-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 19:43 ` Tom Tromey 1999-03-25 21:21 ` Christoph Toshok @ 1999-04-01 0:00 ` Tom Tromey 1 sibling, 0 replies; 16+ messages in thread From: Tom Tromey @ 1999-04-01 0:00 UTC (permalink / raw) To: Uncle George; +Cc: Aaron M. Renn, mauve-discuss >>>>> ">" == 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 16:29 ` Uncle George 1999-03-25 19:09 ` Aaron M. Renn 1999-03-25 19:43 ` Tom Tromey @ 1999-04-01 0:00 ` Uncle George 2 siblings, 0 replies; 16+ messages in thread From: Uncle George @ 1999-04-01 0:00 UTC (permalink / raw) To: Aaron M. Renn, mauve-discuss 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/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Java 1.2 1999-03-25 14:45 Java 1.2 Aaron M. Renn 1999-03-25 16:29 ` Uncle George @ 1999-04-01 0:00 ` Aaron M. Renn 1 sibling, 0 replies; 16+ messages in thread From: Aaron M. Renn @ 1999-04-01 0:00 UTC (permalink / raw) To: Uncle George, mauve-discuss >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/ ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <36FA44BC.43E205A5@voicenet.com>]
* Java 1.2 [not found] <36FA44BC.43E205A5@voicenet.com> @ 1999-03-25 14:23 ` Uncle George 1999-04-01 0:00 ` Uncle George 0 siblings, 1 reply; 16+ messages in thread From: Uncle George @ 1999-03-25 14:23 UTC (permalink / raw) To: mauve-discuss Some of ur tests do not compile unde 1.2. whats the deal with posting patches directed towards 1.2 compatability? gat ^ permalink raw reply [flat|nested] 16+ messages in thread
* Java 1.2 1999-03-25 14:23 ` Uncle George @ 1999-04-01 0:00 ` Uncle George 0 siblings, 0 replies; 16+ messages in thread From: Uncle George @ 1999-04-01 0:00 UTC (permalink / raw) To: mauve-discuss Some of ur tests do not compile unde 1.2. whats the deal with posting patches directed towards 1.2 compatability? gat ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-04-01 0:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-03-25 14:45 Java 1.2 Aaron M. Renn 1999-03-25 16:29 ` Uncle George 1999-03-25 19:09 ` Aaron M. Renn 1999-03-25 19:42 ` Tom Tromey 1999-03-27 3:38 ` Java 1.2: DescriptorTest.java Uncle George 1999-04-01 0:00 ` Uncle George 1999-04-01 0:00 ` Java 1.2 Tom Tromey 1999-04-01 0:00 ` Aaron M. Renn 1999-03-25 19:43 ` Tom Tromey 1999-03-25 21:21 ` Christoph Toshok 1999-04-01 0:00 ` Christoph Toshok 1999-04-01 0:00 ` Tom Tromey 1999-04-01 0:00 ` Uncle George 1999-04-01 0:00 ` Aaron M. Renn [not found] <36FA44BC.43E205A5@voicenet.com> 1999-03-25 14:23 ` Uncle George 1999-04-01 0:00 ` Uncle George
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).