Re: FYI: few DecimalFormat fixes
Hi Mario, On Mon, 2006-11-27 at 03:45 +0100, Mario Torre wrote: > I've fixed some of them. There are a couple of them difficult to find, > though. Nice one! This not only fixed most of the regressions, but according to the autobuilder mauve run on classpath-testresults this (plus some of the other patches made yesterday) made a lot of new tests PASS. I believe we are pretty close to branching for 0.93 now. For those that want to follow at home please take a look at: http://news.gmane.org/gmane.comp.java.classpath.testresults And investigate any regressions or unexpected FAILs you see there. Thanks, Mark signature.asc Description: This is a digitally signed message part
Re: Mauve regressions 0.92/0.93-pre
> We seem to be doing pretty well on regression with respect to 0.92. Here > is the current list. It would be good to get this list down a bit before > we branch for 0.93. The number of new passes has gone up a lot. So it > looks like 0.93 will be a much better release than 0.92. > > - gnu.javax.swing.text.html.parser.support.Parser.Text > - gnu.javax.swing.text.html.parser.support.Parser.textPreProcessor_Test These tests are testing non-API classpath specific stuff (should really be moved to a different place probably). I think the new fails could be related to the whitespace handling. I'll check this. > - java.awt.datatransfer.Clipboard.clipboardFlavors > - java.awt.datatransfer.DataFlavor.flavor > > Failures are in cases where the representation class is one of the > standard classes like java.io.InputStream. I'll look into this. Please compare if these tests fail with the RI or so (many do and are thus probably bogus). I've done some testing with the Harmony tests there only. > - java.awt.image.IndexColorModel.getAlpha > Fails with the following stacktrace: > java.lang.ArrayIndexOutOfBoundsException: 99 >at java.awt.image.IndexColorModel.getAlpha(IndexColorModel.java:585) >at > gnu.testlet.java.awt.image.IndexColorModel.getAlpha.test(getAlpha.java:76) >at RunnerProcess.runtest(RunnerProcess.java:360) >at RunnerProcess.runAndReport(RunnerProcess.java:415) >at RunnerProcess.main(RunnerProcess.java:227) That's mine. I'll look into this. > - java.util.Vector.AcuniaVectorTest > > Fails because it expects a NullPointerException on a v.removeAll(null) > and v.retainAll(null), where the Vector v is empty. This seems a little > pedantic, but might be right. This was already discussed. The RI also fails with this test. I've changed that behaviour in Classpath because I had an app here that wasn't working because of that corner case. I suggest we either remove this specific check or fix it (might not be ideal either, as it's slightly against the spec). > - javax.swing.border.TitledBorder.getBorderInsets > > All results seem slightly off with this test. I'll check this. > - javax.swing.JToolTip.setTipText > > Has one new check failure: > FAIL: line 53: [2] -- got 2 but expected 1 > Probably my bad too. I'll check this. > - javax.swing.text.StringContent.createPosition > - javax.swing.text.StringContent.getChars I believe these tests are checking a corner case in the spec. Where the RI actually behaves wrong (according to the spec). I think David Gilbert even filed bug reports against Sun for these issues. As long as noone complains we should probably leave this as it is. /Roman
Re: Mauve regressions 0.92/0.93-pre
Hi, On Mon, 2006-11-27 at 10:32 +0100, Roman Kennke wrote: > > - java.awt.datatransfer.Clipboard.clipboardFlavors > > - java.awt.datatransfer.DataFlavor.flavor > > > > Failures are in cases where the representation class is one of the > > standard classes like java.io.InputStream. I'll look into this. > > Please compare if these tests fail with the RI or so (many do and are > thus probably bogus). I've done some testing with the Harmony tests > there only. I know I wrote these tests for Mauve from public docs. Unfortunately datatransfer is a little confusing on the precise details of the mime-types used. The failures seem to indicate small differences in interpretation. They are probably non-fatal and the mauve tests are actually wrong or too strict. > > - java.util.Vector.AcuniaVectorTest > > > > Fails because it expects a NullPointerException on a v.removeAll(null) > > and v.retainAll(null), where the Vector v is empty. This seems a little > > pedantic, but might be right. > > This was already discussed. The RI also fails with this test. I've > changed that behaviour in Classpath because I had an app here that > wasn't working because of that corner case. I suggest we either remove > this specific check or fix it (might not be ideal either, as it's > slightly against the spec). Yeah. I'll disable these two checks and add a comment in mauve. Cheers, Mark signature.asc Description: This is a digitally signed message part
[Bug classpath/25557] Breaks badly on solaris9 during build
--- Comment #12 from robilad at kaffe dot org 2006-11-27 14:57 --- Checked in the patch from the mail on the gcj mailing list into classpath. 2006-11-26 Roger Sayle eyesopen.com> Ian Lance Taylor airs.com> Paolo Bonzini gnu.org> Fixes bug #25557. * lib/gen-classlist.sh.in: Avoid using test's -ef operator for increased portability. Likewise, use -f instead of -e. -- robilad at kaffe dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |0.93 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25557 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
GNU Classpath, Sun, Java, GPL, Reflections & The Future
Hi all, It has been 2 weeks now since the announcement that Sun will release Java under the GPL and will adopt the classpath exception for the j2se libraries to be compatible with all our efforts. And I must say I am still recovering from the happy surprise! :) I deliberately waited a little to let it all sink in and to be able to talk to several of you and read all the reactions on Planet Classpath. And to actually see the actions of Sun. They have delivered and having spoken to several Sun people now has convinced me they are really genuine. And the FSF agrees with that. We can include any GPL+exception parts from OpenJDK in GNU Classpath if they are useful. And other GPLed parts can of course be included in other GPL-compatible Free Software projects the community is working on. We used to be really suspicious about Sun and possible code "contamination" (accidental copyright infringement), but all this will soon be a thing of the past. The GPL acts as a covenant between all parties. There is no fear anymore that there is any copyright infringement going on between the projects (if you do keep track of the original copyright statements of course) since they will all use the same license. And the GPL acts like a patent shield between all parties. And it seems GNU Classpath hackers are really happy about this. Sure it sucks a little to have two duplicated free code bases for the core libraries in the future. But for Sun to make their license explicitly compatible is a really big thing. And they deserve major kudos for it. This means people and projects will be able to gradually shift between the various projects, mixing and matching just what is needed to get higher compatibility, performance and features. And I do hope that will happen, just as it has happened in the past with all the projects adopting and collaborating around GNU Classpath. The way Sun did this brings a high credibility to their effort and as Jonathan Schwartz said during the presentation of OpenJDK we can now start trying to figure out how from this point on we all can work together and not duplicate efforts: http://gnu.wildebeest.org/diary/index.php?p=171 The uptake and the drive behind GNU Classpath has been enormous. Just seeing the amount of patches flow in the last 2 weeks (it looks like this announcement made people work even harder to show off how cool GNU Classpath really is!) and the quality of the code (the regressions in Mauve are really minor - down to a handfull now - compared to the huge increase in features and code since the last release) is amazing. And it seems the adoption, features, maturity and collaboration have only been increasing over the years. I have the feeling our work, and our honest open collaborative nature, is substantially responsible for Sun's change in policy. This really is your victory. And we have now been promoted from "Freedom Fighters" that are trying to keep a free Java path to Libre Java platform innovators that will work on equal footing with the larger Java eco-system from now on. It is impossible to predict the future (and I haven't even thought about the implications that come from the fact that Sun decided to also release JEE and JME under the GPL, completing the whole Java picture). But it is clear that the future is very bright. It is also clear that we have some commitments to the community, the various projects around GNU Classpath and the users and distros relying on our work. Sun is really trying to do this correctly and by picking their development branch (1.7) for building up the free product and community they showed that they do understand how building a developer community works. this will allow them to incorporate the community input on a product that is still shaping up instead of dumping some source code as a finished product and project. But this also means it will not be all ready at once for our own community for immediate adoption. And even after half a year when all code should be out there it will still take time and effort to adopt. I think our commitment to our community, users and projects is that we should not regress on freedom. We will provide free versions of anything that Sun won't be able to release (yet). We will not regress in coverage. All the platforms, projects and programs that run now with GNU Classpath should run in the future. And we won't regress on having fun innovating and hacking together! Which to me means we should make it easy to adopt and collaborate. We want to make it easy for people to improve together with GNU Classpath and OpenJDK by helping also the small projects with less resources to adopt the new innovation (coordinating new VM and Platform interfaces, etc.) So now the short time roadmap. We are ready for a release of 0.93 this week. We will hopefully branch tomorrow and release by Friday unless some big disaster strikes. There seems general agreement that this will be our last push before going full steam with the 1.5 gene
Re: Mauve regressions 0.92/0.93-pre
Hello again, > - gnu.javax.swing.text.html.parser.support.Parser.Text > - gnu.javax.swing.text.html.parser.support.Parser.textPreProcessor_Test > > Both fail with subtle differences in the result of what gets parsed. is > this caused by the changes on how to handle whitespace? Yeah this is whitespace handling differences. I'm pretty sure that the whitespacehandling is now quite OK and closer to the specs. At least we can parse most whitespace related special constructs much better than before. I'm thinking that we/I should: 1. Add some tests for the official API that tests certain special WS-related constructs and test the actual outcome in the form of the element structure. 2. Remove these classpath-specific tests OR adjust them and move into classpath's testsuite tree. > - java.awt.image.IndexColorModel.getAlpha > Fails with the following stacktrace: > java.lang.ArrayIndexOutOfBoundsException: 99 >at java.awt.image.IndexColorModel.getAlpha(IndexColorModel.java:585) >at > gnu.testlet.java.awt.image.IndexColorModel.getAlpha.test(getAlpha.java:76) >at RunnerProcess.runtest(RunnerProcess.java:360) >at RunnerProcess.runAndReport(RunnerProcess.java:415) >at RunnerProcess.main(RunnerProcess.java:227) Seems like the JDK has some form of mimimum color map size here, where the internal color map is allocated at least 256 bytes, no matter what is specified in the constructor. I am not sure if we need to follow the RI behaviour here. While most color maps are 256 bytes aligned, I think this is not really relevant. At least it is not specified. Should we make the test less pedantic, or should we adjust our impl and the test to behave closer to the RI behaviour (I already have my sources adjusted to that, so that way would be trivial too...) More checks coming tomorrow. /Roman
Re: SystemProperties secure?
> "Roman" == Roman Kennke <[EMAIL PROTECTED]> writes: Roman> We are using the SystemProperties class throughout the Classpath code to Roman> access system properties and avoid the security checks in Roman> java.lang.System. However, I come to think that this is no good the way Roman> it is. This class is public and nothing prevents use of this class from Roman> application code. As I recall things in gnu.classpath should not be available to application code. The system class loader, or something, has to enforce this. I'm having some trouble with the details but I know Jeroen knows the details here... Tom
RE: SystemProperties secure?
Tom Tromey wrote: > > "Roman" == Roman Kennke <[EMAIL PROTECTED]> writes: > > Roman> We are using the SystemProperties class throughout the > Classpath code to > Roman> access system properties and avoid the security checks in > Roman> java.lang.System. However, I come to think that this > is no good the way > Roman> it is. This class is public and nothing prevents use > of this class from > Roman> application code. > > As I recall things in gnu.classpath should not be available to > application code. The system class loader, or something, has to > enforce this. That's correct. The (default) system class loader calls SecurityManager.checkPackageAccess() in loadClass(String,boolean). > I'm having some trouble with the details but I know Jeroen knows the > details here... I don't remember the details of the rest of the story, but earlier in this thread Casey posted a (very small) patch that enables this infrastructure and protects the gnu.classpath. package. Regards, Jeroen
