Zulu Community

Discussion on Zulu 9 Pre-release 3

Updated on December 19, 2017 in Zulu Releases
21 on February 24, 2016

Azul is happy to announce the availability of the February snapshot of OpenJDK 9 today.

These binaries represent a source snapshot around OpenJDK build 105, reflecting a source fetch circa February 15. As covered in our December pre-release thread, this build should have all of Marlin graphics renderer code changes for JEP 265 in place.

To clarify for all interested, these Zulu builds are coming off the main OpenJDK 9 dev branch. That means only part of the Jigsaw work is in this release and the two prior Zulu 9 pre-release builds. Many of us are eagerly watching the JDK 9 mailing list (archives are here: http://mail.openjdk.java.net/pipermail/jdk9-dev/) in anticipation for signals that the main sync commit of Jigsaw gets merged into dev.

Please provide any feedback about this snapshot, posted http://zulu.org/zulu-9-pre-release-downloads/

Matt

  • Liked by
Reply
1 on March 1, 2016

I confirm the Marlin renderer is enabled and working well in the release zulu9.0.0.3-ea !

I ran benchmarks comparing openjdk9 vs zulu9 and there are very small differences: almost on par ! What is the version of GCC you are using to make the build ?

Laurent

  • Liked by
Reply
Cancel
1 on March 1, 2016

Hello Laurent, thanks for the confirmation. That is great news to hear that the benchmarks are very close. 

As for which GCC, I found this line in the Jenkins log for Zulu Linux:

  Using gcc C compiler version 4.4.7 [gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)]

This looks like the standard compiler version on our RHEL6 host build server. Do you get better behavior using a newer GCC version, like say 4.7.2 from the Red Hat Developer toolset? If so, I’d be curious what level of improvement you see, if any.

Thanks again for the great feedback. I am glad to see proof of Marlin working under the hood in Zulu 9.

Matt

on March 1, 2016

Hi Matt !

Thanks for the build information.
I use GCC 4.8.4 on my laptop (ubuntu 14.4 LTS) to build my own OpenJDK9 build. However I think the official GCC release for OpenJDK 9 is 4.9.x (to be checked).

I only observed very minor difference ~ 1-2 % except on large ellipse fills ~ 10% in favor of zulu (ie gcc 4.4 is better than 4.8). FYI alpha mask fills are performed in native software loops (c macros) so it is subject to both gcc release and its optimization settings.

Here are my raw results (MapBench runs):
See my FOSDEM 2015 slides to have some details on Marlin / MapBench:
https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf

Times are measured in milliseconds (lower is better) and I always look at 95th percentile:

OpenJDK9:
Test                                             Threads    Ops    Med    Pct95    Avg    StdDev    Min    Max    FPS(med)    TotalOps    [ms/op]
EllipseTests-fill-true.ser                       1    25    438.521    438.780    438.511    0.136    438.278    438.922    2.280    25

Scores:
Tests    36    12    12    12    
Threads    4    1    2    4    
Pct95    163.535    160.539    162.897    167.169    
FPS    43.079    43.433    42.973    42.832   

Zulu9:
Test                                             Threads    Ops    Med    Pct95    Avg    StdDev    Min    Max    FPS(med)    TotalOps    [ms/op]
EllipseTests-fill-true.ser                       1    26    398.316    398.618    398.344    0.310    398.015    399.527    2.511    26

Scores:
Tests    36    12    12    12    
Threads    4    1    2    4    
Med    161.754    159.057    161.237    164.968    
Pct95    162.684    159.429    161.753    166.871    
FPS    43.294    43.437    43.277    43.169    

In summary: Zulu 9 EA is providing very good rendering performance.

Show more replies
  • Liked by
Reply
Cancel
1 on March 3, 2016
on March 23, 2016

test

Show more replies
  • Liked by
Reply
Cancel
1 on March 3, 2016

Hi,

thanks for the dedicated work in getting release 3 up. I just wanted to mention that 9.0.0.2 instead of 9.0.0.3 is linked for Windows on your download page. For all other OS´s it´s the right version.

However, I simply changed the name of the ZIP file in the download link to zulu9.0.0.3-ea-jdk9.0.0-win_x64.zip and go the download, so it´s just a error in the link it seems.

Thank you very much,

Geeky

on March 3, 2016

Geeky, thanks for pointing out the Windows link issue. The target URL is now corrected. I appreciate the eagle eyes! –Matt

Show more replies
  • Liked by
Reply
Cancel
0 on March 3, 2016

Maybe someone can give a hint with this please: after updating to “release 3” (build 105) my 3rd party java application is not starting anymore but is giving the following error:

Exception in thread “AWT-EventQueue-0” java.lang.NoClassDefFoundError: sun/swing
/plaf/synth/SynthIcon
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:761)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:152)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:471)
at java.net.URLClassLoader.access$100(URLClassLoader.java:77)
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:365)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:761)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:152)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:471)
at java.net.URLClassLoader.access$100(URLClassLoader.java:77)
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:365)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:372)
at com.sun.beans.finder.ClassFinder.findClass(ClassFinder.java:103)
at com.sun.beans.finder.ClassFinder.resolveClass(ClassFinder.java:171)
at com.sun.beans.decoder.DocumentHandler.findClass(DocumentHandler.java:404)
at com.sun.beans.decoder.NewElementHandler.addAttribute(NewElementHandler.java:80)
at com.sun.beans.decoder.ObjectElementHandler.addAttribute(ObjectElementHandler.java:102)
at com.sun.beans.decoder.DocumentHandler.startElement(DocumentHandler.java:294)
at javax.swing.plaf.synth.SynthParser.startElement(SynthParser.java:1227)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:508)
at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1345)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2794)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:876)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:805)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:140)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1212)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:639)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:323)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
at javax.swing.plaf.synth.SynthParser.parse(SynthParser.java:242)
at javax.swing.plaf.synth.SynthLookAndFeel.load(SynthLookAndFeel.java:579)
at de.javasoft.plaf.synthetica.SyntheticaLookAndFeel.loadXMLConfig(SyntheticaLookAndFeel.java:428)
at de.javasoft.plaf.synthetica.SyntheticaLookAndFeel.<init>(SyntheticaLookAndFeel.java:358)
at de.javasoft.plaf.synthetica.SyntheticaAluOxideLookAndFeel.<init>(SyntheticaAluOxideLookAndFeel.java:31)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:426)
at java.lang.Class.newInstance(Class.java:466)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:585)
at com.sonarbytes.gn.windows.MainWindow$1.run(MainWindow.java:149)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:759)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:712)
at java.awt.EventQueue$3.run(EventQueue.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:77)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:729)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:192)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:117)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:106)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:102)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:94)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:83) Caused by: java.lang.ClassNotFoundException: sun.swing.plaf.synth.SynthIcon
at java.net.URLClassLoader.findClass(URLClassLoader.java:385)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
… 70 more

So the problem seems to be caused by “sun.swing.plaf.synth.SynthIcon”. The same behavior occurs with the “official” Orcale Java 9 build 107. However, with your “release 2” (build 95), the program just launches fine. So it seems to me that they have removed something in terms of internal APIs somewhere between build 95 and 105? Looking through the changelogs between 95 and 105, I can´t find anything in relation to swing, plaf or synthicon though. Any hint would be appreciated, also because I´d like to mail the developer of the java application about this so that he can change his code.

Thank you so much!

  • Liked by
Reply
Cancel
0 on March 3, 2016

Geeky, one of the Azul architects recognized your issue. This particular case is a consequence of bug 

https://bugs.openjdk.java.net/browse/JDK-8081411

that was fixed in November – so right between our two Zulu 9 releases.

Addressing this failure is easy – 

-import sun.swing.plaf.synth.SynthIcon;
+import javax.swing.plaf.synth.SynthIcon;

Please give that a shot and let us know if using the newer package name works.

Matt

  • Liked by
Reply
Cancel
1 on March 3, 2016

Hi Matt,

thanks for that! But if the bug was fixed in November, why is it still there in your build 105 and Oracles build 107 too? Or is it absolutely needed to refer to javax.swing… instead of sun.swing now?

Cheers,

Lorenz

on March 3, 2016

Hi,

You should check your dependency on jdk internal APIs by using either jdeps or maven plugin:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

Laurent

Show more replies
  • Liked by
Reply
Cancel
0 on March 3, 2016

It´s not really my application, I am just using it, but I am not the coder nor do I have access to the code. I just notice that with j9 build 95 everything is fine and with 105 it´s now broken. But if this is related to a bug that was fixed in November and build 105 is a snapshot from February, why would this problem still occur? That´s what I don´t get right now.

  • Liked by
Reply
Cancel
0 on March 10, 2016

Lorenz, my post is a rough paraphrase from the Azul architect. He provided me an off-the-cuff response based only on your stacktrace, but I know he won’t seriously dig into OpenJDK 9 source with gusto until his next project, when he would be able to provide me a better hint. I hope I just got my paraphrase wrong, and rather than the case being fixed in November, instead the issue was introduced in between the two Zulu builds, and fixed after our second snapshot.

So you are aware, we are doing a March build of Zulu 9 next week, so hopefully that build corrects your reported problem. If it doesn’t fix it, I can then get someone involved to repro your issue and identify a workaround that doesn’t require a source change. Unfortunately, the Zulu 9 pre-release builds are not yet in a state to provide active support. Once the Jigsaw and Dev branches of OpenJDK 9 source trees merge and any sync issues get ferreted out, we should be in a better place to get developer time to squash reported issues. That’s the risk inherent in using pre-release builds.

–Matt

  • Liked by
Reply
Cancel
0 on March 17, 2016

The Windows version does not contain the jigsaw? For I make an example of test as the site http://openjdk.java.net/projects/jigsaw/quick-start

and in the windows console displays the following message:

C: \ Users \ Daniel Dias \ Desktop> javac -d mods / com.greetings src / com.greetings / module-info.java src / com.greetings / com / greetings / Main.java

src \ com.greetings \ module-info.java: 1: error: class, interface, or enum expected
{} module com.greetings
^
1 error

Thank you.

  • Liked by
Reply
Cancel