From ravenex at qq.com Mon Jan 4 03:03:24 2010 From: ravenex at qq.com (=?ISO-8859-1?B?cmF2ZW5leA==?=) Date: Mon, 4 Jan 2010 19:03:24 +0800 Subject: question on class loading behavior on array classes Message-ID: Hi all, Not sure where to ask, not sure if it's a bug or not so I'm seeking for advice here. According the the JVM spec, 2nd edition, 5.3.3 Creating Array Classes, both the bootstrap class loader and user-defined class loaders can load array classes, and the corresponding class loaders involved are recorded as initiating class loaders. But starting from JDK 6, Sun's JDK by default doesn't allow array syntax in ClassLoader.loadClass()/ClassLoader.findSystemClass(); array classes couldn't be created by calling defineClass() anyway, so this effectively bans user-defined class loaders to be initiating class loaders for array classes. Calling Class.forName(className, initialize, classLoader) won't record classLoader as an initiating class loader for an array class either. Is this an intended behavior? I'm expecting a call to Class.forName() would mark the loader as an initiating one, for all classes (including array classes). That way I won't have to keep a cache of my own in my custom class loader to keep track of what's been loaded already. I read Bug 6500212 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212) and know that I shouldn't call ClassLoader.loadClass() with array syntax, so I switched to Class.forName(). But then when my class loader is asked to load the same array class again, it calls findLoadedClass() and gets a null back. That's pretty bad because I don't won't to get down to SystemDictionary::resolve_array_class_or_null() every time I load an array class. That'll force me to use my own cache to record just about the same info as what the VM already has, plus the array classes loaded, which looks like a bad smell to me. Any help would be grateful. Thanks in advance, Raven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100104/31deb892/attachment.html From gnu_andrew at member.fsf.org Mon Jan 4 07:26:59 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 4 Jan 2010 15:26:59 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> Message-ID: <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> 2009/12/25 Andrew John Hughes : > 2009/12/24 Joseph D. Darcy : >> Andrew John Hughes wrote: >>> >>> 2009/12/24 Joseph D. Darcy : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> 2009/11/10 Joseph D. Darcy : >>>>> >>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> 2009/11/7 Joseph D. Darcy : >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Jonathan Gibbons wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2009/11/7 Joseph D. Darcy : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hello. >>>>>>>>>>> >>>>>>>>>>> The latest batch of security fixes have been pushed into OpenJDK >>>>>>>>>>> 6. >>>>>>>>>>> >>>>>>>>>>> Martin and Andrew, you're clear to push your other fixes back. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, I'll get onto that tomorrow or Monday. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now that OpenJDK 6 has the latest security fixes, Andrew's >>>>>>>>>>> backport >>>>>>>>>>> of >>>>>>>>>>> Nimbus, and the new delivery model for jaxp and jaxws, that might >>>>>>>>>>> be >>>>>>>>>>> a >>>>>>>>>>> good >>>>>>>>>>> amount of change to be a new build, b18. >>>>>>>>>>> >>>>>>>>>>> Is there any other work that should go back into b18? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'd like to get a backport of >>>>>>>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/d6b08bdb9a54 in. ?It's a >>>>>>>>>> minor fix that Kelly found that gets rid of the superfluous >>>>>>>>>> -fastdebug >>>>>>>>>> build directory currently being produced by OpenJDK6 builds. >>>>>>>>>> >>>>>>>>>> Otherwise I think it's good to go. >>>>>>>>>> >>>>>>>>>> The list has been silent on the matter, but I discussed hs16 and >>>>>>>>>> OpenJDK6 with Dalibor on IRC and we agreed that it would be better >>>>>>>>>> to >>>>>>>>>> wait until this is more stable before bumping up OpenJDK6 to it. >>>>>>>>>> IcedTea is currently supporting it as a build option, but it isn't >>>>>>>>>> turned on by default. ?One advantage to hs16 going into OpenJDK6 is >>>>>>>>>> that the Zero assembler port changeset which was recently promoted >>>>>>>>>> into b75 could be backported. ?Otherwise, it needs a few things >>>>>>>>>> ripping out to work with hs14 (and then putting back when we do go >>>>>>>>>> to >>>>>>>>>> hs16). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Joe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Joe and I have also discussed the possibility of backporting the >>>>>>>>> JDK7 >>>>>>>>> javac filemanager back to OpenJDK 6, now that we have completed a >>>>>>>>> number >>>>>>>>> of >>>>>>>>> significant bug fixes. ?However, this should now probably wait until >>>>>>>>> after >>>>>>>>> b18. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Yes, I think the javac file manager fixes would be good for b19. >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I've pushed two of the approved fixes: >>>>>>> >>>>>>> JAXWS/JAXP ALT_DROPS_DIR sync: >>>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/53012f905520 >>>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/e69b78c54335 >>>>>>> >>>>>>> fastdebug directory fix: >>>>>>> http://hg.openjdk.java.net/jdk6/jdk6/rev/3307d11b8026 >>>>>>> >>>>>>> but having an issue with jcheck and the X11 fix: >>>>>>> >>>>>>> remote: adding changesets >>>>>>> remote: adding manifests >>>>>>> remote: adding file changes >>>>>>> remote: added 2 changesets with 1 changes to 1 files >>>>>>> remote: >>>>>>> remote: > Changeset: 240:318875d8173c >>>>>>> remote: > Author: ? ?andrew >>>>>>> remote: > Date: ? ? ?2009-11-09 06:17 >>>>>>> remote: > >>>>>>> remote: > 6897844: Fix broken build on newer versions of X11 (libXext >>>>>>> >= >>>>>>> 1.1.0) >>>>>>> remote: > Summary: Recent changes to X11's header structure break the >>>>>>> build >>>>>>> remote: > Reviewed-by: prr, flar >>>>>>> remote: > Contributed-by: Diego Petten? >>>>>>> remote: >>>>>>> remote: Invalid contributor attribution >>>>>>> >>>>>>> Does jcheck not like UTF-8? >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> From a quick look at the source, yes, it seems jcheck only wants ASCII >>>>>> alpha >>>>>> numeric characters for the contributed by names and addresses. >>>>>> >>>>>> In other news on b18, I've done some building and testing on the >>>>>> current >>>>>> repo without the X11 fix above. ?With a different network and graphics >>>>>> configuration than used by my published test results, the results look >>>>>> mostly consist with the new tests usually passing: >>>>>> >>>>>> 0: summary.txt ?pass: 3,118; fail: 26 >>>>>> 1: JTreport/text/summary.txt ?pass: 3,135; fail: 25; error: 2 >>>>>> >>>>>> 0 ? ? ?1 ? ? ?Test >>>>>> --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6741426.java >>>>>> --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6849805.java >>>>>> pass ? fail ? com/sun/jdi/BadHandshakeTest.java >>>>>> fail ? pass ? java/awt/Frame/DynamicLayout/DynamicLayout.java >>>>>> fail ? pass >>>>>> java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java >>>>>> fail ? pass >>>>>> java/awt/Frame/ShownOffScreenOnWin98/ShownOffScreenOnWin98Test.java >>>>>> fail ? pass >>>>>> >>>>>> >>>>>> java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java >>>>>> --- ? ?pass ? java/awt/GraphicsDevice/CloneConfigsTest.java >>>>>> fail ? pass ? java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java >>>>>> fail ? pass ? java/awt/Insets/CombinedTestApp1.java >>>>>> fail ? pass >>>>>> >>>>>> >>>>>> java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html >>>>>> fail ? pass >>>>>> >>>>>> >>>>>> java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html >>>>>> fail ? pass >>>>>> >>>>>> >>>>>> java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html >>>>>> pass ? fail >>>>>> java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java >>>>>> fail ? pass ? java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java >>>>>> pass ? --- ? ?java/awt/Window/AlwaysOnTop/AlwaysOnTopEvenOfWindow.java >>>>>> pass ? fail ? java/awt/Window/GrabSequence/GrabSequence.java >>>>>> fail ? pass ? java/awt/event/KeyEvent/CorrectTime/CorrectTime.java >>>>>> fail ? pass ? java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java >>>>>> pass ? fail ? java/awt/print/PrinterJob/ExceptionTest.java >>>>>> --- ? ?pass ? java/lang/ClassLoader/UninitializedParent.java >>>>>> pass ? fail ? java/net/ipv6tests/TcpTest.java >>>>>> pass ? fail ? java/nio/channels/SocketChannel/AdaptSocket.java >>>>>> pass ? fail ? java/nio/channels/SocketChannel/LocalAddress.java >>>>>> pass ? fail ? java/nio/channels/SocketChannel/Shutdown.java >>>>>> pass ? fail ? java/util/logging/LoggingDeadlock2.java >>>>>> --- ? ?pass ? javax/swing/JButton/6604281/bug6604281.java >>>>>> fail ? pass ? javax/swing/JTextArea/Test6593649.java >>>>>> --- ? ?pass ? javax/swing/Security/6657138/ComponentTest.java >>>>>> --- ? ?pass ? javax/swing/Security/6657138/bug6657138.java >>>>>> --- ? ?pass ? javax/swing/ToolTipManager/Test6657026.java >>>>>> --- ? ?pass ? javax/swing/UIManager/Test6657026.java >>>>>> --- ? ?pass ? javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java >>>>>> --- ? ?pass ? javax/swing/plaf/metal/MetalBorders/Test6657026.java >>>>>> --- ? ?pass ? javax/swing/plaf/metal/MetalBumps/Test6657026.java >>>>>> --- ? ?pass >>>>>> javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java >>>>>> --- ? ?pass ? javax/swing/plaf/metal/MetalSliderUI/Test6657026.java >>>>>> pass ? error ?sun/java2d/OpenGL/GradientPaints.java >>>>>> pass ? fail ? sun/rmi/transport/proxy/EagerHttpFallback.java >>>>>> --- ? ?pass >>>>>> sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java >>>>>> --- ? ?pass >>>>>> >>>>>> >>>>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java >>>>>> --- ? ?pass >>>>>> >>>>>> >>>>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java >>>>>> --- ? ?pass >>>>>> >>>>>> >>>>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java >>>>>> pass ? error >>>>>> ?sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java >>>>>> --- ? ?pass ? sun/security/util/DerValue/BadValue.java >>>>>> >>>>>> 45 differences >>>>>> >>>>>> Those two Nimbus tests fail with compilation errors like this: >>>>>> >>>>>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: package >>>>>> com.sun.java.swing.plaf.nimbus does not exist >>>>>> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: cannot find >>>>>> symbol >>>>>> symbol ?: class NimbusLookAndFeel >>>>>> location: class Test6741426 >>>>>> ? ? UIManager.setLookAndFeel(new NimbusLookAndFeel()); >>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>>> 2 errors >>>>>> >>>>>> >>>>>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:38: package >>>>>> javax.swing.plaf.nimbus does not exist >>>>>> ?static class Minimbus extends >>>>>> javax.swing.plaf.nimbus.NimbusLookAndFeel >>>>>> { >>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:41: cannot find >>>>>> symbol >>>>>> symbol ?: method getDerivedColor(java.awt.Color,java.awt.Color,float) >>>>>> location: class Test6849805.Minimbus >>>>>> ? ? ? ? Color r = getDerivedColor(c1, c2, f); >>>>>> ? ? ? ? ? ? ? ? ? ^ >>>>>> 2 errors >>>>>> >>>>>> >>>>>> In the first case, "com.sun.java.swing" is referred to instead of >>>>>> "com.sun.javax.swing" and in the second case the non-existent on >>>>>> OpenJDK >>>>>> 6 >>>>>> javax.swing...nimbus is referenced. ?Changing both of these to >>>>>> com.sun.javax.swing.plaf.nimbus doesn't cause the code to compile. ?I >>>>>> haven't looked into this very deeply, but ignoring the symbol file >>>>>> doesn't >>>>>> resolve the problem. >>>>>> >>>>>> Since nimbus is going into this build, I'd either like the tests be >>>>>> modified >>>>>> to pass if that is possible or removed if it is infeasible to have them >>>>>> pass. >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> >>>>> Finally had a chance to look at this Nimbus issue, and it appears it >>>>> is the symbol file that's to blame: >>>>> >>>>> $ /home/andrew/build/icedtea6-hg/bin/javac >>>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >>>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: >>>>> package com.sun.java.swing.plaf.nimbus does not exist >>>>> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: >>>>> cannot find symbol >>>>> symbol ?: class NimbusLookAndFeel >>>>> location: class Test6741426 >>>>> ? ? ? UIManager.setLookAndFeel(new NimbusLookAndFeel()); >>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>> 2 errors >>>>> andrew at rivendell /mnt/builder/icedtea6-hg $ >>>>> /home/andrew/build/icedtea6-hg/bin/javac -XDignore.symbol.file=true >>>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >>>>> andrew at rivendell /mnt/builder/icedtea6-hg $ >>>>> >>>>> I guess we need to add com.sun.java.swing.plaf.nimbus to the symbol >>>>> file, but what exactly is the purpose of this in the first place? >>>>> >>>>> >>>> >>>> The symbol file is used to implement a proto module system in JDK 6 so >>>> that >>>> non-JDK programs get used to not being able to access JDK-internal >>>> implementation classes, like most of com.sun.*. ?Since the JDK regression >>>> tests are logically part of the JDK, they are justified in using the >>>> -XDignore.symbol.file=true option to get around the symbol file >>>> restrictions. >>>> >>>> >>> >>> It seems more like a hack which confuses people to me. ?It baffled me >>> just now when I could see the NimbusLookAndFeel class was in rt.jar >>> but javac wouldn't see it. ?Setting bootclasspath explicitly works too >>> so the symbol file clearly only works if you rely on the default >>> bootclasspath. >>> >> >> That is correct; the default bootclasspath must be used. >> >>> I think in reality most people will get annoyed by it and then just >>> set -XDignore.symbol.file=true to make their existing code work. >> >> People weren't "supposed" to know about ?-XDignore.symbol.file=true, but >> word has gotten out. >> >> The old situation was problematic that bad behavior could occur without any >> warning or error from the system. >> >>> I >>> strongly dislike the use of these com.sun classes (they cause huge >>> problems when using non-Sun implementations) but I don't think this >>> helps. ?Sun code is just as much an offender; JAXWS should be >>> independent but relies on com.sun.net.httpserver which is given an >>> opt-out from the symbol scheme in NON_CORE_PKGS.gmk. >>> >>> I thought the idea was to produce a warning, not just make the class >>> appear to be missing? >>> >> >> There are multiple settings of the visibility knob for ct.sym, including not >> there at all. ?Classes added in JDK 6 that are not supposed to be generally >> used are not visible; legacy classes visible in JDK 5 or earlier are visible >> with a warning. >> >>> >>>> >>>> Unless NimbusLookAndFeel should be a publicly usable class in OpenJDK 6, >>>> which I think is unlikely, the right solution here seems to be having the >>>> test use -XDignore.symbol.file=true in its @compile directive. >>>> >>>> >>> >>> The other com.sun.java.swing.plaf packages are excluded (see >>> make/common/Release.gmk in the jdk) and presumably NimbusLookAndFeel >>> needs to be available so it can be selected from code or extended. ?I >>> would expect the tests to be indicative of the use of the code by >>> users in this way. ?Note that it's a public javax.swing.plaf class in >>> 7 so having it blocked in 6 contradicts that. >>> >> >> No it does not; com.sun.com.foo.java.swing.Foo != javax.swing.Foo. >> >>> http://cr.openjdk.java.net/~andrew/nimbus/webrev.04/jdk.patch makes >>> both tests pass. ?Can I have a bug ID to push this? >>> >> >> The com.sun.java.swing package in OpenJDK should have the same effective >> compile-time visibility as in Sun JDK. >> > > I don't know what that is; does this mean > com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? ?I > don't mind either way, it just seems that the other plaf packages are > visible. > >> I'm going to start taking my vacation in earnest now so we can finish >> working through this issue early in 2010. >> >> Happy holidays, >> Happy new year! Any more thoughts on the above? >> -Joe >> >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From jonathan.gibbons at sun.com Tue Jan 5 15:25:36 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 05 Jan 2010 23:25:36 +0000 Subject: hg: jdk6/jdk6/langtools: 6559315: Inconsistent non-standard Sun copyright in src/share/opensource/javac/doc/document.css Message-ID: <20100105232538.34B6142434@hg.openjdk.java.net> Changeset: 31aa8fa19a93 Author: jjg Date: 2010-01-05 15:24 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/31aa8fa19a93 6559315: Inconsistent non-standard Sun copyright in src/share/opensource/javac/doc/document.css Reviewed-by: mcimadamore - src/share/opensource/javac/Makefile - src/share/opensource/javac/README-template.html - src/share/opensource/javac/build.properties - src/share/opensource/javac/build.xml - src/share/opensource/javac/doc/document.css - src/share/opensource/javac/doc/javac_lifecycle/Context.html - src/share/opensource/javac/doc/javac_lifecycle/Enter.html - src/share/opensource/javac/doc/javac_lifecycle/JavaCompiler.html - src/share/opensource/javac/doc/javac_lifecycle/Main.html - src/share/opensource/javac/doc/javac_lifecycle/ToDo.html - src/share/opensource/javac/doc/javac_lifecycle/contents.html - src/share/opensource/javac/doc/javac_lifecycle/index.html - src/share/opensource/javac/doc/javac_lifecycle/packages.html - src/share/opensource/javac/doc/javac_lifecycle/style.css - src/share/opensource/javac/nbproject/project.xml - src/share/opensource/javac/src/bin/javac.sh From jonathan.gibbons at sun.com Wed Jan 6 13:16:14 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 06 Jan 2010 21:16:14 +0000 Subject: hg: jdk6/jdk6/langtools: 6855236: Compiler Tree API TreePath class generates NullPointerException from Iterator Message-ID: <20100106211617.43E8D42597@hg.openjdk.java.net> Changeset: 536fbf4fba1f Author: jjg Date: 2010-01-06 13:15 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/536fbf4fba1f 6855236: Compiler Tree API TreePath class generates NullPointerException from Iterator Reviewed-by: darcy ! src/share/classes/com/sun/source/util/TreePath.java + test/tools/javac/T6855236.java From Joe.Darcy at Sun.COM Wed Jan 6 14:53:52 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 06 Jan 2010 14:53:52 -0800 Subject: question on class loading behavior on array classes In-Reply-To: References: Message-ID: <4B451480.7000805@sun.com> ravenex wrote: > Hi all, > > Not sure where to ask, not sure if it's a bug or not so I'm seeking > for advice here. > > According the the JVM spec, 2nd edition, 5.3.3 Creating Array Classes, > both the bootstrap class loader and user-defined class loaders can > load array classes, and the corresponding class loaders involved are > recorded as initiating class loaders. > > But starting from JDK 6, Sun's JDK by default doesn't allow array > syntax in ClassLoader.loadClass()/ClassLoader.findSystemClass(); array > classes couldn't be created by calling defineClass() anyway, so this > effectively bans user-defined class loaders to be initiating class > loaders for array classes. Calling Class.forName(className, > initialize, classLoader) won't record classLoader as an initiating > class loader for an array class either. > > Is this an intended behavior? > > I'm expecting a call to Class.forName() would mark the loader as an > initiating one, for all classes (including array classes). That way I > won't have to keep a cache of my own in my custom class loader to keep > track of what's been loaded already. I read Bug 6500212 > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212) and know > that I shouldn't call ClassLoader.loadClass() with array syntax, so I > switched to Class.forName(). But then when my class loader is asked to > load the same array class again, it calls findLoadedClass() and gets a > null back. That's pretty bad because I don't won't to get down to > SystemDictionary::resolve_array_class_or_null() every time I load an > array class. That'll force me to use my own cache to record just about > the same info as what the VM already has, plus the array classes > loaded, which looks like a bad smell to me. Hello. As noted in bug 6500212, the ban on allowing array syntax (bug 4976356) was intentional. As this class loading issue is not specific to OpenJDK 6, I suggest inquiring on the core-libs-dev at openjdk.java.net alias. Regards, -Joe From ravenex at qq.com Wed Jan 6 18:45:41 2010 From: ravenex at qq.com (=?ISO-8859-1?B?cmF2ZW5leA==?=) Date: Thu, 7 Jan 2010 10:45:41 +0800 Subject: question on class loading behavior on array classes Message-ID: Hi Joe, All right, I'll try core-libs-dev. Thank you! Regards, Raven > ------------------ Original ------------------ > From: "Joseph D. Darcy"; > Date: Thu, Jan 7, 2010 06:53 AM > To: "ravenex"; > Cc: "jdk6-dev"; > Subject: Re: question on class loading behavior on array classes > > Hello. > > As noted in bug 6500212, the ban on allowing array syntax (bug 4976356) > was intentional. As this class loading issue is not specific to OpenJDK > 6, I suggest inquiring on the core-libs-dev at openjdk.java.net alias. > > Regards, > > -Joe From Joe.Darcy at Sun.COM Wed Jan 6 19:27:11 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 06 Jan 2010 19:27:11 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> Message-ID: <4B45548F.9040500@sun.com> Andrew John Hughes wrote: > 2009/12/25 Andrew John Hughes : > >> 2009/12/24 Joseph D. Darcy : >> >>> Andrew John Hughes wrote: >>> [big snip] >>> The com.sun.java.swing package in OpenJDK should have the same effective >>> compile-time visibility as in Sun JDK. >>> >>> >> I don't know what that is; does this mean >> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? I >> don't mind either way, it just seems that the other plaf packages are >> visible. >> >> >>> I'm going to start taking my vacation in earnest now so we can finish >>> working through this issue early in 2010. >>> >>> Happy holidays, >>> >>> > > Happy new year! Any more thoughts on the above? > > Yes, easing back from vacation and donning my fedora and bullwhip, I've dug into what is going on here. In brief, make/common/Release.gmk has a list of packages to exclude from the ct.sym warning (6476749: "Exclude Swing plaf classes from Sun Proprietary warning"); from http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk # The compiler should not issue a "Sun Propietary" warning when compiling # classes in the com.sun.java.swing.plaf packages, since we've always # allowed, and even advocated, extending them (see bug 6476749). # # This approach is NOT to be used as a general purpose way to avoid such # compiler warnings for non-core packages. The correct way is to document # the packages in NON_CORE_PKGS.gmk, and include them in the NON_CORE_PKGS # definition. # # Swing has taken this approach only as a temporary measure to avoid # the compiler warnings until we can properly document these packages. # This is covered under 6491853. EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf \ com.sun.java.swing.plaf.windows \ com.sun.java.swing.plaf.motif \ com.sun.java.swing.plaf.gtk In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on that package list. Therefore, the test file in question compiles without warning using Sun's 6 update release. The corresponding addition to this list has *not* been made in JDK 7, which is probably just an oversight. I'd support com.sun.java.swing.plaf.nimbus being included in this list in OpenJDK 6 as long as * The API of the package is the same as in Sun's 6 update release * Kelly reviews the situation for any other build implications In the 6 update train, the nimbus package was added to the list under bug id 6616742, but for OpenJDK 6 I think we should use a fresh bug id if this goes back. Happy new year, -Joe From gnu_andrew at member.fsf.org Thu Jan 7 03:18:13 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 7 Jan 2010 11:18:13 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B45548F.9040500@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> Message-ID: <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> 2010/1/7 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/25 Andrew John Hughes : >> >>> >>> 2009/12/24 Joseph D. Darcy : >>> >>>> >>>> Andrew John Hughes wrote: >>>> > > [big snip] >>>> >>>> The com.sun.java.swing package in OpenJDK should have the same effective >>>> compile-time visibility as in Sun JDK. >>>> >>>> >>> >>> I don't know what that is; does this mean >>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? ?I >>> don't mind either way, it just seems that the other plaf packages are >>> visible. >>> >>> >>>> >>>> I'm going to start taking my vacation in earnest now so we can finish >>>> working through this issue early in 2010. >>>> >>>> Happy holidays, >>>> >>>> >> >> Happy new year! ?Any more thoughts on the above? >> >> > > Yes, easing back from vacation and donning my fedora and bullwhip, I've dug > into what is going on here. > > In brief, make/common/Release.gmk has a list of packages to exclude from the > ct.sym warning (6476749: "Exclude Swing plaf classes from Sun Proprietary > warning"); from > http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk > > # The compiler should not issue a "Sun Propietary" warning when compiling > # classes in the com.sun.java.swing.plaf packages, since we've always > # allowed, and even advocated, extending them (see bug 6476749). > # > # This approach is NOT to be used as a general purpose way to avoid such > # compiler warnings for non-core packages. The correct way is to document > # the packages in NON_CORE_PKGS.gmk, and include them in the NON_CORE_PKGS > # definition. > # > # Swing has taken this approach only as a temporary measure to avoid > # the compiler warnings until we can properly document these packages. > # This is covered under 6491853. > EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf ? ? ? ? ?\ > ? ? ? ? ? ? ? ? ? ? ? com.sun.java.swing.plaf.windows ?\ > ? ? ? ? ? ? ? ? ? ? ? com.sun.java.swing.plaf.motif ? ?\ > ? ? ? ? ? ? ? ? ? ? ? com.sun.java.swing.plaf.gtk > > In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on that > package list. ?Therefore, the test file in question compiles without warning > using Sun's 6 update release. ?The corresponding addition to this list has > *not* been made in JDK 7, which is probably just an oversight. > In 7, it's now a standard API javax.swing.plaf.nimbus. So you'll find it listed in make/docs/CORE_PKGS.gmk instead: javax.swing.plaf.basic \ javax.swing.plaf.metal \ javax.swing.plaf.multi \ javax.swing.plaf.nimbus \ javax.swing.plaf.synth \ > I'd support com.sun.java.swing.plaf.nimbus being included in this list in > OpenJDK 6 as long as > > * The API of the package is the same as in Sun's 6 update release We have no way of verifying what's in the 6 update release as it is proprietary software. The Nimbus code in OpenJDK6 is a backport of what's in 7, moved back to the com.sun.java.swing.plaf.nimbus namespace wihich I believe was used in the proprietary 6 update train. Remember that this is an open-source project; regardless of whether arbitrary bits of code are made invisible or not in a unpatched build of OpenJDK6, anyone can easily read the code and even rip the ct.sym hack right back out again. Additionally, not doing this would make OpenJDK6 different from the proprietary release -- as you mention above, it doesn't mask this package. > * Kelly reviews the situation for any other build implications > > In the 6 update train, the nimbus package was added to the list under bug id > 6616742, but for OpenJDK 6 I think we should use a fresh bug id if this goes > back. Yes, please allocate one. > > Happy new year, > > -Joe > Happy new year, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Thu Jan 7 15:20:45 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 7 Jan 2010 23:20:45 +0000 Subject: Need reviewer - minor top level make changes In-Reply-To: <4B46595C.702@sun.com> References: <4B048AB9.3050106@sun.com> <17c6771e0912210845j67e7e836g25dbea264bb9c88@mail.gmail.com> <4B325D54.5080009@sun.com> <17c6771e0912231037v7a46950cr113f42ece1fa72fc@mail.gmail.com> <17c6771e1001070856t40b79408i94b32f8bb7d3506b@mail.gmail.com> <4B4626DC.9010705@sun.com> <17c6771e1001071253l3fa0da04wbb07a85b66eb8aaf@mail.gmail.com> <4B46570B.7050501@sun.com> <4B46595C.702@sun.com> Message-ID: <17c6771e1001071520w40b7e22dh762f593c925c2230@mail.gmail.com> 2010/1/7 Tim Bell : > > Andrew John Hughes wrote: >>> Is it tl or build for this one? >> > > Kelly O'Hair wrote: >> >> Either one should be fine. Whatever is easier for you. >> Not sure what the tl schedule is right now. > > I expect to push TL to master tomorrow afternoon (8 January) for b79. > > If you don't mind waiting for b81, feel free to push to TL when ready. > > Otherwise, push to build where it still has a chance to make b79. > > Tim ?(Tools/Libraries/Serviceability/JMX/Security/Networking gatekeeper) > Pushed to build: http://hg.openjdk.java.net/jdk7/build/rev/432cbbdc44bc Joe, can we apply the equivalent patch to OpenJDK6 as well? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Jan 7 16:39:47 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 07 Jan 2010 16:39:47 -0800 Subject: Need reviewer - minor top level make changes In-Reply-To: <17c6771e1001071520w40b7e22dh762f593c925c2230@mail.gmail.com> References: <4B048AB9.3050106@sun.com> <17c6771e0912210845j67e7e836g25dbea264bb9c88@mail.gmail.com> <4B325D54.5080009@sun.com> <17c6771e0912231037v7a46950cr113f42ece1fa72fc@mail.gmail.com> <17c6771e1001070856t40b79408i94b32f8bb7d3506b@mail.gmail.com> <4B4626DC.9010705@sun.com> <17c6771e1001071253l3fa0da04wbb07a85b66eb8aaf@mail.gmail.com> <4B46570B.7050501@sun.com> <4B46595C.702@sun.com> <17c6771e1001071520w40b7e22dh762f593c925c2230@mail.gmail.com> Message-ID: <4B467ED3.3010507@sun.com> Andrew John Hughes wrote: > 2010/1/7 Tim Bell : > >> Andrew John Hughes wrote: >> >>>> Is it tl or build for this one? >>>> >> Kelly O'Hair wrote: >> >>> Either one should be fine. Whatever is easier for you. >>> Not sure what the tl schedule is right now. >>> >> I expect to push TL to master tomorrow afternoon (8 January) for b79. >> >> If you don't mind waiting for b81, feel free to push to TL when ready. >> >> Otherwise, push to build where it still has a chance to make b79. >> >> Tim (Tools/Libraries/Serviceability/JMX/Security/Networking gatekeeper) >> >> > > Pushed to build: http://hg.openjdk.java.net/jdk7/build/rev/432cbbdc44bc > > Joe, can we apply the equivalent patch to OpenJDK6 as well? > > > Sure; approved to push to OpenJDK 6 too. -Joe From Joe.Darcy at Sun.COM Thu Jan 7 19:27:58 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 07 Jan 2010 19:27:58 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> Message-ID: <4B46A63E.3050600@sun.com> Andrew John Hughes wrote: > 2010/1/7 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/25 Andrew John Hughes : >>> >>> >>>> 2009/12/24 Joseph D. Darcy : >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >> [big snip] >> >>>>> The com.sun.java.swing package in OpenJDK should have the same effective >>>>> compile-time visibility as in Sun JDK. >>>>> >>>>> >>>>> >>>> I don't know what that is; does this mean >>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? I >>>> don't mind either way, it just seems that the other plaf packages are >>>> visible. >>>> >>>> >>>> >>>>> I'm going to start taking my vacation in earnest now so we can finish >>>>> working through this issue early in 2010. >>>>> >>>>> Happy holidays, >>>>> >>>>> >>>>> >>> Happy new year! Any more thoughts on the above? >>> >>> >>> >> Yes, easing back from vacation and donning my fedora and bullwhip, I've dug >> into what is going on here. >> >> In brief, make/common/Release.gmk has a list of packages to exclude from the >> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun Proprietary >> warning"); from >> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >> >> # The compiler should not issue a "Sun Propietary" warning when compiling >> # classes in the com.sun.java.swing.plaf packages, since we've always >> # allowed, and even advocated, extending them (see bug 6476749). >> # >> # This approach is NOT to be used as a general purpose way to avoid such >> # compiler warnings for non-core packages. The correct way is to document >> # the packages in NON_CORE_PKGS.gmk, and include them in the NON_CORE_PKGS >> # definition. >> # >> # Swing has taken this approach only as a temporary measure to avoid >> # the compiler warnings until we can properly document these packages. >> # This is covered under 6491853. >> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf \ >> com.sun.java.swing.plaf.windows \ >> com.sun.java.swing.plaf.motif \ >> com.sun.java.swing.plaf.gtk >> >> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on that >> package list. Therefore, the test file in question compiles without warning >> using Sun's 6 update release. The corresponding addition to this list has >> *not* been made in JDK 7, which is probably just an oversight. >> >> > > In 7, it's now a standard API javax.swing.plaf.nimbus. So you'll find > it listed in make/docs/CORE_PKGS.gmk instead: > Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. > javax.swing.plaf.basic \ > javax.swing.plaf.metal \ > javax.swing.plaf.multi \ > javax.swing.plaf.nimbus \ > javax.swing.plaf.synth \ > However, javax.swing.plaf.nimbus being a core package in JDK 7 has no direct bearing how com.sun.java.swing.plaf.nimbus should be regarding in either OpenJDK 6 or the 6 update release. Generally, the "exported external" APIs in the JDK are in the java.* and javax.* namespaces. These are the APIs that everyone is supposed to call, etc. Nearly all of the sun.* and com.sun.* API are not in this category; rather they are only intended to be used by a restricted set of parties, such as the JDK implementation. The Swing packages listed in EXCLUDE_PROPWARN_PKGS are an exception to this rule. The ct.sym feature is a compile-time proto module system to add an enforcement mechanism to this long-standing API policy. >> I'd support com.sun.java.swing.plaf.nimbus being included in this list in >> OpenJDK 6 as long as >> >> * The API of the package is the same as in Sun's 6 update release >> > > We have no way of verifying what's in the 6 update release as it is > proprietary software. After hacking together a small annotation processor, I will send the source for the processor and a list of the signatures of the methods and constructors of the types in the Nimbus package in the 6 update train. > The Nimbus code in OpenJDK6 is a backport of > what's in 7, moved back to the com.sun.java.swing.plaf.nimbus > namespace wihich I believe was used in the proprietary 6 update train. > > Remember that this is an open-source project; regardless of whether > arbitrary bits of code are made invisible or not in a unpatched build > of OpenJDK6, anyone can easily read the code and even rip the ct.sym > hack right back out again. Just because something is technically feasible does not mean it is advisable. Many technically possible changes are not done so that various other goals can be met, such as following the Java SE 6 specification, etc. If one takes steps to circumvent ct.sym or other enforcement mechanism, it is clear who should be responsible for any adverse consequences. For example, if someone circumvents ct.sym and then a type being accessed is changed in a subsequent release, that is a "close not a bug" situation. > Additionally, not doing this would make > OpenJDK6 different from the proprietary release -- as you mention > above, it doesn't mask this package. > Because the proprietary release does not unmask this package, if OpenJDK 6 also unmasks this package, IMO it is important that the OpenJDK 6 API match the API exposed in the proprietary release. -Joe From gnu_andrew at member.fsf.org Fri Jan 8 05:09:20 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 8 Jan 2010 13:09:20 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B46A63E.3050600@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> Message-ID: <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> 2010/1/8 Joe Darcy : > Andrew John Hughes wrote: >> >> 2010/1/7 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/12/25 Andrew John Hughes : >>>> >>>> >>>>> >>>>> 2009/12/24 Joseph D. Darcy : >>>>> >>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>> >>> [big snip] >>> >>>>>> >>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>> effective >>>>>> compile-time visibility as in Sun JDK. >>>>>> >>>>>> >>>>>> >>>>> >>>>> I don't know what that is; does this mean >>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? ?I >>>>> don't mind either way, it just seems that the other plaf packages are >>>>> visible. >>>>> >>>>> >>>>> >>>>>> >>>>>> I'm going to start taking my vacation in earnest now so we can finish >>>>>> working through this issue early in 2010. >>>>>> >>>>>> Happy holidays, >>>>>> >>>>>> >>>>>> >>>> >>>> Happy new year! ?Any more thoughts on the above? >>>> >>>> >>>> >>> >>> Yes, easing back from vacation and donning my fedora and bullwhip, I've >>> dug >>> into what is going on here. >>> >>> In brief, make/common/Release.gmk has a list of packages to exclude from >>> the >>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun Proprietary >>> warning"); from >>> >>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>> >>> # The compiler should not issue a "Sun Propietary" warning when compiling >>> # classes in the com.sun.java.swing.plaf packages, since we've always >>> # allowed, and even advocated, extending them (see bug 6476749). >>> # >>> # This approach is NOT to be used as a general purpose way to avoid such >>> # compiler warnings for non-core packages. The correct way is to document >>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>> NON_CORE_PKGS >>> # definition. >>> # >>> # Swing has taken this approach only as a temporary measure to avoid >>> # the compiler warnings until we can properly document these packages. >>> # This is covered under 6491853. >>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf ? ? ? ? ?\ >>> ? ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.windows ?\ >>> ? ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.motif ? ?\ >>> ? ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.gtk >>> >>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on >>> that >>> package list. ?Therefore, the test file in question compiles without >>> warning >>> using Sun's 6 update release. ?The corresponding addition to this list >>> has >>> *not* been made in JDK 7, which is probably just an oversight. >>> >>> >> >> In 7, it's now a standard API javax.swing.plaf.nimbus. ?So you'll find >> it listed in make/docs/CORE_PKGS.gmk instead: >> > > Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. > >> ?javax.swing.plaf.basic ? ? ? ? ? ? ? ? ? ? ? ? \ >> ?javax.swing.plaf.metal ? ? ? ? ? ? ? ? ? ? ? ? \ >> ?javax.swing.plaf.multi ? ? ? ? ? ? ? ? ? ? ? ? \ >> ?javax.swing.plaf.nimbus ? ? ? ? ? ? ? ? ? ? ? ?\ >> ?javax.swing.plaf.synth ? ? ? ? ? ? ? ? ? ? ? ? \ >> > > However, javax.swing.plaf.nimbus being a core package in JDK 7 has no direct > bearing how com.sun.java.swing.plaf.nimbus should be regarding in either > OpenJDK 6 or the 6 update release. > > Generally, the "exported external" APIs in the JDK are in the java.* and > javax.* namespaces. ?These are the APIs that everyone is supposed to call, > etc. ?Nearly all of the sun.* and com.sun.* API are not in this category; > rather they are only intended to be used by a restricted set of parties, > such as the JDK implementation. ?The Swing packages listed in > EXCLUDE_PROPWARN_PKGS are an exception to this rule. > > The ct.sym feature is a compile-time proto module system to add an > enforcement mechanism to this long-standing API policy. > Indeed. I wasn't saying that it should be treated the same. I was responding to your point that com.sun.java.swing.plaf.nimbus was not added to the exclusion list in OpenJDK7 i.e. it obviously hasn't because the package no longer exists in 7 and had to be recreated from 6. >>> I'd support com.sun.java.swing.plaf.nimbus being included in this list in >>> OpenJDK 6 as long as >>> >>> * The API of the package is the same as in Sun's 6 update release >>> >> >> We have no way of verifying what's in the 6 update release as it is >> proprietary software. > > After hacking together a small annotation processor, I will send the source > for the processor and a list of the signatures of the methods and > constructors of the types in the Nimbus package in the 6 update train. > But what do we do if they don't match? Are we supposed to start recreating missing methods from the proprietary 6 code when we have no idea how they function? The code from 7 is all we have. >> ?The Nimbus code in OpenJDK6 is a backport of >> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >> namespace wihich I believe was used in the proprietary 6 update train. >> >> Remember that this is an open-source project; regardless of whether >> arbitrary bits of code are made invisible or not in a unpatched build >> of OpenJDK6, anyone can easily read the code and even rip the ct.sym >> hack right back out again. > > Just because something is technically feasible does not mean it is > advisable. ?Many technically possible changes are not done so that various > other goals can be met, such as following the Java SE 6 specification, etc. > > If one takes steps to circumvent ct.sym or other enforcement mechanism, it > is clear who should be responsible for any adverse consequences. ?For > example, if someone circumvents ct.sym and then a type being accessed is > changed in a subsequent release, that is a "close not a bug" situation. > I didn't say it was advisable. I'm just pointing out that it was a weak solution to begin with, and even weaker now that people can study and alter the source code rather than just having a binary blob to work with. I'm a fan of warning about the use of this code so it's visibly a bug and something that should be fixed. I also think it's perfectly legitimately to close bugs that refer to code that's not part of the public API (though Sun don't produce OpenJDK6 binaries anyway). Plenty of other open source projects do that without actively trying to stop people using it in the first place. I don't like the idea of code appearing to disappear as it just causes confusion, usually for end users who don't work on the code itself. It also impacts debugging, see Andrew Haley's blog on trying to track down an issue in javac: http://andrew-haley.livejournal.com/ The very fact that you term it 'an enforcement mechanism' suggests treating developers as potential criminals rather than as equals. >> ?Additionally, not doing this would make >> OpenJDK6 different from the proprietary release -- as you mention >> above, it doesn't mask this package. >> > > Because the proprietary release does not unmask this package, if OpenJDK 6 > also unmasks this package, IMO it is important that the OpenJDK 6 API match > the API exposed in the proprietary release. > I'm confused here -- does the proprietary JDK6 make this package visible or not? You seemed to be saying earlier that it did and your idea of checking what the API is using an annotation processor also suggests this. I agree it's important they match. I just don't see what we can do if they don't. > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Fri Jan 8 08:32:02 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 8 Jan 2010 16:32:02 +0000 Subject: Request for Review: 6915313 In-Reply-To: <4B475C9B.5050207@Sun.COM> References: <4B475C9B.5050207@Sun.COM> Message-ID: <17c6771e1001080832s7e794de9id6bb3e96636e06f5@mail.gmail.com> 2010/1/8 Christopher Hegarty - Sun Microsystems Ireland : > Hi, > > We have received several requests about porting the SCTP API to JDK6. This > bug aims to amend the current implementation to minimize the amount of > changes required to port it to JDK6. > > 1) Remove JDK7 API dependences from the implementation > 2) provide all native functionality within libsctp.so > > 6915313: (sctp) Reorganize implementation to make it more feasible to port > to JDK6 > > Webrev: > ?http://cr.openjdk.java.net/~chegar/6915313/webrev.0/webrev/ > > Thanks, > -Chris. > For OpenJDK6, I think it would be better to port over SCTP after the b18 release which is currently undergoing final testing. So please don't push anything to the OpenJDK6 repositories just yet :-) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christopher.Hegarty at Sun.COM Fri Jan 8 08:38:21 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 08 Jan 2010 16:38:21 +0000 Subject: Request for Review: 6915313 In-Reply-To: <17c6771e1001080832s7e794de9id6bb3e96636e06f5@mail.gmail.com> References: <4B475C9B.5050207@Sun.COM> <17c6771e1001080832s7e794de9id6bb3e96636e06f5@mail.gmail.com> Message-ID: <4B475F7D.7040401@Sun.COM> On 08/01/2010 16:32, Andrew John Hughes wrote: > .... > > For OpenJDK6, I think it would be better to port over SCTP after the > b18 release which is currently undergoing final testing. So please > don't push anything to the OpenJDK6 repositories just yet :-) Oh, maybe the bug description is a little misleading. What this bug plans to do is simply reorganize the SCTP implementation in JDK7 so that it can be ripped out and bolted onto a standard Sun JDK6 (if that's the kind of thing you like to do!). There are no changes planned for OpenJDK6, just JDK7. -Chris. From Joe.Darcy at Sun.COM Fri Jan 8 10:07:43 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 08 Jan 2010 10:07:43 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> Message-ID: <4B47746F.7070305@sun.com> Andrew John Hughes wrote: > 2010/1/8 Joe Darcy : > >> Andrew John Hughes wrote: >> >>> 2010/1/7 Joseph D. Darcy : >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> 2009/12/25 Andrew John Hughes : >>>>> >>>>> >>>>> >>>>>> 2009/12/24 Joseph D. Darcy : >>>>>> >>>>>> >>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>> >>>> [big snip] >>>> >>>> >>>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>>> effective >>>>>>> compile-time visibility as in Sun JDK. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I don't know what that is; does this mean >>>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? I >>>>>> don't mind either way, it just seems that the other plaf packages are >>>>>> visible. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I'm going to start taking my vacation in earnest now so we can finish >>>>>>> working through this issue early in 2010. >>>>>>> >>>>>>> Happy holidays, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> Happy new year! Any more thoughts on the above? >>>>> >>>>> >>>>> >>>>> >>>> Yes, easing back from vacation and donning my fedora and bullwhip, I've >>>> dug >>>> into what is going on here. >>>> >>>> In brief, make/common/Release.gmk has a list of packages to exclude from >>>> the >>>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun Proprietary >>>> warning"); from >>>> >>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>>> >>>> # The compiler should not issue a "Sun Propietary" warning when compiling >>>> # classes in the com.sun.java.swing.plaf packages, since we've always >>>> # allowed, and even advocated, extending them (see bug 6476749). >>>> # >>>> # This approach is NOT to be used as a general purpose way to avoid such >>>> # compiler warnings for non-core packages. The correct way is to document >>>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>>> NON_CORE_PKGS >>>> # definition. >>>> # >>>> # Swing has taken this approach only as a temporary measure to avoid >>>> # the compiler warnings until we can properly document these packages. >>>> # This is covered under 6491853. >>>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf \ >>>> com.sun.java.swing.plaf.windows \ >>>> com.sun.java.swing.plaf.motif \ >>>> com.sun.java.swing.plaf.gtk >>>> >>>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on >>>> that >>>> package list. Therefore, the test file in question compiles without >>>> warning >>>> using Sun's 6 update release. The corresponding addition to this list >>>> has >>>> *not* been made in JDK 7, which is probably just an oversight. >>>> >>>> >>>> >>> In 7, it's now a standard API javax.swing.plaf.nimbus. So you'll find >>> it listed in make/docs/CORE_PKGS.gmk instead: >>> >>> >> Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. >> >> >>> javax.swing.plaf.basic \ >>> javax.swing.plaf.metal \ >>> javax.swing.plaf.multi \ >>> javax.swing.plaf.nimbus \ >>> javax.swing.plaf.synth \ >>> >>> >> However, javax.swing.plaf.nimbus being a core package in JDK 7 has no direct >> bearing how com.sun.java.swing.plaf.nimbus should be regarding in either >> OpenJDK 6 or the 6 update release. >> >> Generally, the "exported external" APIs in the JDK are in the java.* and >> javax.* namespaces. These are the APIs that everyone is supposed to call, >> etc. Nearly all of the sun.* and com.sun.* API are not in this category; >> rather they are only intended to be used by a restricted set of parties, >> such as the JDK implementation. The Swing packages listed in >> EXCLUDE_PROPWARN_PKGS are an exception to this rule. >> >> The ct.sym feature is a compile-time proto module system to add an >> enforcement mechanism to this long-standing API policy. >> >> > > Indeed. I wasn't saying that it should be treated the same. I was > responding to your point that com.sun.java.swing.plaf.nimbus was not > added to the exclusion list in OpenJDK7 i.e. it obviously hasn't > because the package no longer exists in 7 and had to be recreated from > 6. > > >>>> I'd support com.sun.java.swing.plaf.nimbus being included in this list in >>>> OpenJDK 6 as long as >>>> >>>> * The API of the package is the same as in Sun's 6 update release >>>> >>>> >>> We have no way of verifying what's in the 6 update release as it is >>> proprietary software. >>> >> After hacking together a small annotation processor, I will send the source >> for the processor and a list of the signatures of the methods and >> constructors of the types in the Nimbus package in the 6 update train. >> >> > > But what do we do if they don't match? Are we supposed to start > recreating missing methods from the proprietary 6 code when we have no > idea how they function? > The code from 7 is all we have. > We can evaluate the difference once we see them. Options include not exposing the com.sun package in OpenJDK 6 and implementing any missing functionality or everything might match and they'll be nothing to do :-) >>> The Nimbus code in OpenJDK6 is a backport of >>> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >>> namespace wihich I believe was used in the proprietary 6 update train. >>> >>> Remember that this is an open-source project; regardless of whether >>> arbitrary bits of code are made invisible or not in a unpatched build >>> of OpenJDK6, anyone can easily read the code and even rip the ct.sym >>> hack right back out again. >>> >> Just because something is technically feasible does not mean it is >> advisable. Many technically possible changes are not done so that various >> other goals can be met, such as following the Java SE 6 specification, etc. >> >> If one takes steps to circumvent ct.sym or other enforcement mechanism, it >> is clear who should be responsible for any adverse consequences. For >> example, if someone circumvents ct.sym and then a type being accessed is >> changed in a subsequent release, that is a "close not a bug" situation. >> >> > > I didn't say it was advisable. I'm just pointing out that it was a > weak solution to begin with, and even weaker now that people can study > and alter the source code rather than just having a binary blob to > work with. > Stronger mechanisms are planned for JDK internal implementation classes new in JDK 7 where backwards compatibility is not a concern. > I'm a fan of warning about the use of this code so it's visibly a bug > and something that should be fixed. I also think it's perfectly > legitimately to close bugs that refer to code that's not part of the > public API (though Sun don't produce OpenJDK6 binaries anyway). > Plenty of other open source projects do that without actively trying > to stop people using it in the first place. > > I don't like the idea of code appearing to disappear as it just causes > confusion, usually for end users who don't work on the code itself. > It also impacts debugging, see Andrew Haley's blog on trying to track > down an issue in javac: http://andrew-haley.livejournal.com/ The very > fact that you term it 'an enforcement mechanism' suggests treating > developers as potential criminals rather than as equals. > There are many enforcement mechanism in the Java platform. The class file verifier. The type checker in javac. The applet sandbox. The security model. No criminality need be inferred. >>> Additionally, not doing this would make >>> OpenJDK6 different from the proprietary release -- as you mention >>> above, it doesn't mask this package. >>> >>> >> Because the proprietary release does not unmask this package, if OpenJDK 6 >> also unmasks this package, IMO it is important that the OpenJDK 6 API match >> the API exposed in the proprietary release. >> >> > > I'm confused here -- does the proprietary JDK6 make this package > visible or not? The com.sun.* nimbus package is visible in the proprietary JDK6 starting (I assume) in 6u10 when Nimbus was added; it is visible in 6u17 where I was able to successfully compile your test program. > You seemed to be saying earlier that it did and your > idea of checking what the API is using an annotation processor also > suggests this. > Correct. > I agree it's important they match. I just don't see what we can do if > they don't. > Let's see how far the two packages are from an alpha rename and evaluate our options. -Joe From ahughes at redhat.com Fri Jan 8 10:29:01 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 08 Jan 2010 18:29:01 +0000 Subject: hg: jdk6/jdk6: 6914986: Make sure openjdk doc generation not turned off with JDK_UPDATE_VERSION Message-ID: <20100108182902.611A74287E@hg.openjdk.java.net> Changeset: 87ed6cf2fb89 Author: andrew Date: 2010-01-08 18:28 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/87ed6cf2fb89 6914986: Make sure openjdk doc generation not turned off with JDK_UPDATE_VERSION Summary: Only turn off documentation for updates when not building OpenJDK Reviewed-by: ohair, darcy ! make/jdk-rules.gmk From gnu_andrew at member.fsf.org Fri Jan 8 10:33:21 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 8 Jan 2010 18:33:21 +0000 Subject: Need reviewer - minor top level make changes In-Reply-To: <4B467ED3.3010507@sun.com> References: <4B048AB9.3050106@sun.com> <4B325D54.5080009@sun.com> <17c6771e0912231037v7a46950cr113f42ece1fa72fc@mail.gmail.com> <17c6771e1001070856t40b79408i94b32f8bb7d3506b@mail.gmail.com> <4B4626DC.9010705@sun.com> <17c6771e1001071253l3fa0da04wbb07a85b66eb8aaf@mail.gmail.com> <4B46570B.7050501@sun.com> <4B46595C.702@sun.com> <17c6771e1001071520w40b7e22dh762f593c925c2230@mail.gmail.com> <4B467ED3.3010507@sun.com> Message-ID: <17c6771e1001081033h36dc7b3iae16f1e5ca742c08@mail.gmail.com> 2010/1/8 Joe Darcy : > Andrew John Hughes wrote: >> >> 2010/1/7 Tim Bell : >> >>> >>> Andrew John Hughes wrote: >>> >>>>> >>>>> Is it tl or build for this one? >>>>> >>> >>> Kelly O'Hair wrote: >>> >>>> >>>> Either one should be fine. Whatever is easier for you. >>>> Not sure what the tl schedule is right now. >>>> >>> >>> I expect to push TL to master tomorrow afternoon (8 January) for b79. >>> >>> If you don't mind waiting for b81, feel free to push to TL when ready. >>> >>> Otherwise, push to build where it still has a chance to make b79. >>> >>> Tim ?(Tools/Libraries/Serviceability/JMX/Security/Networking gatekeeper) >>> >>> >> >> Pushed to build: http://hg.openjdk.java.net/jdk7/build/rev/432cbbdc44bc >> >> Joe, can we apply the equivalent patch to OpenJDK6 as well? >> >> >> > > Sure; approved to push to OpenJDK 6 too. > > -Joe > > Thanks Joe. Pushed: http://hg.openjdk.java.net/jdk6/jdk6/rev/87ed6cf2fb89 -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Mon Jan 11 13:07:33 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 11 Jan 2010 13:07:33 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B47746F.7070305@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> <4B47746F.7070305@sun.com> Message-ID: <4B4B9315.2050401@sun.com> Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> 2010/1/8 Joe Darcy : >> >>> Andrew John Hughes wrote: >>> >>>> 2010/1/7 Joseph D. Darcy : >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> 2009/12/25 Andrew John Hughes : >>>>>> >>>>>> >>>>>> >>>>>>> 2009/12/24 Joseph D. Darcy : >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>> [big snip] >>>>> >>>>> >>>>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>>>> effective >>>>>>>> compile-time visibility as in Sun JDK. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I don't know what that is; does this mean >>>>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary >>>>>>> JDK6? I >>>>>>> don't mind either way, it just seems that the other plaf >>>>>>> packages are >>>>>>> visible. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I'm going to start taking my vacation in earnest now so we can >>>>>>>> finish >>>>>>>> working through this issue early in 2010. >>>>>>>> >>>>>>>> Happy holidays, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Happy new year! Any more thoughts on the above? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Yes, easing back from vacation and donning my fedora and bullwhip, >>>>> I've >>>>> dug >>>>> into what is going on here. >>>>> >>>>> In brief, make/common/Release.gmk has a list of packages to >>>>> exclude from >>>>> the >>>>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun >>>>> Proprietary >>>>> warning"); from >>>>> >>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>>>> >>>>> >>>>> # The compiler should not issue a "Sun Propietary" warning when >>>>> compiling >>>>> # classes in the com.sun.java.swing.plaf packages, since we've always >>>>> # allowed, and even advocated, extending them (see bug 6476749). >>>>> # >>>>> # This approach is NOT to be used as a general purpose way to >>>>> avoid such >>>>> # compiler warnings for non-core packages. The correct way is to >>>>> document >>>>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>>>> NON_CORE_PKGS >>>>> # definition. >>>>> # >>>>> # Swing has taken this approach only as a temporary measure to avoid >>>>> # the compiler warnings until we can properly document these >>>>> packages. >>>>> # This is covered under 6491853. >>>>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf \ >>>>> com.sun.java.swing.plaf.windows \ >>>>> com.sun.java.swing.plaf.motif \ >>>>> com.sun.java.swing.plaf.gtk >>>>> >>>>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is >>>>> included on >>>>> that >>>>> package list. Therefore, the test file in question compiles without >>>>> warning >>>>> using Sun's 6 update release. The corresponding addition to this >>>>> list >>>>> has >>>>> *not* been made in JDK 7, which is probably just an oversight. >>>>> >>>>> >>>>> >>>> In 7, it's now a standard API javax.swing.plaf.nimbus. So you'll find >>>> it listed in make/docs/CORE_PKGS.gmk instead: >>>> >>>> >>> Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. >>> >>> >>>> javax.swing.plaf.basic \ >>>> javax.swing.plaf.metal \ >>>> javax.swing.plaf.multi \ >>>> javax.swing.plaf.nimbus \ >>>> javax.swing.plaf.synth \ >>>> >>>> >>> However, javax.swing.plaf.nimbus being a core package in JDK 7 has >>> no direct >>> bearing how com.sun.java.swing.plaf.nimbus should be regarding in >>> either >>> OpenJDK 6 or the 6 update release. >>> >>> Generally, the "exported external" APIs in the JDK are in the java.* >>> and >>> javax.* namespaces. These are the APIs that everyone is supposed to >>> call, >>> etc. Nearly all of the sun.* and com.sun.* API are not in this >>> category; >>> rather they are only intended to be used by a restricted set of >>> parties, >>> such as the JDK implementation. The Swing packages listed in >>> EXCLUDE_PROPWARN_PKGS are an exception to this rule. >>> >>> The ct.sym feature is a compile-time proto module system to add an >>> enforcement mechanism to this long-standing API policy. >>> >>> >> >> Indeed. I wasn't saying that it should be treated the same. I was >> responding to your point that com.sun.java.swing.plaf.nimbus was not >> added to the exclusion list in OpenJDK7 i.e. it obviously hasn't >> because the package no longer exists in 7 and had to be recreated from >> 6. >> >> >>>>> I'd support com.sun.java.swing.plaf.nimbus being included in this >>>>> list in >>>>> OpenJDK 6 as long as >>>>> >>>>> * The API of the package is the same as in Sun's 6 update release >>>>> >>>>> >>>> We have no way of verifying what's in the 6 update release as it is >>>> proprietary software. >>>> >>> After hacking together a small annotation processor, I will send the >>> source >>> for the processor and a list of the signatures of the methods and >>> constructors of the types in the Nimbus package in the 6 update train. >>> >>> >> >> But what do we do if they don't match? Are we supposed to start >> recreating missing methods from the proprietary 6 code when we have no >> idea how they function? >> The code from 7 is all we have. >> > > We can evaluate the difference once we see them. Options include not > exposing the com.sun package in OpenJDK 6 and implementing any missing > functionality or everything might match and they'll be nothing to do :-) > >>>> The Nimbus code in OpenJDK6 is a backport of >>>> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >>>> namespace wihich I believe was used in the proprietary 6 update train. >>>> >>>> Remember that this is an open-source project; regardless of whether >>>> arbitrary bits of code are made invisible or not in a unpatched build >>>> of OpenJDK6, anyone can easily read the code and even rip the ct.sym >>>> hack right back out again. >>>> >>> Just because something is technically feasible does not mean it is >>> advisable. Many technically possible changes are not done so that >>> various >>> other goals can be met, such as following the Java SE 6 >>> specification, etc. >>> >>> If one takes steps to circumvent ct.sym or other enforcement >>> mechanism, it >>> is clear who should be responsible for any adverse consequences. For >>> example, if someone circumvents ct.sym and then a type being >>> accessed is >>> changed in a subsequent release, that is a "close not a bug" situation. >>> >>> >> >> I didn't say it was advisable. I'm just pointing out that it was a >> weak solution to begin with, and even weaker now that people can study >> and alter the source code rather than just having a binary blob to >> work with. >> > > Stronger mechanisms are planned for JDK internal implementation > classes new in JDK 7 where backwards compatibility is not a concern. > >> I'm a fan of warning about the use of this code so it's visibly a bug >> and something that should be fixed. I also think it's perfectly >> legitimately to close bugs that refer to code that's not part of the >> public API (though Sun don't produce OpenJDK6 binaries anyway). >> Plenty of other open source projects do that without actively trying >> to stop people using it in the first place. >> >> I don't like the idea of code appearing to disappear as it just causes >> confusion, usually for end users who don't work on the code itself. >> It also impacts debugging, see Andrew Haley's blog on trying to track >> down an issue in javac: http://andrew-haley.livejournal.com/ The very >> fact that you term it 'an enforcement mechanism' suggests treating >> developers as potential criminals rather than as equals. >> > > There are many enforcement mechanism in the Java platform. The class > file verifier. The type checker in javac. The applet sandbox. The > security model. No criminality need be inferred. > >>>> Additionally, not doing this would make >>>> OpenJDK6 different from the proprietary release -- as you mention >>>> above, it doesn't mask this package. >>>> >>>> >>> Because the proprietary release does not unmask this package, if >>> OpenJDK 6 >>> also unmasks this package, IMO it is important that the OpenJDK 6 >>> API match >>> the API exposed in the proprietary release. >>> >>> >> >> I'm confused here -- does the proprietary JDK6 make this package >> visible or not? > > The com.sun.* nimbus package is visible in the proprietary JDK6 > starting (I assume) in 6u10 when Nimbus was added; it is visible in > 6u17 where I was able to successfully compile your test program. >> You seemed to be saying earlier that it did and your >> idea of checking what the API is using an annotation processor also >> suggests this. >> > > Correct. > >> I agree it's important they match. I just don't see what we can do if >> they don't. >> > > Let's see how far the two packages are from an alpha rename and > evaluate our options. > Greetings. Before writing an annotation processor, I tried a simple diff. Good news! To make the API signatures of the com.sun.java.swing.plaf.nimbus packages match in OpenJDK 6 and the proprietary JDK the following two classes in OpenJDK 6 need to be made public: LoweredBorder.java TableScrollPaneCorner.java So I will approve the following change * The two classes above are changed to be public * The package in question is added to the EXCLUDE_PROPWARN_PKGS list in make/common/Release.gmk as long as Kelly also reviews any build impact. Thanks, -Joe From gnu_andrew at member.fsf.org Mon Jan 11 15:49:04 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 11 Jan 2010 23:49:04 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B4B9315.2050401@sun.com> References: <4AF4B948.5070702@sun.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> <4B47746F.7070305@sun.com> <4B4B9315.2050401@sun.com> Message-ID: <17c6771e1001111549l3660e1bbp4c81baf294e7ad11@mail.gmail.com> 2010/1/11 Joseph D. Darcy : > Joseph D. Darcy wrote: >> >> Andrew John Hughes wrote: >>> >>> 2010/1/8 Joe Darcy : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> 2010/1/7 Joseph D. Darcy : >>>>> >>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> 2009/12/25 Andrew John Hughes : >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 2009/12/24 Joseph D. Darcy : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> [big snip] >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>>>>> effective >>>>>>>>> compile-time visibility as in Sun JDK. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I don't know what that is; does this mean >>>>>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? ?I >>>>>>>> don't mind either way, it just seems that the other plaf packages >>>>>>>> are >>>>>>>> visible. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I'm going to start taking my vacation in earnest now so we can >>>>>>>>> finish >>>>>>>>> working through this issue early in 2010. >>>>>>>>> >>>>>>>>> Happy holidays, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> Happy new year! ?Any more thoughts on the above? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Yes, easing back from vacation and donning my fedora and bullwhip, >>>>>> I've >>>>>> dug >>>>>> into what is going on here. >>>>>> >>>>>> In brief, make/common/Release.gmk has a list of packages to exclude >>>>>> from >>>>>> the >>>>>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun >>>>>> Proprietary >>>>>> warning"); from >>>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>>>>> >>>>>> # The compiler should not issue a "Sun Propietary" warning when >>>>>> compiling >>>>>> # classes in the com.sun.java.swing.plaf packages, since we've always >>>>>> # allowed, and even advocated, extending them (see bug 6476749). >>>>>> # >>>>>> # This approach is NOT to be used as a general purpose way to avoid >>>>>> such >>>>>> # compiler warnings for non-core packages. The correct way is to >>>>>> document >>>>>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>>>>> NON_CORE_PKGS >>>>>> # definition. >>>>>> # >>>>>> # Swing has taken this approach only as a temporary measure to avoid >>>>>> # the compiler warnings until we can properly document these packages. >>>>>> # This is covered under 6491853. >>>>>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf ? ? ? ? ?\ >>>>>> ? ? ? ? ? ? ? ? ? ? com.sun.java.swing.plaf.windows ?\ >>>>>> ? ? ? ? ? ? ? ? ? ? com.sun.java.swing.plaf.motif ? ?\ >>>>>> ? ? ? ? ? ? ? ? ? ? com.sun.java.swing.plaf.gtk >>>>>> >>>>>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on >>>>>> that >>>>>> package list. ?Therefore, the test file in question compiles without >>>>>> warning >>>>>> using Sun's 6 update release. ?The corresponding addition to this list >>>>>> has >>>>>> *not* been made in JDK 7, which is probably just an oversight. >>>>>> >>>>>> >>>>>> >>>>> >>>>> In 7, it's now a standard API javax.swing.plaf.nimbus. ?So you'll find >>>>> it listed in make/docs/CORE_PKGS.gmk instead: >>>>> >>>>> >>>> >>>> Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. >>>> >>>> >>>>> >>>>> ?javax.swing.plaf.basic ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>> ?javax.swing.plaf.metal ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>> ?javax.swing.plaf.multi ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>> ?javax.swing.plaf.nimbus ? ? ? ? ? ? ? ? ? ? ? ?\ >>>>> ?javax.swing.plaf.synth ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>> >>>>> >>>> >>>> However, javax.swing.plaf.nimbus being a core package in JDK 7 has no >>>> direct >>>> bearing how com.sun.java.swing.plaf.nimbus should be regarding in either >>>> OpenJDK 6 or the 6 update release. >>>> >>>> Generally, the "exported external" APIs in the JDK are in the java.* and >>>> javax.* namespaces. ?These are the APIs that everyone is supposed to >>>> call, >>>> etc. ?Nearly all of the sun.* and com.sun.* API are not in this >>>> category; >>>> rather they are only intended to be used by a restricted set of parties, >>>> such as the JDK implementation. ?The Swing packages listed in >>>> EXCLUDE_PROPWARN_PKGS are an exception to this rule. >>>> >>>> The ct.sym feature is a compile-time proto module system to add an >>>> enforcement mechanism to this long-standing API policy. >>>> >>>> >>> >>> Indeed. ?I wasn't saying that it should be treated the same. ?I was >>> responding to your point that com.sun.java.swing.plaf.nimbus was not >>> added to the exclusion list in OpenJDK7 i.e. it obviously hasn't >>> because the package no longer exists in 7 and had to be recreated from >>> 6. >>> >>> >>>>>> >>>>>> I'd support com.sun.java.swing.plaf.nimbus being included in this list >>>>>> in >>>>>> OpenJDK 6 as long as >>>>>> >>>>>> * The API of the package is the same as in Sun's 6 update release >>>>>> >>>>>> >>>>> >>>>> We have no way of verifying what's in the 6 update release as it is >>>>> proprietary software. >>>>> >>>> >>>> After hacking together a small annotation processor, I will send the >>>> source >>>> for the processor and a list of the signatures of the methods and >>>> constructors of the types in the Nimbus package in the 6 update train. >>>> >>>> >>> >>> But what do we do if they don't match? ?Are we supposed to start >>> recreating missing methods from the proprietary 6 code when we have no >>> idea how they function? >>> The code from 7 is all we have. >>> >> >> We can evaluate the difference once we see them. ?Options include not >> exposing the com.sun package in OpenJDK 6 and implementing any missing >> functionality or everything might match and they'll be nothing to do :-) >> >>>>> ?The Nimbus code in OpenJDK6 is a backport of >>>>> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >>>>> namespace wihich I believe was used in the proprietary 6 update train. >>>>> >>>>> Remember that this is an open-source project; regardless of whether >>>>> arbitrary bits of code are made invisible or not in a unpatched build >>>>> of OpenJDK6, anyone can easily read the code and even rip the ct.sym >>>>> hack right back out again. >>>>> >>>> >>>> Just because something is technically feasible does not mean it is >>>> advisable. ?Many technically possible changes are not done so that >>>> various >>>> other goals can be met, such as following the Java SE 6 specification, >>>> etc. >>>> >>>> If one takes steps to circumvent ct.sym or other enforcement mechanism, >>>> it >>>> is clear who should be responsible for any adverse consequences. ?For >>>> example, if someone circumvents ct.sym and then a type being accessed is >>>> changed in a subsequent release, that is a "close not a bug" situation. >>>> >>>> >>> >>> I didn't say it was advisable. ?I'm just pointing out that it was a >>> weak solution to begin with, and even weaker now that people can study >>> and alter the source code rather than just having a binary blob to >>> work with. >>> >> >> Stronger mechanisms are planned for JDK internal implementation classes >> new in JDK 7 where backwards compatibility is not a concern. >> >>> I'm a fan of warning about the use of this code so it's visibly a bug >>> and something that should be fixed. ?I also think it's perfectly >>> legitimately to close bugs that refer to code that's not part of the >>> public API (though Sun don't produce OpenJDK6 binaries anyway). >>> Plenty of other open source projects do that without actively trying >>> to stop people using it in the first place. >>> >>> I don't like the idea of code appearing to disappear as it just causes >>> confusion, usually for end users who don't work on the code itself. >>> It also impacts debugging, see Andrew Haley's blog on trying to track >>> down an issue in javac: http://andrew-haley.livejournal.com/ ?The very >>> fact that you term it 'an enforcement mechanism' suggests treating >>> developers as potential criminals rather than as equals. >>> >> >> There are many enforcement mechanism in the Java platform. ?The class file >> verifier. ?The type checker in javac. ?The applet sandbox. ?The security >> model. ?No criminality need be inferred. >> >>>>> ?Additionally, not doing this would make >>>>> OpenJDK6 different from the proprietary release -- as you mention >>>>> above, it doesn't mask this package. >>>>> >>>>> >>>> >>>> Because the proprietary release does not unmask this package, if OpenJDK >>>> 6 >>>> also unmasks this package, IMO it is important that the OpenJDK 6 API >>>> match >>>> the API exposed in the proprietary release. >>>> >>>> >>> >>> I'm confused here -- does the proprietary JDK6 make this package >>> visible or not? >> >> The com.sun.* nimbus package is visible in the proprietary JDK6 starting >> (I assume) in 6u10 when Nimbus was added; it is visible in 6u17 where I was >> able to successfully compile your test program. >>> >>> You seemed to be saying earlier that it did and your >>> idea of checking what the API is using an annotation processor also >>> suggests this. >>> >> >> Correct. >> >>> I agree it's important they match. ?I just don't see what we can do if >>> they don't. >>> >> >> Let's see how far the two packages are from an alpha rename and evaluate >> our options. >> > > Greetings. > > Before writing an annotation processor, I tried a simple diff. ?Good news! > ?To make the API signatures of the com.sun.java.swing.plaf.nimbus packages > match in OpenJDK 6 and the proprietary JDK the following two classes in > OpenJDK 6 need to be made public: > > LoweredBorder.java > TableScrollPaneCorner.java > > So I will approve the following change > > * The two classes above are changed to be public > * The package in question is added to the EXCLUDE_PROPWARN_PKGS list in > make/common/Release.gmk > > as long as Kelly also reviews any build impact. > > Thanks, > > -Joe > Great news! Here's a webrev for the revised fix: http://cr.openjdk.java.net/~andrew/nimbus/webrev.05/ -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Mon Jan 11 15:53:32 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 11 Jan 2010 15:53:32 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e1001111549l3660e1bbp4c81baf294e7ad11@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> <4B47746F.7070305@sun.com> <4B4B9315.2050401@sun.com> <17c6771e1001111549l3660e1bbp4c81baf294e7ad11@mail.gmail.com> Message-ID: <4B4BB9FC.3060106@sun.com> Andrew John Hughes wrote: > 2010/1/11 Joseph D. Darcy : >> Joseph D. Darcy wrote: >>> Andrew John Hughes wrote: >>>> 2010/1/8 Joe Darcy : >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>>> 2010/1/7 Joseph D. Darcy : >>>>>> >>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>>> 2009/12/25 Andrew John Hughes : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2009/12/24 Joseph D. Darcy : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> [big snip] >>>>>>> >>>>>>> >>>>>>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>>>>>> effective >>>>>>>>>> compile-time visibility as in Sun JDK. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I don't know what that is; does this mean >>>>>>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? I >>>>>>>>> don't mind either way, it just seems that the other plaf packages >>>>>>>>> are >>>>>>>>> visible. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I'm going to start taking my vacation in earnest now so we can >>>>>>>>>> finish >>>>>>>>>> working through this issue early in 2010. >>>>>>>>>> >>>>>>>>>> Happy holidays, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> Happy new year! Any more thoughts on the above? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Yes, easing back from vacation and donning my fedora and bullwhip, >>>>>>> I've >>>>>>> dug >>>>>>> into what is going on here. >>>>>>> >>>>>>> In brief, make/common/Release.gmk has a list of packages to exclude >>>>>>> from >>>>>>> the >>>>>>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun >>>>>>> Proprietary >>>>>>> warning"); from >>>>>>> >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>>>>>> >>>>>>> # The compiler should not issue a "Sun Propietary" warning when >>>>>>> compiling >>>>>>> # classes in the com.sun.java.swing.plaf packages, since we've always >>>>>>> # allowed, and even advocated, extending them (see bug 6476749). >>>>>>> # >>>>>>> # This approach is NOT to be used as a general purpose way to avoid >>>>>>> such >>>>>>> # compiler warnings for non-core packages. The correct way is to >>>>>>> document >>>>>>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>>>>>> NON_CORE_PKGS >>>>>>> # definition. >>>>>>> # >>>>>>> # Swing has taken this approach only as a temporary measure to avoid >>>>>>> # the compiler warnings until we can properly document these packages. >>>>>>> # This is covered under 6491853. >>>>>>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf \ >>>>>>> com.sun.java.swing.plaf.windows \ >>>>>>> com.sun.java.swing.plaf.motif \ >>>>>>> com.sun.java.swing.plaf.gtk >>>>>>> >>>>>>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included on >>>>>>> that >>>>>>> package list. Therefore, the test file in question compiles without >>>>>>> warning >>>>>>> using Sun's 6 update release. The corresponding addition to this list >>>>>>> has >>>>>>> *not* been made in JDK 7, which is probably just an oversight. >>>>>>> >>>>>>> >>>>>>> >>>>>> In 7, it's now a standard API javax.swing.plaf.nimbus. So you'll find >>>>>> it listed in make/docs/CORE_PKGS.gmk instead: >>>>>> >>>>>> >>>>> Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. >>>>> >>>>> >>>>>> javax.swing.plaf.basic \ >>>>>> javax.swing.plaf.metal \ >>>>>> javax.swing.plaf.multi \ >>>>>> javax.swing.plaf.nimbus \ >>>>>> javax.swing.plaf.synth \ >>>>>> >>>>>> >>>>> However, javax.swing.plaf.nimbus being a core package in JDK 7 has no >>>>> direct >>>>> bearing how com.sun.java.swing.plaf.nimbus should be regarding in either >>>>> OpenJDK 6 or the 6 update release. >>>>> >>>>> Generally, the "exported external" APIs in the JDK are in the java.* and >>>>> javax.* namespaces. These are the APIs that everyone is supposed to >>>>> call, >>>>> etc. Nearly all of the sun.* and com.sun.* API are not in this >>>>> category; >>>>> rather they are only intended to be used by a restricted set of parties, >>>>> such as the JDK implementation. The Swing packages listed in >>>>> EXCLUDE_PROPWARN_PKGS are an exception to this rule. >>>>> >>>>> The ct.sym feature is a compile-time proto module system to add an >>>>> enforcement mechanism to this long-standing API policy. >>>>> >>>>> >>>> Indeed. I wasn't saying that it should be treated the same. I was >>>> responding to your point that com.sun.java.swing.plaf.nimbus was not >>>> added to the exclusion list in OpenJDK7 i.e. it obviously hasn't >>>> because the package no longer exists in 7 and had to be recreated from >>>> 6. >>>> >>>> >>>>>>> I'd support com.sun.java.swing.plaf.nimbus being included in this list >>>>>>> in >>>>>>> OpenJDK 6 as long as >>>>>>> >>>>>>> * The API of the package is the same as in Sun's 6 update release >>>>>>> >>>>>>> >>>>>> We have no way of verifying what's in the 6 update release as it is >>>>>> proprietary software. >>>>>> >>>>> After hacking together a small annotation processor, I will send the >>>>> source >>>>> for the processor and a list of the signatures of the methods and >>>>> constructors of the types in the Nimbus package in the 6 update train. >>>>> >>>>> >>>> But what do we do if they don't match? Are we supposed to start >>>> recreating missing methods from the proprietary 6 code when we have no >>>> idea how they function? >>>> The code from 7 is all we have. >>>> >>> We can evaluate the difference once we see them. Options include not >>> exposing the com.sun package in OpenJDK 6 and implementing any missing >>> functionality or everything might match and they'll be nothing to do :-) >>> >>>>>> The Nimbus code in OpenJDK6 is a backport of >>>>>> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >>>>>> namespace wihich I believe was used in the proprietary 6 update train. >>>>>> >>>>>> Remember that this is an open-source project; regardless of whether >>>>>> arbitrary bits of code are made invisible or not in a unpatched build >>>>>> of OpenJDK6, anyone can easily read the code and even rip the ct.sym >>>>>> hack right back out again. >>>>>> >>>>> Just because something is technically feasible does not mean it is >>>>> advisable. Many technically possible changes are not done so that >>>>> various >>>>> other goals can be met, such as following the Java SE 6 specification, >>>>> etc. >>>>> >>>>> If one takes steps to circumvent ct.sym or other enforcement mechanism, >>>>> it >>>>> is clear who should be responsible for any adverse consequences. For >>>>> example, if someone circumvents ct.sym and then a type being accessed is >>>>> changed in a subsequent release, that is a "close not a bug" situation. >>>>> >>>>> >>>> I didn't say it was advisable. I'm just pointing out that it was a >>>> weak solution to begin with, and even weaker now that people can study >>>> and alter the source code rather than just having a binary blob to >>>> work with. >>>> >>> Stronger mechanisms are planned for JDK internal implementation classes >>> new in JDK 7 where backwards compatibility is not a concern. >>> >>>> I'm a fan of warning about the use of this code so it's visibly a bug >>>> and something that should be fixed. I also think it's perfectly >>>> legitimately to close bugs that refer to code that's not part of the >>>> public API (though Sun don't produce OpenJDK6 binaries anyway). >>>> Plenty of other open source projects do that without actively trying >>>> to stop people using it in the first place. >>>> >>>> I don't like the idea of code appearing to disappear as it just causes >>>> confusion, usually for end users who don't work on the code itself. >>>> It also impacts debugging, see Andrew Haley's blog on trying to track >>>> down an issue in javac: http://andrew-haley.livejournal.com/ The very >>>> fact that you term it 'an enforcement mechanism' suggests treating >>>> developers as potential criminals rather than as equals. >>>> >>> There are many enforcement mechanism in the Java platform. The class file >>> verifier. The type checker in javac. The applet sandbox. The security >>> model. No criminality need be inferred. >>> >>>>>> Additionally, not doing this would make >>>>>> OpenJDK6 different from the proprietary release -- as you mention >>>>>> above, it doesn't mask this package. >>>>>> >>>>>> >>>>> Because the proprietary release does not unmask this package, if OpenJDK >>>>> 6 >>>>> also unmasks this package, IMO it is important that the OpenJDK 6 API >>>>> match >>>>> the API exposed in the proprietary release. >>>>> >>>>> >>>> I'm confused here -- does the proprietary JDK6 make this package >>>> visible or not? >>> The com.sun.* nimbus package is visible in the proprietary JDK6 starting >>> (I assume) in 6u10 when Nimbus was added; it is visible in 6u17 where I was >>> able to successfully compile your test program. >>>> You seemed to be saying earlier that it did and your >>>> idea of checking what the API is using an annotation processor also >>>> suggests this. >>>> >>> Correct. >>> >>>> I agree it's important they match. I just don't see what we can do if >>>> they don't. >>>> >>> Let's see how far the two packages are from an alpha rename and evaluate >>> our options. >>> >> Greetings. >> >> Before writing an annotation processor, I tried a simple diff. Good news! >> To make the API signatures of the com.sun.java.swing.plaf.nimbus packages >> match in OpenJDK 6 and the proprietary JDK the following two classes in >> OpenJDK 6 need to be made public: >> >> LoweredBorder.java >> TableScrollPaneCorner.java >> >> So I will approve the following change >> >> * The two classes above are changed to be public >> * The package in question is added to the EXCLUDE_PROPWARN_PKGS list in >> make/common/Release.gmk >> >> as long as Kelly also reviews any build impact. Makefile change seems harmless. -kto >> >> Thanks, >> >> -Joe >> > > Great news! Here's a webrev for the revised fix: > http://cr.openjdk.java.net/~andrew/nimbus/webrev.05/ From Joe.Darcy at Sun.COM Mon Jan 11 16:07:15 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Mon, 11 Jan 2010 16:07:15 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B4BB9FC.3060106@sun.com> References: <4AF4B948.5070702@sun.com> <4B33F36C.1030005@sun.com> <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> <17c6771e1001040726h6160a92bme82b29f35fa3fb5e@mail.gmail.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> <4B47746F.7070305@sun.com> <4B4B9315.2050401@sun.com> <17c6771e1001111549l3660e1bbp4c81baf294e7ad11@mail.gmail.com> <4B4BB9FC.3060106@sun.com> Message-ID: <4B4BBD33.9070502@sun.com> On 01/11/10 03:53 PM, Kelly O'Hair wrote: > > Andrew John Hughes wrote: >> 2010/1/11 Joseph D. Darcy : >>> Joseph D. Darcy wrote: >>>> Andrew John Hughes wrote: >>>>> 2010/1/8 Joe Darcy : >>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>>> 2010/1/7 Joseph D. Darcy : >>>>>>> >>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>>> 2009/12/25 Andrew John Hughes : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2009/12/24 Joseph D. Darcy : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> [big snip] >>>>>>>> >>>>>>>> >>>>>>>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>>>>>>> effective >>>>>>>>>>> compile-time visibility as in Sun JDK. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I don't know what that is; does this mean >>>>>>>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary >>>>>>>>>> JDK6? I >>>>>>>>>> don't mind either way, it just seems that the other plaf >>>>>>>>>> packages >>>>>>>>>> are >>>>>>>>>> visible. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I'm going to start taking my vacation in earnest now so we can >>>>>>>>>>> finish >>>>>>>>>>> working through this issue early in 2010. >>>>>>>>>>> >>>>>>>>>>> Happy holidays, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> Happy new year! Any more thoughts on the above? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Yes, easing back from vacation and donning my fedora and bullwhip, >>>>>>>> I've >>>>>>>> dug >>>>>>>> into what is going on here. >>>>>>>> >>>>>>>> In brief, make/common/Release.gmk has a list of packages to >>>>>>>> exclude >>>>>>>> from >>>>>>>> the >>>>>>>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun >>>>>>>> Proprietary >>>>>>>> warning"); from >>>>>>>> >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>>>>>>> >>>>>>>> >>>>>>>> # The compiler should not issue a "Sun Propietary" warning when >>>>>>>> compiling >>>>>>>> # classes in the com.sun.java.swing.plaf packages, since we've >>>>>>>> always >>>>>>>> # allowed, and even advocated, extending them (see bug 6476749). >>>>>>>> # >>>>>>>> # This approach is NOT to be used as a general purpose way to >>>>>>>> avoid >>>>>>>> such >>>>>>>> # compiler warnings for non-core packages. The correct way is to >>>>>>>> document >>>>>>>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>>>>>>> NON_CORE_PKGS >>>>>>>> # definition. >>>>>>>> # >>>>>>>> # Swing has taken this approach only as a temporary measure to >>>>>>>> avoid >>>>>>>> # the compiler warnings until we can properly document these >>>>>>>> packages. >>>>>>>> # This is covered under 6491853. >>>>>>>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf \ >>>>>>>> com.sun.java.swing.plaf.windows \ >>>>>>>> com.sun.java.swing.plaf.motif \ >>>>>>>> com.sun.java.swing.plaf.gtk >>>>>>>> >>>>>>>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is >>>>>>>> included on >>>>>>>> that >>>>>>>> package list. Therefore, the test file in question compiles >>>>>>>> without >>>>>>>> warning >>>>>>>> using Sun's 6 update release. The corresponding addition to >>>>>>>> this list >>>>>>>> has >>>>>>>> *not* been made in JDK 7, which is probably just an oversight. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> In 7, it's now a standard API javax.swing.plaf.nimbus. So >>>>>>> you'll find >>>>>>> it listed in make/docs/CORE_PKGS.gmk instead: >>>>>>> >>>>>>> >>>>>> Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. >>>>>> >>>>>> >>>>>>> javax.swing.plaf.basic \ >>>>>>> javax.swing.plaf.metal \ >>>>>>> javax.swing.plaf.multi \ >>>>>>> javax.swing.plaf.nimbus \ >>>>>>> javax.swing.plaf.synth \ >>>>>>> >>>>>>> >>>>>> However, javax.swing.plaf.nimbus being a core package in JDK 7 >>>>>> has no >>>>>> direct >>>>>> bearing how com.sun.java.swing.plaf.nimbus should be regarding in >>>>>> either >>>>>> OpenJDK 6 or the 6 update release. >>>>>> >>>>>> Generally, the "exported external" APIs in the JDK are in the >>>>>> java.* and >>>>>> javax.* namespaces. These are the APIs that everyone is supposed to >>>>>> call, >>>>>> etc. Nearly all of the sun.* and com.sun.* API are not in this >>>>>> category; >>>>>> rather they are only intended to be used by a restricted set of >>>>>> parties, >>>>>> such as the JDK implementation. The Swing packages listed in >>>>>> EXCLUDE_PROPWARN_PKGS are an exception to this rule. >>>>>> >>>>>> The ct.sym feature is a compile-time proto module system to add an >>>>>> enforcement mechanism to this long-standing API policy. >>>>>> >>>>>> >>>>> Indeed. I wasn't saying that it should be treated the same. I was >>>>> responding to your point that com.sun.java.swing.plaf.nimbus was not >>>>> added to the exclusion list in OpenJDK7 i.e. it obviously hasn't >>>>> because the package no longer exists in 7 and had to be recreated >>>>> from >>>>> 6. >>>>> >>>>> >>>>>>>> I'd support com.sun.java.swing.plaf.nimbus being included in >>>>>>>> this list >>>>>>>> in >>>>>>>> OpenJDK 6 as long as >>>>>>>> >>>>>>>> * The API of the package is the same as in Sun's 6 update release >>>>>>>> >>>>>>>> >>>>>>> We have no way of verifying what's in the 6 update release as it is >>>>>>> proprietary software. >>>>>>> >>>>>> After hacking together a small annotation processor, I will send the >>>>>> source >>>>>> for the processor and a list of the signatures of the methods and >>>>>> constructors of the types in the Nimbus package in the 6 update >>>>>> train. >>>>>> >>>>>> >>>>> But what do we do if they don't match? Are we supposed to start >>>>> recreating missing methods from the proprietary 6 code when we >>>>> have no >>>>> idea how they function? >>>>> The code from 7 is all we have. >>>>> >>>> We can evaluate the difference once we see them. Options include not >>>> exposing the com.sun package in OpenJDK 6 and implementing any missing >>>> functionality or everything might match and they'll be nothing to >>>> do :-) >>>> >>>>>>> The Nimbus code in OpenJDK6 is a backport of >>>>>>> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >>>>>>> namespace wihich I believe was used in the proprietary 6 update >>>>>>> train. >>>>>>> >>>>>>> Remember that this is an open-source project; regardless of whether >>>>>>> arbitrary bits of code are made invisible or not in a unpatched >>>>>>> build >>>>>>> of OpenJDK6, anyone can easily read the code and even rip the >>>>>>> ct.sym >>>>>>> hack right back out again. >>>>>>> >>>>>> Just because something is technically feasible does not mean it is >>>>>> advisable. Many technically possible changes are not done so that >>>>>> various >>>>>> other goals can be met, such as following the Java SE 6 >>>>>> specification, >>>>>> etc. >>>>>> >>>>>> If one takes steps to circumvent ct.sym or other enforcement >>>>>> mechanism, >>>>>> it >>>>>> is clear who should be responsible for any adverse consequences. >>>>>> For >>>>>> example, if someone circumvents ct.sym and then a type being >>>>>> accessed is >>>>>> changed in a subsequent release, that is a "close not a bug" >>>>>> situation. >>>>>> >>>>>> >>>>> I didn't say it was advisable. I'm just pointing out that it was a >>>>> weak solution to begin with, and even weaker now that people can >>>>> study >>>>> and alter the source code rather than just having a binary blob to >>>>> work with. >>>>> >>>> Stronger mechanisms are planned for JDK internal implementation >>>> classes >>>> new in JDK 7 where backwards compatibility is not a concern. >>>> >>>>> I'm a fan of warning about the use of this code so it's visibly a bug >>>>> and something that should be fixed. I also think it's perfectly >>>>> legitimately to close bugs that refer to code that's not part of the >>>>> public API (though Sun don't produce OpenJDK6 binaries anyway). >>>>> Plenty of other open source projects do that without actively trying >>>>> to stop people using it in the first place. >>>>> >>>>> I don't like the idea of code appearing to disappear as it just >>>>> causes >>>>> confusion, usually for end users who don't work on the code itself. >>>>> It also impacts debugging, see Andrew Haley's blog on trying to track >>>>> down an issue in javac: http://andrew-haley.livejournal.com/ The >>>>> very >>>>> fact that you term it 'an enforcement mechanism' suggests treating >>>>> developers as potential criminals rather than as equals. >>>>> >>>> There are many enforcement mechanism in the Java platform. The >>>> class file >>>> verifier. The type checker in javac. The applet sandbox. The >>>> security >>>> model. No criminality need be inferred. >>>> >>>>>>> Additionally, not doing this would make >>>>>>> OpenJDK6 different from the proprietary release -- as you mention >>>>>>> above, it doesn't mask this package. >>>>>>> >>>>>>> >>>>>> Because the proprietary release does not unmask this package, if >>>>>> OpenJDK >>>>>> 6 >>>>>> also unmasks this package, IMO it is important that the OpenJDK 6 >>>>>> API >>>>>> match >>>>>> the API exposed in the proprietary release. >>>>>> >>>>>> >>>>> I'm confused here -- does the proprietary JDK6 make this package >>>>> visible or not? >>>> The com.sun.* nimbus package is visible in the proprietary JDK6 >>>> starting >>>> (I assume) in 6u10 when Nimbus was added; it is visible in 6u17 >>>> where I was >>>> able to successfully compile your test program. >>>>> You seemed to be saying earlier that it did and your >>>>> idea of checking what the API is using an annotation processor also >>>>> suggests this. >>>>> >>>> Correct. >>>> >>>>> I agree it's important they match. I just don't see what we can >>>>> do if >>>>> they don't. >>>>> >>>> Let's see how far the two packages are from an alpha rename and >>>> evaluate >>>> our options. >>>> >>> Greetings. >>> >>> Before writing an annotation processor, I tried a simple diff. Good >>> news! >>> To make the API signatures of the com.sun.java.swing.plaf.nimbus >>> packages >>> match in OpenJDK 6 and the proprietary JDK the following two classes in >>> OpenJDK 6 need to be made public: >>> >>> LoweredBorder.java >>> TableScrollPaneCorner.java >>> >>> So I will approve the following change >>> >>> * The two classes above are changed to be public >>> * The package in question is added to the EXCLUDE_PROPWARN_PKGS list in >>> make/common/Release.gmk >>> >>> as long as Kelly also reviews any build impact. > > Makefile change seems harmless. > > -kto > With that, consider the change approved; please push using bug id 6915980 "Do not issue build warnings for use of com.sun.java.swing.plaf.nimbus." Thanks, -Joe From ahughes at redhat.com Mon Jan 11 16:45:43 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Tue, 12 Jan 2010 00:45:43 +0000 Subject: hg: jdk6/jdk6/jdk: 6915980: Do not issue build warnings for use of com.sun.java.swing.plaf.nimbus Message-ID: <20100112004603.7BC0E42D7A@hg.openjdk.java.net> Changeset: f6d8d0c0e6ad Author: andrew Date: 2010-01-12 00:45 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f6d8d0c0e6ad 6915980: Do not issue build warnings for use of com.sun.java.swing.plaf.nimbus Summary: Match API exposure to proprietary JDK6. Reviewed-by: darcy, ohair ! make/common/Release.gmk ! src/share/classes/com/sun/java/swing/plaf/nimbus/LoweredBorder.java ! src/share/classes/com/sun/java/swing/plaf/nimbus/TableScrollPaneCorner.java ! test/com/sun/java/swing/plaf/nimbus/Test6849805.java From gnu_andrew at member.fsf.org Mon Jan 11 17:03:49 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 12 Jan 2010 01:03:49 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B4BBD33.9070502@sun.com> References: <4AF4B948.5070702@sun.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> <4B47746F.7070305@sun.com> <4B4B9315.2050401@sun.com> <17c6771e1001111549l3660e1bbp4c81baf294e7ad11@mail.gmail.com> <4B4BB9FC.3060106@sun.com> <4B4BBD33.9070502@sun.com> Message-ID: <17c6771e1001111703s11d94af0v4d450d5f2208ed18@mail.gmail.com> 2010/1/12 Joe Darcy : > On 01/11/10 03:53 PM, Kelly O'Hair wrote: >> >> Andrew John Hughes wrote: >>> >>> 2010/1/11 Joseph D. Darcy : >>>> >>>> Joseph D. Darcy wrote: >>>>> >>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2010/1/8 Joe Darcy : >>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>>> 2010/1/7 Joseph D. Darcy : >>>>>>>> >>>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2009/12/25 Andrew John Hughes : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2009/12/24 Joseph D. Darcy : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> [big snip] >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>>>>>>>> effective >>>>>>>>>>>> compile-time visibility as in Sun JDK. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I don't know what that is; does this mean >>>>>>>>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? >>>>>>>>>>> ?I >>>>>>>>>>> don't mind either way, it just seems that the other plaf packages >>>>>>>>>>> are >>>>>>>>>>> visible. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'm going to start taking my vacation in earnest now so we can >>>>>>>>>>>> finish >>>>>>>>>>>> working through this issue early in 2010. >>>>>>>>>>>> >>>>>>>>>>>> Happy holidays, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> Happy new year! ?Any more thoughts on the above? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Yes, easing back from vacation and donning my fedora and bullwhip, >>>>>>>>> I've >>>>>>>>> dug >>>>>>>>> into what is going on here. >>>>>>>>> >>>>>>>>> In brief, make/common/Release.gmk has a list of packages to exclude >>>>>>>>> from >>>>>>>>> the >>>>>>>>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun >>>>>>>>> Proprietary >>>>>>>>> warning"); from >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>>>>>>>> >>>>>>>>> # The compiler should not issue a "Sun Propietary" warning when >>>>>>>>> compiling >>>>>>>>> # classes in the com.sun.java.swing.plaf packages, since we've >>>>>>>>> always >>>>>>>>> # allowed, and even advocated, extending them (see bug 6476749). >>>>>>>>> # >>>>>>>>> # This approach is NOT to be used as a general purpose way to avoid >>>>>>>>> such >>>>>>>>> # compiler warnings for non-core packages. The correct way is to >>>>>>>>> document >>>>>>>>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>>>>>>>> NON_CORE_PKGS >>>>>>>>> # definition. >>>>>>>>> # >>>>>>>>> # Swing has taken this approach only as a temporary measure to >>>>>>>>> avoid >>>>>>>>> # the compiler warnings until we can properly document these >>>>>>>>> packages. >>>>>>>>> # This is covered under 6491853. >>>>>>>>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf ? ? ? ? ?\ >>>>>>>>> ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.windows ?\ >>>>>>>>> ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.motif ? ?\ >>>>>>>>> ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.gtk >>>>>>>>> >>>>>>>>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included >>>>>>>>> on >>>>>>>>> that >>>>>>>>> package list. ?Therefore, the test file in question compiles >>>>>>>>> without >>>>>>>>> warning >>>>>>>>> using Sun's 6 update release. ?The corresponding addition to this >>>>>>>>> list >>>>>>>>> has >>>>>>>>> *not* been made in JDK 7, which is probably just an oversight. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> In 7, it's now a standard API javax.swing.plaf.nimbus. ?So you'll >>>>>>>> find >>>>>>>> it listed in make/docs/CORE_PKGS.gmk instead: >>>>>>>> >>>>>>>> >>>>>>> Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. >>>>>>> >>>>>>> >>>>>>>> ?javax.swing.plaf.basic ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>>>>> ?javax.swing.plaf.metal ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>>>>> ?javax.swing.plaf.multi ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>>>>> ?javax.swing.plaf.nimbus ? ? ? ? ? ? ? ? ? ? ? ?\ >>>>>>>> ?javax.swing.plaf.synth ? ? ? ? ? ? ? ? ? ? ? ? \ >>>>>>>> >>>>>>>> >>>>>>> However, javax.swing.plaf.nimbus being a core package in JDK 7 has no >>>>>>> direct >>>>>>> bearing how com.sun.java.swing.plaf.nimbus should be regarding in >>>>>>> either >>>>>>> OpenJDK 6 or the 6 update release. >>>>>>> >>>>>>> Generally, the "exported external" APIs in the JDK are in the java.* >>>>>>> and >>>>>>> javax.* namespaces. ?These are the APIs that everyone is supposed to >>>>>>> call, >>>>>>> etc. ?Nearly all of the sun.* and com.sun.* API are not in this >>>>>>> category; >>>>>>> rather they are only intended to be used by a restricted set of >>>>>>> parties, >>>>>>> such as the JDK implementation. ?The Swing packages listed in >>>>>>> EXCLUDE_PROPWARN_PKGS are an exception to this rule. >>>>>>> >>>>>>> The ct.sym feature is a compile-time proto module system to add an >>>>>>> enforcement mechanism to this long-standing API policy. >>>>>>> >>>>>>> >>>>>> Indeed. ?I wasn't saying that it should be treated the same. ?I was >>>>>> responding to your point that com.sun.java.swing.plaf.nimbus was not >>>>>> added to the exclusion list in OpenJDK7 i.e. it obviously hasn't >>>>>> because the package no longer exists in 7 and had to be recreated from >>>>>> 6. >>>>>> >>>>>> >>>>>>>>> I'd support com.sun.java.swing.plaf.nimbus being included in this >>>>>>>>> list >>>>>>>>> in >>>>>>>>> OpenJDK 6 as long as >>>>>>>>> >>>>>>>>> * The API of the package is the same as in Sun's 6 update release >>>>>>>>> >>>>>>>>> >>>>>>>> We have no way of verifying what's in the 6 update release as it is >>>>>>>> proprietary software. >>>>>>>> >>>>>>> After hacking together a small annotation processor, I will send the >>>>>>> source >>>>>>> for the processor and a list of the signatures of the methods and >>>>>>> constructors of the types in the Nimbus package in the 6 update >>>>>>> train. >>>>>>> >>>>>>> >>>>>> But what do we do if they don't match? ?Are we supposed to start >>>>>> recreating missing methods from the proprietary 6 code when we have no >>>>>> idea how they function? >>>>>> The code from 7 is all we have. >>>>>> >>>>> We can evaluate the difference once we see them. ?Options include not >>>>> exposing the com.sun package in OpenJDK 6 and implementing any missing >>>>> functionality or everything might match and they'll be nothing to do >>>>> :-) >>>>> >>>>>>>> ?The Nimbus code in OpenJDK6 is a backport of >>>>>>>> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >>>>>>>> namespace wihich I believe was used in the proprietary 6 update >>>>>>>> train. >>>>>>>> >>>>>>>> Remember that this is an open-source project; regardless of whether >>>>>>>> arbitrary bits of code are made invisible or not in a unpatched >>>>>>>> build >>>>>>>> of OpenJDK6, anyone can easily read the code and even rip the ct.sym >>>>>>>> hack right back out again. >>>>>>>> >>>>>>> Just because something is technically feasible does not mean it is >>>>>>> advisable. ?Many technically possible changes are not done so that >>>>>>> various >>>>>>> other goals can be met, such as following the Java SE 6 >>>>>>> specification, >>>>>>> etc. >>>>>>> >>>>>>> If one takes steps to circumvent ct.sym or other enforcement >>>>>>> mechanism, >>>>>>> it >>>>>>> is clear who should be responsible for any adverse consequences. ?For >>>>>>> example, if someone circumvents ct.sym and then a type being accessed >>>>>>> is >>>>>>> changed in a subsequent release, that is a "close not a bug" >>>>>>> situation. >>>>>>> >>>>>>> >>>>>> I didn't say it was advisable. ?I'm just pointing out that it was a >>>>>> weak solution to begin with, and even weaker now that people can study >>>>>> and alter the source code rather than just having a binary blob to >>>>>> work with. >>>>>> >>>>> Stronger mechanisms are planned for JDK internal implementation classes >>>>> new in JDK 7 where backwards compatibility is not a concern. >>>>> >>>>>> I'm a fan of warning about the use of this code so it's visibly a bug >>>>>> and something that should be fixed. ?I also think it's perfectly >>>>>> legitimately to close bugs that refer to code that's not part of the >>>>>> public API (though Sun don't produce OpenJDK6 binaries anyway). >>>>>> Plenty of other open source projects do that without actively trying >>>>>> to stop people using it in the first place. >>>>>> >>>>>> I don't like the idea of code appearing to disappear as it just causes >>>>>> confusion, usually for end users who don't work on the code itself. >>>>>> It also impacts debugging, see Andrew Haley's blog on trying to track >>>>>> down an issue in javac: http://andrew-haley.livejournal.com/ ?The very >>>>>> fact that you term it 'an enforcement mechanism' suggests treating >>>>>> developers as potential criminals rather than as equals. >>>>>> >>>>> There are many enforcement mechanism in the Java platform. ?The class >>>>> file >>>>> verifier. ?The type checker in javac. ?The applet sandbox. ?The >>>>> security >>>>> model. ?No criminality need be inferred. >>>>> >>>>>>>> ?Additionally, not doing this would make >>>>>>>> OpenJDK6 different from the proprietary release -- as you mention >>>>>>>> above, it doesn't mask this package. >>>>>>>> >>>>>>>> >>>>>>> Because the proprietary release does not unmask this package, if >>>>>>> OpenJDK >>>>>>> 6 >>>>>>> also unmasks this package, IMO it is important that the OpenJDK 6 API >>>>>>> match >>>>>>> the API exposed in the proprietary release. >>>>>>> >>>>>>> >>>>>> I'm confused here -- does the proprietary JDK6 make this package >>>>>> visible or not? >>>>> >>>>> The com.sun.* nimbus package is visible in the proprietary JDK6 >>>>> starting >>>>> (I assume) in 6u10 when Nimbus was added; it is visible in 6u17 where I >>>>> was >>>>> able to successfully compile your test program. >>>>>> >>>>>> You seemed to be saying earlier that it did and your >>>>>> idea of checking what the API is using an annotation processor also >>>>>> suggests this. >>>>>> >>>>> Correct. >>>>> >>>>>> I agree it's important they match. ?I just don't see what we can do if >>>>>> they don't. >>>>>> >>>>> Let's see how far the two packages are from an alpha rename and >>>>> evaluate >>>>> our options. >>>>> >>>> Greetings. >>>> >>>> Before writing an annotation processor, I tried a simple diff. ?Good >>>> news! >>>> ?To make the API signatures of the com.sun.java.swing.plaf.nimbus >>>> packages >>>> match in OpenJDK 6 and the proprietary JDK the following two classes in >>>> OpenJDK 6 need to be made public: >>>> >>>> LoweredBorder.java >>>> TableScrollPaneCorner.java >>>> >>>> So I will approve the following change >>>> >>>> * The two classes above are changed to be public >>>> * The package in question is added to the EXCLUDE_PROPWARN_PKGS list in >>>> make/common/Release.gmk >>>> >>>> as long as Kelly also reviews any build impact. >> >> Makefile change seems harmless. >> >> -kto >> > > With that, consider the change approved; please push using bug id 6915980 > "Do not issue build warnings for use of com.sun.java.swing.plaf.nimbus." > > Thanks, > > -Joe > Pushed:http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f6d8d0c0e6ad There's another Nimbus patch that should be backported before b18: # HG changeset patch # User peterz # Date 1258555006 -10800 # Node ID fc3997fd1bcebf74031fdc43d44b371e4be3d29b # Parent 4f0275ea56fdb3f8199d16951954cfee80f931c2 6882917: Nimbus and DefaultTableCellRenderer: must start with normal background Reviewed-by: rupashka http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/fc3997fd1bcebf7403 -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Mon Jan 11 17:09:42 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Mon, 11 Jan 2010 17:09:42 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e1001111703s11d94af0v4d450d5f2208ed18@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4B45548F.9040500@sun.com> <17c6771e1001070318n7a90752cnb30395cb0036f2db@mail.gmail.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> <4B47746F.7070305@sun.com> <4B4B9315.2050401@sun.com> <17c6771e1001111549l3660e1bbp4c81baf294e7ad11@mail.gmail.com> <4B4BB9FC.3060106@sun.com> <4B4BBD33.9070502@sun.com> <17c6771e1001111703s11d94af0v4d450d5f2208ed18@mail.gmail.com> Message-ID: <4B4BCBD6.5010705@sun.com> On 01/11/10 05:03 PM, Andrew John Hughes wrote: > 2010/1/12 Joe Darcy : > >> On 01/11/10 03:53 PM, Kelly O'Hair wrote: >> >>> Andrew John Hughes wrote: >>> >>>> 2010/1/11 Joseph D. Darcy : >>>> >>>>> Joseph D. Darcy wrote: >>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>>> 2010/1/8 Joe Darcy : >>>>>>> >>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>>> 2010/1/7 Joseph D. Darcy : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2009/12/25 Andrew John Hughes : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2009/12/24 Joseph D. Darcy : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> [big snip] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> The com.sun.java.swing package in OpenJDK should have the same >>>>>>>>>>>>> effective >>>>>>>>>>>>> compile-time visibility as in Sun JDK. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> I don't know what that is; does this mean >>>>>>>>>>>> com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? >>>>>>>>>>>> I >>>>>>>>>>>> don't mind either way, it just seems that the other plaf packages >>>>>>>>>>>> are >>>>>>>>>>>> visible. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I'm going to start taking my vacation in earnest now so we can >>>>>>>>>>>>> finish >>>>>>>>>>>>> working through this issue early in 2010. >>>>>>>>>>>>> >>>>>>>>>>>>> Happy holidays, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> Happy new year! Any more thoughts on the above? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yes, easing back from vacation and donning my fedora and bullwhip, >>>>>>>>>> I've >>>>>>>>>> dug >>>>>>>>>> into what is going on here. >>>>>>>>>> >>>>>>>>>> In brief, make/common/Release.gmk has a list of packages to exclude >>>>>>>>>> from >>>>>>>>>> the >>>>>>>>>> ct.sym warning (6476749: "Exclude Swing plaf classes from Sun >>>>>>>>>> Proprietary >>>>>>>>>> warning"); from >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk >>>>>>>>>> >>>>>>>>>> # The compiler should not issue a "Sun Propietary" warning when >>>>>>>>>> compiling >>>>>>>>>> # classes in the com.sun.java.swing.plaf packages, since we've >>>>>>>>>> always >>>>>>>>>> # allowed, and even advocated, extending them (see bug 6476749). >>>>>>>>>> # >>>>>>>>>> # This approach is NOT to be used as a general purpose way to avoid >>>>>>>>>> such >>>>>>>>>> # compiler warnings for non-core packages. The correct way is to >>>>>>>>>> document >>>>>>>>>> # the packages in NON_CORE_PKGS.gmk, and include them in the >>>>>>>>>> NON_CORE_PKGS >>>>>>>>>> # definition. >>>>>>>>>> # >>>>>>>>>> # Swing has taken this approach only as a temporary measure to >>>>>>>>>> avoid >>>>>>>>>> # the compiler warnings until we can properly document these >>>>>>>>>> packages. >>>>>>>>>> # This is covered under 6491853. >>>>>>>>>> EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf \ >>>>>>>>>> com.sun.java.swing.plaf.windows \ >>>>>>>>>> com.sun.java.swing.plaf.motif \ >>>>>>>>>> com.sun.java.swing.plaf.gtk >>>>>>>>>> >>>>>>>>>> In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included >>>>>>>>>> on >>>>>>>>>> that >>>>>>>>>> package list. Therefore, the test file in question compiles >>>>>>>>>> without >>>>>>>>>> warning >>>>>>>>>> using Sun's 6 update release. The corresponding addition to this >>>>>>>>>> list >>>>>>>>>> has >>>>>>>>>> *not* been made in JDK 7, which is probably just an oversight. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> In 7, it's now a standard API javax.swing.plaf.nimbus. So you'll >>>>>>>>> find >>>>>>>>> it listed in make/docs/CORE_PKGS.gmk instead: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> javax.swing.plaf.basic \ >>>>>>>>> javax.swing.plaf.metal \ >>>>>>>>> javax.swing.plaf.multi \ >>>>>>>>> javax.swing.plaf.nimbus \ >>>>>>>>> javax.swing.plaf.synth \ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> However, javax.swing.plaf.nimbus being a core package in JDK 7 has no >>>>>>>> direct >>>>>>>> bearing how com.sun.java.swing.plaf.nimbus should be regarding in >>>>>>>> either >>>>>>>> OpenJDK 6 or the 6 update release. >>>>>>>> >>>>>>>> Generally, the "exported external" APIs in the JDK are in the java.* >>>>>>>> and >>>>>>>> javax.* namespaces. These are the APIs that everyone is supposed to >>>>>>>> call, >>>>>>>> etc. Nearly all of the sun.* and com.sun.* API are not in this >>>>>>>> category; >>>>>>>> rather they are only intended to be used by a restricted set of >>>>>>>> parties, >>>>>>>> such as the JDK implementation. The Swing packages listed in >>>>>>>> EXCLUDE_PROPWARN_PKGS are an exception to this rule. >>>>>>>> >>>>>>>> The ct.sym feature is a compile-time proto module system to add an >>>>>>>> enforcement mechanism to this long-standing API policy. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Indeed. I wasn't saying that it should be treated the same. I was >>>>>>> responding to your point that com.sun.java.swing.plaf.nimbus was not >>>>>>> added to the exclusion list in OpenJDK7 i.e. it obviously hasn't >>>>>>> because the package no longer exists in 7 and had to be recreated from >>>>>>> 6. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> I'd support com.sun.java.swing.plaf.nimbus being included in this >>>>>>>>>> list >>>>>>>>>> in >>>>>>>>>> OpenJDK 6 as long as >>>>>>>>>> >>>>>>>>>> * The API of the package is the same as in Sun's 6 update release >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> We have no way of verifying what's in the 6 update release as it is >>>>>>>>> proprietary software. >>>>>>>>> >>>>>>>>> >>>>>>>> After hacking together a small annotation processor, I will send the >>>>>>>> source >>>>>>>> for the processor and a list of the signatures of the methods and >>>>>>>> constructors of the types in the Nimbus package in the 6 update >>>>>>>> train. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> But what do we do if they don't match? Are we supposed to start >>>>>>> recreating missing methods from the proprietary 6 code when we have no >>>>>>> idea how they function? >>>>>>> The code from 7 is all we have. >>>>>>> >>>>>>> >>>>>> We can evaluate the difference once we see them. Options include not >>>>>> exposing the com.sun package in OpenJDK 6 and implementing any missing >>>>>> functionality or everything might match and they'll be nothing to do >>>>>> :-) >>>>>> >>>>>> >>>>>>>>> The Nimbus code in OpenJDK6 is a backport of >>>>>>>>> what's in 7, moved back to the com.sun.java.swing.plaf.nimbus >>>>>>>>> namespace wihich I believe was used in the proprietary 6 update >>>>>>>>> train. >>>>>>>>> >>>>>>>>> Remember that this is an open-source project; regardless of whether >>>>>>>>> arbitrary bits of code are made invisible or not in a unpatched >>>>>>>>> build >>>>>>>>> of OpenJDK6, anyone can easily read the code and even rip the ct.sym >>>>>>>>> hack right back out again. >>>>>>>>> >>>>>>>>> >>>>>>>> Just because something is technically feasible does not mean it is >>>>>>>> advisable. Many technically possible changes are not done so that >>>>>>>> various >>>>>>>> other goals can be met, such as following the Java SE 6 >>>>>>>> specification, >>>>>>>> etc. >>>>>>>> >>>>>>>> If one takes steps to circumvent ct.sym or other enforcement >>>>>>>> mechanism, >>>>>>>> it >>>>>>>> is clear who should be responsible for any adverse consequences. For >>>>>>>> example, if someone circumvents ct.sym and then a type being accessed >>>>>>>> is >>>>>>>> changed in a subsequent release, that is a "close not a bug" >>>>>>>> situation. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I didn't say it was advisable. I'm just pointing out that it was a >>>>>>> weak solution to begin with, and even weaker now that people can study >>>>>>> and alter the source code rather than just having a binary blob to >>>>>>> work with. >>>>>>> >>>>>>> >>>>>> Stronger mechanisms are planned for JDK internal implementation classes >>>>>> new in JDK 7 where backwards compatibility is not a concern. >>>>>> >>>>>> >>>>>>> I'm a fan of warning about the use of this code so it's visibly a bug >>>>>>> and something that should be fixed. I also think it's perfectly >>>>>>> legitimately to close bugs that refer to code that's not part of the >>>>>>> public API (though Sun don't produce OpenJDK6 binaries anyway). >>>>>>> Plenty of other open source projects do that without actively trying >>>>>>> to stop people using it in the first place. >>>>>>> >>>>>>> I don't like the idea of code appearing to disappear as it just causes >>>>>>> confusion, usually for end users who don't work on the code itself. >>>>>>> It also impacts debugging, see Andrew Haley's blog on trying to track >>>>>>> down an issue in javac: http://andrew-haley.livejournal.com/ The very >>>>>>> fact that you term it 'an enforcement mechanism' suggests treating >>>>>>> developers as potential criminals rather than as equals. >>>>>>> >>>>>>> >>>>>> There are many enforcement mechanism in the Java platform. The class >>>>>> file >>>>>> verifier. The type checker in javac. The applet sandbox. The >>>>>> security >>>>>> model. No criminality need be inferred. >>>>>> >>>>>> >>>>>>>>> Additionally, not doing this would make >>>>>>>>> OpenJDK6 different from the proprietary release -- as you mention >>>>>>>>> above, it doesn't mask this package. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Because the proprietary release does not unmask this package, if >>>>>>>> OpenJDK >>>>>>>> 6 >>>>>>>> also unmasks this package, IMO it is important that the OpenJDK 6 API >>>>>>>> match >>>>>>>> the API exposed in the proprietary release. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I'm confused here -- does the proprietary JDK6 make this package >>>>>>> visible or not? >>>>>>> >>>>>> The com.sun.* nimbus package is visible in the proprietary JDK6 >>>>>> starting >>>>>> (I assume) in 6u10 when Nimbus was added; it is visible in 6u17 where I >>>>>> was >>>>>> able to successfully compile your test program. >>>>>> >>>>>>> You seemed to be saying earlier that it did and your >>>>>>> idea of checking what the API is using an annotation processor also >>>>>>> suggests this. >>>>>>> >>>>>>> >>>>>> Correct. >>>>>> >>>>>> >>>>>>> I agree it's important they match. I just don't see what we can do if >>>>>>> they don't. >>>>>>> >>>>>>> >>>>>> Let's see how far the two packages are from an alpha rename and >>>>>> evaluate >>>>>> our options. >>>>>> >>>>>> >>>>> Greetings. >>>>> >>>>> Before writing an annotation processor, I tried a simple diff. Good >>>>> news! >>>>> To make the API signatures of the com.sun.java.swing.plaf.nimbus >>>>> packages >>>>> match in OpenJDK 6 and the proprietary JDK the following two classes in >>>>> OpenJDK 6 need to be made public: >>>>> >>>>> LoweredBorder.java >>>>> TableScrollPaneCorner.java >>>>> >>>>> So I will approve the following change >>>>> >>>>> * The two classes above are changed to be public >>>>> * The package in question is added to the EXCLUDE_PROPWARN_PKGS list in >>>>> make/common/Release.gmk >>>>> >>>>> as long as Kelly also reviews any build impact. >>>>> >>> Makefile change seems harmless. >>> >>> -kto >>> >>> >> With that, consider the change approved; please push using bug id 6915980 >> "Do not issue build warnings for use of com.sun.java.swing.plaf.nimbus." >> >> Thanks, >> >> -Joe >> >> > > Pushed:http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f6d8d0c0e6ad > > There's another Nimbus patch that should be backported before b18: > > # HG changeset patch > # User peterz > # Date 1258555006 -10800 > # Node ID fc3997fd1bcebf74031fdc43d44b371e4be3d29b > # Parent 4f0275ea56fdb3f8199d16951954cfee80f931c2 > 6882917: Nimbus and DefaultTableCellRenderer: must start with normal background > Reviewed-by: rupashka > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/fc3997fd1bcebf7403 > > You're approved to push a port of this fix assuming the patch applies cleanly. Thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100111/1f3049fd/attachment-0001.html From ahughes at redhat.com Mon Jan 11 17:14:25 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Tue, 12 Jan 2010 01:14:25 +0000 Subject: hg: jdk6/jdk6/jdk: 6882917: Nimbus and DefaultTableCellRenderer: must start with normal background Message-ID: <20100112011437.B438542D83@hg.openjdk.java.net> Changeset: 5f6bca79e784 Author: peterz Date: 2009-11-18 17:36 +0300 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/5f6bca79e784 6882917: Nimbus and DefaultTableCellRenderer: must start with normal background Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java From gnu_andrew at member.fsf.org Mon Jan 11 17:23:56 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 12 Jan 2010 01:23:56 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B4BCBD6.5010705@sun.com> References: <4AF4B948.5070702@sun.com> <4B46A63E.3050600@sun.com> <17c6771e1001080509g76a05791idd8420dc4a046cda@mail.gmail.com> <4B47746F.7070305@sun.com> <4B4B9315.2050401@sun.com> <17c6771e1001111549l3660e1bbp4c81baf294e7ad11@mail.gmail.com> <4B4BB9FC.3060106@sun.com> <4B4BBD33.9070502@sun.com> <17c6771e1001111703s11d94af0v4d450d5f2208ed18@mail.gmail.com> <4B4BCBD6.5010705@sun.com> Message-ID: <17c6771e1001111723y6dd93727p3a9357c33b4b79b6@mail.gmail.com> 2010/1/12 Joe Darcy : > On 01/11/10 05:03 PM, Andrew John Hughes wrote: > > 2010/1/12 Joe Darcy : > > > On 01/11/10 03:53 PM, Kelly O'Hair wrote: > > > Andrew John Hughes wrote: > > > 2010/1/11 Joseph D. Darcy : > > > Joseph D. Darcy wrote: > > > Andrew John Hughes wrote: > > > 2010/1/8 Joe Darcy : > > > > Andrew John Hughes wrote: > > > > 2010/1/7 Joseph D. Darcy : > > > > > Andrew John Hughes wrote: > > > > > 2009/12/25 Andrew John Hughes : > > > > > > 2009/12/24 Joseph D. Darcy : > > > > > > Andrew John Hughes wrote: > > > > > > [big snip] > > > > > The com.sun.java.swing package in OpenJDK should have the same > effective > compile-time visibility as in Sun JDK. > > > > > > > I don't know what that is; does this mean > com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? > ?I > don't mind either way, it just seems that the other plaf packages > are > visible. > > > > > > > I'm going to start taking my vacation in earnest now so we can > finish > working through this issue early in 2010. > > Happy holidays, > > > > > > > Happy new year! ?Any more thoughts on the above? > > > > > > > Yes, easing back from vacation and donning my fedora and bullwhip, > I've > dug > into what is going on here. > > In brief, make/common/Release.gmk has a list of packages to exclude > from > the > ct.sym warning (6476749: "Exclude Swing plaf classes from Sun > Proprietary > warning"); from > > > > http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/c00f461c45bc/make/common/Release.gmk > > # The compiler should not issue a "Sun Propietary" warning when > compiling > # classes in the com.sun.java.swing.plaf packages, since we've > always > # allowed, and even advocated, extending them (see bug 6476749). > # > # This approach is NOT to be used as a general purpose way to avoid > such > # compiler warnings for non-core packages. The correct way is to > document > # the packages in NON_CORE_PKGS.gmk, and include them in the > NON_CORE_PKGS > # definition. > # > # Swing has taken this approach only as a temporary measure to > avoid > # the compiler warnings until we can properly document these > packages. > # This is covered under 6491853. > EXCLUDE_PROPWARN_PKGS = com.sun.java.swing.plaf ? ? ? ? ?\ > ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.windows ?\ > ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.motif ? ?\ > ? ? ? ? ? ? ? ? ? ?com.sun.java.swing.plaf.gtk > > In Sun's 6 update train, com.sun.java.swing.plaf.nimbus is included > on > that > package list. ?Therefore, the test file in question compiles > without > warning > using Sun's 6 update release. ?The corresponding addition to this > list > has > *not* been made in JDK 7, which is probably just an oversight. > > > > > > In 7, it's now a standard API javax.swing.plaf.nimbus. ?So you'll > find > it listed in make/docs/CORE_PKGS.gmk instead: > > > > > Yes, for JDK 7 javax.swing.plaf.nimbus is a core package. > > > > > ?javax.swing.plaf.basic ? ? ? ? ? ? ? ? ? ? ? ? \ > ?javax.swing.plaf.metal ? ? ? ? ? ? ? ? ? ? ? ? \ > ?javax.swing.plaf.multi ? ? ? ? ? ? ? ? ? ? ? ? \ > ?javax.swing.plaf.nimbus ? ? ? ? ? ? ? ? ? ? ? ?\ > ?javax.swing.plaf.synth ? ? ? ? ? ? ? ? ? ? ? ? \ > > > > > However, javax.swing.plaf.nimbus being a core package in JDK 7 has no > direct > bearing how com.sun.java.swing.plaf.nimbus should be regarding in > either > OpenJDK 6 or the 6 update release. > > Generally, the "exported external" APIs in the JDK are in the java.* > and > javax.* namespaces. ?These are the APIs that everyone is supposed to > call, > etc. ?Nearly all of the sun.* and com.sun.* API are not in this > category; > rather they are only intended to be used by a restricted set of > parties, > such as the JDK implementation. ?The Swing packages listed in > EXCLUDE_PROPWARN_PKGS are an exception to this rule. > > The ct.sym feature is a compile-time proto module system to add an > enforcement mechanism to this long-standing API policy. > > > > > Indeed. ?I wasn't saying that it should be treated the same. ?I was > responding to your point that com.sun.java.swing.plaf.nimbus was not > added to the exclusion list in OpenJDK7 i.e. it obviously hasn't > because the package no longer exists in 7 and had to be recreated from > 6. > > > > > I'd support com.sun.java.swing.plaf.nimbus being included in this > list > in > OpenJDK 6 as long as > > * The API of the package is the same as in Sun's 6 update release > > > > > We have no way of verifying what's in the 6 update release as it is > proprietary software. > > > > After hacking together a small annotation processor, I will send the > source > for the processor and a list of the signatures of the methods and > constructors of the types in the Nimbus package in the 6 update > train. > > > > > But what do we do if they don't match? ?Are we supposed to start > recreating missing methods from the proprietary 6 code when we have no > idea how they function? > The code from 7 is all we have. > > > > We can evaluate the difference once we see them. ?Options include not > exposing the com.sun package in OpenJDK 6 and implementing any missing > functionality or everything might match and they'll be nothing to do > :-) > > > > ?The Nimbus code in OpenJDK6 is a backport of > what's in 7, moved back to the com.sun.java.swing.plaf.nimbus > namespace wihich I believe was used in the proprietary 6 update > train. > > Remember that this is an open-source project; regardless of whether > arbitrary bits of code are made invisible or not in a unpatched > build > of OpenJDK6, anyone can easily read the code and even rip the ct.sym > hack right back out again. > > > > Just because something is technically feasible does not mean it is > advisable. ?Many technically possible changes are not done so that > various > other goals can be met, such as following the Java SE 6 > specification, > etc. > > If one takes steps to circumvent ct.sym or other enforcement > mechanism, > it > is clear who should be responsible for any adverse consequences. ?For > example, if someone circumvents ct.sym and then a type being accessed > is > changed in a subsequent release, that is a "close not a bug" > situation. > > > > > I didn't say it was advisable. ?I'm just pointing out that it was a > weak solution to begin with, and even weaker now that people can study > and alter the source code rather than just having a binary blob to > work with. > > > > Stronger mechanisms are planned for JDK internal implementation classes > new in JDK 7 where backwards compatibility is not a concern. > > > > I'm a fan of warning about the use of this code so it's visibly a bug > and something that should be fixed. ?I also think it's perfectly > legitimately to close bugs that refer to code that's not part of the > public API (though Sun don't produce OpenJDK6 binaries anyway). > Plenty of other open source projects do that without actively trying > to stop people using it in the first place. > > I don't like the idea of code appearing to disappear as it just causes > confusion, usually for end users who don't work on the code itself. > It also impacts debugging, see Andrew Haley's blog on trying to track > down an issue in javac: http://andrew-haley.livejournal.com/ ?The very > fact that you term it 'an enforcement mechanism' suggests treating > developers as potential criminals rather than as equals. > > > > There are many enforcement mechanism in the Java platform. ?The class > file > verifier. ?The type checker in javac. ?The applet sandbox. ?The > security > model. ?No criminality need be inferred. > > > > ?Additionally, not doing this would make > OpenJDK6 different from the proprietary release -- as you mention > above, it doesn't mask this package. > > > > > Because the proprietary release does not unmask this package, if > OpenJDK > 6 > also unmasks this package, IMO it is important that the OpenJDK 6 API > match > the API exposed in the proprietary release. > > > > > I'm confused here -- does the proprietary JDK6 make this package > visible or not? > > > The com.sun.* nimbus package is visible in the proprietary JDK6 > starting > (I assume) in 6u10 when Nimbus was added; it is visible in 6u17 where I > was > able to successfully compile your test program. > > > You seemed to be saying earlier that it did and your > idea of checking what the API is using an annotation processor also > suggests this. > > > > Correct. > > > > I agree it's important they match. ?I just don't see what we can do if > they don't. > > > > Let's see how far the two packages are from an alpha rename and > evaluate > our options. > > > > Greetings. > > Before writing an annotation processor, I tried a simple diff. ?Good > news! > ?To make the API signatures of the com.sun.java.swing.plaf.nimbus > packages > match in OpenJDK 6 and the proprietary JDK the following two classes in > OpenJDK 6 need to be made public: > > LoweredBorder.java > TableScrollPaneCorner.java > > So I will approve the following change > > * The two classes above are changed to be public > * The package in question is added to the EXCLUDE_PROPWARN_PKGS list in > make/common/Release.gmk > > as long as Kelly also reviews any build impact. > > > Makefile change seems harmless. > > -kto > > > > With that, consider the change approved; please push using bug id 6915980 > "Do not issue build warnings for use of com.sun.java.swing.plaf.nimbus." > > Thanks, > > -Joe > > > > Pushed:http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f6d8d0c0e6ad > > There's another Nimbus patch that should be backported before b18: > > # HG changeset patch > # User peterz > # Date 1258555006 -10800 > # Node ID fc3997fd1bcebf74031fdc43d44b371e4be3d29b > # Parent 4f0275ea56fdb3f8199d16951954cfee80f931c2 > 6882917: Nimbus and DefaultTableCellRenderer: must start with normal > background > Reviewed-by: rupashka > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/fc3997fd1bcebf7403 > > > > You're approved to push a port of this fix assuming the patch applies > cleanly. > > Thanks, > > -Joe > > Done: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/5f6bca79e784 -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From sean.mullan at sun.com Wed Jan 13 06:39:34 2010 From: sean.mullan at sun.com (sean.mullan at sun.com) Date: Wed, 13 Jan 2010 14:39:34 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20100113144014.B507242FE8@hg.openjdk.java.net> Changeset: c33ca6c539bf Author: mullan Date: 2010-01-13 09:29 -0500 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c33ca6c539bf 6744888: OCSP validation code should permit some clock skew when checking validity 6745437: Add option to only check revocation of end-entity certificate in a chain 6869739: Cannot check revocation of single certificate without validating the entire chain 6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on jdk6u18/b02, jdk7/pit/b73 and passes on b72. 6894461: OCSP Checker should not wrap all Exception as "Unable to send OCSP request."(introduced by #6885667) Reviewed-by: dgu, vinnie, xuelei + src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java + src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/share/classes/sun/security/x509/AccessDescription.java Changeset: 22cf4479d879 Author: mullan Date: 2010-01-13 09:31 -0500 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/22cf4479d879 Merge From nse at delfi-konsult.com Fri Jan 15 01:29:46 2010 From: nse at delfi-konsult.com (Niels S. Eliasen) Date: Fri, 15 Jan 2010 10:29:46 +0100 Subject: "could not create parent directories" Message-ID: <7E814437-1859-416B-805E-9A1979150D10@delfi-konsult.com> Hi Just wondered whether anyone knows how to fix this error ?? > compile: > [javac] Compiling 4 source files to /home/nse/ > OpenbravoERP-2.50MP8/src-db/build/classes > [javac] /home/nse/OpenbravoERP-2.50MP8/src-db/src/com/openbravo/ > db/OpenbravoDataFilter.java:22: error while writing > com.openbravo.db.OpenbravoDataFilter: could not create parent > directories > [javac] public final class OpenbravoDataFilter extends > AbstractDatabaseFilter { > [javac] ^ > [javac] 1 error > > BUILD FAILED > /home/nse/OpenbravoERP-2.50MP8/build.xml:515: The following error > occurred while executing this line: > /home/nse/OpenbravoERP-2.50MP8/build.xml:484: The following error > occurred while executing this line: > /home/nse/OpenbravoERP-2.50MP8/src-db/build.xml:39: Compile failed; > see the compiler error output for details. > > Have communicated with the OpenBravo guys.... They do not se this problem on x86.... > munin,nse,~/OpenbravoERP-2.50MP8 > java -version > java version "1.6.0_0" > OpenJDK Runtime Environment (build 1.6.0_0-b11) > OpenJDK Core VM (build 1.6.0_0-b11, interpreted mode) > is the installed version of OpenJDK (standard from the apt repositories.....) and "ant" is: > munin,nse,~/OpenbravoERP-2.50MP8 > ant -version > Apache Ant version 1.7.0 compiled on April 29 2008 > the standard as well...... All on Debian Lenny(PowerPC) .... kind regards nse "Ach, crivens, what a wee snotter....." Quote from "The Wee Free Men" by Terry Pratchett From gnu_andrew at member.fsf.org Fri Jan 15 07:14:45 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 Jan 2010 15:14:45 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets In-Reply-To: <20100113144014.B507242FE8@hg.openjdk.java.net> References: <20100113144014.B507242FE8@hg.openjdk.java.net> Message-ID: <17c6771e1001150714wa16f961hb867d3cdb6de1c71@mail.gmail.com> 2010/1/13 : > Changeset: c33ca6c539bf > Author: ? ?mullan > Date: ? ? ?2010-01-13 09:29 -0500 > URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c33ca6c539bf > > 6744888: OCSP validation code should permit some clock skew when checking validity > 6745437: Add option to only check revocation of end-entity certificate in a chain > 6869739: Cannot check revocation of single certificate without validating the entire chain > 6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on jdk6u18/b02, jdk7/pit/b73 and passes on b72. > 6894461: OCSP Checker should not wrap all Exception as "Unable to send OCSP request."(introduced by #6885667) > Reviewed-by: dgu, vinnie, xuelei > > + src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java > ! src/share/classes/sun/security/provider/certpath/Builder.java > ! src/share/classes/sun/security/provider/certpath/CertId.java > ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java > ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java > ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java > + src/share/classes/sun/security/provider/certpath/OCSP.java > ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java > ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java > ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java > ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java > ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java > ! src/share/classes/sun/security/x509/AccessDescription.java > > Changeset: 22cf4479d879 > Author: ? ?mullan > Date: ? ? ?2010-01-13 09:31 -0500 > URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/22cf4479d879 > > Merge > > > I didn't see this discussed on the jdk6 list. What is it for? We're currently trying to test b18 for release and importing more random changesets really doesn't help! -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Sean.Mullan at Sun.COM Fri Jan 15 07:40:55 2010 From: Sean.Mullan at Sun.COM (Sean Mullan) Date: Fri, 15 Jan 2010 10:40:55 -0500 Subject: hg: jdk6/jdk6/jdk: 2 new changesets In-Reply-To: <17c6771e1001150714wa16f961hb867d3cdb6de1c71@mail.gmail.com> References: <20100113144014.B507242FE8@hg.openjdk.java.net> <17c6771e1001150714wa16f961hb867d3cdb6de1c71@mail.gmail.com> Message-ID: <4B508C87.1050106@sun.com> Andrew John Hughes wrote: > 2010/1/13 : >> Changeset: c33ca6c539bf >> Author: mullan >> Date: 2010-01-13 09:29 -0500 >> URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c33ca6c539bf >> >> 6744888: OCSP validation code should permit some clock skew when checking validity >> 6745437: Add option to only check revocation of end-entity certificate in a chain >> 6869739: Cannot check revocation of single certificate without validating the entire chain >> 6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on jdk6u18/b02, jdk7/pit/b73 and passes on b72. >> 6894461: OCSP Checker should not wrap all Exception as "Unable to send OCSP request."(introduced by #6885667) >> Reviewed-by: dgu, vinnie, xuelei >> >> + src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java >> ! src/share/classes/sun/security/provider/certpath/Builder.java >> ! src/share/classes/sun/security/provider/certpath/CertId.java >> ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java >> ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java >> ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java >> + src/share/classes/sun/security/provider/certpath/OCSP.java >> ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java >> ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java >> ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java >> ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java >> ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java >> ! src/share/classes/sun/security/x509/AccessDescription.java >> >> Changeset: 22cf4479d879 >> Author: mullan >> Date: 2010-01-13 09:31 -0500 >> URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/22cf4479d879 >> >> Merge >> >> >> > > I didn't see this discussed on the jdk6 list. What is it for? We're > currently trying to test b18 for release and importing more random > changesets really doesn't help! There was a request to support multiple OCSP SingleResponses in OpenJDK 6 on the security-dev alias : http://mail.openjdk.java.net/pipermail/security-dev/2010-January/001486.html This required a backport of several related CRs already fixed in OpenJDK 7 that addressed this issue. Let me know if this is still an issue and I will back it out for a later build. Also, I will discuss these and other changes on the jdk6 list before putting changes back in the future. --Sean From gnu_andrew at member.fsf.org Fri Jan 15 07:56:30 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 Jan 2010 15:56:30 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets In-Reply-To: <4B508C87.1050106@sun.com> References: <20100113144014.B507242FE8@hg.openjdk.java.net> <17c6771e1001150714wa16f961hb867d3cdb6de1c71@mail.gmail.com> <4B508C87.1050106@sun.com> Message-ID: <17c6771e1001150756s12a0c2b3xa4358ef977ad9d8@mail.gmail.com> 2010/1/15 Sean Mullan : > Andrew John Hughes wrote: >> >> 2010/1/13 ?: >>> >>> Changeset: c33ca6c539bf >>> Author: ? ?mullan >>> Date: ? ? ?2010-01-13 09:29 -0500 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c33ca6c539bf >>> >>> 6744888: OCSP validation code should permit some clock skew when checking >>> validity >>> 6745437: Add option to only check revocation of end-entity certificate in >>> a chain >>> 6869739: Cannot check revocation of single certificate without validating >>> the entire chain >>> 6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on >>> jdk6u18/b02, jdk7/pit/b73 and passes on b72. >>> 6894461: OCSP Checker should not wrap all Exception as "Unable to send >>> OCSP request."(introduced by #6885667) >>> Reviewed-by: dgu, vinnie, xuelei >>> >>> + >>> src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java >>> ! src/share/classes/sun/security/provider/certpath/Builder.java >>> ! src/share/classes/sun/security/provider/certpath/CertId.java >>> ! >>> src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java >>> ! >>> src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java >>> ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java >>> + src/share/classes/sun/security/provider/certpath/OCSP.java >>> ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java >>> ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java >>> ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java >>> ! >>> src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java >>> ! >>> src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java >>> ! src/share/classes/sun/security/x509/AccessDescription.java >>> >>> Changeset: 22cf4479d879 >>> Author: ? ?mullan >>> Date: ? ? ?2010-01-13 09:31 -0500 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/22cf4479d879 >>> >>> Merge >>> >>> >>> >> >> I didn't see this discussed on the jdk6 list. ?What is it for? ?We're >> currently trying to test b18 for release and importing more random >> changesets really doesn't help! > > There was a request to support multiple OCSP SingleResponses in OpenJDK 6 on > the security-dev alias : > > http://mail.openjdk.java.net/pipermail/security-dev/2010-January/001486.html > > This required a backport of several related CRs already fixed in OpenJDK 7 > that addressed this issue. > > Let me know if this is still an issue and I will back it out for a later > build. Also, I will discuss these and other changes on the jdk6 list before > putting changes back in the future. > > --Sean > > Ok thanks. I found the post in my local mail too, I must have missed it. However, it doesn't say anything about approval to push to JDK6, just that you'd look into backporting it. I think the build issues I'm seeing are easily resolvable and only due to the way we have to bootstrap OpenJDK. We use ecj to bootstrap before doing a full build and it can't understand @Override on interfaces, so we have to patch them out. I'm more concerned that we've done a lot of regression testing on this already and this may alter the results -- though I hope not. Thanks for your understanding, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From kelly.ohair at sun.com Fri Jan 15 08:43:16 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 15 Jan 2010 16:43:16 +0000 Subject: hg: jdk6/jdk6/jdk: 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms Message-ID: <20100115164329.9BE6141721@hg.openjdk.java.net> Changeset: 93c580ce5e88 Author: ohair Date: 2010-01-15 08:41 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/93c580ce5e88 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms Reviewed-by: tbell, jjg ! make/common/Defs.gmk ! make/common/Program.gmk ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/javax/sound/Makefile ! make/launchers/Makefile.launcher From gnu_andrew at member.fsf.org Fri Jan 15 09:26:46 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 Jan 2010 17:26:46 +0000 Subject: hg: jdk6/jdk6/jdk: 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms In-Reply-To: <20100115164329.9BE6141721@hg.openjdk.java.net> References: <20100115164329.9BE6141721@hg.openjdk.java.net> Message-ID: <17c6771e1001150926q22fef3f1v8bc2ab07ba3c23d@mail.gmail.com> 2010/1/15 : > Changeset: 93c580ce5e88 > Author: ? ?ohair > Date: ? ? ?2010-01-15 08:41 -0800 > URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/93c580ce5e88 > > 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms > Reviewed-by: tbell, jjg > > ! make/common/Defs.gmk > ! make/common/Program.gmk > ! make/java/main/java/Makefile > ! make/java/main/javaw/Makefile > ! make/javax/sound/Makefile > ! make/launchers/Makefile.launcher > > Again, where was this approved for OpenJDK6? We're supposed to be preparing for a release of b18! -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Fri Jan 15 09:32:08 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 15 Jan 2010 09:32:08 -0800 Subject: hg: jdk6/jdk6/jdk: 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms In-Reply-To: <17c6771e1001150926q22fef3f1v8bc2ab07ba3c23d@mail.gmail.com> References: <20100115164329.9BE6141721@hg.openjdk.java.net> <17c6771e1001150926q22fef3f1v8bc2ab07ba3c23d@mail.gmail.com> Message-ID: <4B50A698.1020501@sun.com> On 1/15/10 9:26 AM, Andrew John Hughes wrote: > 2010/1/15: >> Changeset: 93c580ce5e88 >> Author: ohair >> Date: 2010-01-15 08:41 -0800 >> URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/93c580ce5e88 >> >> 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms >> Reviewed-by: tbell, jjg >> >> ! make/common/Defs.gmk >> ! make/common/Program.gmk >> ! make/java/main/java/Makefile >> ! make/java/main/javaw/Makefile >> ! make/javax/sound/Makefile >> ! make/launchers/Makefile.launcher >> >> > > Again, where was this approved for OpenJDK6? We're supposed to be > preparing for a release of b18! Sorry. Without these changes GNU make 3.81 can't be used on Windows/MKS systems, I jumped the gun on this push. I should have checked with Joe first. -kto From Jonathan.Gibbons at Sun.COM Fri Jan 15 09:58:49 2010 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 15 Jan 2010 09:58:49 -0800 Subject: hg: jdk6/jdk6/jdk: 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms In-Reply-To: <4B50A698.1020501@sun.com> References: <20100115164329.9BE6141721@hg.openjdk.java.net> <17c6771e1001150926q22fef3f1v8bc2ab07ba3c23d@mail.gmail.com> <4B50A698.1020501@sun.com> Message-ID: <4B50ACD9.5090907@sun.com> Kelly O'Hair wrote: > > On 1/15/10 9:26 AM, Andrew John Hughes wrote: >> 2010/1/15: >>> Changeset: 93c580ce5e88 >>> Author: ohair >>> Date: 2010-01-15 08:41 -0800 >>> URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/93c580ce5e88 >>> >>> 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for >>> all platforms >>> Reviewed-by: tbell, jjg >>> >>> ! make/common/Defs.gmk >>> ! make/common/Program.gmk >>> ! make/java/main/java/Makefile >>> ! make/java/main/javaw/Makefile >>> ! make/javax/sound/Makefile >>> ! make/launchers/Makefile.launcher >>> >>> >> >> Again, where was this approved for OpenJDK6? We're supposed to be >> preparing for a release of b18! > > Sorry. Without these changes GNU make 3.81 can't be used on Windows/MKS > systems, I jumped the gun on this push. > I should have checked with Joe first. > > -kto Perhaps we need a different way of handling the repo nearer significant milestones, such as forking a separate forest to be used as the build candidate. We can then have tighter controls on who has access to that forest. In other words, much the same as we try and do for jdk7. -- Jon From gnu_andrew at member.fsf.org Fri Jan 15 11:56:03 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 Jan 2010 19:56:03 +0000 Subject: hg: jdk6/jdk6/jdk: 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms In-Reply-To: <4B50ACD9.5090907@sun.com> References: <20100115164329.9BE6141721@hg.openjdk.java.net> <17c6771e1001150926q22fef3f1v8bc2ab07ba3c23d@mail.gmail.com> <4B50A698.1020501@sun.com> <4B50ACD9.5090907@sun.com> Message-ID: <17c6771e1001151156v11d22af8pfd8f7314296be07d@mail.gmail.com> 2010/1/15 Jonathan Gibbons : > Kelly O'Hair wrote: >> >> On 1/15/10 9:26 AM, Andrew John Hughes wrote: >>> >>> 2010/1/15: >>>> >>>> Changeset: 93c580ce5e88 >>>> Author: ? ?ohair >>>> Date: ? ? ?2010-01-15 08:41 -0800 >>>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/93c580ce5e88 >>>> >>>> 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all >>>> platforms >>>> Reviewed-by: tbell, jjg >>>> >>>> ! make/common/Defs.gmk >>>> ! make/common/Program.gmk >>>> ! make/java/main/java/Makefile >>>> ! make/java/main/javaw/Makefile >>>> ! make/javax/sound/Makefile >>>> ! make/launchers/Makefile.launcher >>>> >>>> >>> >>> Again, where was this approved for OpenJDK6? ?We're supposed to be >>> preparing for a release of b18! >> >> Sorry. Without these changes GNU make 3.81 can't be used on Windows/MKS >> systems, I jumped the gun on this push. >> I should have checked with Joe first. >> >> -kto > > > Perhaps we need a different way of handling the repo nearer significant > milestones, such as forking a separate forest to be used as the build > candidate. We can then have tighter controls on who has access to that > forest. ?In other words, much the same as we try and do for jdk7. > > -- Jon > I agree. I've been thinking something along the same lines myself. I thought the general policy for 6 was that even straight backports had to be approved by Joe, but this doesn't seem to be the case. I only saw the earlier OCSP fix due to our nightly Hudson build failing to build. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Fri Jan 15 13:52:18 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 Jan 2010 21:52:18 +0000 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings Message-ID: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> When building documentation, both OpenJDK6 and OpenJDK7 spit out a number of warnings when building documentation: /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: warning - Tag @link: reference not found: Stub#connect /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ t_policy_override /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag @return cannot be used in constructor documentation. It can\ only be used in the following types of documentation: method. /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: warning - @ is an unknown tag. /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: warning - Tag @return cannot be used in field documentation\ . It can only be used in the following types of documentation: method. /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: warning - @parm is an unknown tag. /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: warning - @parm is an unknown tag. /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: warning - @parm is an unknown tag. /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: warning - @param argument "a_component" is not a p\ arameter name. /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: warning - @param argument "a_component" is not a p\ arameter name. This patch against OpenJDK7: http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch fixes the warnings. Is this ok to push? If so, can I have a bug ID for it? Joe, would this also be ok for 6? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Fri Jan 15 13:59:13 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 15 Jan 2010 13:59:13 -0800 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> Message-ID: <4B50E531.70803@sun.com> Andrew John Hughes wrote: > When building documentation, both OpenJDK6 and OpenJDK7 spit out a > number of warnings when building documentation: > > /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: > warning - Tag @link: reference not found: Stub#connect > /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: > warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ > t_policy_override > /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag > @return cannot be used in constructor documentation. It can\ > only be used in the following types of documentation: method. > /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: > warning - @ is an unknown tag. > /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: > warning - Tag @return cannot be used in field documentation\ > . It can only be used in the following types of documentation: method. > /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: > warning - @parm is an unknown tag. > /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: > warning - @parm is an unknown tag. > /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: > warning - @parm is an unknown tag. > /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: > warning - @param argument "a_component" is not a p\ > arameter name. > /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: > warning - @param argument "a_component" is not a p\ > arameter name. > > This patch against OpenJDK7: > > http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch > > fixes the warnings. > > Is this ok to push? If so, can I have a bug ID for it? > > Joe, would this also be ok for 6? > > Thanks, > cc'ing Ken Cavanaugh for corba matters. If this fix is approved for JDK 7, I approve it to also go back into OpenJDK 6. Regards, -Joe From Ken.Cavanaugh at Sun.COM Fri Jan 15 15:25:35 2010 From: Ken.Cavanaugh at Sun.COM (Ken Cavanaugh) Date: Fri, 15 Jan 2010 15:25:35 -0800 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <4B50E531.70803@sun.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> Message-ID: <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> The fixes look good to me. Thanks, Ken. On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >> number of warnings when building documentation: >> >> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >> warning - Tag @link: reference not found: Stub#connect >> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >> t_policy_override >> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag >> @return cannot be used in constructor documentation. It can\ >> only be used in the following types of documentation: method. >> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >> warning - @ is an unknown tag. >> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java: >> 48: >> warning - Tag @return cannot be used in field documentation\ >> . It can only be used in the following types of documentation: >> method. >> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/ >> _NamingContextExtStub.java:301: >> warning - @parm is an unknown tag. >> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java: >> 146: >> warning - @parm is an unknown tag. >> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/ >> NamingContextOperations.java:89: >> warning - @parm is an unknown tag. >> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/ >> IORInfoOperations.java:54: >> warning - @param argument "a_component" is not a p\ >> arameter name. >> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/ >> IORInfoOperations.java:72: >> warning - @param argument "a_component" is not a p\ >> arameter name. >> >> This patch against OpenJDK7: >> >> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >> >> fixes the warnings. >> >> Is this ok to push? If so, can I have a bug ID for it? >> >> Joe, would this also be ok for 6? >> >> Thanks, >> > > cc'ing Ken Cavanaugh for corba matters. > > If this fix is approved for JDK 7, I approve it to also go back into > OpenJDK 6. > > Regards, > > -Joe > From gnu_andrew at member.fsf.org Fri Jan 15 15:32:00 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 Jan 2010 23:32:00 +0000 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> Message-ID: <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> 2010/1/15 Ken Cavanaugh : > The fixes look good to me. > > Thanks, > > Ken. > > On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: > >> Andrew John Hughes wrote: >>> >>> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >>> number of warnings when building documentation: >>> >>> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >>> warning - Tag @link: reference not found: Stub#connect >>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >>> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >>> t_policy_override >>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag >>> @return cannot be used in constructor documentation. ?It can\ >>> only be used in the following types of documentation: method. >>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >>> warning - @ is an unknown tag. >>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: >>> warning - Tag @return cannot be used in field documentation\ >>> . ?It can only be used in the following types of documentation: method. >>> >>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: >>> warning - @parm is an unknown tag. >>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: >>> warning - @parm is an unknown tag. >>> >>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: >>> warning - @parm is an unknown tag. >>> >>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: >>> warning - @param argument "a_component" is not a p\ >>> arameter name. >>> >>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: >>> warning - @param argument "a_component" is not a p\ >>> arameter name. >>> >>> This patch against OpenJDK7: >>> >>> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >>> >>> fixes the warnings. >>> >>> Is this ok to push? ?If so, can I have a bug ID for it? >>> >>> Joe, would this also be ok for 6? >>> >>> Thanks, >>> >> >> cc'ing Ken Cavanaugh for corba matters. >> >> If this fix is approved for JDK 7, I approve it to also go back into >> OpenJDK 6. >> >> Regards, >> >> -Joe >> > > Thanks Ken. I don't see you on http://db.openjdk.java.net/people so not sure what I should use for the Reviewed-by field. Joe, can you allocate this a bug ID? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Fri Jan 15 15:43:20 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 15 Jan 2010 15:43:20 -0800 Subject: hg: jdk6/jdk6/jdk: 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms In-Reply-To: <17c6771e1001151156v11d22af8pfd8f7314296be07d@mail.gmail.com> References: <20100115164329.9BE6141721@hg.openjdk.java.net> <17c6771e1001150926q22fef3f1v8bc2ab07ba3c23d@mail.gmail.com> <4B50A698.1020501@sun.com> <4B50ACD9.5090907@sun.com> <17c6771e1001151156v11d22af8pfd8f7314296be07d@mail.gmail.com> Message-ID: <4B50FD98.8010509@sun.com> Andrew John Hughes wrote: > 2010/1/15 Jonathan Gibbons : > >> Kelly O'Hair wrote: >> >>> On 1/15/10 9:26 AM, Andrew John Hughes wrote: >>> >>>> 2010/1/15: >>>> >>>>> Changeset: 93c580ce5e88 >>>>> Author: ohair >>>>> Date: 2010-01-15 08:41 -0800 >>>>> URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/93c580ce5e88 >>>>> >>>>> 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all >>>>> platforms >>>>> Reviewed-by: tbell, jjg >>>>> >>>>> ! make/common/Defs.gmk >>>>> ! make/common/Program.gmk >>>>> ! make/java/main/java/Makefile >>>>> ! make/java/main/javaw/Makefile >>>>> ! make/javax/sound/Makefile >>>>> ! make/launchers/Makefile.launcher >>>>> >>>>> >>>>> >>>> Again, where was this approved for OpenJDK6? We're supposed to be >>>> preparing for a release of b18! >>>> >>> Sorry. Without these changes GNU make 3.81 can't be used on Windows/MKS >>> systems, I jumped the gun on this push. >>> I should have checked with Joe first. >>> >>> -kto >>> >> Perhaps we need a different way of handling the repo nearer significant >> milestones, such as forking a separate forest to be used as the build >> candidate. We can then have tighter controls on who has access to that >> forest. In other words, much the same as we try and do for jdk7. >> >> -- Jon >> >> > > I agree. I've been thinking something along the same lines myself. > > I thought the general policy for 6 was that even straight backports > had to be approved by Joe, but this doesn't seem to be the case. I > only saw the earlier OCSP fix due to our nightly Hudson build failing > to build. > Review requests for OpenJDK 6 should all be sent to jdk6-dev at openjdk.java.net. I'll blog about this in the near future. Regards, -Joe From Joe.Darcy at Sun.COM Fri Jan 15 16:09:06 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 15 Jan 2010 16:09:06 -0800 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> Message-ID: <4B5103A2.20809@sun.com> Andrew John Hughes wrote: > 2010/1/15 Ken Cavanaugh : > >> The fixes look good to me. >> >> Thanks, >> >> Ken. >> >> On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: >> >> >>> Andrew John Hughes wrote: >>> >>>> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >>>> number of warnings when building documentation: >>>> >>>> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >>>> warning - Tag @link: reference not found: Stub#connect >>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >>>> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >>>> t_policy_override >>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag >>>> @return cannot be used in constructor documentation. It can\ >>>> only be used in the following types of documentation: method. >>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >>>> warning - @ is an unknown tag. >>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: >>>> warning - Tag @return cannot be used in field documentation\ >>>> . It can only be used in the following types of documentation: method. >>>> >>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: >>>> warning - @parm is an unknown tag. >>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: >>>> warning - @parm is an unknown tag. >>>> >>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: >>>> warning - @parm is an unknown tag. >>>> >>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: >>>> warning - @param argument "a_component" is not a p\ >>>> arameter name. >>>> >>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: >>>> warning - @param argument "a_component" is not a p\ >>>> arameter name. >>>> >>>> This patch against OpenJDK7: >>>> >>>> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >>>> >>>> fixes the warnings. >>>> >>>> Is this ok to push? If so, can I have a bug ID for it? >>>> >>>> Joe, would this also be ok for 6? >>>> >>>> Thanks, >>>> >>>> >>> cc'ing Ken Cavanaugh for corba matters. >>> >>> If this fix is approved for JDK 7, I approve it to also go back into >>> OpenJDK 6. >>> >>> Regards, >>> >>> -Joe >>> >>> >> > > Thanks Ken. I don't see you on http://db.openjdk.java.net/people so > not sure what I should use for the Reviewed-by field. > > Joe, can you allocate this a bug ID? > 6917485 Corba doc warnings You can use me as a reviewer for jcheck purposes. Have a good weekend, -Joe PS Monday is a holiday for Sun in the US. From ahughes at redhat.com Fri Jan 15 17:36:22 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Sat, 16 Jan 2010 01:36:22 +0000 Subject: hg: jdk6/jdk6/corba: 6917485: Corba doc warnings Message-ID: <20100116013624.5A9CF417C5@hg.openjdk.java.net> Changeset: 05436b84e93a Author: andrew Date: 2010-01-16 01:04 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/05436b84e93a 6917485: Corba doc warnings Summary: Fix warnings generated by javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/corba/se/idl/constExpr/Expression.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/SetOverrideType.java ! src/share/classes/org/omg/CORBA/TCKind.java ! src/share/classes/org/omg/CORBA/UnknownUserException.java ! src/share/classes/org/omg/CORBA/portable/ServantObject.java ! src/share/classes/org/omg/CosNaming/nameservice.idl ! src/share/classes/org/omg/PortableInterceptor/Interceptors.idl From gnu_andrew at member.fsf.org Fri Jan 15 17:56:36 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 16 Jan 2010 01:56:36 +0000 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <4B5103A2.20809@sun.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> <4B5103A2.20809@sun.com> Message-ID: <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> 2010/1/16 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2010/1/15 Ken Cavanaugh : >> >>> >>> The fixes look good to me. >>> >>> Thanks, >>> >>> Ken. >>> >>> On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: >>> >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >>>>> number of warnings when building documentation: >>>>> >>>>> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >>>>> warning - Tag @link: reference not found: Stub#connect >>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >>>>> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >>>>> t_policy_override >>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag >>>>> @return cannot be used in constructor documentation. ?It can\ >>>>> only be used in the following types of documentation: method. >>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >>>>> warning - @ is an unknown tag. >>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: >>>>> warning - Tag @return cannot be used in field documentation\ >>>>> . ?It can only be used in the following types of documentation: method. >>>>> >>>>> >>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: >>>>> warning - @parm is an unknown tag. >>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: >>>>> warning - @parm is an unknown tag. >>>>> >>>>> >>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: >>>>> warning - @parm is an unknown tag. >>>>> >>>>> >>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: >>>>> warning - @param argument "a_component" is not a p\ >>>>> arameter name. >>>>> >>>>> >>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: >>>>> warning - @param argument "a_component" is not a p\ >>>>> arameter name. >>>>> >>>>> This patch against OpenJDK7: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >>>>> >>>>> fixes the warnings. >>>>> >>>>> Is this ok to push? ?If so, can I have a bug ID for it? >>>>> >>>>> Joe, would this also be ok for 6? >>>>> >>>>> Thanks, >>>>> >>>>> >>>> >>>> cc'ing Ken Cavanaugh for corba matters. >>>> >>>> If this fix is approved for JDK 7, I approve it to also go back into >>>> OpenJDK 6. >>>> >>>> Regards, >>>> >>>> -Joe >>>> >>>> >>> >>> >> >> Thanks Ken. ?I don't see you on http://db.openjdk.java.net/people so >> not sure what I should use for the Reviewed-by field. >> >> Joe, can you allocate this a bug ID? >> > > 6917485 Corba doc warnings > > You can use me as a reviewer for jcheck purposes. > > Have a good weekend, > > -Joe > > PS Monday is a holiday for Sun in the US. > > Done: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/05436b84e93a http://hg.openjdk.java.net/jdk7/build/corba/rev/d4c077d44a64 With this fix as well: http://cr.openjdk.java.net/~andrew/build/webrev.05/ the main javadoc build passes with no warnings. There are two remaining warnings from doclets: /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - Tag @link: reference not found: com.sun.tools.doclets.internal.toolkit.util /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - Tag @link: reference not found: com.sun.tools.doclets.internal.toolkit.util 2 warnings -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Fri Jan 15 19:24:04 2010 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 15 Jan 2010 19:24:04 -0800 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> <4B5103A2.20809@sun.com> <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> Message-ID: <4B513154.1070802@sun.com> Andrew John Hughes wrote: > 2010/1/16 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2010/1/15 Ken Cavanaugh : >>> >>> >>>> The fixes look good to me. >>>> >>>> Thanks, >>>> >>>> Ken. >>>> >>>> On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: >>>> >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >>>>>> number of warnings when building documentation: >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >>>>>> warning - Tag @link: reference not found: Stub#connect >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >>>>>> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >>>>>> t_policy_override >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag >>>>>> @return cannot be used in constructor documentation. It can\ >>>>>> only be used in the following types of documentation: method. >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >>>>>> warning - @ is an unknown tag. >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: >>>>>> warning - Tag @return cannot be used in field documentation\ >>>>>> . It can only be used in the following types of documentation: method. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: >>>>>> warning - @parm is an unknown tag. >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: >>>>>> warning - @parm is an unknown tag. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: >>>>>> warning - @parm is an unknown tag. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: >>>>>> warning - @param argument "a_component" is not a p\ >>>>>> arameter name. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: >>>>>> warning - @param argument "a_component" is not a p\ >>>>>> arameter name. >>>>>> >>>>>> This patch against OpenJDK7: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >>>>>> >>>>>> fixes the warnings. >>>>>> >>>>>> Is this ok to push? If so, can I have a bug ID for it? >>>>>> >>>>>> Joe, would this also be ok for 6? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>> cc'ing Ken Cavanaugh for corba matters. >>>>> >>>>> If this fix is approved for JDK 7, I approve it to also go back into >>>>> OpenJDK 6. >>>>> >>>>> Regards, >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>> >>> Thanks Ken. I don't see you on http://db.openjdk.java.net/people so >>> not sure what I should use for the Reviewed-by field. >>> >>> Joe, can you allocate this a bug ID? >>> >>> >> 6917485 Corba doc warnings >> >> You can use me as a reviewer for jcheck purposes. >> >> Have a good weekend, >> >> -Joe >> >> PS Monday is a holiday for Sun in the US. >> >> >> > > Done: > > http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/05436b84e93a > http://hg.openjdk.java.net/jdk7/build/corba/rev/d4c077d44a64 > > With this fix as well: > > http://cr.openjdk.java.net/~andrew/build/webrev.05/ > > the main javadoc build passes with no warnings. There are two > remaining warnings from doclets: > > /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - > Tag @link: reference not found: > com.sun.tools.doclets.internal.toolkit.util > /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - > Tag @link: reference not found: > com.sun.tools.doclets.internal.toolkit.util > 2 warnings > > Andrew, I'll take care of the javadoc/doclets warnings if you like, unless you're wanting to get everything warning free right away. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100115/a019b2f1/attachment.html From gnu_andrew at member.fsf.org Fri Jan 15 20:03:59 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 16 Jan 2010 04:03:59 +0000 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <4B513154.1070802@sun.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> <4B5103A2.20809@sun.com> <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> <4B513154.1070802@sun.com> Message-ID: <17c6771e1001152003j6455ae4fi4e5beda8d2dfb2e0@mail.gmail.com> 2010/1/16 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2010/1/16 Joseph D. Darcy : > > > Andrew John Hughes wrote: > > > 2010/1/15 Ken Cavanaugh : > > > > The fixes look good to me. > > Thanks, > > Ken. > > On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: > > > > > Andrew John Hughes wrote: > > > > When building documentation, both OpenJDK6 and OpenJDK7 spit out a > number of warnings when building documentation: > > /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: > warning - Tag @link: reference not found: Stub#connect > /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: > warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ > t_policy_override > /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag > @return cannot be used in constructor documentation. ?It can\ > only be used in the following types of documentation: method. > /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: > warning - @ is an unknown tag. > /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: > warning - Tag @return cannot be used in field documentation\ > . ?It can only be used in the following types of documentation: method. > > > /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: > warning - @parm is an unknown tag. > /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: > warning - @parm is an unknown tag. > > > /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: > warning - @parm is an unknown tag. > > > /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: > warning - @param argument "a_component" is not a p\ > arameter name. > > > /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: > warning - @param argument "a_component" is not a p\ > arameter name. > > This patch against OpenJDK7: > > http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch > > fixes the warnings. > > Is this ok to push? ?If so, can I have a bug ID for it? > > Joe, would this also be ok for 6? > > Thanks, > > > > > cc'ing Ken Cavanaugh for corba matters. > > If this fix is approved for JDK 7, I approve it to also go back into > OpenJDK 6. > > Regards, > > -Joe > > > > > > > Thanks Ken. ?I don't see you on http://db.openjdk.java.net/people so > not sure what I should use for the Reviewed-by field. > > Joe, can you allocate this a bug ID? > > > > 6917485 Corba doc warnings > > You can use me as a reviewer for jcheck purposes. > > Have a good weekend, > > -Joe > > PS Monday is a holiday for Sun in the US. > > > > > Done: > > http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/05436b84e93a > http://hg.openjdk.java.net/jdk7/build/corba/rev/d4c077d44a64 > > With this fix as well: > > http://cr.openjdk.java.net/~andrew/build/webrev.05/ > > the main javadoc build passes with no warnings. There are two > remaining warnings from doclets: > > /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - > Tag @link: reference not found: > com.sun.tools.doclets.internal.toolkit.util > /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - > Tag @link: reference not found: > com.sun.tools.doclets.internal.toolkit.util > 2 warnings > > > > Andrew, > > I'll take care of the javadoc/doclets warnings if you like, unless you're > wanting to get everything warning free right away. > > -- Jon > No, there's no rush. Actually, I was hoping you'd say that because I wasn't sure how to fix those ;-) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ptisnovs at redhat.com Mon Jan 18 06:42:27 2010 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Mon, 18 Jan 2010 14:42:27 +0000 Subject: hg: jdk6/jdk6/jdk: 6917663: test/java/security/Provider/Turkish.java not samevm friendly Message-ID: <20100118144240.596FC41BA7@hg.openjdk.java.net> Changeset: ea5036d799e5 Author: ptisnovs Date: 2010-01-18 15:41 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ea5036d799e5 6917663: test/java/security/Provider/Turkish.java not samevm friendly Summary: Added othervm flag to ensure that this test will run in isolation. Reviewed-by: alanb ! test/java/security/Provider/Turkish.java From gnu_andrew at member.fsf.org Mon Jan 18 10:56:00 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 18 Jan 2010 18:56:00 +0000 Subject: Request for Review: 6915313 In-Reply-To: <4B475F7D.7040401@Sun.COM> References: <4B475C9B.5050207@Sun.COM> <17c6771e1001080832s7e794de9id6bb3e96636e06f5@mail.gmail.com> <4B475F7D.7040401@Sun.COM> Message-ID: <17c6771e1001181056l6ade4883o2e8097b4413d1082@mail.gmail.com> 2010/1/8 Christopher Hegarty - Sun Microsystems Ireland : > > On 08/01/2010 16:32, Andrew John Hughes wrote: >> >> .... >> >> For OpenJDK6, I think it would be better to port over SCTP after the >> b18 release which is currently undergoing final testing. ?So please >> don't push anything to the OpenJDK6 repositories just yet :-) > > Oh, maybe the bug description is a little misleading. What this bug plans to > do is simply reorganize the SCTP implementation in JDK7 so that it can be > ripped out and bolted onto a standard Sun JDK6 (if that's the kind of thing > you like to do!). There are no changes planned for OpenJDK6, just JDK7. > > -Chris. > Yeah, I got that this was a patch for OpenJDK7, but I thought the long term goal was to backport SCTP to OpenJDK6, not just provide the hack approach of http://openjdk.java.net/projects/sctp/html/sctp6.html with 'standard Sun JDK6' (whatever that is - I guess you mean the proprietary Sun JDK6 builds). I think it would be nice to provide this backport as an option with IcedTea6. Then users could use this with 6 out of the box. Do you know what impact this would have when built with OpenJDK6 (rather than hacked into an existing proprietary build built against ancient system libraries)? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Mon Jan 18 11:58:13 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 18 Jan 2010 19:58:13 +0000 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B50AAD1.4000404@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> Message-ID: <20100118195813.GA32693@rivendell.middle-earth.co.uk> On 09:50 Fri 15 Jan , Joe Wang wrote: > Thanks Alan. Yes, I did receive the bugzilla notice. > > Kelly told me that he applied the same jaxp source tarball to OpenJDK6. > Kelly, could you tell Andrew how to include the jaxp source tarball when > building OpenJDK6? > The tarball jdk6-jaxp-2009_10_27.zip used by the OpenJDK6 build does not include the fix. We are still having to apply the patch: diff -Nru openjdk.orig/jaxp/build.properties openjdk/jaxp/build.properties --- openjdk.orig/jaxp/build.properties 2009-12-08 17:42:33.000000000 +0000 +++ openjdk/jaxp/build.properties 2009-12-08 17:43:03.000000000 +0000 @@ -73,6 +73,9 @@ # Where patches to drop bundle sources live patches.dir=patches +# Patches to apply +jaxp_src.patch.list=xml-encodinginfo.patch + # Sanity information sanity.info= Sanity Settings:${line.separator}\ ant.home=${ant.home}${line.separator}\ diff -Nru openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch --- openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch 1970-01-01 01:00:00.000000000 +0100 +++ openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch 2009-12-08 17:41:58.000000000 +0000 @@ -0,0 +1,18 @@ +diff -Nru src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java +--- src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java 2009-10-27 21:54:16.000000000 +0000 ++++ src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java 2009-12-08 17:40:14.000000000 +0000 +@@ -326,9 +326,11 @@ + m_last = last; + + // Set the range of unicode values that this object +- // explicitly manages +- m_explFirst = codePoint; +- m_explLast = codePoint + (RANGE-1); ++ // explicitly manages. Align the explicitly managed values ++ // to RANGE so multiple EncodingImpl objects dont manage the same ++ // values. ++ m_explFirst = codePoint / RANGE * RANGE; ++ m_explLast = m_explFirst + (RANGE-1); + + m_encoding = encoding; + BTW, we have a testcase for this. Would it be possible to add this to the JDK tree? The complete patch included in the icedtea6-hg tree (http://icedtea.classpath.org/people/andrew/icedtea6-hg), including test case, is attached. > Thanks, > Joe > > > Alan Bateman wrote: >> Joe - I don't know if you get notifications from the bugzilla on >> bugs.openjdk.java.net but can you reply to Andrew on this one? >> >> >> >> bugzilla-daemon at bugs.openjdk.java.net wrote: >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100017 >>> >>> >>> Andrew John Hughes changed: >>> >>> What |Removed |Added >>> ---------------------------------------------------------------------------- >>> Status|FIXDELIVERED |FIXAVAILABLE >>> Resolution|FIXED | >>> >>> >>> >>> >>> --- Comment #7 from Andrew John Hughes 2010-01-15 >>> 07:32:22 PDT --- >>> This fix is not yet in OpenJDK6. When will the JAXP tarballs be updated >>> with >>> this fix? >>> >>> >> > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -------------- next part -------------- --- /dev/null 2009-03-12 10:05:36.797002285 -0400 +++ openjdk/jdk/test/com/sun/org/apache/xml/internal/serializer/XMLStackOverflowBug.java 2009-03-13 16:10:05.000000000 -0400 @@ -0,0 +1,58 @@ +/* + * Copyright 2009 Red Hat, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ + +/* + * @test + * @summary Check that the xml encoder doesnt cause a StackOverflowError + * + */ + +import java.io.IOException; + +import javax.xml.transform.TransformerConfigurationException; +import javax.xml.transform.TransformerFactory; +import javax.xml.transform.sax.SAXTransformerFactory; +import javax.xml.transform.sax.TransformerHandler; +import javax.xml.transform.stream.StreamResult; + +import org.xml.sax.SAXException; + +public class XMLStackOverflowBug { + + public static void main(String[] args) + throws TransformerConfigurationException, IOException, SAXException { + + SAXTransformerFactory stf = (SAXTransformerFactory) TransformerFactory + .newInstance(); + TransformerHandler ser = stf.newTransformerHandler(); + ser.setResult(new StreamResult(System.out)); + + StringBuilder sb = new StringBuilder(4096); + for (int x = 4096; x > 0; x--) { + sb.append((char)x); + } + ser.characters(sb.toString().toCharArray(), 0, sb.toString().toCharArray().length); + ser.endDocument(); + } +} + diff -Nru openjdk.orig/jaxp/build.properties openjdk/jaxp/build.properties --- openjdk.orig/jaxp/build.properties 2009-12-08 17:42:33.000000000 +0000 +++ openjdk/jaxp/build.properties 2009-12-08 17:43:03.000000000 +0000 @@ -73,6 +73,9 @@ # Where patches to drop bundle sources live patches.dir=patches +# Patches to apply +jaxp_src.patch.list=xml-encodinginfo.patch + # Sanity information sanity.info= Sanity Settings:${line.separator}\ ant.home=${ant.home}${line.separator}\ diff -Nru openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch --- openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch 1970-01-01 01:00:00.000000000 +0100 +++ openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch 2009-12-08 17:41:58.000000000 +0000 @@ -0,0 +1,18 @@ +diff -Nru src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java +--- src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java 2009-10-27 21:54:16.000000000 +0000 ++++ src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java 2009-12-08 17:40:14.000000000 +0000 +@@ -326,9 +326,11 @@ + m_last = last; + + // Set the range of unicode values that this object +- // explicitly manages +- m_explFirst = codePoint; +- m_explLast = codePoint + (RANGE-1); ++ // explicitly manages. Align the explicitly managed values ++ // to RANGE so multiple EncodingImpl objects dont manage the same ++ // values. ++ m_explFirst = codePoint / RANGE * RANGE; ++ m_explLast = m_explFirst + (RANGE-1); + + m_encoding = encoding; + From mstjohns at comcast.net Wed Jan 20 10:05:28 2010 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 20 Jan 2010 13:05:28 -0500 Subject: [security-dev 01253]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4ABBAD55.7070206@sun.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> Message-ID: <20100120180532.5D2E364A1@mail.openjdk.java.net> Hi - this seems to have stalled out again. Any chance of revival? Mike At 12:33 PM 9/24/2009, Vincent Ryan wrote: >Hello Andrew, > >I'll need a little more time to come up to speed on this fix. I'm concerned that >there may be interoperability or backwards compatibility issues. > > > >Andrew John Hughes wrote: >> 2009/9/2 Andrew John Hughes : >>> 2009/9/2 Michael StJohns : >>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>> 2009/9/2 Michael StJohns : >>>>>> ?? This appears to be related specifically to PKCS11.?? Specifically, PKCS11 >>>>>> v2.20 has some ambiguity of the representation of an EC point (which is >>>>>> different in the text than an ASN1 ECPoint). >>>>>> >>>>>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>>>>> format described in?? X9.62, where the first octet indicates the encoding and >>>>>> there are either N or 2N octets following)?? being the expected value, but >>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>> >>>>>> One of the reasons for going that way was how the JDK PKCS11 provider had >>>>>> interpreted the issue and implemented its code. >>>>>> >>>>>> I don't support this fix - among other things, this fix only deals with 1/2 >>>>>> of the problem.?? The other half is related to encoding the value.?? Also, >>>>>> changing the code at decodePoint seems further into the stack than needed >>>>>> and may affect other uses of that method. >>>>>> >>>>> That's really too vague to be of much help in improving the patch. >>>>> You seem to be saying little more than 'I don't like it'. >>>> Sorry about that. My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >>>> >>>> >>>>>> There's an existing JDK bug on this coming at it from a different direction >>>>>> - 6763530 ... and there may be considerations at >>>>>> >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>> >>>>> It seems likely that's the NSS change that causes the current failure. >>>>> The fix I submitted here is based on the way this is handle in NSS. >>>>> In fact, the code is similar enough to suggest that one was developed >>>> >from the other. >>>>>> ?? that should be looked at. >>>>> The JDK bug is not really 'from a different direction', it's reporting >>>>> exactly the same error but from a less trivial example (I get the same >>>>> failure while trying to create an example key, while this seems to >>>>> require specific hardware if I'm reading it correctly). >>>> Not exactly. You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >>>> >>>> >>>>> Also see 6779460 which is mostly a duplicate of >>>>>> 6763530. >>>>>> >>>>> The patch on 6779460 seems wrong. It means that the method will >>>>> return a DER-encoded value where it would either have returned an >>>>> uncompressed value before or failed. >>>> My point exactly as I mentioned in the comments. :-) >>>> >>>> >>>>>> It's probable that the fix I suggested at 6763530?? (in comments submitted 29 >>>>>> Nov 08) may be a better approach given the NSS fixes.?? I believe it will fix >>>>>> the keytool problem noted in the original message. >>>>>> >>>>> Ok, I can see the logic in the fix and it would appear to work, though >>>>> I haven't tested it. >>>>> Given the patch was written nine months ago, why has it not been >>>>> applied? If it had, it would have saved me hours having to debug this >>>>> same issue again. >>>> Yup. I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >>>> >>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on your >>>>> patch and we can finally get this fixed. Without it, NSS support is >>>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>>> priority bug! >>>> I do have an SCA on file. Note that the recommendation from the NSS guys was to raise the priority. >>>> >>>> The reason I haven't submitted this is because I submitted a different EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process >>>> and was waiting on progress there before continuing. I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. And then I got busy with some other things... >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2009/8/28 Andrew John Hughes : >>>>>> >>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>> >>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>> >>>>>> If NSS is configured as specified in this blog, keytool can be used to >>>>>> generate a key as follows: >>>>>> >>>>>> Hello. >>>>>> >>>>>> Allowing keytool and friends to work in more cases if the provider is >>>>>> capable seems fine to me. >>>>>> >>>>>> Security team, do you have concerns about this patch? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>> >>>>> >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>>> >>> Ok here is a new webrev: >>> >>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>> >>> with a slightly revised version of your change (you can't throw a >>> PKCS11Exception which only takes a long ID from the native code, so I >>> changed this to an IllegalArgumentException). >>> >>> Security team, does this look ok to push? >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> >> Ping! Security developers, any thoughts on this patch: >> >> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >> >> Does it look ok to push? >> >> Thanks, From gnu_andrew at member.fsf.org Wed Jan 20 10:06:43 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 20 Jan 2010 18:06:43 +0000 Subject: [security-dev 01253]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4b5745f0.8f53f10a.4f8d.ffff8f81SMTPIN_ADDED@mx.google.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <4b5745f0.8f53f10a.4f8d.ffff8f81SMTPIN_ADDED@mx.google.com> Message-ID: <17c6771e1001201006l3cb4046uc49c2ebd2e2714c0@mail.gmail.com> 2010/1/20 Michael StJohns : > Hi - this seems to have stalled out again. ?Any chance of revival? > Never mind stalled, it doesn't appear to have even started to begin with! We do ship the patch with IcedTea6. If Sun don't want the fix for OpenJDK itself, I guess that's their problem. > Mike > > > At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>Hello Andrew, >> >>I'll need a little more time to come up to speed on this fix. I'm concerned that >>there may be interoperability or backwards compatibility issues. >> >> >> >>Andrew John Hughes wrote: >>> 2009/9/2 Andrew John Hughes : >>>> 2009/9/2 Michael StJohns : >>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>> 2009/9/2 Michael StJohns : >>>>>>> ?? This appears to be related specifically to PKCS11.?? ?Specifically, PKCS11 >>>>>>> v2.20 has some ambiguity of the representation of an EC point (which is >>>>>>> different in the text than an ASN1 ECPoint). >>>>>>> >>>>>>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>>>>>> format described in?? ?X9.62, where the first octet indicates the encoding and >>>>>>> there are either N or 2N octets following)?? ?being the expected value, but >>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>> >>>>>>> One of the reasons for going that way was how the JDK PKCS11 provider had >>>>>>> interpreted the issue and implemented its code. >>>>>>> >>>>>>> I don't support this fix - among other things, this fix only deals with 1/2 >>>>>>> of the problem.?? ?The other half is related to encoding the value.?? ?Also, >>>>>>> changing the code at decodePoint seems further into the stack than needed >>>>>>> and may affect other uses of that method. >>>>>>> >>>>>> That's really too vague to be of much help in improving the patch. >>>>>> You seem to be saying little more than 'I don't like it'. >>>>> Sorry about that. ?My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >>>>> >>>>> >>>>>>> There's an existing JDK bug on this coming at it from a different direction >>>>>>> - 6763530 ... and there may be considerations at >>>>>>> >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>> >>>>>> It seems likely that's the NSS change that causes the current failure. >>>>>> The fix I submitted here is based on the way this is handle in NSS. >>>>>> In fact, the code is similar enough to suggest that one was developed >>>>> >from the other. >>>>>>> ?? that should be looked at. >>>>>> The JDK bug is not really 'from a different direction', it's reporting >>>>>> exactly the same error but from a less trivial example (I get the same >>>>>> failure while trying to create an example key, while this seems to >>>>>> require specific hardware if I'm reading it correctly). >>>>> Not exactly. ?You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >>>>> >>>>> >>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>> 6763530. >>>>>>> >>>>>> The patch on 6779460 seems wrong. ?It means that the method will >>>>>> return a DER-encoded value where it would either have returned an >>>>>> uncompressed value before or failed. >>>>> My point exactly as I mentioned in the comments. ?:-) >>>>> >>>>> >>>>>>> It's probable that the fix I suggested at 6763530?? ?(in comments submitted 29 >>>>>>> Nov 08) may be a better approach given the NSS fixes.?? ?I believe it will fix >>>>>>> the keytool problem noted in the original message. >>>>>>> >>>>>> Ok, I can see the logic in the fix and it would appear to work, though >>>>>> I haven't tested it. >>>>>> Given the patch was written nine months ago, why has it not been >>>>>> applied? ?If it had, it would have saved me hours having to debug this >>>>>> same issue again. >>>>> Yup. ?I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >>>>> >>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on your >>>>>> patch and we can finally get this fixed. ?Without it, NSS support is >>>>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>>>> priority bug! >>>>> I do have an SCA on file. ?Note that the recommendation from the NSS guys was to raise the priority. >>>>> >>>>> The reason I haven't submitted this is because I submitted a different EC fix ?https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process >>>>> ?and was waiting on progress there before continuing. ?I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. ?And then I got busy with some other things... >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>> >>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>> >>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>> >>>>>>> If NSS is configured as specified in this blog, keytool can be used to >>>>>>> generate a key as follows: >>>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> Allowing keytool and friends to work in more cases if the provider is >>>>>>> capable seems fine to me. >>>>>>> >>>>>>> Security team, do you have concerns about this patch? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>> Ok here is a new webrev: >>>> >>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>> >>>> with a slightly revised version of your change (you can't throw a >>>> PKCS11Exception which only takes a long ID from the native code, so I >>>> changed this to an IllegalArgumentException). >>>> >>>> Security team, does this look ok to push? >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>> >>> >>> Ping! Security developers, any thoughts on this patch: >>> >>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>> >>> Does it look ok to push? >>> >>> Thanks, > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From daniel.daugherty at sun.com Wed Jan 20 12:14:48 2010 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 20 Jan 2010 20:14:48 +0000 Subject: hg: jdk6/jdk6/hotspot: 2 new changesets Message-ID: <20100120201454.3E29641F1C@hg.openjdk.java.net> Changeset: 7fbf850d87b7 Author: dcubed Date: 2010-01-13 09:39 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/7fbf850d87b7 6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining Summary: Add support for additional implementation specific info to the JVM/TI CompiledMethodLoad event via the compile_info parameter. Reviewed-by: never, ohair, tbell, tdeneau Contributed-by: Vasanth Venkatachalam ! make/Makefile ! make/defs.make + src/share/vm/code/jvmticmlr.h ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiExport.cpp Changeset: 7dbe24cb959c Author: dcubed Date: 2010-01-20 10:35 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/7dbe24cb959c Merge ! make/Makefile ! make/defs.make ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiExport.cpp From daniel.daugherty at sun.com Wed Jan 20 14:10:34 2010 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 20 Jan 2010 22:10:34 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20100120221059.DAE8E41F3D@hg.openjdk.java.net> Changeset: 6073840fbd22 Author: dcubed Date: 2010-01-13 09:42 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/6073840fbd22 6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining Summary: Add support for additional implementation specific info to the JVM/TI CompiledMethodLoad event via the compile_info parameter. Reviewed-by: never, ohair, tbell, tdeneau Contributed-by: Vasanth Venkatachalam ! make/common/shared/Sanity.gmk ! make/java/jvm/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/jvmti/README.txt + make/mkdemo/jvmti/compiledMethodLoad/Makefile + src/share/demo/jvmti/compiledMethodLoad/README.txt + src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c + src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/index.html + src/share/javavm/export/jvmticmlr.h + test/demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java ! test/demo/jvmti/heapTracker/HeapTrackerTest.java ! test/demo/jvmti/hprof/CpuTimesDefineClassTest.java ! test/demo/jvmti/hprof/CpuTimesTest.java ! test/demo/jvmti/minst/MinstTest.java ! test/demo/jvmti/mtrace/TraceJFrame.java Changeset: b2510c4f0228 Author: dcubed Date: 2010-01-20 11:47 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b2510c4f0228 Merge From gnu_andrew at member.fsf.org Wed Jan 20 14:16:59 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 20 Jan 2010 22:16:59 +0000 Subject: [security-dev 01541]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> Message-ID: <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> 2010/1/20 Tomas Gustavsson : > > I'll second this request. This is a critical patch and many production > installations have to live with this manually patched now. > > I know of no pkcs11 implementation that works with the current code. > It has four votes: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 I don't know how many they need to wake up and review the patch. The new release of IcedTea6 1.7 is imminent and will include the fix so it should at least be resolved on the next version shipping with most GNU/Linux distributions. > Regards, > Tomas Gustavsson > PrimeKey Solutions AB > > > On Wed, 20 Jan 2010, Michael StJohns wrote: > >> Hi - this seems to have stalled out again. ?Any chance of revival? >> >> Mike >> >> >> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>> >>> Hello Andrew, >>> >>> I'll need a little more time to come up to speed on this fix. I'm >>> concerned that >>> there may be interoperability or backwards compatibility issues. >>> >>> >>> >>> Andrew John Hughes wrote: >>>> >>>> 2009/9/2 Andrew John Hughes : >>>>> >>>>> 2009/9/2 Michael StJohns : >>>>>> >>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>> >>>>>>> 2009/9/2 Michael StJohns : >>>>>>>> >>>>>>>> ?? This appears to be related specifically to PKCS11.?? >>>>>>>> ?Specifically, PKCS11 >>>>>>>> v2.20 has some ambiguity of the representation of an EC point (which >>>>>>>> is >>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>> >>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>> (e.g.the >>>>>>>> format described in?? ?X9.62, where the first octet indicates the >>>>>>>> encoding and >>>>>>>> there are either N or 2N octets following)?? ?being the expected >>>>>>>> value, but >>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>> >>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>> provider had >>>>>>>> interpreted the issue and implemented its code. >>>>>>>> >>>>>>>> I don't support this fix - among other things, this fix only deals >>>>>>>> with 1/2 >>>>>>>> of the problem.?? ?The other half is related to encoding the >>>>>>>> value.?? ?Also, >>>>>>>> changing the code at decodePoint seems further into the stack than >>>>>>>> needed >>>>>>>> and may affect other uses of that method. >>>>>>>> >>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>> >>>>>> Sorry about that. ?My point was that your patch didn't completely >>>>>> solve the problem and that the point at where you were fixing it could have >>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>> >>>>>> >>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>> direction >>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>> >>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>> >>>>>>> It seems likely that's the NSS change that causes the current >>>>>>> failure. >>>>>>> The fix I submitted here is based on the way this is handle in NSS. >>>>>>> In fact, the code is similar enough to suggest that one was developed >>>>>>> from the other. >>>>>>>> >>>>>>>> ?? that should be looked at. >>>>>>> >>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>> reporting >>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>> same >>>>>>> failure while trying to create an example key, while this seems to >>>>>>> require specific hardware if I'm reading it correctly). >>>>>> >>>>>> Not exactly. ?You're using the NSS as a PKCS11 module - this problem >>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>> >>>>>> >>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>> >>>>>>>> 6763530. >>>>>>>> >>>>>>> The patch on 6779460 seems wrong. ?It means that the method will >>>>>>> return a DER-encoded value where it would either have returned an >>>>>>> uncompressed value before or failed. >>>>>> >>>>>> My point exactly as I mentioned in the comments. ?:-) >>>>>> >>>>>> >>>>>>>> It's probable that the fix I suggested at 6763530?? ?(in comments >>>>>>>> submitted 29 >>>>>>>> Nov 08) may be a better approach given the NSS fixes.?? ?I believe >>>>>>>> it will fix >>>>>>>> the keytool problem noted in the original message. >>>>>>>> >>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>> though >>>>>>> I haven't tested it. >>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>> applied? ?If it had, it would have saved me hours having to debug >>>>>>> this >>>>>>> same issue again. >>>>>> >>>>>> Yup. ?I did do a search for PKCS11 related bugs when I encountered the >>>>>> same problem and did find the original error. >>>>>> >>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>> your >>>>>>> patch and we can finally get this fixed. ?Without it, NSS support is >>>>>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>>>>> priority bug! >>>>>> >>>>>> I do have an SCA on file. ?Note that the recommendation from the NSS >>>>>> guys was to raise the priority. >>>>>> >>>>>> The reason I haven't submitted this is because I submitted a different >>>>>> EC fix ?https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the >>>>>> documented process >>>>>> ?and was waiting on progress there before continuing. ?I've got a >>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I was trying >>>>>> for a worked example before proceeding. ?And then I got busy with some other >>>>>> things... >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>> >>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>> available >>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>> >>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>> >>>>>>>> If NSS is configured as specified in this blog, keytool can be used >>>>>>>> to >>>>>>>> generate a key as follows: >>>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> Allowing keytool and friends to work in more cases if the provider >>>>>>>> is >>>>>>>> capable seems fine to me. >>>>>>>> >>>>>>>> Security team, do you have concerns about this patch? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Andrew :-) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>>> >>>>>> >>>>> Ok here is a new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>> >>>>> with a slightly revised version of your change (you can't throw a >>>>> PKCS11Exception which only takes a long ID from the native code, so I >>>>> changed this to an IllegalArgumentException). >>>>> >>>>> Security team, does this look ok to push? >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>> >>>> >>>> Ping! Security developers, any thoughts on this patch: >>>> >>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>> >>>> Does it look ok to push? >>>> >>>> Thanks, >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Vincent.Ryan at Sun.COM Thu Jan 21 02:12:25 2010 From: Vincent.Ryan at Sun.COM (Vincent Ryan) Date: Thu, 21 Jan 2010 10:12:25 +0000 Subject: [security-dev 01544]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4B5805DD.8060101@primekey.se> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> <4B5805DD.8060101@primekey.se> Message-ID: <4B582889.6080903@sun.com> I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. On 21/01/2010 07:44, Tomas Gustavsson wrote: > > Now it has one more vote. > > /Tomas > > Andrew John Hughes wrote: >> 2010/1/20 Tomas Gustavsson : >>> I'll second this request. This is a critical patch and many production >>> installations have to live with this manually patched now. >>> >>> I know of no pkcs11 implementation that works with the current code. >>> >> >> It has four votes: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 >> I don't know how many they need to wake up and review the patch. >> >> The new release of IcedTea6 1.7 is imminent and will include the fix >> so it should at least be resolved on the next version shipping with >> most GNU/Linux distributions. >> >>> Regards, >>> Tomas Gustavsson >>> PrimeKey Solutions AB >>> >>> >>> On Wed, 20 Jan 2010, Michael StJohns wrote: >>> >>>> Hi - this seems to have stalled out again. Any chance of revival? >>>> >>>> Mike >>>> >>>> >>>> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>>>> Hello Andrew, >>>>> >>>>> I'll need a little more time to come up to speed on this fix. I'm >>>>> concerned that >>>>> there may be interoperability or backwards compatibility issues. >>>>> >>>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>>> 2009/9/2 Andrew John Hughes : >>>>>>> 2009/9/2 Michael StJohns : >>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>> ?? This appears to be related specifically to PKCS11.?? >>>>>>>>>> Specifically, PKCS11 >>>>>>>>>> v2.20 has some ambiguity of the representation of an EC point >>>>>>>>>> (which >>>>>>>>>> is >>>>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>>>> >>>>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>>>> (e.g.the >>>>>>>>>> format described in?? X9.62, where the first octet indicates the >>>>>>>>>> encoding and >>>>>>>>>> there are either N or 2N octets following)?? being the expected >>>>>>>>>> value, but >>>>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>>>> >>>>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>>>> provider had >>>>>>>>>> interpreted the issue and implemented its code. >>>>>>>>>> >>>>>>>>>> I don't support this fix - among other things, this fix only >>>>>>>>>> deals >>>>>>>>>> with 1/2 >>>>>>>>>> of the problem.?? The other half is related to encoding the >>>>>>>>>> value.?? Also, >>>>>>>>>> changing the code at decodePoint seems further into the stack >>>>>>>>>> than >>>>>>>>>> needed >>>>>>>>>> and may affect other uses of that method. >>>>>>>>>> >>>>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>>>> Sorry about that. My point was that your patch didn't completely >>>>>>>> solve the problem and that the point at where you were fixing it >>>>>>>> could have >>>>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>>>> >>>>>>>> >>>>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>>>> direction >>>>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>>>> >>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>>>> >>>>>>>>> It seems likely that's the NSS change that causes the current >>>>>>>>> failure. >>>>>>>>> The fix I submitted here is based on the way this is handle in >>>>>>>>> NSS. >>>>>>>>> In fact, the code is similar enough to suggest that one was >>>>>>>>> developed >>>>>>>>> from the other. >>>>>>>>>> ?? that should be looked at. >>>>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>>>> reporting >>>>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>>>> same >>>>>>>>> failure while trying to create an example key, while this seems to >>>>>>>>> require specific hardware if I'm reading it correctly). >>>>>>>> Not exactly. You're using the NSS as a PKCS11 module - this >>>>>>>> problem >>>>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>>>> >>>>>>>> >>>>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>>>> 6763530. >>>>>>>>>> >>>>>>>>> The patch on 6779460 seems wrong. It means that the method will >>>>>>>>> return a DER-encoded value where it would either have returned an >>>>>>>>> uncompressed value before or failed. >>>>>>>> My point exactly as I mentioned in the comments. :-) >>>>>>>> >>>>>>>> >>>>>>>>>> It's probable that the fix I suggested at 6763530?? (in comments >>>>>>>>>> submitted 29 >>>>>>>>>> Nov 08) may be a better approach given the NSS fixes.?? I >>>>>>>>>> believe >>>>>>>>>> it will fix >>>>>>>>>> the keytool problem noted in the original message. >>>>>>>>>> >>>>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>>>> though >>>>>>>>> I haven't tested it. >>>>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>>>> applied? If it had, it would have saved me hours having to debug >>>>>>>>> this >>>>>>>>> same issue again. >>>>>>>> Yup. I did do a search for PKCS11 related bugs when I >>>>>>>> encountered the >>>>>>>> same problem and did find the original error. >>>>>>>> >>>>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>>>> your >>>>>>>>> patch and we can finally get this fixed. Without it, NSS >>>>>>>>> support is >>>>>>>>> completely broken in OpenJDK6 which makes me wonder why this is >>>>>>>>> a low >>>>>>>>> priority bug! >>>>>>>> I do have an SCA on file. Note that the recommendation from the >>>>>>>> NSS >>>>>>>> guys was to raise the priority. >>>>>>>> >>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>> different >>>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>> the >>>>>>>> documented process >>>>>>>> and was waiting on progress there before continuing. I've got a >>>>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I >>>>>>>> was trying >>>>>>>> for a worked example before proceeding. And then I got busy >>>>>>>> with some other >>>>>>>> things... >>>>>>>> >>>>>>>> Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> Mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>>>> >>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>> >>>>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>>>> >>>>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>>>> available >>>>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>>>> >>>>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>>>> >>>>>>>>>> If NSS is configured as specified in this blog, keytool can be >>>>>>>>>> used >>>>>>>>>> to >>>>>>>>>> generate a key as follows: >>>>>>>>>> >>>>>>>>>> Hello. >>>>>>>>>> >>>>>>>>>> Allowing keytool and friends to work in more cases if the >>>>>>>>>> provider >>>>>>>>>> is >>>>>>>>>> capable seems fine to me. >>>>>>>>>> >>>>>>>>>> Security team, do you have concerns about this patch? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Joe >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Andrew :-) >>>>>>>>> >>>>>>>>> Free Java Software Engineer >>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>> >>>>>>>>> Support Free Java! >>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>> http://openjdk.java.net >>>>>>>>> >>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>> >>>>>>> Ok here is a new webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>> >>>>>>> with a slightly revised version of your change (you can't throw a >>>>>>> PKCS11Exception which only takes a long ID from the native code, >>>>>>> so I >>>>>>> changed this to an IllegalArgumentException). >>>>>>> >>>>>>> Security team, does this look ok to push? >>>>>>> -- >>>>>>> Andrew :-) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>> >>>>>> Ping! Security developers, any thoughts on this patch: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>> >>>>>> Does it look ok to push? >>>>>> >>>>>> Thanks, >> >> >> From Christopher.Hegarty at Sun.COM Thu Jan 21 05:50:08 2010 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland) Date: Thu, 21 Jan 2010 13:50:08 +0000 Subject: Request for Review: 6915313 In-Reply-To: <17c6771e1001181056l6ade4883o2e8097b4413d1082@mail.gmail.com> References: <4B475C9B.5050207@Sun.COM> <17c6771e1001080832s7e794de9id6bb3e96636e06f5@mail.gmail.com> <4B475F7D.7040401@Sun.COM> <17c6771e1001181056l6ade4883o2e8097b4413d1082@mail.gmail.com> Message-ID: <4B585B90.10905@sun.com> Andrew John Hughes wrote: > 2010/1/8 Christopher Hegarty - Sun Microsystems Ireland > : >> On 08/01/2010 16:32, Andrew John Hughes wrote: >>> .... >>> >>> For OpenJDK6, I think it would be better to port over SCTP after the >>> b18 release which is currently undergoing final testing. So please >>> don't push anything to the OpenJDK6 repositories just yet :-) >> Oh, maybe the bug description is a little misleading. What this bug plans to >> do is simply reorganize the SCTP implementation in JDK7 so that it can be >> ripped out and bolted onto a standard Sun JDK6 (if that's the kind of thing >> you like to do!). There are no changes planned for OpenJDK6, just JDK7. >> >> -Chris. >> > > Yeah, I got that this was a patch for OpenJDK7, but I thought the long > term goal was to backport SCTP to OpenJDK6, not just provide the hack > approach of http://openjdk.java.net/projects/sctp/html/sctp6.html with > 'standard Sun JDK6' (whatever that is - I guess you mean the > proprietary Sun JDK6 builds). Yes, this is correct. > I think it would be nice to provide this backport as an option with > IcedTea6. Then users could use this with 6 out of the box. Do you > know what impact this would have when built with OpenJDK6 (rather than > hacked into an existing proprietary build built against ancient system > libraries)? I think building the SCTP source with OpenJDK6 should not be a problem. -Chris. From mstjohns at comcast.net Thu Jan 21 09:28:02 2010 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 21 Jan 2010 12:28:02 -0500 Subject: [security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4B582889.6080903@sun.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> <4B5805DD.8060101@primekey.se> <4B582889.6080903@sun.com> Message-ID: <20100121172807.9DBCA6AC8@mail.openjdk.java.net> At 05:12 AM 1/21/2010, Vincent Ryan wrote: >I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. I don't suppose I could get a two-fer and get this one done as well? It's been sitting around for even longer. >>>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>>> different >>>>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>>> the Mike >On 21/01/2010 07:44, Tomas Gustavsson wrote: >> >> Now it has one more vote. >> >> /Tomas >> >> Andrew John Hughes wrote: >>> 2010/1/20 Tomas Gustavsson : >>>> I'll second this request. This is a critical patch and many production >>>> installations have to live with this manually patched now. >>>> >>>> I know of no pkcs11 implementation that works with the current code. >>>> >>> >>> It has four votes: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 >>> I don't know how many they need to wake up and review the patch. >>> >>> The new release of IcedTea6 1.7 is imminent and will include the fix >>> so it should at least be resolved on the next version shipping with >>> most GNU/Linux distributions. >>> >>>> Regards, >>>> Tomas Gustavsson >>>> PrimeKey Solutions AB >>>> >>>> >>>> On Wed, 20 Jan 2010, Michael StJohns wrote: >>>> >>>>> Hi - this seems to have stalled out again. Any chance of revival? >>>>> >>>>> Mike >>>>> >>>>> >>>>> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>>>>> Hello Andrew, >>>>>> >>>>>> I'll need a little more time to come up to speed on this fix. I'm >>>>>> concerned that >>>>>> there may be interoperability or backwards compatibility issues. >>>>>> >>>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>>> 2009/9/2 Andrew John Hughes : >>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>>> ??? This appears to be related specifically to PKCS11.??? >? >>>>>>>>>>> Specifically, PKCS11 >>>>>>>>>>> v2.20 has some ambiguity of the representation of an EC point >>>>>>>>>>> (which >>>>>>>>>>> is >>>>>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>>>>> >>>>>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>>>>> (e.g.the >>>>>>>>>>> format described in??? X9.62, where the first octet indicates the >>>>>>>>>>> encoding and >>>>>>>>>>> there are either N or 2N octets following)??? being the expected >>>>>>>>>>> value, but >>>>>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>>>>> >>>>>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>>>>> provider had >>>>>>>>>>> interpreted the issue and implemented its code. >>>>>>>>>>> >>>>>>>>>>> I don't support this fix - among other things, this fix only >>>>>>>>>>> deals >>>>>>>>>>> with 1/2 >>>>>>>>>>> of the problem.??? The other half is related to encoding the >>>>>>>>>>> value.??? Also, >>>>>>>>>>> changing the code at decodePoint seems further into the stack >>>>>>>>>>> than >>>>>>>>>>> needed >>>>>>>>>>> and may affect other uses of that method. >>>>>>>>>>> >>>>>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>>>>> Sorry about that. My point was that your patch didn't completely >>>>>>>>> solve the problem and that the point at where you were fixing it >>>>>>>>> could have >>>>>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>>>>> direction >>>>>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>>>>> >>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>>>>> >>>>>>>>>> It seems likely that's the NSS change that causes the current >>>>>>>>>> failure. >>>>>>>>>> The fix I submitted here is based on the way this is handle in >>>>>>>>>> NSS. >>>>>>>>>> In fact, the code is similar enough to suggest that one was >>>>>>>>>> developed >>>>>>>>>> from the other. >>>>>>>>>>> ??? that should be looked at. >>>>>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>>>>> reporting >>>>>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>>>>> same >>>>>>>>>> failure while trying to create an example key, while this seems to >>>>>>>>>> require specific hardware if I'm reading it correctly). >>>>>>>>> Not exactly. You're using the NSS as a PKCS11 module - this >>>>>>>>> problem >>>>>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>>>>> 6763530. >>>>>>>>>>> >>>>>>>>>> The patch on 6779460 seems wrong. It means that the method will >>>>>>>>>> return a DER-encoded value where it would either have returned an >>>>>>>>>> uncompressed value before or failed. >>>>>>>>> My point exactly as I mentioned in the comments. :-) >>>>>>>>> >>>>>>>>> >>>>>>>>>>> It's probable that the fix I suggested at 6763530??? (in comments >>>>>>>>>>> submitted 29 >>>>>>>>>>> Nov 08) may be a better approach given the NSS fixes.??? I >>>>>>>>>>> believe >>>>>>>>>>> it will fix >>>>>>>>>>> the keytool problem noted in the original message. >>>>>>>>>>> >>>>>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>>>>> though >>>>>>>>>> I haven't tested it. >>>>>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>>>>> applied? If it had, it would have saved me hours having to debug >>>>>>>>>> this >>>>>>>>>> same issue again. >>>>>>>>> Yup. I did do a search for PKCS11 related bugs when I >>>>>>>>> encountered the >>>>>>>>> same problem and did find the original error. >>>>>>>>> >>>>>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>>>>> your >>>>>>>>>> patch and we can finally get this fixed. Without it, NSS >>>>>>>>>> support is >>>>>>>>>> completely broken in OpenJDK6 which makes me wonder why this is >>>>>>>>>> a low >>>>>>>>>> priority bug! >>>>>>>>> I do have an SCA on file. Note that the recommendation from the >>>>>>>>> NSS >>>>>>>>> guys was to raise the priority. >>>>>>>>> >>>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>>> different >>>>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>>> the >>>>>>>>> documented process >>>>>>>>> and was waiting on progress there before continuing. I've got a >>>>>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I >>>>>>>>> was trying >>>>>>>>> for a worked example before proceeding. And then I got busy >>>>>>>>> with some other >>>>>>>>> things... >>>>>>>>> >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Mike >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>>>>> >>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>> >>>>>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>>>>> >>>>>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>>>>> available >>>>>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>>>>> >>>>>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>>>>> >>>>>>>>>>> If NSS is configured as specified in this blog, keytool can be >>>>>>>>>>> used >>>>>>>>>>> to >>>>>>>>>>> generate a key as follows: >>>>>>>>>>> >>>>>>>>>>> Hello. >>>>>>>>>>> >>>>>>>>>>> Allowing keytool and friends to work in more cases if the >>>>>>>>>>> provider >>>>>>>>>>> is >>>>>>>>>>> capable seems fine to me. >>>>>>>>>>> >>>>>>>>>>> Security team, do you have concerns about this patch? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Joe >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andrew :-) >>>>>>>>>> >>>>>>>>>> Free Java Software Engineer >>>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>>> >>>>>>>>>> Support Free Java! >>>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>>> http://openjdk.java.net >>>>>>>>>> >>>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>>> >>>>>>>> Ok here is a new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>>> >>>>>>>> with a slightly revised version of your change (you can't throw a >>>>>>>> PKCS11Exception which only takes a long ID from the native code, >>>>>>>> so I >>>>>>>> changed this to an IllegalArgumentException). >>>>>>>> >>>>>>>> Security team, does this look ok to push? >>>>>>>> -- >>>>>>>> Andrew :-) >>>>>>>> >>>>>>>> Free Java Software Engineer >>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>> >>>>>>>> Support Free Java! >>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>> http://www.gnu.org/software/classpath >>>>>>>> http://openjdk.java.net >>>>>>>> >>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>> >>>>>>> Ping! Security developers, any thoughts on this patch: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>> >>>>>>> Does it look ok to push? >>>>>>> >>>>>>> Thanks, >>> >>> >>> From Joe.Darcy at Sun.COM Thu Jan 21 15:59:16 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 21 Jan 2010 15:59:16 -0800 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <20100118195813.GA32693@rivendell.middle-earth.co.uk> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> Message-ID: <4B58EA54.3090009@sun.com> Hello. Andrew John Hughes wrote: > On 09:50 Fri 15 Jan , Joe Wang wrote: >> Thanks Alan. Yes, I did receive the bugzilla notice. >> >> Kelly told me that he applied the same jaxp source tarball to OpenJDK6. >> Kelly, could you tell Andrew how to include the jaxp source tarball when >> building OpenJDK6? >> > > The tarball jdk6-jaxp-2009_10_27.zip used by the OpenJDK6 build does not > include the fix. We are still having to apply the patch: > > diff -Nru openjdk.orig/jaxp/build.properties openjdk/jaxp/build.properties > --- openjdk.orig/jaxp/build.properties 2009-12-08 17:42:33.000000000 +0000 > +++ openjdk/jaxp/build.properties 2009-12-08 17:43:03.000000000 +0000 > @@ -73,6 +73,9 @@ > # Where patches to drop bundle sources live > patches.dir=patches > > +# Patches to apply > +jaxp_src.patch.list=xml-encodinginfo.patch > + > # Sanity information > sanity.info= Sanity Settings:${line.separator}\ > ant.home=${ant.home}${line.separator}\ > diff -Nru openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch > --- openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch 1970-01-01 01:00:00.000000000 +0100 > +++ openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch 2009-12-08 17:41:58.000000000 +0000 > @@ -0,0 +1,18 @@ > +diff -Nru src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java > +--- src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java 2009-10-27 21:54:16.000000000 +0000 > ++++ src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java 2009-12-08 17:40:14.000000000 +0000 > +@@ -326,9 +326,11 @@ > + m_last = last; > + > + // Set the range of unicode values that this object > +- // explicitly manages > +- m_explFirst = codePoint; > +- m_explLast = codePoint + (RANGE-1); > ++ // explicitly manages. Align the explicitly managed values > ++ // to RANGE so multiple EncodingImpl objects dont manage the same > ++ // values. > ++ m_explFirst = codePoint / RANGE * RANGE; > ++ m_explLast = m_explFirst + (RANGE-1); > + > + m_encoding = encoding; > + Joe (Wang), I'll let you decide on the appropriateness of the fix for jaxp. If the fix is good, a new jaxp bundle for OpenJDK 6 would be fine by me. > BTW, we have a testcase for this. Would it be possible to add this to > the JDK tree? The complete patch included in the icedtea6-hg tree > (http://icedtea.classpath.org/people/andrew/icedtea6-hg), including > test case, is attached. Tests are good of course and since the jaxp repo doesn't currently have any regression tests, putting the test into OpenJDK 6 in the jdk repo seems like the right home for it, as the patch currently does. Note that at the moment the license header of the test files says "Copyright 2009 Red Hat" but later states "Please contact Sun Microsystems ... if you need additional information or have any questions." If this goes upstream, the copyright holder should be changed to Sun. Thanks, -Joe From tomas at primekey.se Wed Jan 20 11:00:09 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Wed, 20 Jan 2010 20:00:09 +0100 (CET) Subject: [security-dev 01541]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <20100120180532.909D064A2@mail.openjdk.java.net> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> Message-ID: I'll second this request. This is a critical patch and many production installations have to live with this manually patched now. I know of no pkcs11 implementation that works with the current code. Regards, Tomas Gustavsson PrimeKey Solutions AB On Wed, 20 Jan 2010, Michael StJohns wrote: > Hi - this seems to have stalled out again. Any chance of revival? > > Mike > > > At 12:33 PM 9/24/2009, Vincent Ryan wrote: >> Hello Andrew, >> >> I'll need a little more time to come up to speed on this fix. I'm concerned that >> there may be interoperability or backwards compatibility issues. >> >> >> >> Andrew John Hughes wrote: >>> 2009/9/2 Andrew John Hughes : >>>> 2009/9/2 Michael StJohns : >>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>> 2009/9/2 Michael StJohns : >>>>>>> ?? This appears to be related specifically to PKCS11.?? Specifically, PKCS11 >>>>>>> v2.20 has some ambiguity of the representation of an EC point (which is >>>>>>> different in the text than an ASN1 ECPoint). >>>>>>> >>>>>>> This is being clarified in v2.30 with the unencoded point format (e.g.the >>>>>>> format described in?? X9.62, where the first octet indicates the encoding and >>>>>>> there are either N or 2N octets following)?? being the expected value, but >>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>> >>>>>>> One of the reasons for going that way was how the JDK PKCS11 provider had >>>>>>> interpreted the issue and implemented its code. >>>>>>> >>>>>>> I don't support this fix - among other things, this fix only deals with 1/2 >>>>>>> of the problem.?? The other half is related to encoding the value.?? Also, >>>>>>> changing the code at decodePoint seems further into the stack than needed >>>>>>> and may affect other uses of that method. >>>>>>> >>>>>> That's really too vague to be of much help in improving the patch. >>>>>> You seem to be saying little more than 'I don't like it'. >>>>> Sorry about that. My point was that your patch didn't completely solve the problem and that the point at where you were fixing it could have some bad side effects for anyone calling decodePoint directly. >>>>> >>>>> >>>>>>> There's an existing JDK bug on this coming at it from a different direction >>>>>>> - 6763530 ... and there may be considerations at >>>>>>> >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>> >>>>>> It seems likely that's the NSS change that causes the current failure. >>>>>> The fix I submitted here is based on the way this is handle in NSS. >>>>>> In fact, the code is similar enough to suggest that one was developed >>>>>> from the other. >>>>>>> ?? that should be looked at. >>>>>> The JDK bug is not really 'from a different direction', it's reporting >>>>>> exactly the same error but from a less trivial example (I get the same >>>>>> failure while trying to create an example key, while this seems to >>>>>> require specific hardware if I'm reading it correctly). >>>>> Not exactly. You're using the NSS as a PKCS11 module - this problem would occur with any PKCS11 module that implements EC stuff. >>>>> >>>>> >>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>> 6763530. >>>>>>> >>>>>> The patch on 6779460 seems wrong. It means that the method will >>>>>> return a DER-encoded value where it would either have returned an >>>>>> uncompressed value before or failed. >>>>> My point exactly as I mentioned in the comments. :-) >>>>> >>>>> >>>>>>> It's probable that the fix I suggested at 6763530?? (in comments submitted 29 >>>>>>> Nov 08) may be a better approach given the NSS fixes.?? I believe it will fix >>>>>>> the keytool problem noted in the original message. >>>>>>> >>>>>> Ok, I can see the logic in the fix and it would appear to work, though >>>>>> I haven't tested it. >>>>>> Given the patch was written nine months ago, why has it not been >>>>>> applied? If it had, it would have saved me hours having to debug this >>>>>> same issue again. >>>>> Yup. I did do a search for PKCS11 related bugs when I encountered the same problem and did find the original error. >>>>> >>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on your >>>>>> patch and we can finally get this fixed. Without it, NSS support is >>>>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>>>> priority bug! >>>>> I do have an SCA on file. Note that the recommendation from the NSS guys was to raise the priority. >>>>> >>>>> The reason I haven't submitted this is because I submitted a different EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented process >>>>> and was waiting on progress there before continuing. I've got a number of EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked example before proceeding. And then I got busy with some other things... >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>> >>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are available >>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>> >>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>> >>>>>>> If NSS is configured as specified in this blog, keytool can be used to >>>>>>> generate a key as follows: >>>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> Allowing keytool and friends to work in more cases if the provider is >>>>>>> capable seems fine to me. >>>>>>> >>>>>>> Security team, do you have concerns about this patch? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>> Ok here is a new webrev: >>>> >>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>> >>>> with a slightly revised version of your change (you can't throw a >>>> PKCS11Exception which only takes a long ID from the native code, so I >>>> changed this to an IllegalArgumentException). >>>> >>>> Security team, does this look ok to push? >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>> >>> Ping! Security developers, any thoughts on this patch: >>> >>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>> >>> Does it look ok to push? >>> >>> Thanks, > > From tomas at primekey.se Wed Jan 20 23:44:29 2010 From: tomas at primekey.se (Tomas Gustavsson) Date: Thu, 21 Jan 2010 08:44:29 +0100 Subject: [security-dev 01544]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> Message-ID: <4B5805DD.8060101@primekey.se> Now it has one more vote. /Tomas Andrew John Hughes wrote: > 2010/1/20 Tomas Gustavsson : >> I'll second this request. This is a critical patch and many production >> installations have to live with this manually patched now. >> >> I know of no pkcs11 implementation that works with the current code. >> > > It has four votes: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 > I don't know how many they need to wake up and review the patch. > > The new release of IcedTea6 1.7 is imminent and will include the fix > so it should at least be resolved on the next version shipping with > most GNU/Linux distributions. > >> Regards, >> Tomas Gustavsson >> PrimeKey Solutions AB >> >> >> On Wed, 20 Jan 2010, Michael StJohns wrote: >> >>> Hi - this seems to have stalled out again. Any chance of revival? >>> >>> Mike >>> >>> >>> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>>> Hello Andrew, >>>> >>>> I'll need a little more time to come up to speed on this fix. I'm >>>> concerned that >>>> there may be interoperability or backwards compatibility issues. >>>> >>>> >>>> >>>> Andrew John Hughes wrote: >>>>> 2009/9/2 Andrew John Hughes : >>>>>> 2009/9/2 Michael StJohns : >>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>> ?? This appears to be related specifically to PKCS11.?? >>>>>>>>> Specifically, PKCS11 >>>>>>>>> v2.20 has some ambiguity of the representation of an EC point (which >>>>>>>>> is >>>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>>> >>>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>>> (e.g.the >>>>>>>>> format described in?? X9.62, where the first octet indicates the >>>>>>>>> encoding and >>>>>>>>> there are either N or 2N octets following)?? being the expected >>>>>>>>> value, but >>>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>>> >>>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>>> provider had >>>>>>>>> interpreted the issue and implemented its code. >>>>>>>>> >>>>>>>>> I don't support this fix - among other things, this fix only deals >>>>>>>>> with 1/2 >>>>>>>>> of the problem.?? The other half is related to encoding the >>>>>>>>> value.?? Also, >>>>>>>>> changing the code at decodePoint seems further into the stack than >>>>>>>>> needed >>>>>>>>> and may affect other uses of that method. >>>>>>>>> >>>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>>> Sorry about that. My point was that your patch didn't completely >>>>>>> solve the problem and that the point at where you were fixing it could have >>>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>>> >>>>>>> >>>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>>> direction >>>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>>> >>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>>> >>>>>>>> It seems likely that's the NSS change that causes the current >>>>>>>> failure. >>>>>>>> The fix I submitted here is based on the way this is handle in NSS. >>>>>>>> In fact, the code is similar enough to suggest that one was developed >>>>>>>> from the other. >>>>>>>>> ?? that should be looked at. >>>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>>> reporting >>>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>>> same >>>>>>>> failure while trying to create an example key, while this seems to >>>>>>>> require specific hardware if I'm reading it correctly). >>>>>>> Not exactly. You're using the NSS as a PKCS11 module - this problem >>>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>>> >>>>>>> >>>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>>> 6763530. >>>>>>>>> >>>>>>>> The patch on 6779460 seems wrong. It means that the method will >>>>>>>> return a DER-encoded value where it would either have returned an >>>>>>>> uncompressed value before or failed. >>>>>>> My point exactly as I mentioned in the comments. :-) >>>>>>> >>>>>>> >>>>>>>>> It's probable that the fix I suggested at 6763530?? (in comments >>>>>>>>> submitted 29 >>>>>>>>> Nov 08) may be a better approach given the NSS fixes.?? I believe >>>>>>>>> it will fix >>>>>>>>> the keytool problem noted in the original message. >>>>>>>>> >>>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>>> though >>>>>>>> I haven't tested it. >>>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>>> applied? If it had, it would have saved me hours having to debug >>>>>>>> this >>>>>>>> same issue again. >>>>>>> Yup. I did do a search for PKCS11 related bugs when I encountered the >>>>>>> same problem and did find the original error. >>>>>>> >>>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>>> your >>>>>>>> patch and we can finally get this fixed. Without it, NSS support is >>>>>>>> completely broken in OpenJDK6 which makes me wonder why this is a low >>>>>>>> priority bug! >>>>>>> I do have an SCA on file. Note that the recommendation from the NSS >>>>>>> guys was to raise the priority. >>>>>>> >>>>>>> The reason I haven't submitted this is because I submitted a different >>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the >>>>>>> documented process >>>>>>> and was waiting on progress there before continuing. I've got a >>>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I was trying >>>>>>> for a worked example before proceeding. And then I got busy with some other >>>>>>> things... >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>> >>>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>>> >>>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>>> available >>>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>>> >>>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>>> >>>>>>>>> If NSS is configured as specified in this blog, keytool can be used >>>>>>>>> to >>>>>>>>> generate a key as follows: >>>>>>>>> >>>>>>>>> Hello. >>>>>>>>> >>>>>>>>> Allowing keytool and friends to work in more cases if the provider >>>>>>>>> is >>>>>>>>> capable seems fine to me. >>>>>>>>> >>>>>>>>> Security team, do you have concerns about this patch? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Joe >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Andrew :-) >>>>>>>> >>>>>>>> Free Java Software Engineer >>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>> >>>>>>>> Support Free Java! >>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>> http://www.gnu.org/software/classpath >>>>>>>> http://openjdk.java.net >>>>>>>> >>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>> >>>>>> Ok here is a new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>> >>>>>> with a slightly revised version of your change (you can't throw a >>>>>> PKCS11Exception which only takes a long ID from the native code, so I >>>>>> changed this to an IllegalArgumentException). >>>>>> >>>>>> Security team, does this look ok to push? >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>> >>>>> Ping! Security developers, any thoughts on this patch: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>> >>>>> Does it look ok to push? >>>>> >>>>> Thanks, > > > From tomasg at primekey.se Thu Jan 21 02:24:15 2010 From: tomasg at primekey.se (Tomas Gustavsson) Date: Thu, 21 Jan 2010 11:24:15 +0100 Subject: [security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4B582889.6080903@sun.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> <4B5805DD.8060101@primekey.se> <4B582889.6080903@sun.com> Message-ID: <4B582B4F.5040207@primekey.se> Wonderful! Thanks! Cheers, Tomas Vincent Ryan wrote: > I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. > > > On 21/01/2010 07:44, Tomas Gustavsson wrote: >> Now it has one more vote. >> >> /Tomas >> >> Andrew John Hughes wrote: >>> 2010/1/20 Tomas Gustavsson : >>>> I'll second this request. This is a critical patch and many production >>>> installations have to live with this manually patched now. >>>> >>>> I know of no pkcs11 implementation that works with the current code. >>>> >>> It has four votes: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 >>> I don't know how many they need to wake up and review the patch. >>> >>> The new release of IcedTea6 1.7 is imminent and will include the fix >>> so it should at least be resolved on the next version shipping with >>> most GNU/Linux distributions. >>> >>>> Regards, >>>> Tomas Gustavsson >>>> PrimeKey Solutions AB >>>> >>>> >>>> On Wed, 20 Jan 2010, Michael StJohns wrote: >>>> >>>>> Hi - this seems to have stalled out again. Any chance of revival? >>>>> >>>>> Mike >>>>> >>>>> >>>>> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>>>>> Hello Andrew, >>>>>> >>>>>> I'll need a little more time to come up to speed on this fix. I'm >>>>>> concerned that >>>>>> there may be interoperability or backwards compatibility issues. >>>>>> >>>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>>> 2009/9/2 Andrew John Hughes : >>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>>> ?? This appears to be related specifically to PKCS11.?? >>>>>>>>>>> Specifically, PKCS11 >>>>>>>>>>> v2.20 has some ambiguity of the representation of an EC point >>>>>>>>>>> (which >>>>>>>>>>> is >>>>>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>>>>> >>>>>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>>>>> (e.g.the >>>>>>>>>>> format described in?? X9.62, where the first octet indicates the >>>>>>>>>>> encoding and >>>>>>>>>>> there are either N or 2N octets following)?? being the expected >>>>>>>>>>> value, but >>>>>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>>>>> >>>>>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>>>>> provider had >>>>>>>>>>> interpreted the issue and implemented its code. >>>>>>>>>>> >>>>>>>>>>> I don't support this fix - among other things, this fix only >>>>>>>>>>> deals >>>>>>>>>>> with 1/2 >>>>>>>>>>> of the problem.?? The other half is related to encoding the >>>>>>>>>>> value.?? Also, >>>>>>>>>>> changing the code at decodePoint seems further into the stack >>>>>>>>>>> than >>>>>>>>>>> needed >>>>>>>>>>> and may affect other uses of that method. >>>>>>>>>>> >>>>>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>>>>> Sorry about that. My point was that your patch didn't completely >>>>>>>>> solve the problem and that the point at where you were fixing it >>>>>>>>> could have >>>>>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>>>>> direction >>>>>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>>>>> >>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>>>>> >>>>>>>>>> It seems likely that's the NSS change that causes the current >>>>>>>>>> failure. >>>>>>>>>> The fix I submitted here is based on the way this is handle in >>>>>>>>>> NSS. >>>>>>>>>> In fact, the code is similar enough to suggest that one was >>>>>>>>>> developed >>>>>>>>>> from the other. >>>>>>>>>>> ?? that should be looked at. >>>>>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>>>>> reporting >>>>>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>>>>> same >>>>>>>>>> failure while trying to create an example key, while this seems to >>>>>>>>>> require specific hardware if I'm reading it correctly). >>>>>>>>> Not exactly. You're using the NSS as a PKCS11 module - this >>>>>>>>> problem >>>>>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>>>>> 6763530. >>>>>>>>>>> >>>>>>>>>> The patch on 6779460 seems wrong. It means that the method will >>>>>>>>>> return a DER-encoded value where it would either have returned an >>>>>>>>>> uncompressed value before or failed. >>>>>>>>> My point exactly as I mentioned in the comments. :-) >>>>>>>>> >>>>>>>>> >>>>>>>>>>> It's probable that the fix I suggested at 6763530?? (in comments >>>>>>>>>>> submitted 29 >>>>>>>>>>> Nov 08) may be a better approach given the NSS fixes.?? I >>>>>>>>>>> believe >>>>>>>>>>> it will fix >>>>>>>>>>> the keytool problem noted in the original message. >>>>>>>>>>> >>>>>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>>>>> though >>>>>>>>>> I haven't tested it. >>>>>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>>>>> applied? If it had, it would have saved me hours having to debug >>>>>>>>>> this >>>>>>>>>> same issue again. >>>>>>>>> Yup. I did do a search for PKCS11 related bugs when I >>>>>>>>> encountered the >>>>>>>>> same problem and did find the original error. >>>>>>>>> >>>>>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>>>>> your >>>>>>>>>> patch and we can finally get this fixed. Without it, NSS >>>>>>>>>> support is >>>>>>>>>> completely broken in OpenJDK6 which makes me wonder why this is >>>>>>>>>> a low >>>>>>>>>> priority bug! >>>>>>>>> I do have an SCA on file. Note that the recommendation from the >>>>>>>>> NSS >>>>>>>>> guys was to raise the priority. >>>>>>>>> >>>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>>> different >>>>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>>> the >>>>>>>>> documented process >>>>>>>>> and was waiting on progress there before continuing. I've got a >>>>>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I >>>>>>>>> was trying >>>>>>>>> for a worked example before proceeding. And then I got busy >>>>>>>>> with some other >>>>>>>>> things... >>>>>>>>> >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Mike >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>>>>> >>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>> >>>>>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>>>>> >>>>>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>>>>> available >>>>>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>>>>> >>>>>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>>>>> >>>>>>>>>>> If NSS is configured as specified in this blog, keytool can be >>>>>>>>>>> used >>>>>>>>>>> to >>>>>>>>>>> generate a key as follows: >>>>>>>>>>> >>>>>>>>>>> Hello. >>>>>>>>>>> >>>>>>>>>>> Allowing keytool and friends to work in more cases if the >>>>>>>>>>> provider >>>>>>>>>>> is >>>>>>>>>>> capable seems fine to me. >>>>>>>>>>> >>>>>>>>>>> Security team, do you have concerns about this patch? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Joe >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andrew :-) >>>>>>>>>> >>>>>>>>>> Free Java Software Engineer >>>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>>> >>>>>>>>>> Support Free Java! >>>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>>> http://openjdk.java.net >>>>>>>>>> >>>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>> Ok here is a new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>>> >>>>>>>> with a slightly revised version of your change (you can't throw a >>>>>>>> PKCS11Exception which only takes a long ID from the native code, >>>>>>>> so I >>>>>>>> changed this to an IllegalArgumentException). >>>>>>>> >>>>>>>> Security team, does this look ok to push? >>>>>>>> -- >>>>>>>> Andrew :-) >>>>>>>> >>>>>>>> Free Java Software Engineer >>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>> >>>>>>>> Support Free Java! >>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>> http://www.gnu.org/software/classpath >>>>>>>> http://openjdk.java.net >>>>>>>> >>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>> >>>>>>> Ping! Security developers, any thoughts on this patch: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>> >>>>>>> Does it look ok to push? >>>>>>> >>>>>>> Thanks, >>> >>> From tomasg at primekey.se Thu Jan 21 09:33:46 2010 From: tomasg at primekey.se (Tomas Gustavsson) Date: Thu, 21 Jan 2010 18:33:46 +0100 Subject: [security-dev 01549]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <20100121172807.8E36E6AC7@mail.openjdk.java.net> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> <4B5805DD.8060101@primekey.se> <4B582889.6080903@sun.com> <20100121172807.8E36E6AC7@mail.openjdk.java.net> Message-ID: <4B588FFA.8030209@primekey.se> Second that one too, that is the same as: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6738532 And I have voted for that one as well, actually I used up all my bug votes on ECC stuff. Cheers; Tomas Michael StJohns wrote: > At 05:12 AM 1/21/2010, Vincent Ryan wrote: >> I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. > > > I don't suppose I could get a two-fer and get this one done as well? It's been sitting around for even longer. > >>>>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>>>> different >>>>>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>>>> the > > Mike > > > > >> On 21/01/2010 07:44, Tomas Gustavsson wrote: >>> Now it has one more vote. >>> >>> /Tomas >>> >>> Andrew John Hughes wrote: >>>> 2010/1/20 Tomas Gustavsson : >>>>> I'll second this request. This is a critical patch and many production >>>>> installations have to live with this manually patched now. >>>>> >>>>> I know of no pkcs11 implementation that works with the current code. >>>>> >>>> It has four votes: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 >>>> I don't know how many they need to wake up and review the patch. >>>> >>>> The new release of IcedTea6 1.7 is imminent and will include the fix >>>> so it should at least be resolved on the next version shipping with >>>> most GNU/Linux distributions. >>>> >>>>> Regards, >>>>> Tomas Gustavsson >>>>> PrimeKey Solutions AB >>>>> >>>>> >>>>> On Wed, 20 Jan 2010, Michael StJohns wrote: >>>>> >>>>>> Hi - this seems to have stalled out again. Any chance of revival? >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>>>>>> Hello Andrew, >>>>>>> >>>>>>> I'll need a little more time to come up to speed on this fix. I'm >>>>>>> concerned that >>>>>>> there may be interoperability or backwards compatibility issues. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>>> 2009/9/2 Andrew John Hughes : >>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>>>> ??? This appears to be related specifically to PKCS11.??? >> ? >>>>>>>>>>>> Specifically, PKCS11 >>>>>>>>>>>> v2.20 has some ambiguity of the representation of an EC point >>>>>>>>>>>> (which >>>>>>>>>>>> is >>>>>>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>>>>>> >>>>>>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>>>>>> (e.g.the >>>>>>>>>>>> format described in??? X9.62, where the first octet indicates the >>>>>>>>>>>> encoding and >>>>>>>>>>>> there are either N or 2N octets following)??? being the expected >>>>>>>>>>>> value, but >>>>>>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>>>>>> >>>>>>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>>>>>> provider had >>>>>>>>>>>> interpreted the issue and implemented its code. >>>>>>>>>>>> >>>>>>>>>>>> I don't support this fix - among other things, this fix only >>>>>>>>>>>> deals >>>>>>>>>>>> with 1/2 >>>>>>>>>>>> of the problem.??? The other half is related to encoding the >>>>>>>>>>>> value.??? Also, >>>>>>>>>>>> changing the code at decodePoint seems further into the stack >>>>>>>>>>>> than >>>>>>>>>>>> needed >>>>>>>>>>>> and may affect other uses of that method. >>>>>>>>>>>> >>>>>>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>>>>>> Sorry about that. My point was that your patch didn't completely >>>>>>>>>> solve the problem and that the point at where you were fixing it >>>>>>>>>> could have >>>>>>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>>>>>> direction >>>>>>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>>>>>> >>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>>>>>> >>>>>>>>>>> It seems likely that's the NSS change that causes the current >>>>>>>>>>> failure. >>>>>>>>>>> The fix I submitted here is based on the way this is handle in >>>>>>>>>>> NSS. >>>>>>>>>>> In fact, the code is similar enough to suggest that one was >>>>>>>>>>> developed >>>>>>>>>>> from the other. >>>>>>>>>>>> ??? that should be looked at. >>>>>>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>>>>>> reporting >>>>>>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>>>>>> same >>>>>>>>>>> failure while trying to create an example key, while this seems to >>>>>>>>>>> require specific hardware if I'm reading it correctly). >>>>>>>>>> Not exactly. You're using the NSS as a PKCS11 module - this >>>>>>>>>> problem >>>>>>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>>>>>> 6763530. >>>>>>>>>>>> >>>>>>>>>>> The patch on 6779460 seems wrong. It means that the method will >>>>>>>>>>> return a DER-encoded value where it would either have returned an >>>>>>>>>>> uncompressed value before or failed. >>>>>>>>>> My point exactly as I mentioned in the comments. :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> It's probable that the fix I suggested at 6763530??? (in comments >>>>>>>>>>>> submitted 29 >>>>>>>>>>>> Nov 08) may be a better approach given the NSS fixes.??? I >>>>>>>>>>>> believe >>>>>>>>>>>> it will fix >>>>>>>>>>>> the keytool problem noted in the original message. >>>>>>>>>>>> >>>>>>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>>>>>> though >>>>>>>>>>> I haven't tested it. >>>>>>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>>>>>> applied? If it had, it would have saved me hours having to debug >>>>>>>>>>> this >>>>>>>>>>> same issue again. >>>>>>>>>> Yup. I did do a search for PKCS11 related bugs when I >>>>>>>>>> encountered the >>>>>>>>>> same problem and did find the original error. >>>>>>>>>> >>>>>>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>>>>>> your >>>>>>>>>>> patch and we can finally get this fixed. Without it, NSS >>>>>>>>>>> support is >>>>>>>>>>> completely broken in OpenJDK6 which makes me wonder why this is >>>>>>>>>>> a low >>>>>>>>>>> priority bug! >>>>>>>>>> I do have an SCA on file. Note that the recommendation from the >>>>>>>>>> NSS >>>>>>>>>> guys was to raise the priority. >>>>>>>>>> >>>>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>>>> different >>>>>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>>>> the >>>>>>>>>> documented process >>>>>>>>>> and was waiting on progress there before continuing. I've got a >>>>>>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I >>>>>>>>>> was trying >>>>>>>>>> for a worked example before proceeding. And then I got busy >>>>>>>>>> with some other >>>>>>>>>> things... >>>>>>>>>> >>>>>>>>>> Mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Mike >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>>>>>> >>>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>>>>>> >>>>>>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>>>>>> available >>>>>>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>>>>>> >>>>>>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>>>>>> >>>>>>>>>>>> If NSS is configured as specified in this blog, keytool can be >>>>>>>>>>>> used >>>>>>>>>>>> to >>>>>>>>>>>> generate a key as follows: >>>>>>>>>>>> >>>>>>>>>>>> Hello. >>>>>>>>>>>> >>>>>>>>>>>> Allowing keytool and friends to work in more cases if the >>>>>>>>>>>> provider >>>>>>>>>>>> is >>>>>>>>>>>> capable seems fine to me. >>>>>>>>>>>> >>>>>>>>>>>> Security team, do you have concerns about this patch? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Joe >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Andrew :-) >>>>>>>>>>> >>>>>>>>>>> Free Java Software Engineer >>>>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>>>> >>>>>>>>>>> Support Free Java! >>>>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>>>> http://openjdk.java.net >>>>>>>>>>> >>>>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>>> Ok here is a new webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>>>> >>>>>>>>> with a slightly revised version of your change (you can't throw a >>>>>>>>> PKCS11Exception which only takes a long ID from the native code, >>>>>>>>> so I >>>>>>>>> changed this to an IllegalArgumentException). >>>>>>>>> >>>>>>>>> Security team, does this look ok to push? >>>>>>>>> -- >>>>>>>>> Andrew :-) >>>>>>>>> >>>>>>>>> Free Java Software Engineer >>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>> >>>>>>>>> Support Free Java! >>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>> http://openjdk.java.net >>>>>>>>> >>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>>> >>>>>>>> Ping! Security developers, any thoughts on this patch: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>>> >>>>>>>> Does it look ok to push? >>>>>>>> >>>>>>>> Thanks, >>>> >>>> > From joe.wang at sun.com Thu Jan 21 16:38:17 2010 From: joe.wang at sun.com (Joe Wang) Date: Thu, 21 Jan 2010 16:38:17 -0800 Subject: test integration -> Re: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B58EA54.3090009@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> Message-ID: <4B58F379.8090901@sun.com> Joe, The patch, contributed by Andrew, was integrated into OpenJDK7, which Andrew confirmed. According to Kelly, he applied the same source tarball to OpenJDK6. So we need to find out why jdk6-jaxp-2009_10_27.zip did not have this fix. About tests, we do have unit test for every fix in jaxp, and for this particular bug, we've used the testcase Andrew contributed. Bill had asked me to upload all of the unit tests along with source tarball. According to Bill, his team will take over from there and integrate them into the jdk workspace. Thanks, Joe Joe Darcy wrote: > Hello. > > Andrew John Hughes wrote: >> On 09:50 Fri 15 Jan , Joe Wang wrote: >>> Thanks Alan. Yes, I did receive the bugzilla notice. >>> >>> Kelly told me that he applied the same jaxp source tarball to >>> OpenJDK6. Kelly, could you tell Andrew how to include the jaxp >>> source tarball when building OpenJDK6? >>> >> >> The tarball jdk6-jaxp-2009_10_27.zip used by the OpenJDK6 build does not >> include the fix. We are still having to apply the patch: >> >> diff -Nru openjdk.orig/jaxp/build.properties >> openjdk/jaxp/build.properties >> --- openjdk.orig/jaxp/build.properties 2009-12-08 >> 17:42:33.000000000 +0000 >> +++ openjdk/jaxp/build.properties 2009-12-08 >> 17:43:03.000000000 +0000 >> @@ -73,6 +73,9 @@ >> # Where patches to drop bundle sources live >> patches.dir=patches >> >> +# Patches to apply >> +jaxp_src.patch.list=xml-encodinginfo.patch >> + >> # Sanity information >> sanity.info= Sanity Settings:${line.separator}\ >> ant.home=${ant.home}${line.separator}\ >> diff -Nru openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch >> openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch >> --- openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch >> 1970-01-01 01:00:00.000000000 +0100 >> +++ openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch >> 2009-12-08 17:41:58.000000000 +0000 >> @@ -0,0 +1,18 @@ >> +diff -Nru >> src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >> src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >> +--- >> src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >> 2009-10-27 21:54:16.000000000 +0000 >> ++++ >> src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >> 2009-12-08 17:40:14.000000000 +0000 >> +@@ -326,9 +326,11 @@ >> + m_last = last; >> + + // Set the range of unicode values that this object >> +- // explicitly manages >> +- m_explFirst = codePoint; >> +- m_explLast = codePoint + (RANGE-1); >> ++ // explicitly manages. Align the explicitly managed values >> ++ // to RANGE so multiple EncodingImpl objects dont >> manage the same ++ // values. >> ++ m_explFirst = codePoint / RANGE * RANGE; >> ++ m_explLast = m_explFirst + (RANGE-1); >> + + m_encoding = encoding; >> + > > Joe (Wang), I'll let you decide on the appropriateness of the fix for > jaxp. If the fix is good, a new jaxp bundle for OpenJDK 6 would be > fine by me. > >> BTW, we have a testcase for this. Would it be possible to add this to >> the JDK tree? The complete patch included in the icedtea6-hg tree >> (http://icedtea.classpath.org/people/andrew/icedtea6-hg), including >> test case, is attached. > > Tests are good of course and since the jaxp repo doesn't currently > have any regression tests, putting the test into OpenJDK 6 in the jdk > repo seems like the right home for it, as the patch currently does. > > Note that at the moment the license header of the test files says > "Copyright 2009 Red Hat" but later states "Please contact Sun > Microsystems ... if you need additional information or have any > questions." If this goes upstream, the copyright holder should be > changed to Sun. > > Thanks, > > -Joe From gnu_andrew at member.fsf.org Thu Jan 21 17:38:25 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 22 Jan 2010 01:38:25 +0000 Subject: [security-dev 01544]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4B582889.6080903@sun.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> <4B5805DD.8060101@primekey.se> <4B582889.6080903@sun.com> Message-ID: <17c6771e1001211738w6137d2b8s2160e5515c43bac2@mail.gmail.com> 2010/1/21 Vincent Ryan : > I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. > Thanks! Would this be suitable for OpenJDK6 as well? CCing the jdk6-dev list on that. > > On 21/01/2010 07:44, Tomas Gustavsson wrote: >> >> Now it has one more vote. >> >> /Tomas >> >> Andrew John Hughes wrote: >>> 2010/1/20 Tomas Gustavsson : >>>> I'll second this request. This is a critical patch and many production >>>> installations have to live with this manually patched now. >>>> >>>> I know of no pkcs11 implementation that works with the current code. >>>> >>> >>> It has four votes: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 >>> I don't know how many they need to wake up and review the patch. >>> >>> The new release of IcedTea6 1.7 is imminent and will include the fix >>> so it should at least be resolved on the next version shipping with >>> most GNU/Linux distributions. >>> >>>> Regards, >>>> Tomas Gustavsson >>>> PrimeKey Solutions AB >>>> >>>> >>>> On Wed, 20 Jan 2010, Michael StJohns wrote: >>>> >>>>> Hi - this seems to have stalled out again. ?Any chance of revival? >>>>> >>>>> Mike >>>>> >>>>> >>>>> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>>>>> Hello Andrew, >>>>>> >>>>>> I'll need a little more time to come up to speed on this fix. I'm >>>>>> concerned that >>>>>> there may be interoperability or backwards compatibility issues. >>>>>> >>>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>>> 2009/9/2 Andrew John Hughes : >>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>>> ?? This appears to be related specifically to PKCS11.?? >>>>>>>>>>> ?Specifically, PKCS11 >>>>>>>>>>> v2.20 has some ambiguity of the representation of an EC point >>>>>>>>>>> (which >>>>>>>>>>> is >>>>>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>>>>> >>>>>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>>>>> (e.g.the >>>>>>>>>>> format described in?? ?X9.62, where the first octet indicates the >>>>>>>>>>> encoding and >>>>>>>>>>> there are either N or 2N octets following)?? ?being the expected >>>>>>>>>>> value, but >>>>>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>>>>> >>>>>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>>>>> provider had >>>>>>>>>>> interpreted the issue and implemented its code. >>>>>>>>>>> >>>>>>>>>>> I don't support this fix - among other things, this fix only >>>>>>>>>>> deals >>>>>>>>>>> with 1/2 >>>>>>>>>>> of the problem.?? ?The other half is related to encoding the >>>>>>>>>>> value.?? ?Also, >>>>>>>>>>> changing the code at decodePoint seems further into the stack >>>>>>>>>>> than >>>>>>>>>>> needed >>>>>>>>>>> and may affect other uses of that method. >>>>>>>>>>> >>>>>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>>>>> Sorry about that. ?My point was that your patch didn't completely >>>>>>>>> solve the problem and that the point at where you were fixing it >>>>>>>>> could have >>>>>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>>>>> direction >>>>>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>>>>> >>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>>>>> >>>>>>>>>> It seems likely that's the NSS change that causes the current >>>>>>>>>> failure. >>>>>>>>>> The fix I submitted here is based on the way this is handle in >>>>>>>>>> NSS. >>>>>>>>>> In fact, the code is similar enough to suggest that one was >>>>>>>>>> developed >>>>>>>>>> from the other. >>>>>>>>>>> ?? that should be looked at. >>>>>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>>>>> reporting >>>>>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>>>>> same >>>>>>>>>> failure while trying to create an example key, while this seems to >>>>>>>>>> require specific hardware if I'm reading it correctly). >>>>>>>>> Not exactly. ?You're using the NSS as a PKCS11 module - this >>>>>>>>> problem >>>>>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>>>>> 6763530. >>>>>>>>>>> >>>>>>>>>> The patch on 6779460 seems wrong. ?It means that the method will >>>>>>>>>> return a DER-encoded value where it would either have returned an >>>>>>>>>> uncompressed value before or failed. >>>>>>>>> My point exactly as I mentioned in the comments. ?:-) >>>>>>>>> >>>>>>>>> >>>>>>>>>>> It's probable that the fix I suggested at 6763530?? ?(in comments >>>>>>>>>>> submitted 29 >>>>>>>>>>> Nov 08) may be a better approach given the NSS fixes.?? ?I >>>>>>>>>>> believe >>>>>>>>>>> it will fix >>>>>>>>>>> the keytool problem noted in the original message. >>>>>>>>>>> >>>>>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>>>>> though >>>>>>>>>> I haven't tested it. >>>>>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>>>>> applied? ?If it had, it would have saved me hours having to debug >>>>>>>>>> this >>>>>>>>>> same issue again. >>>>>>>>> Yup. ?I did do a search for PKCS11 related bugs when I >>>>>>>>> encountered the >>>>>>>>> same problem and did find the original error. >>>>>>>>> >>>>>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>>>>> your >>>>>>>>>> patch and we can finally get this fixed. ?Without it, NSS >>>>>>>>>> support is >>>>>>>>>> completely broken in OpenJDK6 which makes me wonder why this is >>>>>>>>>> a low >>>>>>>>>> priority bug! >>>>>>>>> I do have an SCA on file. ?Note that the recommendation from the >>>>>>>>> NSS >>>>>>>>> guys was to raise the priority. >>>>>>>>> >>>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>>> different >>>>>>>>> EC fix ?https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>>> the >>>>>>>>> documented process >>>>>>>>> ?and was waiting on progress there before continuing. ?I've got a >>>>>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I >>>>>>>>> was trying >>>>>>>>> for a worked example before proceeding. ?And then I got busy >>>>>>>>> with some other >>>>>>>>> things... >>>>>>>>> >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Mike >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>>>>> >>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>> >>>>>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>>>>> >>>>>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>>>>> available >>>>>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>>>>> >>>>>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>>>>> >>>>>>>>>>> If NSS is configured as specified in this blog, keytool can be >>>>>>>>>>> used >>>>>>>>>>> to >>>>>>>>>>> generate a key as follows: >>>>>>>>>>> >>>>>>>>>>> Hello. >>>>>>>>>>> >>>>>>>>>>> Allowing keytool and friends to work in more cases if the >>>>>>>>>>> provider >>>>>>>>>>> is >>>>>>>>>>> capable seems fine to me. >>>>>>>>>>> >>>>>>>>>>> Security team, do you have concerns about this patch? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Joe >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Andrew :-) >>>>>>>>>> >>>>>>>>>> Free Java Software Engineer >>>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>>> >>>>>>>>>> Support Free Java! >>>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>>> http://openjdk.java.net >>>>>>>>>> >>>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>>>>>> >>>>>>>> Ok here is a new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>>> >>>>>>>> with a slightly revised version of your change (you can't throw a >>>>>>>> PKCS11Exception which only takes a long ID from the native code, >>>>>>>> so I >>>>>>>> changed this to an IllegalArgumentException). >>>>>>>> >>>>>>>> Security team, does this look ok to push? >>>>>>>> -- >>>>>>>> Andrew :-) >>>>>>>> >>>>>>>> Free Java Software Engineer >>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>> >>>>>>>> Support Free Java! >>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>> http://www.gnu.org/software/classpath >>>>>>>> http://openjdk.java.net >>>>>>>> >>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>>>>> >>>>>>> Ping! Security developers, any thoughts on this patch: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>> >>>>>>> Does it look ok to push? >>>>>>> >>>>>>> Thanks, >>> >>> >>> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mark at klomp.org Fri Jan 22 04:27:32 2010 From: mark at klomp.org (Mark Wielaard) Date: Fri, 22 Jan 2010 13:27:32 +0100 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B58EA54.3090009@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> Message-ID: <1264163252.29473.51.camel@hermans.wildebeest.org> Hi Joe, On Thu, 2010-01-21 at 15:59 -0800, Joe Darcy wrote: > Note that at the moment the license header of the test files says > "Copyright 2009 Red Hat" but later states "Please contact Sun > Microsystems ... if you need additional information or have any > questions." If this goes upstream, the copyright holder should be > changed to Sun. Just for the record, as Mark Reinhold previously stated you must never remove copyright notices. Contributors keep the copyright over their code. You can only add an extra copyright notice. Mark explains when: http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000716.html (Of course if contributed through the SCA, Sun then gets all the rights from the copyright owner to license and redistribute the code under the GPL.) Cheers, Mark From joe.wang at sun.com Fri Jan 22 10:42:24 2010 From: joe.wang at sun.com (Joe Wang) Date: Fri, 22 Jan 2010 10:42:24 -0800 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <1264163252.29473.51.camel@hermans.wildebeest.org> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> <1264163252.29473.51.camel@hermans.wildebeest.org> Message-ID: <4B59F190.10309@sun.com> Mark, Thanks for the comment. Since JAXP itself is an open source project, this fix was done in JAXP and then integrated into JDK7. In JAXP, I kept the Red Hat Copyright header and noted that it was contributed by Omair Majid who originally created the bug report. I did add GNU+CDDL license header which I will remove from the jaxp project. This test has not been integrated into OpenJDK. I'll pass the comment to SQE who would be responsible for integrating tests. During a discussion for 100123, I was told I could not use the patch/test unless the contributor has signed the SCA. I'll check with legal again on this. Andrew: have you or Omair signed the SCA? Thanks, Joe Mark Wielaard wrote: > Hi Joe, > > On Thu, 2010-01-21 at 15:59 -0800, Joe Darcy wrote: > >> Note that at the moment the license header of the test files says >> "Copyright 2009 Red Hat" but later states "Please contact Sun >> Microsystems ... if you need additional information or have any >> questions." If this goes upstream, the copyright holder should be >> changed to Sun. >> > > Just for the record, as Mark Reinhold previously stated you must never > remove copyright notices. Contributors keep the copyright over their > code. You can only add an extra copyright notice. Mark explains when: > http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000716.html > (Of course if contributed through the SCA, Sun then gets all the rights > from the copyright owner to license and redistribute the code under the > GPL.) > > Cheers, > > Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100122/224a0ff7/attachment.html From joe.wang at sun.com Fri Jan 22 10:51:10 2010 From: joe.wang at sun.com (Joe Wang) Date: Fri, 22 Jan 2010 10:51:10 -0800 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B59F190.10309@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> <1264163252.29473.51.camel@hermans.wildebeest.org> <4B59F190.10309@sun.com> Message-ID: <4B59F39E.8020501@sun.com> Joe Wang wrote: > Mark, > > Thanks for the comment. Since JAXP itself is an open source project, > this fix was done in JAXP and then integrated into JDK7. In JAXP, I > kept the Red Hat Copyright header and noted that it was contributed by > Omair Majid who originally created the bug report. I did add GNU+CDDL > license header which I will remove from the jaxp project. This test > has not been integrated into OpenJDK. I'll pass the comment to SQE who > would be responsible for integrating tests. > > During a discussion for 100123, I was told I could not use the > patch/test unless the contributor has signed the SCA. I'll check with > legal again on this. > > Andrew: have you or Omair signed the SCA? I answer to myself :) Andrew, I see your name on the list, but not Omair. --Joe > > Thanks, > Joe > > Mark Wielaard wrote: >> Hi Joe, >> >> On Thu, 2010-01-21 at 15:59 -0800, Joe Darcy wrote: >> >>> Note that at the moment the license header of the test files says >>> "Copyright 2009 Red Hat" but later states "Please contact Sun >>> Microsystems ... if you need additional information or have any >>> questions." If this goes upstream, the copyright holder should be >>> changed to Sun. >>> >> >> Just for the record, as Mark Reinhold previously stated you must never >> remove copyright notices. Contributors keep the copyright over their >> code. You can only add an extra copyright notice. Mark explains when: >> http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000716.html >> (Of course if contributed through the SCA, Sun then gets all the rights >> from the copyright owner to license and redistribute the code under the >> GPL.) >> >> Cheers, >> >> Mark >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100122/e27ef750/attachment.html From Vincent.Ryan at Sun.COM Fri Jan 22 10:53:37 2010 From: Vincent.Ryan at Sun.COM (Vincent Ryan) Date: Fri, 22 Jan 2010 18:53:37 +0000 Subject: [security-dev 01544]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <17c6771e1001211738w6137d2b8s2160e5515c43bac2@mail.gmail.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> <4B5805DD.8060101@primekey.se> <4B582889.6080903@sun.com> <17c6771e1001211738w6137d2b8s2160e5515c43bac2@mail.gmail.com> Message-ID: <4B59F431.1030307@sun.com> On 22/01/2010 01:38, Andrew John Hughes wrote: > 2010/1/21 Vincent Ryan : >> I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. >> > > Thanks! Would this be suitable for OpenJDK6 as well? CCing the > jdk6-dev list on that. Yes. The patch should be applied to OpenJDK6 too. > >> >> On 21/01/2010 07:44, Tomas Gustavsson wrote: >>> >>> Now it has one more vote. >>> >>> /Tomas >>> >>> Andrew John Hughes wrote: >>>> 2010/1/20 Tomas Gustavsson : >>>>> I'll second this request. This is a critical patch and many production >>>>> installations have to live with this manually patched now. >>>>> >>>>> I know of no pkcs11 implementation that works with the current code. >>>>> >>>> >>>> It has four votes: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530 >>>> I don't know how many they need to wake up and review the patch. >>>> >>>> The new release of IcedTea6 1.7 is imminent and will include the fix >>>> so it should at least be resolved on the next version shipping with >>>> most GNU/Linux distributions. >>>> >>>>> Regards, >>>>> Tomas Gustavsson >>>>> PrimeKey Solutions AB >>>>> >>>>> >>>>> On Wed, 20 Jan 2010, Michael StJohns wrote: >>>>> >>>>>> Hi - this seems to have stalled out again. Any chance of revival? >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> At 12:33 PM 9/24/2009, Vincent Ryan wrote: >>>>>>> Hello Andrew, >>>>>>> >>>>>>> I'll need a little more time to come up to speed on this fix. I'm >>>>>>> concerned that >>>>>>> there may be interoperability or backwards compatibility issues. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>>> 2009/9/2 Andrew John Hughes : >>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>>>>>>>>>> 2009/9/2 Michael StJohns : >>>>>>>>>>>> ?? This appears to be related specifically to PKCS11.?? >>>>>>>>>>>> Specifically, PKCS11 >>>>>>>>>>>> v2.20 has some ambiguity of the representation of an EC point >>>>>>>>>>>> (which >>>>>>>>>>>> is >>>>>>>>>>>> different in the text than an ASN1 ECPoint). >>>>>>>>>>>> >>>>>>>>>>>> This is being clarified in v2.30 with the unencoded point format >>>>>>>>>>>> (e.g.the >>>>>>>>>>>> format described in?? X9.62, where the first octet indicates the >>>>>>>>>>>> encoding and >>>>>>>>>>>> there are either N or 2N octets following)?? being the expected >>>>>>>>>>>> value, but >>>>>>>>>>>> with PKCS11 providers allowed - legacy - to accept either. >>>>>>>>>>>> >>>>>>>>>>>> One of the reasons for going that way was how the JDK PKCS11 >>>>>>>>>>>> provider had >>>>>>>>>>>> interpreted the issue and implemented its code. >>>>>>>>>>>> >>>>>>>>>>>> I don't support this fix - among other things, this fix only >>>>>>>>>>>> deals >>>>>>>>>>>> with 1/2 >>>>>>>>>>>> of the problem.?? The other half is related to encoding the >>>>>>>>>>>> value.?? Also, >>>>>>>>>>>> changing the code at decodePoint seems further into the stack >>>>>>>>>>>> than >>>>>>>>>>>> needed >>>>>>>>>>>> and may affect other uses of that method. >>>>>>>>>>>> >>>>>>>>>>> That's really too vague to be of much help in improving the patch. >>>>>>>>>>> You seem to be saying little more than 'I don't like it'. >>>>>>>>>> Sorry about that. My point was that your patch didn't completely >>>>>>>>>> solve the problem and that the point at where you were fixing it >>>>>>>>>> could have >>>>>>>>>> some bad side effects for anyone calling decodePoint directly. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> There's an existing JDK bug on this coming at it from a different >>>>>>>>>>>> direction >>>>>>>>>>>> - 6763530 ... and there may be considerations at >>>>>>>>>>>> >>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=480280 >>>>>>>>>>>> >>>>>>>>>>> It seems likely that's the NSS change that causes the current >>>>>>>>>>> failure. >>>>>>>>>>> The fix I submitted here is based on the way this is handle in >>>>>>>>>>> NSS. >>>>>>>>>>> In fact, the code is similar enough to suggest that one was >>>>>>>>>>> developed >>>>>>>>>>> from the other. >>>>>>>>>>>> ?? that should be looked at. >>>>>>>>>>> The JDK bug is not really 'from a different direction', it's >>>>>>>>>>> reporting >>>>>>>>>>> exactly the same error but from a less trivial example (I get the >>>>>>>>>>> same >>>>>>>>>>> failure while trying to create an example key, while this seems to >>>>>>>>>>> require specific hardware if I'm reading it correctly). >>>>>>>>>> Not exactly. You're using the NSS as a PKCS11 module - this >>>>>>>>>> problem >>>>>>>>>> would occur with any PKCS11 module that implements EC stuff. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Also see 6779460 which is mostly a duplicate of >>>>>>>>>>>> 6763530. >>>>>>>>>>>> >>>>>>>>>>> The patch on 6779460 seems wrong. It means that the method will >>>>>>>>>>> return a DER-encoded value where it would either have returned an >>>>>>>>>>> uncompressed value before or failed. >>>>>>>>>> My point exactly as I mentioned in the comments. :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> It's probable that the fix I suggested at 6763530?? (in comments >>>>>>>>>>>> submitted 29 >>>>>>>>>>>> Nov 08) may be a better approach given the NSS fixes.?? I >>>>>>>>>>>> believe >>>>>>>>>>>> it will fix >>>>>>>>>>>> the keytool problem noted in the original message. >>>>>>>>>>>> >>>>>>>>>>> Ok, I can see the logic in the fix and it would appear to work, >>>>>>>>>>> though >>>>>>>>>>> I haven't tested it. >>>>>>>>>>> Given the patch was written nine months ago, why has it not been >>>>>>>>>>> applied? If it had, it would have saved me hours having to debug >>>>>>>>>>> this >>>>>>>>>>> same issue again. >>>>>>>>>> Yup. I did do a search for PKCS11 related bugs when I >>>>>>>>>> encountered the >>>>>>>>>> same problem and did find the original error. >>>>>>>>>> >>>>>>>>>>> Do you have an SCA with Sun? If so, I'll create a webrev based on >>>>>>>>>>> your >>>>>>>>>>> patch and we can finally get this fixed. Without it, NSS >>>>>>>>>>> support is >>>>>>>>>>> completely broken in OpenJDK6 which makes me wonder why this is >>>>>>>>>>> a low >>>>>>>>>>> priority bug! >>>>>>>>>> I do have an SCA on file. Note that the recommendation from the >>>>>>>>>> NSS >>>>>>>>>> guys was to raise the priority. >>>>>>>>>> >>>>>>>>>> The reason I haven't submitted this is because I submitted a >>>>>>>>>> different >>>>>>>>>> EC fix https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per >>>>>>>>>> the >>>>>>>>>> documented process >>>>>>>>>> and was waiting on progress there before continuing. I've got a >>>>>>>>>> number of EC and PKCS11 related fixes I'd like to submit, but I >>>>>>>>>> was trying >>>>>>>>>> for a worked example before proceeding. And then I got busy >>>>>>>>>> with some other >>>>>>>>>> things... >>>>>>>>>> >>>>>>>>>> Mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Mike >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> At 04:39 PM 9/1/2009, Joe Darcy wrote: >>>>>>>>>>>> >>>>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2009/8/28 Andrew John Hughes : >>>>>>>>>>>> >>>>>>>>>>>> In OpenJDK6, the elliptic curve cryptography algorithms are >>>>>>>>>>>> available >>>>>>>>>>>> if the PKCS11 provider is configured to point to NSS. See: >>>>>>>>>>>> >>>>>>>>>>>> http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>>>>>>>>>>> >>>>>>>>>>>> If NSS is configured as specified in this blog, keytool can be >>>>>>>>>>>> used >>>>>>>>>>>> to >>>>>>>>>>>> generate a key as follows: >>>>>>>>>>>> >>>>>>>>>>>> Hello. >>>>>>>>>>>> >>>>>>>>>>>> Allowing keytool and friends to work in more cases if the >>>>>>>>>>>> provider >>>>>>>>>>>> is >>>>>>>>>>>> capable seems fine to me. >>>>>>>>>>>> >>>>>>>>>>>> Security team, do you have concerns about this patch? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Joe >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Andrew :-) >>>>>>>>>>> >>>>>>>>>>> Free Java Software Engineer >>>>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>>>> >>>>>>>>>>> Support Free Java! >>>>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>>>> http://openjdk.java.net >>>>>>>>>>> >>>>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>>>> >>>>>>>>> Ok here is a new webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>>>> >>>>>>>>> with a slightly revised version of your change (you can't throw a >>>>>>>>> PKCS11Exception which only takes a long ID from the native code, >>>>>>>>> so I >>>>>>>>> changed this to an IllegalArgumentException). >>>>>>>>> >>>>>>>>> Security team, does this look ok to push? >>>>>>>>> -- >>>>>>>>> Andrew :-) >>>>>>>>> >>>>>>>>> Free Java Software Engineer >>>>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>>>> >>>>>>>>> Support Free Java! >>>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>>> http://www.gnu.org/software/classpath >>>>>>>>> http://openjdk.java.net >>>>>>>>> >>>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>>> >>>>>>>> Ping! Security developers, any thoughts on this patch: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ >>>>>>>> >>>>>>>> Does it look ok to push? >>>>>>>> >>>>>>>> Thanks, >>>> >>>> >>>> >> > > > From Joe.Darcy at Sun.COM Fri Jan 22 11:04:04 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 22 Jan 2010 11:04:04 -0800 Subject: [security-dev 01544]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6 In-Reply-To: <4B59F431.1030307@sun.com> References: <17c6771e0909220318l4cdecc25v54844e73c7916708@mail.gmail.com> <4ABBAD55.7070206@sun.com> <20100120180532.909D064A2@mail.openjdk.java.net> <17c6771e1001201416m4d44ab72o58bf51ffd453827a@mail.gmail.com> <4B5805DD.8060101@primekey.se> <4B582889.6080903@sun.com> <17c6771e1001211738w6137d2b8s2160e5515c43bac2@mail.gmail.com> <4B59F431.1030307@sun.com> Message-ID: <4B59F6A4.4000405@sun.com> Vincent Ryan wrote: > On 22/01/2010 01:38, Andrew John Hughes wrote: > >> 2010/1/21 Vincent Ryan : >> >>> I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. >>> >>> >> Thanks! Would this be suitable for OpenJDK6 as well? CCing the >> jdk6-dev list on that. >> > > > Yes. The patch should be applied to OpenJDK6 too. > > I hereby authorize you do push the fix to OpenJDK 6 too :-) Repositories are under http://hg.openjdk.java.net/jdk6/jdk6/ -Joe From Joe.Darcy at Sun.COM Fri Jan 22 11:14:19 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 22 Jan 2010 11:14:19 -0800 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B59F39E.8020501@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> <1264163252.29473.51.camel@hermans.wildebeest.org> <4B59F190.10309@sun.com> <4B59F39E.8020501@sun.com> Message-ID: <4B59F90B.1030200@sun.com> Joe Wang wrote: > Joe Wang wrote: >> Mark, >> >> Thanks for the comment. Since JAXP itself is an open source project, >> this fix was done in JAXP and then integrated into JDK7. In JAXP, I >> kept the Red Hat Copyright header and noted that it was contributed >> by Omair Majid who originally created the bug report. I did add >> GNU+CDDL license header which I will remove from the jaxp project. >> This test has not been integrated into OpenJDK. I'll pass the comment >> to SQE who would be responsible for integrating tests. >> >> During a discussion for 100123, I was told I could not use the >> patch/test unless the contributor has signed the SCA. I'll check with >> legal again on this. >> >> Andrew: have you or Omair signed the SCA? > I answer to myself :) Andrew, I see your name on the list, but not Omair. > If Omair is the Omair who works for Red Hat, Red Hat as a company has signed the SCA [1] so individual Red Hat engineers do not have to sign before contributing to OpenJDK (or other Sun open source project). -Joe [1] http://www.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20071105005882&newsLang=en From Joe.Darcy at Sun.COM Fri Jan 22 11:23:16 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 22 Jan 2010 11:23:16 -0800 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <1264163252.29473.51.camel@hermans.wildebeest.org> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> <1264163252.29473.51.camel@hermans.wildebeest.org> Message-ID: <4B59FB24.7040302@sun.com> Mark Wielaard wrote: > Hi Joe, > > On Thu, 2010-01-21 at 15:59 -0800, Joe Darcy wrote: > >> Note that at the moment the license header of the test files says >> "Copyright 2009 Red Hat" but later states "Please contact Sun >> Microsystems ... if you need additional information or have any >> questions." If this goes upstream, the copyright holder should be >> changed to Sun. >> > > Just for the record, as Mark Reinhold previously stated you must never > remove copyright notices. Contributors keep the copyright over their > code. You can only add an extra copyright notice. Mark explains when: > http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000716.html > (Of course if contributed through the SCA, Sun then gets all the rights > from the copyright owner to license and redistribute the code under the > GPL.) > My misstatement, yes the Red Hat copyright should be preserved. Thanks for the correction, -Joe From joe.wang at sun.com Fri Jan 22 15:41:23 2010 From: joe.wang at sun.com (Joe Wang) Date: Fri, 22 Jan 2010 15:41:23 -0800 Subject: test integration -> Re: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B5A338C.4080904@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> <4B58F379.8090901@sun.com> <4B5A338C.4080904@sun.com> Message-ID: <4B5A37A3.5090708@sun.com> Bill Situ wrote: > Clarification: > > Bill had asked me to upload all of the unit tests along with source > tarball. According to Bill, his team will take over from there and > integrate them into the jdk workspace. > > Joe, > > My recollection is that we were talking about the sqe test, not jdk > regression test. And my team did handle fixes for the sqe in the last > few months. My team does not handle integration to jdk. Ok, it may be my misunderstanding. I'll find the original thread and continue the discussion. Thanks, Joe > > Thanks, > > Bill > > Joe Wang wrote: >> Joe, >> >> The patch, contributed by Andrew, was integrated into OpenJDK7, which >> Andrew confirmed. According to Kelly, he applied the same source >> tarball to OpenJDK6. So we need to find out why >> jdk6-jaxp-2009_10_27.zip did not have this fix. >> >> About tests, we do have unit test for every fix in jaxp, and for this >> particular bug, we've used the testcase Andrew contributed. Bill had >> asked me to upload all of the unit tests along with source tarball. >> According to Bill, his team will take over from there and integrate >> them into the jdk workspace. >> >> Thanks, >> Joe >> >> Joe Darcy wrote: >>> Hello. >>> >>> Andrew John Hughes wrote: >>>> On 09:50 Fri 15 Jan , Joe Wang wrote: >>>>> Thanks Alan. Yes, I did receive the bugzilla notice. >>>>> >>>>> Kelly told me that he applied the same jaxp source tarball to >>>>> OpenJDK6. Kelly, could you tell Andrew how to include the jaxp >>>>> source tarball when building OpenJDK6? >>>>> >>>> >>>> The tarball jdk6-jaxp-2009_10_27.zip used by the OpenJDK6 build >>>> does not >>>> include the fix. We are still having to apply the patch: >>>> >>>> diff -Nru openjdk.orig/jaxp/build.properties >>>> openjdk/jaxp/build.properties >>>> --- openjdk.orig/jaxp/build.properties 2009-12-08 >>>> 17:42:33.000000000 +0000 >>>> +++ openjdk/jaxp/build.properties 2009-12-08 >>>> 17:43:03.000000000 +0000 >>>> @@ -73,6 +73,9 @@ >>>> # Where patches to drop bundle sources live >>>> patches.dir=patches >>>> >>>> +# Patches to apply >>>> +jaxp_src.patch.list=xml-encodinginfo.patch >>>> + >>>> # Sanity information >>>> sanity.info= Sanity Settings:${line.separator}\ >>>> ant.home=${ant.home}${line.separator}\ >>>> diff -Nru openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>>> openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>>> --- >>>> openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>>> 1970-01-01 01:00:00.000000000 +0100 >>>> +++ openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>>> 2009-12-08 17:41:58.000000000 +0000 >>>> @@ -0,0 +1,18 @@ >>>> +diff -Nru >>>> src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>>> src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>>> +--- >>>> src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>>> 2009-10-27 21:54:16.000000000 +0000 >>>> ++++ >>>> src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>>> 2009-12-08 17:40:14.000000000 +0000 >>>> +@@ -326,9 +326,11 @@ >>>> + m_last = last; >>>> + + // Set the range of unicode values that this object >>>> +- // explicitly manages >>>> +- m_explFirst = codePoint; >>>> +- m_explLast = codePoint + (RANGE-1); >>>> ++ // explicitly manages. Align the explicitly managed >>>> values >>>> ++ // to RANGE so multiple EncodingImpl objects dont >>>> manage the same ++ // values. >>>> ++ m_explFirst = codePoint / RANGE * RANGE; >>>> ++ m_explLast = m_explFirst + (RANGE-1); >>>> + + m_encoding = encoding; >>>> + >>> >>> Joe (Wang), I'll let you decide on the appropriateness of the fix >>> for jaxp. If the fix is good, a new jaxp bundle for OpenJDK 6 would >>> be fine by me. >>> >>>> BTW, we have a testcase for this. Would it be possible to add this to >>>> the JDK tree? The complete patch included in the icedtea6-hg tree >>>> (http://icedtea.classpath.org/people/andrew/icedtea6-hg), including >>>> test case, is attached. >>> >>> Tests are good of course and since the jaxp repo doesn't currently >>> have any regression tests, putting the test into OpenJDK 6 in the >>> jdk repo seems like the right home for it, as the patch currently does. >>> >>> Note that at the moment the license header of the test files says >>> "Copyright 2009 Red Hat" but later states "Please contact Sun >>> Microsystems ... if you need additional information or have any >>> questions." If this goes upstream, the copyright holder should be >>> changed to Sun. >>> >>> Thanks, >>> >>> -Joe >> From Bill.Situ at Sun.COM Fri Jan 22 15:23:56 2010 From: Bill.Situ at Sun.COM (Bill Situ) Date: Fri, 22 Jan 2010 15:23:56 -0800 Subject: test integration -> Re: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B58F379.8090901@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> <4B58F379.8090901@sun.com> Message-ID: <4B5A338C.4080904@sun.com> Clarification: Bill had asked me to upload all of the unit tests along with source tarball. According to Bill, his team will take over from there and integrate them into the jdk workspace. Joe, My recollection is that we were talking about the sqe test, not jdk regression test. And my team did handle fixes for the sqe in the last few months. My team does not handle integration to jdk. Thanks, Bill Joe Wang wrote: > Joe, > > The patch, contributed by Andrew, was integrated into OpenJDK7, which > Andrew confirmed. According to Kelly, he applied the same source > tarball to OpenJDK6. So we need to find out why > jdk6-jaxp-2009_10_27.zip did not have this fix. > > About tests, we do have unit test for every fix in jaxp, and for this > particular bug, we've used the testcase Andrew contributed. Bill had > asked me to upload all of the unit tests along with source tarball. > According to Bill, his team will take over from there and integrate > them into the jdk workspace. > > Thanks, > Joe > > Joe Darcy wrote: >> Hello. >> >> Andrew John Hughes wrote: >>> On 09:50 Fri 15 Jan , Joe Wang wrote: >>>> Thanks Alan. Yes, I did receive the bugzilla notice. >>>> >>>> Kelly told me that he applied the same jaxp source tarball to >>>> OpenJDK6. Kelly, could you tell Andrew how to include the jaxp >>>> source tarball when building OpenJDK6? >>>> >>> >>> The tarball jdk6-jaxp-2009_10_27.zip used by the OpenJDK6 build does >>> not >>> include the fix. We are still having to apply the patch: >>> >>> diff -Nru openjdk.orig/jaxp/build.properties >>> openjdk/jaxp/build.properties >>> --- openjdk.orig/jaxp/build.properties 2009-12-08 >>> 17:42:33.000000000 +0000 >>> +++ openjdk/jaxp/build.properties 2009-12-08 >>> 17:43:03.000000000 +0000 >>> @@ -73,6 +73,9 @@ >>> # Where patches to drop bundle sources live >>> patches.dir=patches >>> >>> +# Patches to apply >>> +jaxp_src.patch.list=xml-encodinginfo.patch >>> + >>> # Sanity information >>> sanity.info= Sanity Settings:${line.separator}\ >>> ant.home=${ant.home}${line.separator}\ >>> diff -Nru openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>> openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>> --- openjdk.orig/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>> 1970-01-01 01:00:00.000000000 +0100 >>> +++ openjdk/jaxp/patches/jaxp_src/xml-encodinginfo.patch >>> 2009-12-08 17:41:58.000000000 +0000 >>> @@ -0,0 +1,18 @@ >>> +diff -Nru >>> src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>> src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>> +--- >>> src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>> 2009-10-27 21:54:16.000000000 +0000 >>> ++++ >>> src.new/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java >>> 2009-12-08 17:40:14.000000000 +0000 >>> +@@ -326,9 +326,11 @@ >>> + m_last = last; >>> + + // Set the range of unicode values that this object >>> +- // explicitly manages >>> +- m_explFirst = codePoint; >>> +- m_explLast = codePoint + (RANGE-1); >>> ++ // explicitly manages. Align the explicitly managed >>> values >>> ++ // to RANGE so multiple EncodingImpl objects dont >>> manage the same ++ // values. >>> ++ m_explFirst = codePoint / RANGE * RANGE; >>> ++ m_explLast = m_explFirst + (RANGE-1); >>> + + m_encoding = encoding; >>> + >> >> Joe (Wang), I'll let you decide on the appropriateness of the fix for >> jaxp. If the fix is good, a new jaxp bundle for OpenJDK 6 would be >> fine by me. >> >>> BTW, we have a testcase for this. Would it be possible to add this to >>> the JDK tree? The complete patch included in the icedtea6-hg tree >>> (http://icedtea.classpath.org/people/andrew/icedtea6-hg), including >>> test case, is attached. >> >> Tests are good of course and since the jaxp repo doesn't currently >> have any regression tests, putting the test into OpenJDK 6 in the jdk >> repo seems like the right home for it, as the patch currently does. >> >> Note that at the moment the license header of the test files says >> "Copyright 2009 Red Hat" but later states "Please contact Sun >> Microsystems ... if you need additional information or have any >> questions." If this goes upstream, the copyright holder should be >> changed to Sun. >> >> Thanks, >> >> -Joe > From ahughes at redhat.com Sun Jan 24 15:25:36 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Sun, 24 Jan 2010 23:25:36 +0000 Subject: [Bug 100017] XML encoder can cause a StackOverflowError In-Reply-To: <4B59F39E.8020501@sun.com> References: <20100115153223.5CDD02164@bugs.openjdk.java.net> <4B508DD8.4000600@sun.com> <4B50AAD1.4000404@sun.com> <20100118195813.GA32693@rivendell.middle-earth.co.uk> <4B58EA54.3090009@sun.com> <1264163252.29473.51.camel@hermans.wildebeest.org> <4B59F190.10309@sun.com> <4B59F39E.8020501@sun.com> Message-ID: <20100124232536.GA9986@rivendell.middle-earth.co.uk> On 10:51 Fri 22 Jan , Joe Wang wrote: > Joe Wang wrote: >> Mark, >> >> Thanks for the comment. Since JAXP itself is an open source project, this >> fix was done in JAXP and then integrated into JDK7. In JAXP, I kept the >> Red Hat Copyright header and noted that it was contributed by Omair Majid >> who originally created the bug report. I did add GNU+CDDL license header >> which I will remove from the jaxp project. This test has not been >> integrated into OpenJDK. I'll pass the comment to SQE who would be >> responsible for integrating tests. >> >> During a discussion for 100123, I was told I could not use the patch/test >> unless the contributor has signed the SCA. I'll check with legal again on >> this. >> >> Andrew: have you or Omair signed the SCA? > I answer to myself :) Andrew, I see your name on the list, but not Omair. My name is on the list as a private person from before I joined Red Hat, but Red Hat itself has a company SCA which covers both myself and Omair's work for us as an intern. > > --Joe >> >> Thanks, >> Joe >> >> Mark Wielaard wrote: >>> Hi Joe, >>> >>> On Thu, 2010-01-21 at 15:59 -0800, Joe Darcy wrote: >>> >>>> Note that at the moment the license header of the test files says >>>> "Copyright 2009 Red Hat" but later states "Please contact Sun >>>> Microsystems ... if you need additional information or have any >>>> questions." If this goes upstream, the copyright holder should be >>>> changed to Sun. >>>> >>> >>> Just for the record, as Mark Reinhold previously stated you must never >>> remove copyright notices. Contributors keep the copyright over their >>> code. You can only add an extra copyright notice. Mark explains when: >>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000716.html >>> (Of course if contributed through the SCA, Sun then gets all the rights >>> from the copyright owner to license and redistribute the code under the >>> GPL.) >>> >>> Cheers, >>> >>> Mark >>> >>> >> > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ptisnovs at redhat.com Mon Jan 25 04:53:22 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 25 Jan 2010 13:53:22 +0100 Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java Message-ID: <4B5D9442.8090204@redhat.com> Hi, please review changes made in regression test /java/awt/TestArea/UsingWithMouse.java. Webrev is available at http://cr.openjdk.java.net/~ptisnovs/SelectionAutoscrollTest/ There's added small delay between each scroll event, so the scrolling (and related text selection by mouse cursor) is really performed on Gnome. Tested on RHEL x86_64 with Gnome installed. I also tried to use only Util.waitForIdle(robot) instead of Thread.sleep() but this does not help in this case. This patch can be applied to OpenJDK7 too. Thanks in advance Pavel Tisnovsky Red Hat QA From ptisnovs at redhat.com Mon Jan 25 08:54:30 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 25 Jan 2010 17:54:30 +0100 Subject: Please review changes in regression test /java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java Message-ID: <4B5DCCC6.2020805@redhat.com> Hi, please review changes made in regression test /java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java Webrev is available at http://cr.openjdk.java.net/~ptisnovs/LocationRelativeToTest/ I changed only minor part of test code utilized to check, if frame is placed at the center of the screen. The test should (IMHO, of course) use Point returned by GraphicsEnvironment.getCenterPoint() in this case, not coordinates computed from selected GraphicsConfiguration's bound. According to JavaSE 6 documentation: "If the component is not currently showing (*** our case ***), or c is null, the window is placed at the center of the screen. The center point can be determined with GraphicsEnvironment.getCenterPoint" Tested on: Fedora 10 with multi-screen configuration (laptop screen+external LCD) RHEL 5 x86_64 with virtual framebuffer (this tests fails on these machines before being patched) Thanks in advance Pavel Tisnovsky Red Hat QA From Anthony.Petrov at Sun.COM Mon Jan 25 10:05:53 2010 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Mon, 25 Jan 2010 21:05:53 +0300 Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java In-Reply-To: <4B5D9442.8090204@redhat.com> References: <4B5D9442.8090204@redhat.com> Message-ID: <4B5DDD81.9010409@sun.com> Hi Pavel, I think what you really need to use here instead of Thread.sleep() is the ((sun.awt.SunToolkit)Toolkit.getDefaultToolkit()).realSync(); method which actually ends up in calling the XSync(), and therefore makes sure the X server processes the requests we're sending. waitForIdle() can't help with that because it only waits for the java events to be processed, not the requests to the X server. Could you try this and see if that fixes the test? -- best regards, Anthony On 1/25/2010 3:53 PM Pavel Tisnovsky wrote: > Hi, > > please review changes made in regression test > /java/awt/TestArea/UsingWithMouse.java. > > Webrev is available at > http://cr.openjdk.java.net/~ptisnovs/SelectionAutoscrollTest/ > > There's added small delay between each scroll event, so the scrolling > (and related text selection by mouse cursor) is really performed on > Gnome. Tested on RHEL x86_64 with Gnome installed. I also tried to use > only Util.waitForIdle(robot) instead of Thread.sleep() but this does not > help in this case. > > This patch can be applied to OpenJDK7 too. > > Thanks in advance > Pavel Tisnovsky > Red Hat QA > From ptisnovs at redhat.com Mon Jan 25 11:24:13 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 25 Jan 2010 14:24:13 -0500 (EST) Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java In-Reply-To: <4B5DDD81.9010409@sun.com> Message-ID: <1670472541.114191264447453751.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Hi Anthony, thank you for the tip, I'll try to use realSync(), it seems to be the best solution. Pavel ----- Original Message ----- From: Anthony Petrov To: Pavel Tisnovsky Cc: awt-dev at openjdk.java.net, jdk6-dev at openjdk.java.net Sent: Mon, 25 Jan 2010 13:05:53 -0500 (EST) Subject: Re: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java Hi Pavel, I think what you really need to use here instead of Thread.sleep() is the ((sun.awt.SunToolkit)Toolkit.getDefaultToolkit()).realSync(); method which actually ends up in calling the XSync(), and therefore makes sure the X server processes the requests we're sending. waitForIdle() can't help with that because it only waits for the java events to be processed, not the requests to the X server. Could you try this and see if that fixes the test? -- best regards, Anthony On 1/25/2010 3:53 PM Pavel Tisnovsky wrote: > Hi, > > please review changes made in regression test > /java/awt/TestArea/UsingWithMouse.java. > > Webrev is available at > http://cr.openjdk.java.net/~ptisnovs/SelectionAutoscrollTest/ > > There's added small delay between each scroll event, so the scrolling > (and related text selection by mouse cursor) is really performed on > Gnome. Tested on RHEL x86_64 with Gnome installed. I also tried to use > only Util.waitForIdle(robot) instead of Thread.sleep() but this does not > help in this case. > > This patch can be applied to OpenJDK7 too. > > Thanks in advance > Pavel Tisnovsky > Red Hat QA > From Joe.Darcy at Sun.COM Tue Jan 26 00:10:30 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 26 Jan 2010 00:10:30 -0800 Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java In-Reply-To: <1670472541.114191264447453751.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> References: <1670472541.114191264447453751.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Message-ID: <4B5EA376.4040308@sun.com> Pavel Tisnovsky wrote: > Hi Anthony, > > thank you for the tip, I'll try to use realSync(), it seems to be the best solution. > If the fix is approved by the awt team, I'm happy for the test change to go back into OpenJDK 6. -Joe From ptisnovs at redhat.com Tue Jan 26 00:31:13 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Tue, 26 Jan 2010 09:31:13 +0100 Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java (second version of patch) Message-ID: <4B5EA851.5070200@redhat.com> Hi, please review changes made in regression test /java/awt/TestArea/UsingWithMouse.java. Webrev is available at http://cr.openjdk.java.net/~ptisnovs/SelectionAutoscrollTest2/ I've added synchronization of scrolling using method SunToolkit.realSync(), it seems to works perfectly on RHEL x86_64 + Gnome and Fedora 10 i386 + Gnome. Thanks Anthony Petrov for his tip! This patch can be applied to OpenJDK7 too. Thanks in advance Pavel Tisnovsky Red Hat QA From Anthony.Petrov at Sun.COM Tue Jan 26 02:19:16 2010 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 26 Jan 2010 13:19:16 +0300 Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java (second version of patch) - approved In-Reply-To: <4B5EA851.5070200@redhat.com> References: <4B5EA851.5070200@redhat.com> Message-ID: <4B5EC1A4.6000005@sun.com> Pavel, The fix looks great. AWT team approves the changes. Please feel free to push the changeset to both jdk6 and jdk7 (awt-gate). Thank you for the fix! -- best regards, Anthony On 1/26/2010 11:31 AM Pavel Tisnovsky wrote: > Hi, > > please review changes made in regression test > /java/awt/TestArea/UsingWithMouse.java. > > Webrev is available at > http://cr.openjdk.java.net/~ptisnovs/SelectionAutoscrollTest2/ > > I've added synchronization of scrolling using method > SunToolkit.realSync(), it seems to works perfectly on RHEL x86_64 + > Gnome and Fedora 10 i386 + Gnome. Thanks Anthony Petrov for his tip! > > This patch can be applied to OpenJDK7 too. > > Thanks in advance > Pavel Tisnovsky > Red Hat QA > > From Artem.Ananiev at Sun.COM Tue Jan 26 03:25:39 2010 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Tue, 26 Jan 2010 14:25:39 +0300 Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java (second version of patch) In-Reply-To: <4B5EA851.5070200@redhat.com> References: <4B5EA851.5070200@redhat.com> Message-ID: <4B5ED133.5010703@sun.com> Hi, Pavel, On 1/26/2010 11:31 AM, Pavel Tisnovsky wrote: > Hi, > > please review changes made in regression test > /java/awt/TestArea/UsingWithMouse.java. > > Webrev is available at > http://cr.openjdk.java.net/~ptisnovs/SelectionAutoscrollTest2/ > > I've added synchronization of scrolling using method > SunToolkit.realSync(), it seems to works perfectly on RHEL x86_64 + > Gnome and Fedora 10 i386 + Gnome. Thanks Anthony Petrov for his tip! the problem looks really, really strange... Util.waitForIdle() is implemented exactly the same way: as a call to realSync() - while you wrote that calling waitForIdle() didn't help. Please, postpone your fix (don't integrate into AWT gate repository) and check if Util.waitForIdle() does the job. realSync() is a low-level and private Sun's API, so I'd prefer having it in a single place (in Util) so we can change it easily, if necessary (e.g. when realSync() becomes public). Thanks, Artem > This patch can be applied to OpenJDK7 too. > > Thanks in advance > Pavel Tisnovsky > Red Hat QA > > From ptisnovs at redhat.com Tue Jan 26 03:57:05 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Tue, 26 Jan 2010 12:57:05 +0100 Subject: Please review changes in regression test /java/awt/TestArea/UsingWithMouse.java (second version of patch) In-Reply-To: <4B5ED133.5010703@sun.com> References: <4B5EA851.5070200@redhat.com> <4B5ED133.5010703@sun.com> Message-ID: <4B5ED891.1060907@redhat.com> Artem Ananiev wrote: >> I've added synchronization of scrolling using method >> SunToolkit.realSync(), it seems to works perfectly on RHEL x86_64 + >> Gnome and Fedora 10 i386 + Gnome. Thanks Anthony Petrov for his tip! > > the problem looks really, really strange... Util.waitForIdle() is > implemented exactly the same way: as a call to realSync() - while you > wrote that calling waitForIdle() didn't help. > > Please, postpone your fix (don't integrate into AWT gate repository) and > check if Util.waitForIdle() does the job. realSync() is a low-level and > private Sun's API, so I'd prefer having it in a single place (in Util) > so we can change it easily, if necessary (e.g. when realSync() becomes > public). Yes, you are right, Util.waitForIdle() simply calls realSync(). It is interesting - without this sync (waifForIdle/realSync, does not matter which I use) this test always fails on my machine (i.e. it does not selects all lines of TextArea), with sync included it fails "only" in circa 1/10 of its run. At this time, I don't plan to push this patch as it isn't 100% correct. > > Thanks, > > Artem > >> This patch can be applied to OpenJDK7 too. >> >> Thanks in advance >> Pavel Tisnovsky >> Red Hat QA >> >> From ptisnovs at redhat.com Tue Jan 26 08:23:07 2010 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Tue, 26 Jan 2010 16:23:07 +0000 Subject: hg: jdk6/jdk6/jdk: 6920172: Regression test LocationRelativeToTest does not check frame position correctly. Message-ID: <20100126162320.536BE41C1D@hg.openjdk.java.net> Changeset: 0db3dbda124a Author: ptisnovs Date: 2010-01-26 17:22 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0db3dbda124a 6920172: Regression test LocationRelativeToTest does not check frame position correctly. Summary: Testcase correction - check frame position against graphics environment's center point Reviewed-by: art ! test/java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java From ptisnovs at redhat.com Wed Jan 27 08:37:22 2010 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Wed, 27 Jan 2010 16:37:22 +0000 Subject: hg: jdk6/jdk6/jdk: 6920143: test/java/awt/TestArea/UsingWithMouse.java needs realSync() Message-ID: <20100127163735.8F5A141DB5@hg.openjdk.java.net> Changeset: 879703b75a4a Author: ptisnovs Date: 2010-01-27 17:36 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/879703b75a4a 6920143: test/java/awt/TestArea/UsingWithMouse.java needs realSync() Summary: Added small delay to make sure that TextArea animation have finished Reviewed-by: anthony ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.java From gnu_andrew at member.fsf.org Wed Jan 27 08:59:01 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 27 Jan 2010 16:59:01 +0000 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> <4B5103A2.20809@sun.com> <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> Message-ID: <17c6771e1001270859g77971a44pcd7d267ebfd17393@mail.gmail.com> 2010/1/16 Andrew John Hughes : > 2010/1/16 Joseph D. Darcy : >> Andrew John Hughes wrote: >>> >>> 2010/1/15 Ken Cavanaugh : >>> >>>> >>>> The fixes look good to me. >>>> >>>> Thanks, >>>> >>>> Ken. >>>> >>>> On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: >>>> >>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>>> >>>>>> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >>>>>> number of warnings when building documentation: >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >>>>>> warning - Tag @link: reference not found: Stub#connect >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >>>>>> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >>>>>> t_policy_override >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag >>>>>> @return cannot be used in constructor documentation. ?It can\ >>>>>> only be used in the following types of documentation: method. >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >>>>>> warning - @ is an unknown tag. >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: >>>>>> warning - Tag @return cannot be used in field documentation\ >>>>>> . ?It can only be used in the following types of documentation: method. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: >>>>>> warning - @parm is an unknown tag. >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: >>>>>> warning - @parm is an unknown tag. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: >>>>>> warning - @parm is an unknown tag. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: >>>>>> warning - @param argument "a_component" is not a p\ >>>>>> arameter name. >>>>>> >>>>>> >>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: >>>>>> warning - @param argument "a_component" is not a p\ >>>>>> arameter name. >>>>>> >>>>>> This patch against OpenJDK7: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >>>>>> >>>>>> fixes the warnings. >>>>>> >>>>>> Is this ok to push? ?If so, can I have a bug ID for it? >>>>>> >>>>>> Joe, would this also be ok for 6? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>> >>>>> cc'ing Ken Cavanaugh for corba matters. >>>>> >>>>> If this fix is approved for JDK 7, I approve it to also go back into >>>>> OpenJDK 6. >>>>> >>>>> Regards, >>>>> >>>>> -Joe >>>>> >>>>> >>>> >>>> >>> >>> Thanks Ken. ?I don't see you on http://db.openjdk.java.net/people so >>> not sure what I should use for the Reviewed-by field. >>> >>> Joe, can you allocate this a bug ID? >>> >> >> 6917485 Corba doc warnings >> >> You can use me as a reviewer for jcheck purposes. >> >> Have a good weekend, >> >> -Joe >> >> PS Monday is a holiday for Sun in the US. >> >> > > Done: > > http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/05436b84e93a > http://hg.openjdk.java.net/jdk7/build/corba/rev/d4c077d44a64 > > With this fix as well: > > http://cr.openjdk.java.net/~andrew/build/webrev.05/ > > the main javadoc build passes with no warnings. ?There are two > remaining warnings from doclets: > > /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - > Tag @link: reference not found: > com.sun.tools.doclets.internal.toolkit.util > /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - > Tag @link: reference not found: > com.sun.tools.doclets.internal.toolkit.util > 2 warnings > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Does http://cr.openjdk.java.net/~andrew/build/webrev.05/ look ok? If so, can I have a bug ID to push to 6 and 7? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Jan 28 12:07:32 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 28 Jan 2010 12:07:32 -0800 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <17c6771e1001270859g77971a44pcd7d267ebfd17393@mail.gmail.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> <4B5103A2.20809@sun.com> <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> <17c6771e1001270859g77971a44pcd7d267ebfd17393@mail.gmail.com> Message-ID: <4B61EE84.5030600@sun.com> Andrew John Hughes wrote: > 2010/1/16 Andrew John Hughes : > >> 2010/1/16 Joseph D. Darcy : >> >>> Andrew John Hughes wrote: >>> >>>> 2010/1/15 Ken Cavanaugh : >>>> >>>> >>>>> The fixes look good to me. >>>>> >>>>> Thanks, >>>>> >>>>> Ken. >>>>> >>>>> On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: >>>>> >>>>> >>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >>>>>>> number of warnings when building documentation: >>>>>>> >>>>>>> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >>>>>>> warning - Tag @link: reference not found: Stub#connect >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >>>>>>> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >>>>>>> t_policy_override >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - Tag >>>>>>> @return cannot be used in constructor documentation. It can\ >>>>>>> only be used in the following types of documentation: method. >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >>>>>>> warning - @ is an unknown tag. >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: >>>>>>> warning - Tag @return cannot be used in field documentation\ >>>>>>> . It can only be used in the following types of documentation: method. >>>>>>> >>>>>>> >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: >>>>>>> warning - @parm is an unknown tag. >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: >>>>>>> warning - @parm is an unknown tag. >>>>>>> >>>>>>> >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: >>>>>>> warning - @parm is an unknown tag. >>>>>>> >>>>>>> >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: >>>>>>> warning - @param argument "a_component" is not a p\ >>>>>>> arameter name. >>>>>>> >>>>>>> >>>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: >>>>>>> warning - @param argument "a_component" is not a p\ >>>>>>> arameter name. >>>>>>> >>>>>>> This patch against OpenJDK7: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >>>>>>> >>>>>>> fixes the warnings. >>>>>>> >>>>>>> Is this ok to push? If so, can I have a bug ID for it? >>>>>>> >>>>>>> Joe, would this also be ok for 6? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>> cc'ing Ken Cavanaugh for corba matters. >>>>>> >>>>>> If this fix is approved for JDK 7, I approve it to also go back into >>>>>> OpenJDK 6. >>>>>> >>>>>> Regards, >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> >>>> Thanks Ken. I don't see you on http://db.openjdk.java.net/people so >>>> not sure what I should use for the Reviewed-by field. >>>> >>>> Joe, can you allocate this a bug ID? >>>> >>>> >>> 6917485 Corba doc warnings >>> >>> You can use me as a reviewer for jcheck purposes. >>> >>> Have a good weekend, >>> >>> -Joe >>> >>> PS Monday is a holiday for Sun in the US. >>> >>> >>> >> Done: >> >> http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/05436b84e93a >> http://hg.openjdk.java.net/jdk7/build/corba/rev/d4c077d44a64 >> >> With this fix as well: >> >> http://cr.openjdk.java.net/~andrew/build/webrev.05/ >> >> the main javadoc build passes with no warnings. There are two >> remaining warnings from doclets: >> >> /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - >> Tag @link: reference not found: >> com.sun.tools.doclets.internal.toolkit.util >> /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - >> Tag @link: reference not found: >> com.sun.tools.doclets.internal.toolkit.util >> 2 warnings >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > Does http://cr.openjdk.java.net/~andrew/build/webrev.05/ look ok? > > If so, can I have a bug ID to push to 6 and 7? > > Thanks, > Ah yes, the specdefault tag. I forget offhand where these occur in the JDK sources, but they have been there for many years and not caused any harm so I'm willing having to have specdefault listed in the set of known tags to silence some spurious errors. You can use 6921068 Remove javadoc builds warnings from specdefault tag for this issue. I approve this going into OpenJDK 6 and JDK 7. Thanks, -Joe From ahughes at redhat.com Thu Jan 28 13:01:30 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 28 Jan 2010 21:01:30 +0000 Subject: hg: jdk6/jdk6/jdk: 6921068: Remove javadoc builds warnings from specdefault tag Message-ID: <20100128210143.05A4141F94@hg.openjdk.java.net> Changeset: ffceebe8e01f Author: andrew Date: 2010-01-28 21:01 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ffceebe8e01f 6921068: Remove javadoc builds warnings from specdefault tag Summary: Ignore specdefault tag to avoid javadoc warnings Reviewed-by: darcy, ohair ! make/docs/Makefile From gnu_andrew at member.fsf.org Thu Jan 28 15:40:50 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 28 Jan 2010 23:40:50 +0000 Subject: [PATCH FOR REVIEW]: Fix CORBA documentation warnings In-Reply-To: <4B61EE84.5030600@sun.com> References: <17c6771e1001151352t18411e66le715ab90a8ac239c@mail.gmail.com> <4B50E531.70803@sun.com> <31C7A98B-D029-4978-AB7E-B91D9D7F5517@Sun.COM> <17c6771e1001151532q5cc16077h9eec885f82da900d@mail.gmail.com> <4B5103A2.20809@sun.com> <17c6771e1001151756i2089408cp869bb7218031e89a@mail.gmail.com> <17c6771e1001270859g77971a44pcd7d267ebfd17393@mail.gmail.com> <4B61EE84.5030600@sun.com> Message-ID: <17c6771e1001281540p61237b29x4535c7286901eb7e@mail.gmail.com> On 28 January 2010 20:07, Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> >> 2010/1/16 Andrew John Hughes : >> >>> >>> 2010/1/16 Joseph D. Darcy : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> 2010/1/15 Ken Cavanaugh : >>>>> >>>>> >>>>>> >>>>>> The fixes look good to me. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ken. >>>>>> >>>>>> On Jan 15, 2010, at 1:59 PM, Joseph D. Darcy wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> When building documentation, both OpenJDK6 and OpenJDK7 spit out a >>>>>>>> number of warnings when building documentation: >>>>>>>> >>>>>>>> /mnt/builder/jdk6/impsrc/javax/rmi/PortableRemoteObject.java:171: >>>>>>>> warning - Tag @link: reference not found: Stub#connect >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/SetOverrideType.java:50: >>>>>>>> warning - Tag @link: reference not found: omg.org.CORBA.Object._se\ >>>>>>>> t_policy_override >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/TCKind.java:552: warning - >>>>>>>> Tag >>>>>>>> @return cannot be used in constructor documentation. ?It can\ >>>>>>>> only be used in the following types of documentation: method. >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/UnknownUserException.java:62: >>>>>>>> warning - @ is an unknown tag. >>>>>>>> >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CORBA/portable/ServantObject.java:48: >>>>>>>> warning - Tag @return cannot be used in field documentation\ >>>>>>>> . ?It can only be used in the following types of documentation: >>>>>>>> method. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextExtStub.java:301: >>>>>>>> warning - @parm is an unknown tag. >>>>>>>> >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/_NamingContextStub.java:146: >>>>>>>> warning - @parm is an unknown tag. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/CosNaming/NamingContextOperations.java:89: >>>>>>>> warning - @parm is an unknown tag. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:54: >>>>>>>> warning - @param argument "a_component" is not a p\ >>>>>>>> arameter name. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /mnt/builder/jdk6/impsrc/org/omg/PortableInterceptor/IORInfoOperations.java:72: >>>>>>>> warning - @param argument "a_component" is not a p\ >>>>>>>> arameter name. >>>>>>>> >>>>>>>> This patch against OpenJDK7: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/build/webrev.04/corba.patch >>>>>>>> >>>>>>>> fixes the warnings. >>>>>>>> >>>>>>>> Is this ok to push? ?If so, can I have a bug ID for it? >>>>>>>> >>>>>>>> Joe, would this also be ok for 6? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> cc'ing Ken Cavanaugh for corba matters. >>>>>>> >>>>>>> If this fix is approved for JDK 7, I approve it to also go back into >>>>>>> OpenJDK 6. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> Thanks Ken. ?I don't see you on http://db.openjdk.java.net/people so >>>>> not sure what I should use for the Reviewed-by field. >>>>> >>>>> Joe, can you allocate this a bug ID? >>>>> >>>>> >>>> >>>> 6917485 Corba doc warnings >>>> >>>> You can use me as a reviewer for jcheck purposes. >>>> >>>> Have a good weekend, >>>> >>>> -Joe >>>> >>>> PS Monday is a holiday for Sun in the US. >>>> >>>> >>>> >>> >>> Done: >>> >>> http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/05436b84e93a >>> http://hg.openjdk.java.net/jdk7/build/corba/rev/d4c077d44a64 >>> >>> With this fix as well: >>> >>> http://cr.openjdk.java.net/~andrew/build/webrev.05/ >>> >>> the main javadoc build passes with no warnings. ?There are two >>> remaining warnings from doclets: >>> >>> /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - >>> Tag @link: reference not found: >>> com.sun.tools.doclets.internal.toolkit.util >>> /mnt/builder/jdk6/impsrc/com/sun/tools/doclets/package.html: warning - >>> Tag @link: reference not found: >>> com.sun.tools.doclets.internal.toolkit.util >>> 2 warnings >>> >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> >> >> Does http://cr.openjdk.java.net/~andrew/build/webrev.05/ look ok? >> >> If so, can I have a bug ID to push to 6 and 7? >> >> Thanks, >> > > Ah yes, the specdefault tag. ?I forget offhand where these occur in the JDK > sources, but they have been there for many years and not caused any harm so > I'm willing having to have specdefault listed in the set of known tags to > silence some spurious errors. > It's from jaxws. That's why I didn't even bother to look at the code as it's no longer part of the OpenJDK tree. /mnt/builder/tl/impsrc/javax/jws/WebMethod.java:54: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebParam.java:70: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebParam.java:82: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebParam.java:95: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebParam.java:107: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebResult.java:59: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebResult.java:71: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebResult.java:84: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebService.java:52: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebService.java:68: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebService.java:79: warning - @specdefault is an unknown tag. /mnt/builder/tl/impsrc/javax/jws/WebService.java:92: warning - @specdefault is an unknown tag. > You can use > > 6921068 Remove javadoc builds warnings from specdefault tag > > for this issue. > > I approve this going into OpenJDK 6 and JDK 7. > Done: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ffceebe8e01f http://hg.openjdk.java.net/jdk7/build/jdk/rev/b250e6c5a9e5 > Thanks, > > -Joe > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From kelly.ohair at sun.com Thu Jan 28 17:10:55 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 29 Jan 2010 01:10:55 +0000 Subject: hg: jdk6/jdk6/jaxp: 2 new changesets Message-ID: <20100129011055.E996241FDA@hg.openjdk.java.net> Changeset: f23bb60a908d Author: ohair Date: 2010-01-28 17:08 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/f23bb60a908d 6894833: Upgrade jaxp drop source bundle Reviewed-by: darcy ! jaxp.properties Changeset: 5df1daaa67c8 Author: ohair Date: 2010-01-28 17:10 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/5df1daaa67c8 Merge From xerxes at zafena.se Fri Jan 29 07:45:55 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Fri, 29 Jan 2010 16:45:55 +0100 Subject: hg: jdk6/jdk6/jaxp: 2 new changesets In-Reply-To: <20100129011055.E996241FDA@hg.openjdk.java.net> References: <20100129011055.E996241FDA@hg.openjdk.java.net> Message-ID: <4B6302B3.9000701@zafena.se> kelly.ohair at sun.com wrote: > Changeset: f23bb60a908d > Author: ohair > Date: 2010-01-28 17:08 -0800 > URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/f23bb60a908d > > 6894833: Upgrade jaxp drop source bundle > Reviewed-by: darcy > > ! jaxp.properties > > Changeset: 5df1daaa67c8 > Author: ohair > Date: 2010-01-28 17:10 -0800 > URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/5df1daaa67c8 > > Merge > > > the changeset looks odd http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/f23bb60a908d -jaxp_src.bundle.name=jdk6-jaxp-2009_10_27.zip -jaxp_src.bundle.md5.checksum=0bb03bbd7b1b6d87cc65772c6adb2d6a +jaxp_src.bundle.name=jdk6-jaxp-2009_10_13.zip +jaxp_src.bundle.md5.checksum=a2f7b972124cd776ff71e7754eb9a429 Why did we "upgrade" to a older version of jaxp after the move? I assume jdk6-jaxp-2009_10_13.zip contain older stuff than jdk6-jaxp-2009_10_27.zip. Cheers and have a great day! Xerxes From ahughes at redhat.com Fri Jan 29 07:50:19 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 29 Jan 2010 15:50:19 +0000 Subject: [joe.wang@sun.com: Re: [Bug 100017] XML encoder can cause a StackOverflowError] Message-ID: <20100129155019.GO3214@rivendell.middle-earth.co.uk> The discussion seems to have verged off-list for no reason: ----- Forwarded message from Joe Wang ----- Date: Thu, 28 Jan 2010 14:54:11 -0800 From: Joe Wang To: Kelly O'Hair Subject: Re: [Bug 100017] XML encoder can cause a StackOverflowError User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Kelly O'Hair wrote: > > So this is the diff of the necessary changes to jdk6/jaxp/jaxp.properties: > > --- > dhcp-usca22-160-209.SFBay.Sun.COM<34> hg diff > diff --git a/jaxp.properties b/jaxp.properties > --- a/jaxp.properties > +++ b/jaxp.properties > @@ -24,10 +24,10 @@ > # > > drops.master.copy.base=${drops.dir} > -drops.master.url.base=http://kenai.com/projects/jdk6-drops/downloads/download > +drops.master.url.base=https://jaxp.dev.java.net/files/documents/913/147329 > > -jaxp_src.bundle.name=jdk6-jaxp-2009_10_27.zip > -jaxp_src.bundle.md5.checksum=0bb03bbd7b1b6d87cc65772c6adb2d6a > +jaxp_src.bundle.name=jdk6-jaxp-2009_10_13.zip > +jaxp_src.bundle.md5.checksum=a2f7b972124cd776ff71e7754eb9a429 > jaxp_src.master.bundle.dir=${drops.master.copy.base} > jaxp_src.master.bundle.url.base=${drops.master.url.base} > > --- > Plus I need to copy this file internally to our shared: > /java/devtools/share/jdk6-drops/ > area, once you think this is a final bundle. Is it final? > > It seems a little confusing for this name to go from 10_27 to 10_13, > but as long as you jaxp expert know what is in it. ;^) Yeh, a little backwards :) But I can assure that this is the same bundle as that for JDK7 M5. Meanwhile, We've just released JAXP 1.4.3 (https://jaxp.dev.java.net/). I'm working on another bundle for JDK7 M6 and OpenJDK6 that will include changes since 10/13/09. --Joe > > --- > Joe Darcy, > > Do you want this change pushed into openjdk6? > > -kto > > > On 1/28/10 2:30 PM, Joe Wang wrote: >> Kelly, >> >> My bad. You're right. I've just re-uploaded the file without "jaxp" >> folder. Here's the new link: >> https://jaxp.dev.java.net/files/documents/913/147329/jdk6-jaxp-2009_10_13.zip >> >> >> --Joe >> >> >> Kelly O'Hair wrote: >>> >>> >>> On 1/28/10 1:33 PM, Joe Wang wrote: >>>> Thanks Joe and Kelly. >>>> >>>> Kelly, >>>> >>>> I've uploaded a tarball to the jaxp download area. Here's the url to >>>> the >>>> file: >>>> https://jaxp.dev.java.net/files/documents/913/147327/jdk6-jaxp-2009_10_13.zip >>>> >>>> >>> >>> Looks wrong to me. There should be no jaxp root directory. >>> I should see src at the top, e.g. >>> mkdir temp >>> cd temp >>> unzip jdk6-jaxp-2009_10_13.zip >>> ls src >>> >>>> >>>> Since there is no fixed OpenJDK 6 schedule, I've named it after the >>>> cut-off date for the update. >>> >>> That's fine. You can pick the name. ;^) >>> >>>> >>>> By the way, I noticed that the file (jdk6-jaxp-2009_10_27) on kenai has >>>> a slightly different file structure from the one for jdk7 which had a >>>> root "jaxp". If the build process is the same as that for JDK7 which >>>> copies the source from under the jaxp folder, it probably won't get >>>> updated properly. >>> >>> Yipes... Which jdk7 one has a root of jaxp? >>> >>> I just did an unzip jdk7-jaxp-m5.zip and all I see is: >>> >>> ASSEMBLY_EXCEPTION THIRD_PARTY_README src/ >>> LICENSE TRADEMARK >>> >>> There should be no root dir "jaxp". >>> >>> I don't think the build process will work if the zip file has >>> a root directory name. >>> >>> -kto >>> >>>> >>>> Thanks, >>>> Joe >>>> >>>> Joe Darcy wrote: >>>>> On 01/27/10 09:35 AM, Kelly O'Hair wrote: >>>>>> >>>>>> >>>>>> On 1/27/10 8:55 AM, Joe Wang wrote: >>>>>>> Andrew John Hughes wrote: >>>>>>>> On 20:16 Tue 26 Jan , Kelly O'Hair wrote: >>>>>>>> >>>>>>>>> On 1/25/10 8:09 PM, Joe Wang wrote: >>>>>>>>> >>>>>>>>>> Kelly, >>>>>>>>>> >>>>>>>>>> I agree with the idea of creating a separate download for >>>>>>>>>> OpenJDK6. I >>>>>>>>>> will create a folder "OpenJDK6" parallel to that for jdk7 and to >>>>>>>>>> differentiate it from the JDK6. >>>>>>>>>> >>>>>>>>>> So if I understand correctly, b19 was using the same bundle as >>>>>>>>>> JDK7 M5. >>>>>>>>>> >>>>>>>>> b19? what is b19? >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Wondering the same; OpenJDK6 is not even yet at b18. >>>>>>>> >>>>>>> I picked that up from Kelly's original mail when you mentioned >>>>>>> "jdk6-jaxp-b19.zip", I thought you meant that OpenJDK6 is at b19. >>>>>>> And >>>>>>> it's the question I was asking: where to find the schedule? >>>>>> >>>>>> Oh, sorry, that was just a suggested name. >>>>>> >>>>>> I'm not sure what the OpenJDK6 schedule is, or if there is one. >>>>>> Joe Darcy would need to comment on that. >>>>>> >>>>> >>>>> There is no fixed OpenJDK 6 schedule; the builds occur as needed. >>>>> Generally a build should be needed when a new batch of security fixes >>>>> is available, but recently we've been holding the build for some other >>>>> outstanding work to go back. >>>>> >>>>> -Joe >>>> >> ----- End forwarded message ----- -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Fri Jan 29 09:13:35 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 29 Jan 2010 09:13:35 -0800 Subject: hg: jdk6/jdk6/jaxp: 2 new changesets In-Reply-To: <4B6302B3.9000701@zafena.se> References: <20100129011055.E996241FDA@hg.openjdk.java.net> <4B6302B3.9000701@zafena.se> Message-ID: <4B63173F.6090107@sun.com> Sorry, should have assed a Summary: line to the changeset to clarify this. Ignore the dates in the filenames. The 10_13 bundles are the correct ones, and represent newer sources than the ones in 10_27. The date now reflects the JAXP team's dates. The jdk6 10_13 file should match the jdk7 M5 version. -kto On 1/29/10 7:45 AM, Xerxes R?nby wrote: > kelly.ohair at sun.com wrote: >> Changeset: f23bb60a908d >> Author: ohair >> Date: 2010-01-28 17:08 -0800 >> URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/f23bb60a908d >> >> 6894833: Upgrade jaxp drop source bundle >> Reviewed-by: darcy >> >> ! jaxp.properties >> >> Changeset: 5df1daaa67c8 >> Author: ohair >> Date: 2010-01-28 17:10 -0800 >> URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/5df1daaa67c8 >> >> Merge >> >> >> > > the changeset looks odd > > http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/f23bb60a908d > > -jaxp_src.bundle.name=jdk6-jaxp-2009_10_27.zip > -jaxp_src.bundle.md5.checksum=0bb03bbd7b1b6d87cc65772c6adb2d6a > +jaxp_src.bundle.name=jdk6-jaxp-2009_10_13.zip > +jaxp_src.bundle.md5.checksum=a2f7b972124cd776ff71e7754eb9a429 Why did > we "upgrade" to a older version of jaxp after the move? I assume > jdk6-jaxp-2009_10_13.zip contain older stuff than > jdk6-jaxp-2009_10_27.zip. Cheers and have a great day! Xerxes > From Kelly.Ohair at Sun.COM Fri Jan 29 09:20:15 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 29 Jan 2010 09:20:15 -0800 Subject: hg: jdk6/jdk6/jaxp: 2 new changesets In-Reply-To: <4B63173F.6090107@sun.com> References: <20100129011055.E996241FDA@hg.openjdk.java.net> <4B6302B3.9000701@zafena.se> <4B63173F.6090107@sun.com> Message-ID: <4B6318CF.2030505@sun.com> On 1/29/10 9:13 AM, Kelly O'Hair wrote: > Sorry, should have assed a Summary: line to the changeset to added ;^) -kto > clarify this. > > Ignore the dates in the filenames. > The 10_13 bundles are the correct ones, and represent newer sources > than the ones in 10_27. The date now reflects the JAXP team's dates. > > The jdk6 10_13 file should match the jdk7 M5 version. > > -kto > > > On 1/29/10 7:45 AM, Xerxes R?nby wrote: >> kelly.ohair at sun.com wrote: >>> Changeset: f23bb60a908d >>> Author: ohair >>> Date: 2010-01-28 17:08 -0800 >>> URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/f23bb60a908d >>> >>> 6894833: Upgrade jaxp drop source bundle >>> Reviewed-by: darcy >>> >>> ! jaxp.properties >>> >>> Changeset: 5df1daaa67c8 >>> Author: ohair >>> Date: 2010-01-28 17:10 -0800 >>> URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/5df1daaa67c8 >>> >>> Merge >>> >>> >>> >> >> the changeset looks odd >> >> http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/f23bb60a908d >> >> -jaxp_src.bundle.name=jdk6-jaxp-2009_10_27.zip >> -jaxp_src.bundle.md5.checksum=0bb03bbd7b1b6d87cc65772c6adb2d6a >> +jaxp_src.bundle.name=jdk6-jaxp-2009_10_13.zip >> +jaxp_src.bundle.md5.checksum=a2f7b972124cd776ff71e7754eb9a429 Why did >> we "upgrade" to a older version of jaxp after the move? I assume >> jdk6-jaxp-2009_10_13.zip contain older stuff than >> jdk6-jaxp-2009_10_27.zip. Cheers and have a great day! Xerxes >>