Security fixes are back; other fixes can go in. Time for build 18?
Andrew John Hughes
gnu_andrew at member.fsf.org
Thu Dec 24 08:43:42 PST 2009
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.
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. 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?
> 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.
http://cr.openjdk.java.net/~andrew/nimbus/webrev.04/jdk.patch makes
both tests pass. Can I have a bug ID to push this?
> -Joe
>
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
More information about the jdk6-dev
mailing list