GNU Classpath

We really need more Free Software for desktop users. Please consider backing the Krita 2016 Fundraiser to make text and vector art awesome!

The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as a PulseAudio sound driver, the ability to build against system libraries and support for alternative ... [More] virtual machines and architectures beyond those supported by OpenJDK. This release updates our OpenJDK 6 support in the 1.13.x series with the April 2016 security fixes. If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place on the distro-pkg-dev OpenJDK mailing list and patches are always welcome. Full details of the release can be found below. What’s New? New in release 1.13.11 (2016-05-04) Security fixes S8129952, CVE-2016-0686: Ensure thread consistency S8132051, CVE-2016-0687: Better byte behavior S8138593, CVE-2016-0695: Make DSA more fair S8139008: Better state table management S8143167, CVE-2016-3425: Better buffering of XML strings S8144430, CVE-2016-3427: Improve JMX connections S8146494: Better ligature substitution S8146498: Better device table adjustments Import of OpenJDK6 b38 S4459600: java -jar fails to run Main-Class if classname followed by whitespace. S6378099: RFE: Use libfontconfig to create/synthesise a fontconfig.properties S6452854: Provide a flag to print the java configuration S6742159: (launcher) improve the java launching mechanism S6752622: java.awt.Font.getPeer throws “java.lang.InternalError: Not implemented” on Linux S6758881: (launcher) needs to throw NoClassDefFoundError instead of JavaRuntimeException S6856415: Enabling java security manager will make program thrown wrong exception ( main method not found ) S6892493: potential memory leaks in 2D font code indentified by parfait. S6925851: Localize JRE into pt_BR (corba) S6968053: (launcher) hide exceptions under certain launcher failures S6977738: Deadlock between java.lang.ClassLoader and java.util.Properties S6981001: (launcher) EnsureJREInstallation is not being called in order S7017734: jdk7 message drop 1 translation integration S7026184: (launcher) Regression: class with unicode name can’t be launched by java. S7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu S7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 S7127906: (launcher) convert the launcher regression tests to java S7141141: Add 3 new test scenarios for testing Main-Class attribute in jar manifest file S7158988: jvm crashes while debugging on x86_32 and x86_64 S7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes S7193318: C2: remove number of inputs requirement from Node’s new operator S8002116: This JdbReadTwiceTest.sh gets an exit 1 S8004007: test/sun/tools/jinfo/Basic.sh fails on when runSA is set to true S8023990: Regression: postscript size increase from 6u18 S8027705: com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. S8028537: PPC64: Updated the JDK regression tests to run on AIX S8036132: Tab characters in test/com/sun/jdi files S8038963: com/sun/jdi tests fail because cygwin’s ps sometimes misses processes S8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root S8059661: Test SoftReference and OOM behavior S8067364: Printing to Postscript doesn’t support dieresis S8072753: Nondeterministic wrong answer on arithmetic S8073735: [TEST_BUG] compiler/loopopts/CountedLoopProblem.java got OOME S8074146: [TEST_BUG] jdb has succeded to read an unreadable file S8075584: test for 8067364 depends on hardwired text advance S8134297: NPE in GSSNameElement nameType check S8134650: Xsl transformation gives different results in 8u66 S8141229: [Parfait] Null pointer dereference in cmsstrcasecmp of cmserr.c S8143002: [Parfait] JNI exception pending in fontpath.c:1300 S8146477: [TEST_BUG] ClientJSSEServerJSSE.java failing again S8146967: [TEST_BUG] javax/security/auth/SubjectDomainCombiner/Optimize.java should use 4-args ProtectionDomain constructor S8147567: InterpreterRuntime::post_field_access not updated for boolean in JDK-8132051 S8148446: (tz) Support tzdata2016a S8148475: Missing SA Bytecode updates. S8149170: Better byte behavior for native arguments S8149367: PolicyQualifierInfo/index_Ctor JCk test fails with IOE: Invalid encoding for PolicyQualifierInfo S8150012: Better byte behavior for reflection S8150790: 8u75 L10n resource file translation update S8154210: Zero: Better byte behaviour S8155261: Zero broken since HS23 update S8155699: Resolve issues created by backports in OpenJDK 6 b39 S8155746: Sync Windows export list in make/java/jli/Makefile with make/java/jli/mapfile-vers Backports S6863746, PR2951: javap should not scan ct.sym by default S8071705, PR2820, RH1182694: Java application menu misbehaves when running multiple screen stacked vertically S8150954, PR2868, RH1176206: AWT Robot not compatible with GNOME Shell Bug fixes PR2887: Location of ‘stap’ executable is hard-coded PR2890: OpenJDK should check for system cacerts database (e.g. /etc/pki/java/cacerts) PR2952: test/tapset/jstaptest.pl requires Perl PR2953: make dist fails after PR2887 made jstaptest.pl auto-generated The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea6-1.13.11.tar.gz http://icedtea.classpath.org/download/source/icedtea6-1.13.11.tar.xz We provide both gzip and xz tarballs, so that those who are able to make use of the smaller tarball produced by xz may do so. The tarballs are accompanied by digital signatures available at: http://icedtea.classpath.org/download/source/icedtea6-1.13.11.tar.gz.sig http://icedtea.classpath.org/download/source/icedtea6-1.13.11.tar.xz.sig PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 GnuPG >= 2.1 is required to be able to handle this key. SHA256 checksums: f69ab75ccf594931ae5bf5ebc16bce233878d9793516b4abc72f08d7188f5861 icedtea6-1.13.11.tar.gz f12d470c3aefc599388e5f897367c6ca0ef0902f95ba187be12b3adc4b689f1f icedtea6-1.13.11.tar.gz.sig 526ecdf6fec35c10160df305e87cb477f5fe1ea32f02f6c9b1c865a2d28833bf icedtea6-1.13.11.tar.xz 1c01648a7139c8c3b7cd4626652a0509664b797469c234a020a864dead51d2e6 icedtea6-1.13.11.tar.xz.sig The checksums can be downloaded from: http://icedtea.classpath.org/download/source/icedtea6-1.13.11.sha256 A 1.13.11 ebuild for Gentoo is available. The following people helped with these releases: Andrew Haley (S8154210) Andrew Hughes (all other backports and bug fixes, release management) Mario Torre (S8150954 & S8071705) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea6-1.13.11.tar.gz or: $ tar x -I xz -f icedtea6-1.13.11.tar.xz then: $ mkdir icedtea-build $ cd icedtea-build $ ../icedtea6-1.13.11/configure $ make Full build requirements and instructions are available in the INSTALL file. Happy hacking! [Less]

Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200), reorganized the source code according to that structure (JEP 201), and ... [More] restructured the JDK and JRE run-time images to support modules (JEP 220). The last major component, the module system itself (JSR 376 and JEP 261), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111. Breaking changes Like the previous major change, the introduction of modular run-time images, the introduction of the module system might impact you even if you don’t make direct use of it. That’s because the module system is now fully operative at both compile time and run time, at least for the modules comprising the JDK itself. Most of the JDK’s internal APIs are, as a consequence, fully encapsulated and hence, by default, inaccessible to code outside of the JDK. An existing application that uses only standard Java SE APIs and runs on JDK 8 should just work, as they say, on JDK 9. If, however, your application uses a JDK-internal API, or uses a library or framework that does so, then it’s likely to fail. In many cases you can work around this via the -XaddExports option of the javac and java commands. If, e.g., your application uses the internal sun.security.x509.X500Name class then you can enable access to it via the option -XaddExports:java.base/sun.security.x509=ALL-UNNAMED This causes all members of the sun.security.x509 package in the java.base module to be exported to the special unnamed module in which classes from the class path are defined. A few broadly-used internal APIs that cannot reasonably be implemented outside of the JDK, such as sun.misc.Unsafe, are still accessible for now. As outlined in JEP 260, however, these will be removed in a future release after suitable standard replacements are available. The encapsulation of JDK-internal APIs is the change you’re most likely to notice when running an existing application. Other relevant but, for the most part, less-noticeable changes are described in the risks-and-assumptions section of JEP 261. If you have trouble running an existing application on JDK 9 build 111 or later, and you think that’s due to the introduction of the module system but not caused by one of the changes listed in JEPs 260 or 261, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com. New features If you’d like to start learning about the module system itself, the video of my Devoxx BE 2015 keynote gives a high-level overview and The State of the Module System summarizes the design of the module system proposed for JSR 376. Further details are available in the six Jigsaw JEPs, listed on the main project page, and in videos of other sessions given at JavaOne 2015 and Devoxx BE 2015. The module-system design will continue to evolve in the JSR for a while yet, based on feedback and experience. The implementation will evolve in parallel in the Project Jigsaw “Jake” forest, and we’ll continue to publish bleeding-edge early-access builds based on that code, separately from the more-stable JDK 9 builds. [Less]

Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200), reorganized the source code according to that structure (JEP 201), and ... [More] restructured the JDK and JRE run-time images to support modules (JEP 220). The last major component, the module system itself (JSR 376 and JEP 261), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111. Breaking changes Like the previous major change, the introduction of modular run-time images, the introduction of the module system might impact you even if you don’t make direct use of it. That’s because the module system is now fully operative at both compile time and run time, at least for the modules comprising the JDK itself. Most of the JDK’s internal APIs are, as a consequence, fully encapsulated and hence, by default, inaccessible to code outside of the JDK. An existing application that uses only standard Java SE APIs and runs on JDK 8 should just work, as they say, on JDK 9. If, however, your application uses a JDK-internal API, or uses a library or framework that does so, then it’s likely to fail. In many cases you can work around this via the -XaddExports option of the javac and java commands. If, e.g., your application uses the internal sun.security.x509.X500Name class then you can enable access to it via the option -XaddExports:java.base/sun.security.x509=ALL-UNNAMED This causes all members of the sun.security.x509 package in the java.base module to be exported to the special unnamed module in which classes from the class path are defined. A few broadly-used internal APIs that cannot reasonably be implemented outside of the JDK, such as sun.misc.Unsafe, are still accessible for now. As outlined in JEP 260, however, these will be removed in a future release after suitable standard replacements are available. The encapsulation of JDK-internal APIs is the change you’re most likely to notice when running an existing application. Other relevant but, for the most part, less-noticeable changes are described in the risks-and-assumptions section of JEP 261. If you have trouble running an existing application on JDK 9 build 111 or later, and you think that’s due to the introduction of the module system but not caused by one of the changes listed in JEPs 260 or 261, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com. New features If you’d like to start learning about the module system itself, the video of my Devoxx BE 2015 keynote gives a high-level overview and The State of the Module System summarizes the design of the module system proposed for JSR 376. Further details are available in the six Jigsaw JEPs, listed on the main project page, and in videos of other sessions given at JavaOne 2015 and Devoxx BE 2015. The module-system design will continue to evolve in the JSR for a while yet, based on feedback and experience. The implementation will evolve in parallel in the Project Jigsaw “Jake” forest, and we’ll continue to publish bleeding-edge early-access builds based on that code, separately from the more-stable JDK 9 builds. [Less]

I finished getting Excorporate and all its dependencies into GNU ELPA. Excorporate lets Emacs retrieve calendar items from an Exchange server. I had to rewrite the default UI to use Org Mode, because Calfw isn’t entirely copyright-assigned to the ... [More] FSF yet. The Calfw UI is still there for reference, but as a text file so that GNU ELPA’s build and publishing steps ignore it. Both UI handlers use the same updated APIs from the main excorporate.el library. I made sure Excorporate and all its dependencies use only features available since GNU Emacs 24.1. This is pretty good coverage; Emacs 24.1 introduced the packaging system, so if an Emacs version supports packages, it supports Excorporate. Other than DNS lookups, Excorporate is completely asynchronous, so it won’t block the Emacs main loop. And it is pure Emacs Lisp so it runs on any operating system that Emacs does. In addition to Org Mode support, release 0.7.0 collects all the suggestions users have made on this blog and adds Exchange 2007 support. To install: M-x package-install RET excorporate To get the source code: git clone git://git.savannah.gnu.org/emacs/elpa.git To report bugs: M-x report-emacs-bug [Less]

I wanted to attent FOSDEM two weeks ago, but couldn’t because I was sick, in bed with fever. I should have done a presentation about Shenandoah. Unfortunately, my backup Andrew Dinn also became sick that weekend, so that presentation simply didn’t ... [More] happen. I want to summarize some interesting news that I wanted to show there. About Shenandoah’s performance. When I talked about Shenandoah at FOSDEM 2015, I didn’t really announce any performance numbers, because we would have been embarrassed by them We spent the better part of last year optimizing the heck out of it, especially the barriers in the C2 compiler, and here we are, with some great results. SPECjvm2015 Ok. This doesn’t really exist. The last SPECjvm release was SPECjvm2008. Unfortunately, SPEC doesn’t seem to care about SPECjvm anymore, which means the last Java version that runs it without any modifications is Java7. We did some small fixes, that allows it to run with Java9 too. This invalidates compliance of the results. But they are still tremendously useful for comparison. So here it comes: This was run on a 32 core box with 160GB of RAM, giving the JVM 140GB of heap. Exact same JVM and settings with G1 and Shenandoah. No special tuning parameters. In terms of numbers, we get: Throughput:   Shenandoah: 374 ops/m  vs. G1: 393 ops/m (95%, min 80%, max 140%) Pauses:          Shenandoah: avg: 41 ms, max 202 ms                     G1:               avg: 240 ms, max 1126 ms This means, throughput of Java apps, running with Shenandoah is on average 95% that of G1, depending on the actual application, it’ll range from around 80% to around 140%. However, pause times on such large heaps are significantly better with Shenandoah! SPECjbb2015 SPECjbb2015 measures throughput of a simulated shop system under response time constraints, or service level agreements (SLAs). It measures ‘max-jops’ which is maximum throughput of the system without SLA, and critical-jops, which is throughput of the system under a restrictive SLA. Here are the numbers, G1 vs. Shenandoah, same machine and JVM settings as above: This basically confirms the results that we got from SPECjvm2008: general throughput in the area of 95% behind G1, but much better pause times, reflected in a much higher score of critical-jops. Other exciting news is that Shenandoah is now stable enough that we want to encourage everybody who’s interested to try it out. The nice folks at Adopt-OpenJDK have set up a nightly build from where you can grab binaries (Shenandoah JDK8 or Shenandoah JDK9). Enjoy! (And please report back if you encounter any problems!) [Less]

I wanted to attent FOSDEM two weeks ago, but couldn’t because I was sick, in bed with fever. I should have done a presentation about Shenandoah. Unfortunately, my backup Andrew Dinn also became sick that weekend, so that presentation simply didn’t ... [More] happen. I want to summarize some interesting news that I wanted to show there. About Shenandoah’s performance. When I talked about Shenandoah at FOSDEM 2015, I didn’t really announce any performance numbers, because we would have been embarrassed by them We spent the better part of last year optimizing the heck out of it, especially the barriers in the C2 compiler, and here we are, with some great results. SPECjvm2015 Ok. This doesn’t really exist. The last SPECjvm release was SPECjvm2008. Unfortunately, SPEC doesn’t seem to care about SPECjvm anymore, which means the last Java version that runs it without any modifications is Java7. We did some small fixes, that allows it to run with Java9 too. This invalidates compliance of the results. But they are still tremendously useful for comparison. So here it comes: This was run on a 32 core box with 160GB of RAM, giving the JVM 140GB of heap. Exact same JVM and settings with G1 and Shenandoah. No special tuning parameters. In terms of numbers, we get: Throughput:   Shenandoah: 374 ops/m  vs. G1: 393 ops/m (95%, min 80%, max 140%) Pauses:          Shenandoah: avg: 41 ms, max 202 ms                     G1:               avg: 240 ms, max 1126 ms This means, throughput of Java apps, running with Shenandoah is on average 95% that of G1, depending on the actual application, it’ll range from around 80% to around 140%. However, pause times on such large heaps are significantly better with Shenandoah! SPECjbb2015 SPECjbb2015 measures throughput of a simulated shop system under response time constraints, or service level agreements (SLAs). It measures ‘max-jops’ which is maximum throughput of the system without SLA, and critical-jops, which is throughput of the system under a restrictive SLA. Here are the numbers, G1 vs. Shenandoah, same machine and JVM settings as above: This basically confirms the results that we got from SPECjvm2008: general throughput in the area of 95% behind G1, but much better pause times, reflected in a much higher score of critical-jops. Other exciting news is that Shenandoah is now stable enough that we want to encourage everybody who’s interested to try it out. The nice folks at Adopt-OpenJDK have set up a nightly build from where you can grab binaries (Shenandoah JDK8 or Shenandoah JDK9). Enjoy! (And please report back if you encounter any problems!) [Less]

I wanted to attent FOSDEM two weeks ago, but couldn’t because I was sick, in bed with fever. I should have done a presentation about Shenandoah. Unfortunately, my backup Andrew Dinn also became sick that weekend, so that presentation simply didn’t ... [More] happen. I want to summarize some interesting news that I wanted to show there. About Shenandoah’s performance. When I talked about Shenandoah at FOSDEM 2015, I didn’t really announce any performance numbers, because we would have been embarrassed by them :-) We spent the better part of last year optimizing the heck out of it, especially the barriers in the C2 compiler, and here we are, with some great results. SPECjvm2015 Ok. This doesn’t really exist. The last SPECjvm release was SPECjvm2008. Unfortunately, SPEC doesn’t seem to care about SPECjvm anymore, which means the last Java version that runs it without any modifications is Java7. We did some small fixes, that allows it to run with Java9 too. This invalidates compliance of the results. But they are still tremendously useful for comparison. So here it comes: This was run on a 32 core box with 160GB of RAM, giving the JVM 140GB of heap. Exact same JVM and settings with G1 and Shenandoah. No special tuning parameters. In terms of numbers, we get: Throughput:   Shenandoah: 374 ops/m  vs. G1: 393 ops/m (95%, min 80%, max 140%) Pauses:          Shenandoah: avg: 41 ms, max 202 ms                     G1:               avg: 240 ms, max 1126 ms This means, throughput of Java apps, running with Shenandoah is on average 95% that of G1, depending on the actual application, it’ll range from around 80% to around 140%. However, pause times on such large heaps are significantly better with Shenandoah! SPECjbb2015 SPECjbb2015 measures throughput of a simulated shop system under response time constraints, or service level agreements (SLAs). It measures ‘max-jops’ which is maximum throughput of the system without SLA, and critical-jops, which is throughput of the system under a restrictive SLA. Here are the numbers, G1 vs. Shenandoah, same machine and JVM settings as above: This basically confirms the results that we got from SPECjvm2008: general throughput in the area of 95% behind G1, but much better pause times, reflected in a much higher score of critical-jops. Other exciting news is that Shenandoah is now stable enough that we want to encourage everybody who’s interested to try it out. The nice folks at Adopt-OpenJDK have set up a nightly build from where you can grab binaries (Shenandoah JDK8 or Shenandoah JDK9). Enjoy! (And please report back if you encounter any problems!) [Less]

I wanted to attent FOSDEM two weeks ago, but couldn’t because I was sick, in bed with fever. I should have done a presentation about Shenandoah. Unfortunately, my backup Andrew Dinn also became sick that weekend, so that presentation simply didn’t ... [More] happen. I want to summarize some interesting news that I wanted to show there. About Shenandoah’s performance. When I talked about Shenandoah at FOSDEM 2015, I didn’t really announce any performance numbers, because we would have been embarrassed by them We spent the better part of last year optimizing the heck out of it, especially the barriers in the C2 compiler, and here we are, with some great results. SPECjvm2015 Ok. This doesn’t really exist. The last SPECjvm release was SPECjvm2008. Unfortunately, SPEC doesn’t seem to care about SPECjvm anymore, which means the last Java version that runs it without any modifications is Java7. We did some small fixes, that allows it to run with Java9 too. This invalidates compliance of the results. But they are still tremendously useful for comparison. So here it comes: This was run on a 32 core box with 160GB of RAM, giving the JVM 140GB of heap. Exact same JVM and settings with G1 and Shenandoah. No special tuning parameters. In terms of numbers, we get: Throughput:   Shenandoah: 374 ops/m  vs. G1: 393 ops/m (95%, min 80%, max 140%) Pauses:          Shenandoah: avg: 41 ms, max 202 ms                     G1:               avg: 240 ms, max 1126 ms This means, throughput of Java apps, running with Shenandoah is on average 95% that of G1, depending on the actual application, it’ll range from around 80% to around 140%. However, pause times on such large heaps are significantly better with Shenandoah! SPECjbb2015 SPECjbb2015 measures throughput of a simulated shop system under response time constraints, or service level agreements (SLAs). It measures ‘max-jops’ which is maximum throughput of the system without SLA, and critical-jops, which is throughput of the system under a restrictive SLA. Here are the numbers, G1 vs. Shenandoah, same machine and JVM settings as above: This basically confirms the results that we got from SPECjvm2008: general throughput in the area of 95% behind G1, but much better pause times, reflected in a much higher score of critical-jops. Other exciting news is that Shenandoah is now stable enough that we want to encourage everybody who’s interested to try it out. The nice folks at Adopt-OpenJDK have set up a nightly build from where you can grab binaries (Shenandoah JDK8 or Shenandoah JDK9). Enjoy! (And please report back if you encounter any problems!) [Less]

It was a great pleasure to have a chance to serve on this year’s EclipseCon Program Committee. As Java SE 8 adoption took place at “record-setting pace” during the past year, I was glad to see the EclipseCon team set their sights ahead, towards JDK ... [More] 9, with its own track at EclipseCon. If you’d just like to take a peek at the changes being considered, developed and integrated into the JDK 9 Project, you can check out its web site in the OpenJDK community, and try out the Early Access builds. If you’d like to hear what JDK 9 means for Eclipse, though, then you should come to EclipseCon in March and hear about it first hand from Jay Arthanareeswaran from IBM and Manoj Palat, who will talk about Java 9 support in Eclipse. In their session, they will look at what kind of support JDT provides for developers who would like to use JDK 9 in their projects, discussing planned Eclipse features as well as what modules could mean to different projects and how to best leverage the upcoming module system. Within the OpenJDK community, Project Jigsaw is where development of the reference implementation of JSR 376 – Java Platform Module System takes place, along with the modularization of the JDK itself and the development of a new run-time image format. That’s a lot of new stuff to digest – fortunately, we’ll have Thomas Schindl at EclipseCon to give us a personal view and overview of what he calls "most likely the biggest change in Java’s history" in the “You, Me and Jigsaw” session. At this point, you may be wondering if JDK 9 is all about modules. Modularity plays a huge role, but there is a lot more to it – more than 70 JDK Enhancement Proposals have been targeted for the JDK 9 release so far. To walk us through some of Java 9’s other puzzle pieces, we’ll have Erik Costlow from Oracle.Finally, closing this track on Thursday, Erik will discuss “Preparing your code for JDK 9”. There are some steps you can take already to make your code ready to benefit from the new features planned for JDK 9, such as analyzing your project’s library dependencies for unintentional reliance on JDK-internal APIs. I hope that you will enjoy this EclipseCon track, and that you will be inspired to start experimenting with JDK 9 and Eclipse. [Less]