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

Andrew John Hughes gnu_andrew at member.fsf.org
Tue Nov 10 02:45:15 PST 2009 

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.
>

I guessed it was something like a [A-Za-z ] check.  Any change of
getting this fixed to accept contributor names correctly (I guess
something like Character.isLetter() rather than an ASCII check)?

> In other news on b18, I've done some building and testing on the current
> repo without the X11 fix above.

Great, I'm going to try and get something similar setup with IcedTea6
today.  The X11 fix shouldn't make any difference at all, it's just a
build fix for newer Xorg versions.

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.
>

Ok, I don't know how these slipped through as they are.  I'll look
into a solution.

> -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

More information about the jdk6-dev mailing list