Security fixes are back; other fixes can go in. Time for build 18?
Andrew John Hughes
gnu_andrew at member.fsf.org
Mon Jan 4 07:26:59 PST 2010
2009/12/25 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 2009/12/24 Joseph D. Darcy <Joe.Darcy at sun.com>:
>> Andrew John Hughes wrote:
>>>
>>> 2009/12/24 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>
>>>>
>>>> Andrew John Hughes wrote:
>>>>
>>>>>
>>>>> 2009/11/10 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>>
>>>>>
>>>>>>
>>>>>> Andrew John Hughes wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2009/11/7 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Jonathan Gibbons wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/11/7 Joseph D. Darcy <Joe.Darcy at sun.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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ò <flameeyes at gmail.com>
>>>>>>> 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
More information about the jdk6-dev
mailing list