For users of --with-openjdk

Dr Andrew John Hughes ahughes at redhat.com
Wed Aug 25 08:34:29 PDT 2010 

On 13:08 Sat 14 Aug     , DJ Lucas wrote:
> On 08/13/2010 02:57 PM, Dr Andrew John Hughes wrote:
> > On 20:34 Thu 12 Aug     , DJ Lucas wrote:
> >> On 08/12/2010 07:41 PM, Dr Andrew John Hughes wrote:
> >>> On 18:33 Thu 12 Aug     , DJ Lucas wrote:
> >>>> On 08/11/2010 07:08 PM, DJ Lucas wrote:
> >>>>
> >>>>>
> >>>
> >>> With regard to your previous e-mail, I think you're right that the sun.awt.Toolkit
> >>> fix is insufficent.  It was the result of only considering the two existing configurations;
> >>> gcj+bootstrap, icedtea+no-bootstrap, with the intent of speeding up the no-bootstrap
> >>> case.  In the no-bootstrap case, the built rt files aren't used so it was a waste of
> >>> time building them.  So instead of removing the conditional altogether, I'd go for
> >>> changing it to a BOOTSTRAPPING conditional.
> >>>
> >>
> >> OK, will do.
> >>
> > 
> > I've pushed this.
> 
> Got it locally now.  Thanks.
> 
> >>>>
> >>>> The correct fix is to include $(SHARE)/javax/swing/plaf in
> >>>> ICEDTEA_BOOTSTRAP_DIRS (as I am still using the 1.8.1 nimbus classes in
> >>>> this particular case).  Again, given the larger target of possible
> >>>> system JDKs, I wonder if it would be best to build rt.jar from scratch
> >>>> rather than copying from the system version and updating selectively
> >>>> (for similar reason to rebuilding tools.jar unconditionally as mentioned
> >>>> earlier in this thread).  
> >>>
> >>> I've been thinking about this a bit.  It's quite a weird one.  The failure
> >>> is due to a hack needed for backporting Nimbus to JDK6.  The SynthLookAndFeel
> >>> class has to know about a possible subclass, NimbusLookAndFeel, because we can't
> >>> add the needed method to the appropriate interface/superclass, as was done in
> >>> 7.  So the synth look and feel now depends on the nimbus one being built before.
> >>>
> >>> In 1.8.1, you have an older version of NimbusLookAndFeel which is what causes the
> >>> complaint.  In icedtea-no-bootstrap mode (and straight OpenJDK builds), we fixed
> >>> this by building Nimbus first.  However, gcj can't generate Nimbus; so in bootstrap
> >>> mode, you'll see that we pass DISABLE_NIMBUS=true in the Makefile and the files
> >>> are instead compiled from pre-generated versions in the rt.stamp stage.
> >>>
> >>> I'm guessing this doesn't work for the icedtea-bootstrap mode because it doesn't
> >>> pull in as many classes to rebuild as gcj does (presumably because Sun classes which
> >>> are built when using gcj are found in rt.jar when using IcedTea).  Your fix seems
> >>> correct, though for IcedTea, removing the DISABLE_NIMBUS line would also work.
> >>
> >> No, my proposed fix is not correct.  Disabling Nimbus in the stage1
> >> build is the only working fix for both targets.  Will do locally.
> > 
> > I don't understand.  It already is disabled and bootstrapping with gcj works fine.
> 
> No, it was me who did not understand.  I misread your previous comments.
>  Sorry for the confusion.  I was referring to including
> $(SHARE)/javax/swing/plaf/synth in ICETEA_BOOTSTRAP_DIRS on a gcj build.
>  IIUC, this will not work with a gcj bootstrap (though I haven't tried
> it yet).  If that is true, then it has to be conditional.  Also, I did
> not remove DISABLE_NIMBUS="true", but rather changed it to false
> conditionally, and that resulted in the same error, so I went back to
> the extra classes refresh in rt.jar.  Attached patch works for me, but
> there is probably already a way to determine what the host JDK is, but
> it escapes me at the moment if it is there already.  As of now, I am
> basically working from tip with the exception of OpenType font support,
> but I'll go back and build tip with the result of tonight's build to
> verify anyway.
> 

I think I found a simpler fix for this.  At least, it works when bootstrapping
with both IcedTea6 1.8 and gcj 4.5.1.  Basically, instead of trying to build
the whole of javax.swing.plaf.synth, we just build NimbusLookAndFeel which is
the class this is outdated in 1.8:

http://icedtea.classpath.org/hg/icedtea6/rev/6f017e9047ab

Let me know if this works for you as well.

> <Snip>
> 
> > 
> > If someone wants to test a JDK as a bootstrap JDK, and they find
> > issues, we'll try to fix them where appropriate.  There aren't really
> > any specific versions, it's more a case of what people are willing to
> > actively maintain.  If someone is willing to step up and keep doing
> > regular builds with a certain system JDK, it'll be supported.
> 
> I'll be happy to continue down my current path whenever I am able to.
> I'm always going to want to keep up with the current closed JDK.
> 

Great!

> <Snip>
> 
> >> BTW, 1.8 worked well enough with the -2 patch I posted a link to earlier
> >> for my target (1.8.1->1.8.1)
> > 
> > Yeah I guessed it would without the OpenGL change.  It's probably worth
> > fixing that on the 1.9 branch too so we don't regress from 1.8.
> 
> Attached patch will have to be moved appropriately for 1.9 branch (if
> accepted) and could be done in the same location for 1.10 in FIND_JAVAC.
> 

These changes will just be in 1.10.  I want them to have plenty of soak
time before being used generally.

> > 
> > With regard to your patch for that, I don't think testing the VM is
> > correct; it may get fixed in later versions of gcj and other VMs than
> > gcj use that javah. I think (part of) the issue is
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40188 again, which there
> > is already a configure test for in IcedTea7.  So I'll backport that.
> > The other part of the issue is that gjavah doesn't seem to handle
> > inner classes implicitly.
> 
> Excellent! That's one more done.  Applied locally.  So now, I have
> nothing in my 1.9 that is not in 1.10 except the attached patch which
> gets me a 1.9 build to completion (ignore the 1.9 in the name, is for
> 1.10).  I will try tip in a few moments, but don't expect a confirmation
> until tomorrow.  BTW, for reference, machine is x86_64 with only 32bit
> toolchain.  Not so sure I like the unattended testsuite results, so I
> reran them without the screen saver active, and the results still are
> not looking so good to me.  Are there some test suite changes that need
> to come back with the Xrender changes?
> 

Pavel has been looking into the Xrender test breakages which also affect
OpenJDK7:

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-August/009988.html

So it looks like Oracle made changes without fixing the tests.  Pavel now has
a fix which should be committed shortly.

On JDK, I don't think there's ever been a 100% pass, and some aren't even
stable tests.  So you're looking more for regressions between builds.

To my knowledge, the HotSpot and langtools suites should all pass (and
take a considerably shorter time to run).

> --------------- jtreg console summary for hotspot ---------------
> Test results: passed: 86
> --------------- jtreg console summary for langtools ---------------
> Error:  tools/javac/processing/6499119/ClassProcessor.java
> FAILED: tools/javac/InterfaceAssert.java
> Test results: passed: 1,377; failed: 1; error: 1
> --------------- jtreg console summary for jdk ---------------
> FAILED: com/sun/net/httpserver/bugs/B6361557.java
> FAILED:
> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
> FAILED: java/awt/Focus/TranserFocusToWindow/TranserFocusToWindow.java
> FAILED: java/awt/font/TextLayout/TextLayoutBounds.java
> FAILED: java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
> FAILED:
> java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java
> FAILED:
> java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java
> FAILED: java/awt/Graphics2D/DrawString/RotTransText.java
> FAILED: java/awt/GraphicsDevice/CloneConfigsTest.java
> FAILED: java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html
> FAILED: java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html
> FAILED: java/awt/print/PrinterJob/ExceptionTest.java
> FAILED: java/awt/xembed/server/RunTestXEmbed.java
> FAILED: java/beans/XMLEncoder/javax_swing_tree_TreePath.java
> FAILED: java/net/MulticastSocket/NoLoopbackPackets.java
> FAILED: java/net/URL/TestHttps.java
> FAILED: java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
> FAILED: java/rmi/transport/pinLastArguments/PinLastArguments.java
> MyDeflater had end() called
> MyInflater had end() called
> FAILED: javax/swing/plaf/synth/Test6933784.java
> FAILED: sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java
> FAILED: sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java
> FAILED: sun/java2d/cmm/ColorConvertOp/MTColConvTest.java
> FAILED: sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java
> FAILED: sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java
> FAILED:
> sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
> FAILED: sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java
> FAILED:
> sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java
> FAILED: sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java
> FAILED: sun/java2d/OpenGL/DrawBufImgOp.java
> FAILED: sun/java2d/OpenGL/GradientPaints.java
> FAILED: sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java
> FAILED: sun/java2d/pipe/MutableColorTest/MutableColorTest.java
> FAILED: sun/java2d/SunGraphics2D/DrawImageBilinear.java
> FAILED: sun/java2d/SunGraphics2D/PolyVertTest.java
> FAILED: sun/java2d/SunGraphics2D/SimplePrimQuality.java
> FAILED: sun/nio/cs/Test4200310.sh
> FAILED: sun/nio/cs/TestSJIS0213.java
> Test results: passed: 3,287; failed: 37
> : # kill testsuite processes still hanging
> nothing to cleanup
> make[1]: Leaving directory `/home/dj/icedtea6-1-9-7816c6d7a641'
> 
> 
> DirectX?  I'm fairly sure those are expected to fail at least. :-)
> 
> <Snip>
> 
> > 
> > The JCK only applies to binaries.  So it would only allow you to test
> > a binary that you built and provided to users.  Anyone using the
> > script (just like anyone using a Gentoo source ebuild) would have to
> > license the JCK and test it themselves.
> > 
> > If binaries aren't your primary target, I wouldn't put too much weight
> > on it.  The Free JTreg test suite is already integrated with IcedTea
> > (try 'make check') and can be used to check the sanity of your
> > builds. Others
> > (http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html)
> > already run the JCK on binaries built from the same sources.
> 
> Getting OT for this part of the discussion, but I just want it to verify
> that the book instructions work as I expect them to.  As far as
> providing a 'compatible' binary version, I could probably just piggy
> back off of the RedHat RPM with rpm2tgz or similar.  That is the other
> reason for wanting to use icedtea to bootstrap icedtea--historically,
> building JDK from scratch has always been optional (and was dropped
> shortly after OpenJDK was announced as the JRL source releases were
> lagging behind quite a bit at that time), but there has always been an
> upstream jdk*{arch}*.bin to install from, whereas there currently is not
> (or not that I'm aware of) for IcedTea6.
> 

I don't know anthing about the JRL source code; looking at that would taint
developers of Free Java.

The Fedora RPMs are probably the best choice if you want a binary, as
these have passed the TCK:
http://magazine.redhat.com/2008/07/08/java-in-fedora-first/.  That and
all the distro packages AFAIK are based on IcedTea.  Oracle don't make
OpenJDK builds available and such builds would not include a plugin or
Web Start support, as these are added by IcedTea.

> -- DJ Lucas
> 
> -- 
> This message has been scanned for viruses and
> dangerous content, and is believed to be clean.
> 

> diff -Naur icedtea6-1-9-7816c6d7a641-orig/acinclude.m4 icedtea6-1-9-7816c6d7a641/acinclude.m4
> --- icedtea6-1-9-7816c6d7a641-orig/acinclude.m4	2010-08-14 00:18:37.000000000 -0500
> +++ icedtea6-1-9-7816c6d7a641/acinclude.m4	2010-08-14 01:38:43.000000000 -0500
> @@ -139,6 +139,9 @@
>        AC_MSG_ERROR([cannot find a Java compiler, try --with-javac or --with-ecj])
>    fi
>    AC_SUBST(JAVAC)
> +  dnl If system javac is derived from Oracle, need synth update in rt
> +  javac_link=`basename $(readlink -f ${JAVAC})`
> +  AM_CONDITIONAL([NEED_RT_SYNTH_UPDATE], test x"${javac_link}" = "xjavac")
>  ])
>  
>  AC_DEFUN([IT_FIND_ECJ],
> diff -Naur icedtea6-1-9-7816c6d7a641-orig/Makefile.am icedtea6-1-9-7816c6d7a641/Makefile.am
> --- icedtea6-1-9-7816c6d7a641-orig/Makefile.am	2010-08-14 00:18:37.000000000 -0500
> +++ icedtea6-1-9-7816c6d7a641/Makefile.am	2010-08-14 01:37:53.000000000 -0500
> @@ -74,7 +74,14 @@
>  	$(SHARE)/javax/net/ssl \
>  	$(SHARE)/javax/script \
>  	$(SHARE)/javax/security/auth/kerberos \
> -	$(SHARE)/javax/security/sasl \
> +	$(SHARE)/javax/security/sasl
> +
> +if NEED_RT_SYNTH_UPDATE 
> +ICEDTEA_BOOTSTRAP_DIRS += \
> +	$(SHARE)/javax/swing/plaf/synth
> +endif
> +
> +ICEDTEA_BOOTSTRAP_DIRS += \
>  	$(LANGTOOLS)/com/sun/mirror \
>  	$(LANGTOOLS)/com/sun/tools/apt
>  


-- 
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 distro-pkg-dev mailing list