GNU Classpath

The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as the ability to build against system libraries and support for alternative virtual machines and ... [More] architectures beyond those supported by OpenJDK. This release updates our OpenJDK 7 support in the 2.6.x series with the October 2017 security fixes from OpenJDK 7 u161. 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 2.6.12 (2017-12-05) Security fixes S8165543: Better window framing S8169026, CVE-2017-10274: Handle smartcard clean up better S8169966: Larger AWT menus S8170218: Improved Font Metrics S8171252: Improve exception checking S8171261: Stability fixes for lcms S8174109, CVE-2017-10281: Better queuing priorities S8174966, CVE-2017-10285: Unreferenced references S8175940: More certificate subject checking S8176751, CVE-2017-10295: Better URL connections S8178794, CVE-2017-10388: Correct Kerberos ticket grants S8179101, CVE-2017-10193: Improve algorithm constraints implementation S8179998, CVE-2017-10198: Clear certificate chain connections S8180024: Improve construction of objects during deserialization S8180711, CVE-2017-10346: Better invokespecial checks S8181100, CVE-2017-10350: Better Base Exceptions S8181323, CVE-2017-10347: Better timezone processing S8181327, CVE-2017-10349: Better X processing S8181370, CVE-2017-10345: Better keystore handling S8181432, CVE-2017-10348: Better processing of unresolved permissions S8181597, CVE-2017-10357: Process Proxy presentation S8181612, CVE-2017-10355: More stable connection processing S8181692, CVE-2017-10356: Update storage implementations S8183028, CVE-2016-10165: Improve CMS header processing S8184682, CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843: Upgrade compression library Import of OpenJDK 7 u161 build 0 S6475361: Attempting to remove help menu from java.awt.MenuBar throws NullPointerException S6637288: Add OCSP support to PKIX CertPathBuilder implementation S6854712: Revocation checking enhancements (JEP-124) S6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum size S7015157: String “Tabular Navigation” should be rephrased for avoiding mistranslation S7115744: Do not call File::deleteOnExit in security tests S7126011: ReverseBuilder.getMatchingCACerts may throws NPE S7147336: clarification on warning of keytool -printcrl S7162687: enhance KDC server availability detection S7176627: CertPath/jep124/PreferCRL_SoftFail test fails (Could not determine revocation status) S7195409: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest fails with NullPointerException S7196382: PKCS11 provider should support 2048-bit DH S7197672: There are issues with shared data on windows S7199939: DSA 576 and 640 bit keys fail when initializing for No precomputed parameters S8002074: Support for AES on SPARC S8005408: KeyStore API enhancements S8006863: javadoc cleanup for 8005408 S8006946: PKCS12 test failure due to incorrect alias name S8006951: Avoid storing duplicate PKCS12 attributes S8006994: Cleanup PKCS12 tests to ensure streams get closed S8007483: attributes are ignored when loading keys from a PKCS12 keystore S8007967: Infinite loop can happen in sun.security.provider.certpath.SunCertPathBuilder.depthFirstSearchForward() S8010112: NullPointerException in sun.security.provider.certpath.CertId() S8012900: CICO ignores AAD in GCM mode (with refactoring from 6996769) S8015571: OCSP validation fails if ocsp.responderCertSubjectName is set S8016252: More defensive HashSet.readObject S8025215: jdk8 l10n resource file translation update 4 S8026943: SQE test jce/Global/Cipher/SameBuffer failed S8027575: b113 causing a lot of memory allocation and regression for wls_webapp_atomics S8029659: Keytool, print key algorithm of certificate or key entry S8029788: Certificate validation – java.lang.ClassCastException S8031825: OCSP client can’t find responder cert if it uses a different subject key id algorithm than responderID S8033117: PPC64: Adapt to 8002074: Support for AES on SPARC S8035623: [parfait] JNI exception pending in jdk/src/windows/native/sun/windows/awt_Font.cpp S8049312: AES/CICO test failed with on several modes S8050374: More Signature tests S8057810: New defaults for DSA keys in jarsigner and keytool S8062552: Support keystore type detection for JKS and PKCS12 keystores S8068427: Hashtable deserialization reconstitutes table with wrong capacity S8068881: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. S8075484, PR3474, RH1490713: SocketInputStream.socketRead0 can hang even with soTimeout set S8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException S8079129: NullPointerException in PKCS#12 Keystore in PKCS12KeyStore.java S8087144: sun/security/krb5/auto/MaxRetries.java fails with Retry count is -1 less S8136534: Loading JKS keystore using non-null InputStream results in closed stream S8149411: PKCS12KeyStore cannot extract AES Secret Keys S8153146: sun/security/krb5/auto/MaxRetries.java failed with timeout S8157561: Ship the unlimited policy files in JDK Updates S8158517: Minor optimizations to ISO10126PADDING S8164846: CertificateException missing cause of underlying exception S8165751: NPE hit with java.security.debug=provider S8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms S8173853: IllegalArgumentException in java.awt.image.ReplicateScaleFilter S8176536: Improved algorithm constraints checking S8177569: keytool should not warn if signature algorithm used in cacerts is weak S8178714: PKIX validator nameConstraints check failing after change 8175940 S8179423: 2 security tests started failing for JDK 1.6.0 u161 b05 S8179564: Missing @bug for tests added with JDK-8165367 S8181048: Refactor existing providers to refer to the same constants for default values for key length S8182879: Add warnings to keytool when using JKS and JCEKS S8184673, PR3476: Fix compatibility issue in AlgorithmChecker for 3rd party JCE providers S8184937: LCMS error 13: Couldn’t link the profiles S8185039: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle S8185040: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle S8185778: 8u151 L10n resource file update S8185845: Add SecurityTools.java test library S8186503: sun/security/tools/jarsigner/DefaultSigalg.java failed after backport to JDK 6/7/8 S8186533: 8u151 L10n resource file update md20 S8191137: keytool fails to format resource strings for keys for some languages after JDK-8171319 S8191840: Update localizations with positional arguments following JDK-8191137 S8191845: [TEST_BUG] Too many new-lines in backport of WeakAlg test Import of OpenJDK 7 u151 build 1 S8035640: JNU_CHECK_EXCEPTION should support c++ JNI syntax Backports S8138745, PR3465, RH1484399: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot S8185164, PR3433: GetOwnedMonitorInfo() returns incorrect owned monitor S8188030, PR3460, RH1484079: AWT java apps fail to start when some minimal fonts are present Bug fixes PR3470, RH1492139: Hotspot object_alloc tapset uses HeapWordSize incorrectly PR3480, RH1486025: ECC and NSS JVM crash AArch64 port S8145438, PR3443, RH1482244: Guarantee failures since 8144028: Use AArch64 bit-test instructions in C2 PR3497: AArch64: Adapt to 8002074: Support for AES on SPARC The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-2.6.12.tar.gz http://icedtea.classpath.org/download/source/icedtea-2.6.12.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/icedtea-2.6.12.tar.gz.sig http://icedtea.classpath.org/download/source/icedtea-2.6.12.tar.xz.sig These are produced using my public key. See details below. PGP Key: ed25519/0xCFDA0F9B35964222 (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: 90183fc86a001d8832ef5b9ba8617d11bde1c5f595d3da6493de7f4d7c35b68a icedtea-2.6.12.tar.gz 9f0c534914188c61b88662c4072bcf87c6dafac6aedef98f3752e30c1794c25d icedtea-2.6.12.tar.gz.sig f3de9f5ea1a447fe8a290cde5012d33b1534f0d3d484b2664a4be9202b801f68 icedtea-2.6.12.tar.xz d242e506c297925beb47c805da7ebdee2e66057d1403c666aa8d4bffa6ab7fc8 icedtea-2.6.12.tar.xz.sig The checksums can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-2.6.12.sha256 A 2.6.12 ebuild for Gentoo is available. The following people helped with these releases: Martin Balao (PR3480/RH1486025 ECC+NSS crash fix) Severin Gehwolf (PR3470/RH1492139 SystemTap fix) Andrew Hughes (all other backports & bug fixes, release management) Mario Torre (PR3459/S8188030/RH1484079 font fix) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea-2.6.12.tar.gz or: $ tar x -I xz -f icedtea-2.6.12.tar.xz then: $ mkdir icedtea-build $ cd icedtea-build $ ../icedtea-2.6.12/configure $ make Full build requirements and instructions are available in the INSTALL file. Happy hacking! [Less]

We are pleased to announce the release of IcedTea 3.6.0! The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as the ability to build against system ... [More] libraries and support for alternative virtual machines and architectures beyond those supported by OpenJDK. This release updates our OpenJDK 8 support with the October 2017 security fixes from OpenJDK 8 u151. 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 3.6.0 (2017-10-31) Security fixes S8165543: Better window framing S8169026, CVE-2017-10274: Handle smartcard clean up better S8169966: Larger AWT menus S8170218: Improved Font Metrics S8171252: Improve exception checking S8171261: Stability fixes for lcms S8174109, CVE-2017-10281: Better queuing priorities S8174966, CVE-2017-10285: Unreferenced references S8175940: More certificate subject checking S8176751, CVE-2017-10295: Better URL connections S8178794, CVE-2017-10388: Correct Kerberos ticket grants S8180024: Improve construction of objects during deserialization S8180711, CVE-2017-10346: Better invokespecial checks S8181100, CVE-2017-10350: Better Base Exceptions S8181323, CVE-2017-10347: Better timezone processing S8181327, CVE-2017-10349: Better X processing S8181370, CVE-2017-10345: Better keystore handling S8181432, CVE-2017-10348: Better processing of unresolved permissions S8181597, CVE-2017-10357: Process Proxy presentation S8181612, CVE-2017-10355: More stable connection processing S8181692, CVE-2017-10356: Update storage implementations S8183028, CVE-2016-10165: Improve CMS header processing S8184682, CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843: Upgrade compression library New features PR3469: Alternative path to tzdb.dat PR3483: Separate addition of nss.cfg and tz.properties into separate targets PR3484: Move SystemTap support to its own target PR3485: Support additional targets for the bootstrap build Import of OpenJDK 8 u151 build 12 S8029659: Keytool, print key algorithm of certificate or key entry S8057810: New defaults for DSA keys in jarsigner and keytool S8075484, PR3473, RH1490713: SocketInputStream.socketRead0 can hang even with soTimeout set S8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException S8087144: sun/security/krb5/auto/MaxRetries.java fails with Retry count is -1 less S8153146: sun/security/krb5/auto/MaxRetries.java failed with timeout S8157561: Ship the unlimited policy files in JDK Updates S8158517: Minor optimizations to ISO10126PADDING S8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms S8177569: keytool should not warn if signature algorithm used in cacerts is weak S8177837: need to upgrade install tools S8178714: PKIX validator nameConstraints check failing after change 8175940 S8179423: 2 security tests started failing for JDK 1.6.0 u161 b05 S8179564: Missing @bug for tests added with JDK-8165367 S8181048: Refactor existing providers to refer to the same constants for default values for key length S8182879: Add warnings to keytool when using JKS and JCEKS S8184937: LCMS error 13: Couldn’t link the profiles S8185039: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle S8185040: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle S8185778: 8u151 L10n resource file update S8185845: Add SecurityTools.java test library S8186503: sun/security/tools/jarsigner/DefaultSigalg.java failed after backport to JDK 6/7/8 S8186533: 8u151 L10n resource file update md20 S8186674: Remove JDK-8174109 from CPU Aug 21 week builds Backports S8035496, PR3487: G1 ARM: missing remset entry noticed by VerifyAfterGC for vm/gc/concurrent/lp50yp10rp70mr30st0 S8146086, PR3439, RH1478402: Publishing two webservices on same port fails with “java.net.BindException: Address already in use” S8184673, PR3475, RH1487266: Fix compatibility issue in AlgorithmChecker for 3rd party JCE providers S8185164, PR3438: GetOwnedMonitorInfo() returns incorrect owned monitor S8187822, PR3478, RH1494230: C2 conditonal move optimization might create broken graph Bug fixes PR3479, RH1486025: ECC and NSS JVM crash PR3486: Path to jvm.cfg is wrong in add-systemtap-boot S8165852, PR3468: (fs) Mount point not found for a file which is present in overlayfs S8188030, PR3459, RH1484079: AWT java apps fail to start when some minimal fonts are present PPC port S8145913, PR3466, RH1498309: PPC64: add Montgomery multiply intrinsic S8168318, PR3466, RH1498320: PPC64: Use cmpldi instead of li/cmpld S8170328, PR3466, RH1498321: PPC64: Use andis instead of lis/and S8181810, PR3466, RH1498319: PPC64: Leverage extrdi for bitfield extract AArch64 port S8161190, PR3488: AArch64: Fix overflow in immediate cmp instruction S8187224, PR3488: aarch64: some inconsistency between aarch64_ad.m4 and aarch64.ad SystemTap PR3467, RH1492139: Hotspot object_alloc tapset uses HeapWordSize incorrectly Shenandoah Add missing UseShenandoahGC checks to C2 [backport] Add JVMTI notifications to Shenandoah GC pauses. [backport] After Evac verification should run consistently [backport] All definitions should start with Shenandoah* [backport] Allocation latency tracing [backport] Allow allocations in pinned regions [backport] Assorted monitoring support fixes [backport] Avoid Full STW GC on System.gc() + related fixes [backport] BrooksPointer tracing overwhelms -Xlog:gc=trace [backport] Cannot do more than 1000 Full GCs [backport] Cap heap size for TestRegionSizeArgs test [backport] Cleanup “dirty” mentions [backport] Cleanup unused methods and statements + Trivial cleanup: removed unused field, etc. [backport] Common pause marker to capture everything before/after pause [backport] Consistent print_on and tty handling [backport] “continuous” heuristics [backport] Disable biased locking by default [backport] Fix build error: avoid loops with empty bodies [backport] Fix build error: switches over enums should take all enums [backport] Fix build error: verifier liveness should not be implicitly casted to size_t [backport] Fixed assertion failures when printing heap region to trace output [backport] Fixed C calling convention of shenandoah_wb() on Windows [backport] LotsOfCycles test always degrades to Full GC [backport] Made ShenandoahPrinter debug only [backport] Make sure different Verifier levels work [backport] Make sure we have at least one memory pool per memory manager (JMX) + JMX double-counts heap used size [backport] Mark heuristics diagnostic/experimental [backport] Move Verifier “start” message under (gc,start) [backport] On-demand commit as heap resizing strategy [backport] Periodic GC [backport] PhiNode::has_only_data_users() needs to apply to shenandoah barrier only [backport] Pinning humongous regions should be allowed [backport] Reclaimed humongous regions should count towards immediate garbage [backport] Refactor region flags into finite state machine [backport] Refactor ShConcThread dispatch [backport] Refactor ShenandoahFreeSet + Fast-forward over humongous regions to keep “current” non-humongous [backport] Refactor ShenandoahHeapLock [backport] Refactor ShenandoahHeapRegionSet [backport] Region (byte|word) shifts as the replacement for divisions [backport] Rehash -XX:-UseTLAB in tests + Rehash allocation tests [backport] Rename inline guards [backport] Selectable humongous threshold + Humongous top() should be correct for iteration [backport] Shortcut concurrent cycle when enough immediate garbage is reclaimed [backport] Templatize and improve inlining of arraycopy and clone barriers. [backport] TestRegionSampling test [backport] TestSmallHeap test for Shenandoah [backport] Uncommit heap regions after given delay [backport] Underflow in adaptive free_threshold calculation [backport] Unlock more GC-specific tests for Shenandoah [backport] Update counters on slow-path more rarely [backport] Verifier should avoid pushing on stack when walking objects past TAMS [backport] Verifier should walk cset and humongous regions [backport] Verify humongous regions liveness [backport] Verify liveness data Correct way to fix Windows call convention issue Fix build error in release config. Fixed Fixed message logging Handle Java heap initialization and expansion failures Make sure -verbose:gc, PrintGC, PrintGCDetails work consistently Missing barriers on constant oops + acmp rework + cas fix + write barrier on constant oop fix Missing UseShenandoahGC check in LibraryCallKit::inline_multiplyToLen() Missing UseShenandoahGC check to C2 OOME in SurrogateLockerThread deadlocks the GC cycle Properly unlock ShenandoahVerify Remove unused memory_for, fixing the build Remove useless code following acmp rework Revert accidental G1 closure rename Test bug: test library and flags in TestHeapAlloc UnlockDiagnosticVMOptions flag is needed for ShenandoahVerify Write barrier pin and expand cleanup The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-3.6.0.tar.gz http://icedtea.classpath.org/download/source/icedtea-3.6.0.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/icedtea-3.6.0.tar.gz.sig http://icedtea.classpath.org/download/source/icedtea-3.6.0.tar.xz.sig These are produced using my public key. See details below. PGP Key: ed25519/0xCFDA0F9B35964222 (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: 74a43c4e027c72bb1c324f8f73af21565404326c9998f534f234ec2a36ca1cdb icedtea-3.6.0.tar.gz 6050c8e69974a33641b764afdbd91f07725336abd20e7f260e2a0dbf562f8b32 icedtea-3.6.0.tar.gz.sig d0a0a9ce58b3ed29f2deecef8b78f28a79315f4a6330ee833410f79cbf48417e icedtea-3.6.0.tar.xz 2de4119e3e59cf7acbb1f9c93a5760397c846116067d3c45504bd3ff6297f9a8 icedtea-3.6.0.tar.xz.sig The checksums can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-3.6.0.sha256 A 3.6.0 ebuild for Gentoo is available. The following people helped with these releases: Martin Balao (PR3479/RH1486025) Severin Gehwolf (PR3467/RH1492139) Andrew Hughes (all other bug fixes and backports, release management) Fridrich Strba (PR3468/S8165852, PR3469) Mario Torre (PR3459/S8188030/RH1484079) Felix Yang (PR3488/S8187224) Yang Zhang (PR3488/S8161190) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea-3.6.0.tar.gz or: $ tar x -I xz -f icedtea-3.6.0.tar.xz then: $ mkdir icedtea-build $ cd icedtea-build $ ../icedtea-3.6.0/configure $ make Full build requirements and instructions are available in the INSTALL file. Happy hacking! [Less]

I attended the 5th Chrome Dev Summit this week. The talks were all recorded and are available via the schedule (the keynote and leadership panel on day 1 are perhaps of broadest interest and highest bang-for-buck viewing value). It was a high ... [More] quality, well-produced event with an intimate feel – I was very surprised when Robert Nyman told me it was over 700 people! I appreciated the good vegetarian food options and noticed and was very impressed by the much-better-than-typical-tech-conferences gender representation and code of conduct visibility. It doesn’t always look this way from the outside, but the various browser engine teams are more often than not working toward the same goals and in constant contact. For those who don’t know that, it was nice to see the shoutouts for other browsers and the use of Firefox’s new logo! The focus of the event IMO was, as expected, the mobile Web. While the audience was Web developers, it was interesting to see what the Chrome team is focusing on. Some of the efforts felt like Firefox OS 4 years ago but I guess FxOS was just ahead of its time From my perspective, Firefox is in pretty good shape for supporting the things Chrome was promoting (Service Workers, Custom Elements and Shadow DOM, wasm, performance-related tooling, etc.). There are of course areas we can improve: further work on Fennec support for add-to-homescreen, devtools, and seeing a few things through to release (e.g. JS modules, Custom Elements, and Shadow DOM – work is underway and we’re hoping for soon!). Oh, and one notable exception to being aligned on things is the Network Information API that the Mozilla community isn’t super fond. Other highlights for me personally included the Chrome User Experience Report (“a public dataset of key user experience metrics for popular origins on the web, as experienced by Chrome users under real-world conditions”) and the discussion about improving the developer experience for Web Workers. It was great putting faces to names and enjoying sunny San Francisco (no, seriously, it was super sunny and hot). Thanks for the great show, Google! [Less]

I did an interview with the Software Freedom Conservancy to discuss why I try to contribute to the Conservancy whenever I can. Because I believe many more free software communities deserve to have a home for their project at the Conservancy. Please ... [More] support the Software Freedom Conservancy by donating so they will be able to provide a home to many more communities. A donation of 10 US dollars a month will make you an official sponsor. Or donate directly to one of their many member projects. Software Freedom Conservancy Member Projects [Less]

I did an interview with the Software Freedom Conservancy to discuss why I try to contribute to the Conservancy whenever I can. Because I believe many more free software communities deserve to have a home for their project at the Conservancy. Please ... [More] support the Software Freedom Conservancy by donating so they will be able to provide a home to many more communities. A donation of 10 US dollars a month will make you an official sponsor. Or donate directly to one of their many member projects. Software Freedom Conservancy Member Projects [Less]

It’s been a long road, but at last the puzzle is complete: Today we delivered Project Jigsaw for general use, as part of JDK 9. Jigsaw enhances Java to support programming in the large by adding a module system to the Java SE Platform and to its ... [More] reference implementation, the JDK. You can now leverage the key advantages of that system, namely strong encapsulation and reliable configuration, to climb out of JAR hell and better structure your code for reusability and long-term evolution. Jigsaw also applies the module system to the Platform itself, and to the massive, monolithic JDK, to improve security, integrity, performance, and scalability. The last of these goals was originally intended to reduce download times and scale Java SE down to small devices, but it is today just as relevant to dense deployments in the cloud. The Java SE 9 API is divided into twenty-six standard modules; JDK 9 contains dozens more for the usual development and serviceability tools, service providers, and JDK-specific APIs. As a result you can now deliver a Java application together with a slimmed-down Java run-time system that contains just the modules that your application requires. We made all these changes with a keen eye — as always — toward compatibility. The Java SE Platform and the JDK are now modular, but that doesn’t mean that you must convert your own code into modules in order to run on JDK 9 or a slimmed-down version of it. Existing class-path applications that use only standard Java SE 8 APIs will, for the most part, work without change. Existing libraries and frameworks that depend upon internal implementation details of the JDK may require change, and they may cause warnings to be issued at run time until their maintainers fix them. Some popular libraries, frameworks, and tools — including Maven, Gradle, and Ant — were in this category but have already been fixed, so be sure to upgrade to the latest versions. Looking ahead It’s been a long road to deliver Jigsaw, and I expect it will be a long road to its wide adoption — and that’s perfectly fine. Many developers will make use of the newly-modular nature of the platform long before they use the module system in their own code, and it will be easier to use the module system for new code rather than existing code. Modularizing an existing software system can, in fact, be difficult. Sometimes it won’t be worth the effort. Jigsaw does, however, ease that effort by supporting both top-down and bottom-up migration to modules. You can thus begin to modularize your own applications long before their dependencies are modularized by their maintainers. If you maintain a library or framework then we encourage you to publish a modularized version of it as soon as possible, though not until all of its dependencies have been modularized. Modularizing the Java SE Platform and the JDK was extremely difficult, but I’m confident it will prove to have been worth the effort: It lays a strong foundation for the future of Java. The modular nature of the platform makes it possible to remove obsolete modules and to deliver new yet non-final APIs in incubator modules for early testing. The improved integrity of the platform, enabled by the strong encapsulation of internal APIs, makes it easier to move Java forward faster by ensuring that libraries, frameworks, and applications do not depend upon rapidly-changing internal implementation details. Learning more There are by now plenty of ways to learn about Jigsaw, from those of us who created it as well as those who helped out along the way. If your time is limited, consider one or more of the following: The State of the Module System is a concise, informal written overview of the module system. (It’s slightly out of date; I’ll update it soon.) Make Way for Modules!, my keynote presentation at Devoxx Belgium 2015, packs a lot of high-level information into thirty minutes. I followed that up a year later with a quick live demo of Jigsaw’s key features. Alex Buckley’s Modular Development with JDK 9, from Devoxx US 2017, covers the essentials in more depth, in just under an hour. If you really want to dive in: To get your hands dirty right away, download JDK 9 and then follow the examples in Alan Bateman’s Quick-Start Guide. If you use an IDE then you’ll need to upgrade to the latest version in order to compile and package modules. The Project Jigsaw page in the OpenJDK Community is the authoritative source for all things Jigsaw. It includes links to the six Jigsaw JEPs (JDK Enhancement Proposals), to the JSR for the module system, to the Java SE 9 versions of the key platform specifications, and to recordings of many other conference presentations. Java 9 Modularity, by Sander Mak and Paul Bakker, is a comprehensive and pragmatic guide to both the module system and the modular JDK. Java Application Architecture, by Kirk Knoernschild, predates Jigsaw but offers a clear set of principles for constructing modular software systems. Comments, questions, and suggestions are welcome on the jigsaw-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.) Thanks! Project Jigsaw was an extended, exhilarating, and sometimes exhausting nine-year effort. I was incredibly fortunate to work with an amazing core team from pretty much the very beginning: Alan Bateman, Alex Buckley, Mandy Chung, Jonathan Gibbons, and Karen Kinnear. To all of you: My deepest thanks. Key contributions later on came from Sundar Athijegannathan, Chris Hegarty, Lois Foltan, Magnus Ihse Bursie, Erik Joelsson, Jim Laskey, Jan Lahoda, Claes Redestad, Paul Sandoz, and Harold Seigel. Jigsaw benefited immensely from critical comments and suggestions from many others including Jayaprakash Artanareeswaran, Paul Bakker, Martin Buchholz, Stephen Colebourne, Andrew Dinn, Christoph Engelbert, Rémi Forax, Brian Fox, Trisha Gee, Brian Goetz, Mike Hearn, Stephan Herrmann, Juergen Hoeller, Peter Levart, Sander Mak, Gunnar Morling, Simon Nash, Nicolai Parlog, Michael Rasmussen, John Rose, Uwe Schindler, Robert Scholte, Bill Shannon, Aleksey Shipilëv, Jochen Theodorou, Weijun Wang, Tom Watson, and Rafael Winterhalter. To everyone who contributed, in ways large and small: Thank you! Thanks to Alan Bateman and Alex Buckley for comments on drafts of this entry. [Less]

It’s been a long road, but at last the puzzle is complete: Today we delivered Project Jigsaw for general use, as part of JDK 9. Jigsaw enhances Java to support programming in the large by adding a module system to the Java SE Platform and to its ... [More] reference implementation, the JDK. You can now leverage the key advantages of that system, namely strong encapsulation and reliable configuration, to climb out of JAR hell and better structure your code for reusability and long-term evolution. Jigsaw also applies the module system to the Platform itself, and to the massive, monolithic JDK, to improve security, integrity, performance, and scalability. The last of these goals was originally intended to reduce download times and scale Java SE down to small devices, but it is today just as relevant to dense deployments in the cloud. The Java SE 9 API is divided into twenty-six standard modules; JDK 9 contains dozens more for the usual development and serviceability tools, service providers, and JDK-specific APIs. As a result you can now deliver a Java application together with a slimmed-down Java run-time system that contains just the modules that your application requires. We made all these changes with a keen eye — as always — toward compatibility. The Java SE Platform and the JDK are now modular, but that doesn’t mean that you must convert your own code into modules in order to run on JDK 9 or a slimmed-down version of it. Existing class-path applications that use only standard Java SE 8 APIs will, for the most part, work without change. Existing libraries and frameworks that depend upon internal implementation details of the JDK may require change, and they may cause warnings to be issued at run time until their maintainers fix them. Some popular libraries, frameworks, and tools — including Maven, Gradle, and Ant — were in this category but have already been fixed, so be sure to upgrade to the latest versions. Looking ahead It’s been a long road to deliver Jigsaw, and I expect it will be a long road to its wide adoption — and that’s perfectly fine. Many developers will make use of the newly-modular nature of the platform long before they use the module system in their own code, and it will be easier to use the module system for new code rather than existing code. Modularizing an existing software system can, in fact, be difficult. Sometimes it won’t be worth the effort. Jigsaw does, however, ease that effort by supporting both top-down and bottom-up migration to modules. You can thus begin to modularize your own applications long before their dependencies are modularized by their maintainers. If you maintain a library or framework then we encourage you to publish a modularized version of it as soon as possible, though not until all of its dependencies have been modularized. Modularizing the Java SE Platform and the JDK was extremely difficult, but I’m confident it will prove to have been worth the effort: It lays a strong foundation for the future of Java. The modular nature of the platform makes it possible to remove obsolete modules and to deliver new yet non-final APIs in incubator modules for early testing. The improved integrity of the platform, enabled by the strong encapsulation of internal APIs, makes it easier to move Java forward faster by ensuring that libraries, frameworks, and applications do not depend upon rapidly-changing internal implementation details. Learning more There are by now plenty of ways to learn about Jigsaw, from those of us who created it as well as those who helped out along the way. If your time is limited, consider one or more of the following: The State of the Module System is a concise, informal written overview of the module system. (It’s slightly out of date; I’ll update it soon.) Make Way for Modules!, my keynote presentation at Devoxx Belgium 2015, packs a lot of high-level information into thirty minutes. I followed that up a year later with a quick live demo of Jigsaw’s key features. Alex Buckley’s Modular Development with JDK 9, from Devoxx US 2017, covers the essentials in more depth, in just under an hour. If you really want to dive in: To get your hands dirty right away, download JDK 9 and then follow the examples in Alan Bateman’s Quick-Start Guide. If you use an IDE then you’ll need to upgrade to the latest version in order to compile and package modules. The Project Jigsaw page in the OpenJDK Community is the authoritative source for all things Jigsaw. It includes links to the six Jigsaw JEPs (JDK Enhancement Proposals), to the JSR for the module system, to the Java SE 9 versions of the key platform specifications, and to recordings of many other conference presentations. Java 9 Modularity, by Sander Mak and Paul Bakker, is a comprehensive and pragmatic guide to both the module system and the modular JDK. Java Application Architecture, by Kirk Knoernschild, predates Jigsaw but offers a clear set of principles for constructing modular software systems. Comments, questions, and suggestions are welcome on the jigsaw-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.) Thanks! Project Jigsaw was an extended, exhilarating, and sometimes exhausting nine-year effort. I was incredibly fortunate to work with an amazing core team from pretty much the very beginning: Alan Bateman, Alex Buckley, Mandy Chung, Jonathan Gibbons, and Karen Kinnear. To all of you: My deepest thanks. Key contributions later on came from Sundar Athijegannathan, Chris Hegarty, Lois Foltan, Magnus Ihse Bursie, Erik Joelsson, Jim Laskey, Jan Lahoda, Paul Sandoz, and Harold Seigel. Jigsaw benefited immensely from critical comments and suggestions from many others including Jayaprakash Artanareeswaran, Paul Bakker, Martin Buchholz, Stephen Colebourne, Andrew Dinn, Christoph Engelbert, Rémi Forax, Brian Fox, Trisha Gee, Brian Goetz, Mike Hearn, Stephan Herrmann, Juergen Hoeller, Peter Levart, Sander Mak, Gunnar Morling, Simon Nash, Nicolai Parlog, Michael Rasmussen, John Rose, Uwe Schindler, Robert Scholte, Bill Shannon, Aleksey Shipilëv, Jochen Theodorou, Weijun Wang, Tom Watson, and Rafael Winterhalter. To everyone who contributed, in ways large and small: Thank you! Thanks to Alan Bateman and Alex Buckley for comments on drafts of this entry. [Less]

The Talos II is now available for pre-order. It is the more affordable, more power-efficient successor to the Talos I machine I wrote about in a previous post. This is a very affordable machine for how powerful it will be, and there are minimal ... [More] mainboard + CPU + RAM bundles (e.g., this one), around which one can build a workstation with more readily-available parts. I’ve placed an order for one of the bundles, and will buy the chassis and GPU separately (mainly to avoid high cross-border shipping fees for the full workstation). The Talos II is an important machine for Free Software, and will likely be RYF-certified by the FSF. Pre-orders end September 15th! [Less]

For over twenty years the Java SE Platform and the JDK have evolved in large, irregular, and somewhat unpredictable steps. Each feature release has been driven by one or a few significant features, and so the schedule of each release has been ... [More] adjusted as needed — sometimes more than once! — in order to accommodate the development of those features. This approach made it possible to deliver big new features at a high level of quality, after thorough review and testing by early adopters. The downside, however, was that smaller API, language, and JVM features could only be delivered when the big features were ready. This was an acceptable tradeoff in the decades before and after the turn of the century, when Java competed with just a few platforms which evolved at a similar stately pace. Nowadays, however, Java competes with many platforms which evolve at a more rapid pace. For Java to remain competitive it must not just continue to move forward — it must move forward faster. Back on the train Five years ago I mused in this space on the tension between developers, who prefer rapid innovation, and enterprises, which prefer stability, and the fact that everyone prefers regular and predictable releases. To address these differing desires I suggested, back then, that we switch from the historical feature-driven release model to a time-driven “train” model, with a feature release every two years. In this type of model the development process is a continuous pipeline of innovation that’s only loosely coupled to the actual release process, which itself has a constant cadence. Any particular feature, large or small, is merged only when it’s nearly finished. If a feature misses the current train then that’s unfortunate but it’s not the end of the world, since the next train will already be waiting and will also leave on schedule. The two-year train model was appealing in theory, but proved unworkable in practice. We took an additional eight months for Java 8 in order to address critical security issues and finish Project Lambda, which was preferable to delaying Lambda by two years. We initially planned Java 9 as a two-and-a-half year release in order to include Project Jigsaw, which was preferable to delaying Jigsaw by an additional eighteen months, yet in the end we wound up taking an additional year and so Java 9 will ship this month, three and a half years after Java 8. A two-year release cadence is, in retrospect, simply too slow. To achieve a constant cadence we must ship feature releases at a more rapid rate. Deferring a feature from one release to the next should be a tactical decision with minor inconveniences rather than a strategic decision with major consequences. So, let’s ship a feature release every six months. That’s fast enough to minimize the pain of waiting for the next train, yet slow enough that we can still deliver each release at a high level of quality. Proposal Taking inspiration from the release models used by other platforms and by various operating-system distributions, I propose that after Java 9 we adopt a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years. Feature releases can contain any type of feature, including not just new and improved APIs but also language and JVM features. New features will be merged only when they’re nearly finished, so that the release currently in development is feature-complete at all times. Feature releases will ship in March and September of each year, starting in March of 2018. Update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Each feature release will receive two updates before the next feature release. Update releases will ship quarterly in January, April, July, and October, as they do today. Every three years, starting in September of 2018, the feature release will be a long-term support release. Updates for these releases will be available for at least three years and quite possibly longer, depending upon your vendor. In this model the overall rate of change should be about the same as it is today; what’s different is that there will be many more opportunities to deliver innovation. The six-month feature releases will be smaller than the multi-year feature releases of the past, and therefore easier to adopt. Six-month feature releases will also reduce the pressure to backport new features to older releases, since the next feature release will never be more than six months away. Developers who prefer rapid innovation, so that they can leverage new features in production as soon as possible, can use the most recent feature release or an update release thereof and move on to the next one when it ships. They can deliver an application in a Docker image, or other type of container package, along with the exact Java release on which the application will run. Since the application and the Java release can always be tested together, in a modern continuous-integration and continuous-deployment pipeline, it will be straightforward to move from one Java release to the next. Enterprises that prefer stability, so that they can run multiple large applications on a single shared Java release, can instead use the current long-term support release. They can plan ahead to migrate from one long-term support release to the next, like clockwork, every three years. To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9. Implications This proposal will, if adopted, require major changes in how contributors in the OpenJDK Community produce the JDK itself; I’ve posted some initial thoughts as to how we might proceed there. It will be made easier if we can reduce the overhead of the Java Community Process, which governs the evolution of the Java SE Platform; my colleagues Brian Goetz and Georges Saab have already raised this topic with the JCP Executive Committee. This proposal will, ultimately, affect every developer, user, and enterprise that relies upon Java. It will, if successful, help Java remain competitive — while maintaining its core values of compatibility, reliability, and thoughtful evolution — for many years to come. Comments and questions are welcome, either on the OpenJDK general discussion list (please subscribe to that list in order to post to it) or on Twitter, with the hashtag #javatrain. [Less]

An update on my notes to compile NetBSD kernels and userland.Build / update the tools:-U : for unprivilged building-u : to update-m : to specify architecture./build.sh -U -u tools To cross compile, this is would enough:./build.sh -U -m i386 -u ... [More] toolsHowever, since I do want to build on the same computer and the build script would be confused, we add -T /usr/tools-${HOST_ARCH}-${TARGET_ARCH} and also separate the object dir with -O!./build.sh -U -m i386 -u -O /usr/obj-amd64-i386 -T /usr/tools-amd64-i386 toolsThen we build the kernel./build.sh -U kernel=CONFNAMEor for cross compilation:./build.sh -U -O /usr/obj-amd64-i386 -T /usr/tools-amd64-i386 -m i386 -u kernel=GENERICThe modules:./build.sh -U -u modules installmodules=/Now to build userland, including X11. I did not attempt to cross-build userland yet../build.sh -U -x -u distribution./build.sh -U -x -u distribution install=/ [Less]