Security fixes are back; other fixes can go in. Time for build 18?

Joseph D. Darcy Joe.Darcy at Sun.COM
Thu Dec 24 07:49:05 PST 2009


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.

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.

-Joe


More information about the jdk6-dev mailing list