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 April 2017 security fixes from OpenJDK 7 u141. . 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.10 (2017-05-16) Security fixes S8163520, CVE-2017-3509: Reuse cache entries S8163528, CVE-2017-3511: Better library loading S8165626, CVE-2017-3512: Improved window framing S8167110, CVE-2017-3514: Windows peering issue S8169011, CVE-2017-3526: Resizing XML parse trees S8170222, CVE-2017-3533: Better transfers of files S8171121, CVE-2017-3539: Enhancing jar checking S8171533, CVE-2017-3544: Better email transfer S8172299: Improve class processing New features PR3347: jstack.stp should support AArch64 Import of OpenJDK 7 u141 build 0 S4717864: setFont() does not update Fonts of Menus already on screen S6474807: (smartcardio) CardTerminal.connect() throws CardException instead of CardNotPresentException S6518907: cleanup IA64 specific code in Hotspot S6869327: Add new C2 flag to keep safepoints in counted loops. S7112912: Message “Error occurred during initialization of VM” on boxes with lots of RAM S7124213: [macosx] pack() does ignore size of a component; doesn’t on the other platforms S7124219: [macosx] Unable to draw images to fullscreen S7124552: [macosx] NullPointerException in getBufferStrategy() S7148275: [macosx] setIconImages() not working correctly (distorted icon when minimized) S7154841: [macosx] Popups appear behind taskbar S7155957: closed/java/awt/MenuBar/MenuBarStress1/MenuBarStress1.java hangs on win 64 bit with jdk8 S7160627: [macosx] TextArea has wrong initial size S7167293: FtpURLConnection connection leak on FileNotFoundException S7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray S7197203: sun/misc/URLClassPath/ClassnameCharTest.sh failed, compile error S8005255: [macosx] Cleanup warnings in sun.lwawt S8006088: Incompatible heap size flags accepted by VM S8007295: Reduce number of warnings in awt classes S8010722: assert: failed: heap size is too big for compressed oops S8011059: [macosx] Support automatic @2x images loading on Mac OS X S8014058: Regression tests for 8006088 S8014489: tests/gc/arguments/Test(Serial|CMS|Parallel|G1)HeapSizeFlags jtreg tests invoke wrong class S8016302: Change type of the number of GC workers to unsigned int (2) S8024662: gc/arguments/TestUseCompressedOopsErgo.java does not compile. S8024669: Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9 S8024926: [macosx] AquaIcon HiDPI support S8025974: l10n for policytool S8027025: [macosx] getLocationOnScreen returns 0 if parent invisible S8028212: Custom cursor HiDPI support S8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. S8031573: [macosx] Checkmarks of JCheckBoxMenuItems aren’t rendered in high resolution on Retina S8033534: [macosx] Get MultiResolution image from native system S8033786: White flashing when opening Dialogs and Menus using Nimbus with dark background S8035568: [macosx] Cursor management unification S8041734: JFrame in full screen mode leaves empty workspace after close S8059803: Update use of GetVersionEx to get correct Windows version in hs_err files S8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version 0 S8079595: Resizing dialog which is JWindow parent makes JVM crash S8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus S8130769: The new menu can’t be shown on the menubar after clicking the “Add” button. S8133357: 8u65 l10n resource file translation update S8146602: jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java test fails with NullPointerException S8147842: IME Composition Window is displayed at incorrect location S8147910: Cache initial active_processor_count S8150490: Update OS detection code to recognize Windows Server 2016 S8161147: jvm crashes when -XX:+UseCountedLoopSafepoints is enabled S8161195: Regression: closed/javax/swing/text/FlowView/LayoutTest.java S8161993: G1 crashes if active_processor_count changes during startup S8162603: Unrecognized VM option ‘UseCountedLoopSafepoints’ S8162876: [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails intermittently S8164533: sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with “Error while cleaning up threads after test” S8167179: Make XSL generated namespace prefixes local to transformation process S8169465: Deadlock in com.sun.jndi.ldap.pool.Connections S8169589: [macosx] Activating a JDialog puts to back another dialog S8170307: Stack size option -Xss is ignored S8170316: (tz) Support tzdata2016j S8170814: Reuse cache entries (part II) S8171388: Update JNDI Thread contexts S8171949: [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state S8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked. S8173931: 8u131 L10n resource file update S8174844: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle S8175087: [bsd] Fix build after “8024900: PPC64: Enable new build on AIX (jdk part)” S8175163: [bsd] Fix build after “8005629: javac warnings compiling java.awt.EventDispatchThread…” S8176044: (tz) Support tzdata2017a Import of OpenJDK 7 u141 build 1 S8043723: max_heap_for_compressed_oops() declared with size_t, but defined with uintx Import of OpenJDK 7 u141 build 2 S8011123: serialVersionUID of java.awt.dnd.InvalidDnDOperationException changed in JDK8-b82 Backports S6515172, PR3362: Runtime.availableProcessors() ignores Linux taskset command S8011621, PR3209: live_ranges_in_separate_class.patch S8022284, PR3209: Hide internal data structure in PhaseCFG S8023003, PR3209: Cleanup the public interface to PhaseCFG S8023691, PR3209: Create interface for nodes in class Block S8023988, PR3209: Move local scheduling of nodes to the CFG creation and code motion phase (PhaseCFG) S8043780, PR3369: Use open(O_CLOEXEC) instead of fcntl(FD_CLOEXEC) S8157306, PR3209: Random infrequent null pointer exceptions in javac S8173783, PR3329: IllegalArgumentException: jdk.tls.namedGroups S8173941, PR3330: SA does not work if executable is DSO S8174729, PR3361: Race Condition in java.lang.reflect.WeakCache Bug fixes PR3349: Architectures unsupported by SystemTap tapsets throw a parse error PR3370: Disable ARM32 JIT by default in jdk_generic_profile.sh PR3379: Perl should be mandatory PR3390: javac.in and javah.in should use @PERL@ rather than a hardcoded path CACAO PR2732: Raise javadoc memory limits for CACAO again! AArch64 port S8177661, PR3367: Correct ad rule output register types from iRegX to iRegXNoSp The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-2.6.10.tar.gz http://icedtea.classpath.org/download/source/icedtea-2.6.10.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.10.tar.gz.sig http://icedtea.classpath.org/download/source/icedtea-2.6.10.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: 02af605d4437e314a55c85a334321719d16be3ff670064de8972c15e30f5ceed icedtea-2.6.10.tar.gz 48f7b14d67c9a67e5e29c5ada64e8b9875f3feefacf07df1dc66dd668166d8df icedtea-2.6.10.tar.gz.sig 1c49fd735cc908677044935b6899e59434356b7e65d163bb5033e32f6621a92a icedtea-2.6.10.tar.xz abcd0e05aad77528da4957e5ccebd02282adae0938b02685100244e93da27eac icedtea-2.6.10.tar.xz.sig The checksums can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-2.6.10.sha256 A 2.6.10 ebuild for Gentoo is available. The following people helped with these releases: James Le Cuirot (PR2732) Andrew Dinn (PR3347) Andrew Hughes (all other backports & bug fixes, release management) David Smith (PR3349) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea-2.6.10.tar.gz or: $ tar x -I xz -f icedtea-2.6.10.tar.xz then: $ mkdir icedtea-build $ cd icedtea-build $ ../icedtea-2.6.10/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.4.0: ARMed and Ready! 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 ... [More] against system libraries and support for alternative virtual machines and architectures beyond those supported by OpenJDK. This release updates our OpenJDK 8 support with the April 2017 security fixes from OpenJDK 8 u131. We also add support for building using the AArch32 HotSpot port. This is now the default on arm[32], which should lead to significant performance increases over the previous default Zero assembler build. AArch64 also gets some love, with support for this architecture in the Shenandoah HotSpot build (PR3297) and the SystemTap JDK tapsets (PR3340). 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.4.0 (2017-05-16) Security fixes S8163520, CVE-2017-3509: Reuse cache entries S8163528, CVE-2017-3511: Better library loading S8165626, CVE-2017-3512: Improved window framing S8167110, CVE-2017-3514: Windows peering issue S8168699: Validate special case invocations S8169011, CVE-2017-3526: Resizing XML parse trees S8170222, CVE-2017-3533: Better transfers of files S8171121, CVE-2017-3539: Enhancing jar checking S8171533, CVE-2017-3544: Better email transfer S8172299: Improve class processing New features PR1969: Add AArch32 JIT port PR3297: Allow Shenandoah to be used on AArch64 PR3340: jstack.stp should support AArch64 Import of OpenJDK 8 u131 build 11 S6474807: (smartcardio) CardTerminal.connect() throws CardException instead of CardNotPresentException S6515172, PR3346: Runtime.availableProcessors() ignores Linux taskset command S7155957: closed/java/awt/MenuBar/MenuBarStress1/MenuBarStress1.java hangs on win 64 bit with jdk8 S7167293: FtpURLConnection connection leak on FileNotFoundException S8035568: [macosx] Cursor management unification S8079595: Resizing dialog which is JWindow parent makes JVM crash S8130769: The new menu can’t be shown on the menubar after clicking the “Add” button. S8146602: jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java test fails with NullPointerException S8147842: IME Composition Window is displayed at incorrect location S8147910, PR3346: Cache initial active_processor_count S8150490: Update OS detection code to recognize Windows Server 2016 S8160951: [TEST_BUG] javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group S8160958: [TEST_BUG] java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group S8161147: jvm crashes when -XX:+UseCountedLoopSafepoints is enabled S8161195: Regression: closed/javax/swing/text/FlowView/LayoutTest.java S8161993, PR3346: G1 crashes if active_processor_count changes during startup S8162876: [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails intermittently S8162916: Test sun/security/krb5/auto/UnboundSSL.java fails S8164533: sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with “Error while cleaning up threads after test” S8167179: Make XSL generated namespace prefixes local to transformation process S8168774: Polymorhic signature method check crashes javac S8169465: Deadlock in com.sun.jndi.ldap.pool.Connections S8169589: [macosx] Activating a JDialog puts to back another dialog S8170307: Stack size option -Xss is ignored S8170316: (tz) Support tzdata2016j S8170814: Reuse cache entries (part II) S8170888, PR3314, RH1284948: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments S8171388: Update JNDI Thread contexts S8171949: [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state S8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked. S8173030: Temporary backout fix #8035568 from 8u131-b03 S8173031: Temporary backout fix #8171952 from 8u131-b03 S8173783, PR3328: IllegalArgumentException: jdk.tls.namedGroups S8173931: 8u131 L10n resource file update S8174844: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle S8174985: NTLM authentication doesn’t work with IIS if NTLM cache is disabled S8176044: (tz) Support tzdata2017a Backports S6457406, PR3335: javadoc doesn’t handle http://…’> properly in producing index pages S8030245, PR3335: Update langtools to use try-with-resources and multi-catch S8030253, PR3335: Update langtools to use strings-in-switch S8030262, PR3335: Update langtools to use foreach loops S8031113, PR3337: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Basic.java fails intermittently S8031625, PR3335: javadoc problems referencing inner class constructors S8031649, PR3335: Clean up javadoc tests S8031670, PR3335: Remove unneeded -source options in javadoc tests S8032066, PR3335: Serialized form has broken links to non private inner classes of package private S8034174, PR2290: Remove use of JVM_* functions from java.net code S8034182, PR2290: Misc. warnings in java.net code S8035876, PR2290: AIX build issues after ’8034174: Remove use of JVM_* functions from java.net code’ S8038730, PR3335: Clean up the way JavadocTester is invoked, and checks for errors. S8040903, PR3335: Clean up use of BUG_ID in javadoc tests S8040904, PR3335: Ensure javadoc tests do not overwrite results within tests S8040908, PR3335: javadoc test TestDocEncoding should use -notimestamp S8041150, PR3335: Avoid silly use of static methods in JavadocTester S8041253, PR3335: Avoid redundant synonyms of NO_TEST S8043780, PR3368: Use open(O_CLOEXEC) instead of fcntl(FD_CLOEXEC) S8061305, PR3335: Javadoc crashes when method name ends with “Property” S8072452, PR3337: Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits S8075565, PR3337: Define @intermittent jtreg keyword and mark intermittently failing jdk tests S8075670, PR3337: Remove intermittent keyword from some tests S8078334, PR3337: Mark regression tests using randomness S8078880, PR3337: Mark a few more intermittently failuring security-libs S8133318, PR3337: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier S8144539, PR3337: Update PKCS11 tests to run with security manager S8144566, PR3352: Custom HostnameVerifier disables SNI extension S8153711, PR3313, RH1284948: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command S8155049, PR3352: New tests from 8144566 fail with “No expected Server Name Indication” S8173941, PR3326: SA does not work if executable is DSO S8174164, PR3334, RH1417266: SafePointNode::_replaced_nodes breaks with irreducible loops S8174729, PR3336, RH1420518: Race Condition in java.lang.reflect.WeakCache S8175097, PR3334, RH1417266: [TESTBUG] 8174164 fix missed the test Bug fixes PR3348: Architectures unsupported by SystemTap tapsets throw a parse error PR3378: Perl should be mandatory PR3389: javac.in and javah.in should use @PERL@ rather than a hardcoded path AArch64 port S8168699, PR3372: Validate special case invocations [AArch64 support] S8170100, PR3372: AArch64: Crash in C1-compiled code accessing References S8172881, PR3372: AArch64: assertion failure: the int pressure is incorrect S8173472, PR3372: AArch64: C1 comparisons with null only use 32-bit instructions S8177661, PR3372: Correct ad rule output register types from iRegX to iRegXNoSp AArch32 port PR3380: Zero should not be enabled by default on arm with the AArch32 HotSpot build PR3384, S8139303, S8167584: Add support for AArch32 architecture to configure and jdk makefiles PR3385: aarch32 does not support -Xshare:dump PR3386, S8164652: AArch32 jvm.cfg wrong for C1 build PR3387: Installation fails on arm with AArch32 port as INSTALL_ARCH_DIR is arm, not aarch32 PR3388: Wrong path for jvm.cfg being used on arm with AArch32 build Shenandoah Fix Shenandoah argument checking on 32bit builds. Import from Shenandoah tag aarch64-shenandoah-jdk8u101-b14-shenandoah-merge-2016-07-25 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-02-20 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-03-06 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-03-09 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-03-23 The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-3.4.0.tar.gz http://icedtea.classpath.org/download/source/icedtea-3.4.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.4.0.tar.gz.sig http://icedtea.classpath.org/download/source/icedtea-3.4.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: 2b606bbbf4ca5bcf2c8e811ea9060da30744860f3d63e1b3149fb5550a90b92b icedtea-3.4.0.tar.gz 15391447e489cb939277a6981ff9dbc2a57d50c6d3682e0159a1dab04a05da02 icedtea-3.4.0.tar.gz.sig b518f389c44d45bb264d7e954b3c0b836d3d23ba9fbd620ff7c68f934a012e9a icedtea-3.4.0.tar.xz 32e80eacf27e3ec31dd698486e2f79a92bc146c4bc37c76bb7e3d8b7e34a7084 icedtea-3.4.0.tar.xz.sig The checksums can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-3.4.0.sha256 A 3.4.0 ebuild for Gentoo is available. The following people helped with these releases: Andrew Dinn (PR3340) Andrew Hughes (all other bug fixes and backports, release management) David Smith (PR3348) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea-3.4.0.tar.gz or: $ tar x -I xz -f icedtea-3.4.0.tar.xz then: $ mkdir icedtea-build $ cd icedtea-build $ ../icedtea-3.4.0/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.4.0: ARMed and Ready! 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 ... [More] against system libraries and support for alternative virtual machines and architectures beyond those supported by OpenJDK. This release updates our OpenJDK 8 support with the April 2017 security fixes from OpenJDK 8 u131. We also add support for building using the AArch32 HotSpot port. This is now the default on arm[32], which should lead to significant performance increases over the previous default Zero assembler build. AArch64 also gets some love, with support for this architecture in the Shenandoah HotSpot build (PR3297) and the SystemTap JDK tapsets (PR3340). 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.4.0 (2017-05-16) Security fixes S8163520, CVE-2017-3509: Reuse cache entries S8163528, CVE-2017-3511: Better library loading S8165626, CVE-2017-3512: Improved window framing S8167110, CVE-2017-3514: Windows peering issue S8168699: Validate special case invocations S8169011, CVE-2017-3526: Resizing XML parse trees S8170222, CVE-2017-3533: Better transfers of files S8171121, CVE-2017-3539: Enhancing jar checking S8171533, CVE-2017-3544: Better email transfer S8172299: Improve class processing New features PR1969: Add AArch32 JIT port PR3297: Allow Shenandoah to be used on AArch64 PR3340: jstack.stp should support AArch64 Import of OpenJDK 8 u131 build 11 S6474807: (smartcardio) CardTerminal.connect() throws CardException instead of CardNotPresentException S6515172, PR3346: Runtime.availableProcessors() ignores Linux taskset command S7155957: closed/java/awt/MenuBar/MenuBarStress1/MenuBarStress1.java hangs on win 64 bit with jdk8 S7167293: FtpURLConnection connection leak on FileNotFoundException S8035568: [macosx] Cursor management unification S8079595: Resizing dialog which is JWindow parent makes JVM crash S8130769: The new menu can’t be shown on the menubar after clicking the “Add” button. S8146602: jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java test fails with NullPointerException S8147842: IME Composition Window is displayed at incorrect location S8147910, PR3346: Cache initial active_processor_count S8150490: Update OS detection code to recognize Windows Server 2016 S8160951: [TEST_BUG] javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group S8160958: [TEST_BUG] java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group S8161147: jvm crashes when -XX:+UseCountedLoopSafepoints is enabled S8161195: Regression: closed/javax/swing/text/FlowView/LayoutTest.java S8161993, PR3346: G1 crashes if active_processor_count changes during startup S8162876: [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails intermittently S8162916: Test sun/security/krb5/auto/UnboundSSL.java fails S8164533: sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with “Error while cleaning up threads after test” S8167179: Make XSL generated namespace prefixes local to transformation process S8168774: Polymorhic signature method check crashes javac S8169465: Deadlock in com.sun.jndi.ldap.pool.Connections S8169589: [macosx] Activating a JDialog puts to back another dialog S8170307: Stack size option -Xss is ignored S8170316: (tz) Support tzdata2016j S8170814: Reuse cache entries (part II) S8170888, PR3314, RH1284948: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments S8171388: Update JNDI Thread contexts S8171949: [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state S8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked. S8173030: Temporary backout fix #8035568 from 8u131-b03 S8173031: Temporary backout fix #8171952 from 8u131-b03 S8173783, PR3328: IllegalArgumentException: jdk.tls.namedGroups S8173931: 8u131 L10n resource file update S8174844: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle S8174985: NTLM authentication doesn’t work with IIS if NTLM cache is disabled S8176044: (tz) Support tzdata2017a Backports S6457406, PR3335: javadoc doesn’t handle http://…’> properly in producing index pages S8030245, PR3335: Update langtools to use try-with-resources and multi-catch S8030253, PR3335: Update langtools to use strings-in-switch S8030262, PR3335: Update langtools to use foreach loops S8031113, PR3337: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Basic.java fails intermittently S8031625, PR3335: javadoc problems referencing inner class constructors S8031649, PR3335: Clean up javadoc tests S8031670, PR3335: Remove unneeded -source options in javadoc tests S8032066, PR3335: Serialized form has broken links to non private inner classes of package private S8034174, PR2290: Remove use of JVM_* functions from java.net code S8034182, PR2290: Misc. warnings in java.net code S8035876, PR2290: AIX build issues after ’8034174: Remove use of JVM_* functions from java.net code’ S8038730, PR3335: Clean up the way JavadocTester is invoked, and checks for errors. S8040903, PR3335: Clean up use of BUG_ID in javadoc tests S8040904, PR3335: Ensure javadoc tests do not overwrite results within tests S8040908, PR3335: javadoc test TestDocEncoding should use -notimestamp S8041150, PR3335: Avoid silly use of static methods in JavadocTester S8041253, PR3335: Avoid redundant synonyms of NO_TEST S8043780, PR3368: Use open(O_CLOEXEC) instead of fcntl(FD_CLOEXEC) S8061305, PR3335: Javadoc crashes when method name ends with “Property” S8072452, PR3337: Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits S8075565, PR3337: Define @intermittent jtreg keyword and mark intermittently failing jdk tests S8075670, PR3337: Remove intermittent keyword from some tests S8078334, PR3337: Mark regression tests using randomness S8078880, PR3337: Mark a few more intermittently failuring security-libs S8133318, PR3337: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier S8144539, PR3337: Update PKCS11 tests to run with security manager S8144566, PR3352: Custom HostnameVerifier disables SNI extension S8153711, PR3313, RH1284948: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command S8155049, PR3352: New tests from 8144566 fail with “No expected Server Name Indication” S8173941, PR3326: SA does not work if executable is DSO S8174164, PR3334, RH1417266: SafePointNode::_replaced_nodes breaks with irreducible loops S8174729, PR3336, RH1420518: Race Condition in java.lang.reflect.WeakCache S8175097, PR3334, RH1417266: [TESTBUG] 8174164 fix missed the test Bug fixes PR3348: Architectures unsupported by SystemTap tapsets throw a parse error PR3378: Perl should be mandatory PR3389: javac.in and javah.in should use @PERL@ rather than a hardcoded path AArch64 port S8168699, PR3372: Validate special case invocations [AArch64 support] S8170100, PR3372: AArch64: Crash in C1-compiled code accessing References S8172881, PR3372: AArch64: assertion failure: the int pressure is incorrect S8173472, PR3372: AArch64: C1 comparisons with null only use 32-bit instructions S8177661, PR3372: Correct ad rule output register types from iRegX to iRegXNoSp AArch32 port PR3380: Zero should not be enabled by default on arm with the AArch32 HotSpot build PR3384, S8139303, S8167584: Add support for AArch32 architecture to configure and jdk makefiles PR3385: aarch32 does not support -Xshare:dump PR3386, S8164652: AArch32 jvm.cfg wrong for C1 build PR3387: Installation fails on arm with AArch32 port as INSTALL_ARCH_DIR is arm, not aarch32 PR3388: Wrong path for jvm.cfg being used on arm with AArch32 build Shenandoah Fix Shenandoah argument checking on 32bit builds. Import from Shenandoah tag aarch64-shenandoah-jdk8u101-b14-shenandoah-merge-2016-07-25 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-02-20 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-03-06 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-03-09 Import from Shenandoah tag aarch64-shenandoah-jdk8u121-b14-shenandoah-merge-2017-03-23 The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-3.4.0.tar.gz http://icedtea.classpath.org/download/source/icedtea-3.4.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.4.0.tar.gz.sig http://icedtea.classpath.org/download/source/icedtea-3.4.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: 2b606bbbf4ca5bcf2c8e811ea9060da30744860f3d63e1b3149fb5550a90b92b icedtea-3.4.0.tar.gz 15391447e489cb939277a6981ff9dbc2a57d50c6d3682e0159a1dab04a05da02 icedtea-3.4.0.tar.gz.sig b518f389c44d45bb264d7e954b3c0b836d3d23ba9fbd620ff7c68f934a012e9a icedtea-3.4.0.tar.xz 32e80eacf27e3ec31dd698486e2f79a92bc146c4bc37c76bb7e3d8b7e34a7084 icedtea-3.4.0.tar.xz.sig The checksums can be downloaded from: http://icedtea.classpath.org/download/source/icedtea-3.4.0.sha256 A 3.4.0 ebuild for Gentoo is available. The following people helped with these releases: Andrew Dinn (PR3340) Christine Flood (S8170888, PR3314, RH1284948 CGroup memory limit handling) Severin Gehwolf (S8153711, PR3313, RH1284948 JDWP memory leak) Andrew Hughes (all other bug fixes and backports, release management) David Smith (PR3348) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea-3.4.0.tar.gz or: $ tar x -I xz -f icedtea-3.4.0.tar.xz then: $ mkdir icedtea-build $ cd icedtea-build $ ../icedtea-3.4.0/configure $ make Full build requirements and instructions are available in the INSTALL file. Happy hacking! [Less]

Dear Members of the JCP Executive Committee: I am the Specification Lead for JSR 376, the Java Platform Module System. The goal of this JSR is to design a module system that is approachable by all developers for use in their own code yet scalable to ... [More] the modularization of the Java SE Platform itself, as stated in the JSR submission which the EC approved in December 2014. The present draft Specification achieves that goal, as further expressed in a set of requirements agreed to by the JSR 376 Expert Group in April 2015. The Specification reflects input not only from the EG but, also, from an active community of developers that includes the maintainers of some of the most widely-used open-source Java libraries, frameworks, and tools. We are still working on a few minor open issues, but I am confident that we can resolve them in short order. Just yesterday I posted a revised proposal for the automatic-modules issue raised by some of the core Maven developers, and they have responded positively. The Public Review Ballot for this JSR will close in a few days. Red Hat Middleware has indicated, as you know, that they will not support this JSR. That is disappointing, but not surprising. Red Hat Middleware initially agreed to the goals and requirements of the JSR, but then worked consistently to undermine them. They attempted to turn this JSR into something other than it was intended to be. Rather than design one module system that is both approachable and scalable they instead wanted to design a “meta” module system via which multiple different module systems could interoperate on an intimate basis. I can only assume that they pursued this alternate goal in order to preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem. Designing a “meta” module system would be an interesting project, but it would be even larger in scope and much more difficult than this JSR. By focusing on an audience of module-system experts it would likely result in a design that is far from approachable by all developers. That is why I repeatedly pointed out to Red Hat Middleware that many of the features they advocated were out of scope, but they chose not to accept those decisions. IBM has declared publicly that they will cast an explicit vote against this JSR. That is disappointing also—and surprising. IBM has said very little during the course of this JSR. After they announced that they would vote against it they later sent a list of specific issues to the EG, but only in response to a request from another EG member. None of those issues is new, many of them were discussed long ago, and IBM was silent during most of the discussions. IBM’s recent position appears rooted in a vague desire for “closer consensus” amongst EG members. I would prefer more consensus too, but that is not possible given Red Hat Middleware’s position. I can only conclude that IBM has decided that their interests are best served by delaying this JSR and, also, JSR 379 (Java SE 9)—which is regrettable. Is the present Specification for this JSR perfect? No, of course not. It does, however, reflect years of development, testing, and refinement with active feedback from many developers. Could we make the Specification better if we spent more time on it? Yes, of course we could. What we have now does not solve every practical modularity-related problem that developers face, but it meets the agreed goals and requirements and is a solid foundation for future work. It is time to ship what we have, see what we learn, and iteratively improve. Let not the perfect be the enemy of the good. Should we further delay this JSR—possibly for years—in order to gain “closer consensus” by pursuing a different goal that will likely result in a design so bloated and complex that no working developer would ever use it? I do not see how that could possibly be in the best interest of the Java community. As you consider how to cast your vote I urge you to judge the Specification on its merits and, also, to take into account the nature of the precedent that your vote will set. A vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself. The Process does not mandate consensus, and for good reason. It intentionally gives Specification Leads broad decision powers, precisely to prevent EG members from obstructing progress in order to defend their own narrow interests. If you take away that authority then you doom future JSRs to the consensus of self-serving “experts.” Many failed technologies have been designed in exactly that way. That is not the future that I want for Java. Respectfully yours, Mark Reinhold [Less]

Dear Members of the JCP Executive Committee: I am the Specification Lead for JSR 376, the Java Platform Module System. The goal of this JSR is to design a module system that is approachable by all developers for use in their own code yet scalable to ... [More] the modularization of the Java SE Platform itself, as stated in the JSR submission which the EC approved in December 2014. The present draft Specification achieves that goal, as further expressed in a set of requirements agreed to by the JSR 376 Expert Group in April 2015. The Specification reflects input not only from the EG but, also, from an active community of developers that includes the maintainers of some of the most widely-used open-source Java libraries, frameworks, and tools. We are still working on a few minor open issues, but I am confident that we can resolve them in short order. Just yesterday I posted a revised proposal for the automatic-modules issue raised by some of the core Maven developers, and they have responded positively. The Public Review Ballot for this JSR will close in a few days. Red Hat Middleware has indicated, as you know, that they will not support this JSR. That is disappointing, but not surprising. Red Hat Middleware initially agreed to the goals and requirements of the JSR, but then worked consistently to undermine them. They attempted to turn this JSR into something other than it was intended to be. Rather than design one module system that is both approachable and scalable they instead wanted to design a “meta” module system via which multiple different module systems could interoperate on an intimate basis. I can only assume that they pursued this alternate goal in order to preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem. Designing a “meta” module system would be an interesting project, but it would be even larger in scope and much more difficult than this JSR. By focusing on an audience of module-system experts it would likely result in a design that is far from approachable by all developers. That is why I repeatedly pointed out to Red Hat Middleware that many of the features they advocated were out of scope, but they chose not to accept those decisions. IBM has declared publicly that they will cast an explicit vote against this JSR. That is disappointing also—and surprising. IBM has said very little during the course of this JSR. After they announced that they would vote against it they later sent a list of specific issues to the EG, but only in response to a request from another EG member. None of those issues is new, many of them were discussed long ago, and IBM was silent during most of the discussions. IBM’s recent position appears rooted in a vague desire for “closer consensus” amongst EG members. I would prefer more consensus too, but that is not possible given Red Hat Middleware’s position. I can only conclude that IBM has decided that their interests are best served by delaying this JSR and, also, JSR 379 (Java SE 9)—which is regrettable. Is the present Specification for this JSR perfect? No, of course not. It does, however, reflect years of development, testing, and refinement with active feedback from many developers. Could we make the Specification better if we spent more time on it? Yes, of course we could. What we have now does not solve every practical modularity-related problem that developers face, but it meets the agreed goals and requirements and is a solid foundation for future work. It is time to ship what we have, see what we learn, and iteratively improve. Let not the perfect be the enemy of the good. Should we further delay this JSR—possibly for years—in order to gain “closer consensus” by pursuing a different goal that will likely result in a design so bloated and complex that no working developer would ever use it? I do not see how that could possibly be in the best interest of the Java community. As you consider how to cast your vote I urge you to judge the Specification on its merits and, also, to take into account the nature of the precedent that your vote will set. A vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself. The Process does not mandate consensus, and for good reason. It intentionally gives Specification Leads broad decision powers, precisely to prevent EG members from obstructing progress in order to defend their own narrow interests. If you take away that authority then you doom future JSRs to the consensus of self-serving “experts.” Many failed technologies have been designed in exactly that way. That is not the future that I want for Java. Respectfully yours, Mark Reinhold [Less]

Dear Members of the JCP Executive Committee: I am the Specification Lead for JSR 376, the Java Platform Module System. The goal of this JSR is to design a module system that is approachable by all developers for use in their own code yet scalable to ... [More] the modularization of the Java SE Platform itself, as stated in the JSR submission which the EC approved in December 2014. The present draft Specification achieves that goal, as further expressed in a set of requirements agreed to by the JSR 376 Expert Group in April 2015. The Specification reflects input not only from the EG but, also, from an active community of developers that includes the maintainers of some of the most widely-used open-source Java libraries, frameworks, and tools. We are still working on a few minor open issues, but I am confident that we can resolve them in short order. Just yesterday I posted a revised proposal for the automatic-modules issue raised by some of the core Maven developers, and they have responded positively. The Public Review Ballot for this JSR will close in a few days. Red Hat Middleware has indicated, as you know, that they will not support this JSR. That is disappointing, but not surprising. Red Hat Middleware initially agreed to the goals and requirements of the JSR, but then worked consistently to undermine them. They attempted to turn this JSR into something other than it was intended to be. Rather than design one module system that is both approachable and scalable they instead wanted to design a “meta” module system via which multiple different module systems could interoperate on an intimate basis. I can only assume that they pursued this alternate goal in order to preserve and protect their home-grown, non-standard module system, which is little used outside of the JBoss/Wildfly ecosystem. Designing a “meta” module system would be an interesting project, but it would be even larger in scope and much more difficult than this JSR. By focusing on an audience of module-system experts it would likely result in a design that is far from approachable by all developers. That is why I repeatedly pointed out to Red Hat Middleware that many of the features they advocated were out of scope, but they chose not to accept those decisions. IBM has declared publicly that they will cast an explicit vote against this JSR. That is disappointing also — and surprising. IBM has said very little during the course of this JSR. After they announced that they would vote against it they later sent a list of specific issues to the EG, but only in response to a request from another EG member. None of those issues is new, many of them were discussed long ago, and IBM was silent during most of the discussions. IBM’s recent position appears rooted in a vague desire for “closer consensus” amongst EG members. I would prefer more consensus too, but that is not possible given Red Hat Middleware’s position. I can only conclude that IBM has decided that their interests are best served by delaying this JSR and, also, JSR 379 (Java SE 9) — which is regrettable. Is the present Specification for this JSR perfect? No, of course not. It does, however, reflect years of development, testing, and refinement with active feedback from many developers. Could we make the Specification better if we spent more time on it? Yes, of course we could. What we have now does not solve every practical modularity-related problem that developers face, but it meets the agreed goals and requirements and is a solid foundation for future work. It is time to ship what we have, see what we learn, and iteratively improve. Let not the perfect be the enemy of the good. Should we further delay this JSR — possibly for years — in order to gain “closer consensus” by pursuing a different goal that will likely result in a design so bloated and complex that no working developer would ever use it? I do not see how that could possibly be in the best interest of the Java community. As you consider how to cast your vote I urge you to judge the Specification on its merits and, also, to take into account the nature of the precedent that your vote will set. A vote against this JSR due to lack of consensus in the EG is a vote against the Java Community Process itself. The Process does not mandate consensus, and for good reason. It intentionally gives Specification Leads broad decision powers, precisely to prevent EG members from obstructing progress in order to defend their own narrow interests. If you take away that authority then you doom future JSRs to the consensus of self-serving “experts.” Many failed technologies have been designed in exactly that way. That is not the future that I want for Java. Respectfully yours, Mark Reinhold [Less]

After (too) many years, finally a new release of Graphos.This release has two new important features: cusps and images.Splines support now cusps, that is left and right asymmetrical tangents to a control point.A new image item object exists. This ... [More] allows you to paste a preferably small image and move it around like it were a box, resizing it at will.This is quite useful to be able to manually overlay lines and trace images.Since the image is directly encoded in the file and not saved as a separate image it is not very efficient and using large images is not advisable. In the future a new bundle file format needs to be implemented.The screenshot shows an example of tracing the GNUstep logo imported as a bitmap, using the cusp point in the upper right.Many bug fixes and improvements in these past years, some major:  Text improvements (editor display, reading/&saving, Mac support)  Circles/Ovals save/read fix  Properties inspector fixes  Portability fixes To support cusps, the file format changed again, reading of old formats is still supported. [Less]

After almost fifteen years I have decided to quit working on IKVM.NET. The decision has been a long time coming. Those of you that saw yesterday’s Twitter spat, please don’t assume that was the cause. It rather shared an underlying cause. I’ve slowly ... [More] been losing faith in .NET. Looking back, I guess this process started with the release of .NET 3.5. On the Java side things don’t look much better. The Java 9 module system reminds me too much of the generics erasure debacle. I hope someone will fork IKVM.NET and continue working on it. Although, I’d appreciate it if they’d pick another name. I’ve gotten so much criticism for the name over the years, that I’d like to hang on to it 😊 I’d like to thank the following people for helping me make this journey or making the journey so much fun: Brian Goetz, Chris Brumme, Chris Laffra, Dawid Weiss, Erik Meijer, Jb Evain, John Rose, Mads Torgersen, Mark Reinhold, Volker Berlin, Wayne Kovsky, The GNU Classpath Community, The Mono Community. And I want to especially thank my friend Miguel de Icaza for his guidance, support, inspiration and tireless efforts to promote IKVM. Thank you all and goodbye. [Less]

[NOTE: This article talks about commercial products and contains links to them, I do not receive any money if you buy those tools, nor I work for or I am affiliated to any of those companies. The opinion expressed here are mine and the review is ... [More] subjective] This is my attempt at a review of Spitfire Audio BT Phobos. Before diving into the review, and since I know I will be critic particularly on some aspects, I think it’s fair to assess the plugin right away: BT Phobos is an awesome tool, make no mistakes. BT Phobos is a “polyconvolution” synthesiser. It is, in fact, the first “standalone” plugin produced by Spitfire Audio, which is one of the companies I respect the most when it comes to music production and sample based instruments. The term polyconvolution is used by the Spitfire Audio team to indicate the simultaneous use of three convolvers for four primary audio paths: you can send any amount of each of those four primary sources (numbered 1 to 4) outputs to each of the three convolution engines (named W, X and Y). Source material controls There is lot of flexibility in the mixing capabilities; there are, of course, separate dry/wet signal knobs that send a specific portion of the unprocessed source material to the “amplifier” module, control how much of the signal goes to the convolution circuits, and finally how much of each of the convolution engines applies to each of the source sound. This last bit is achieved by means of an interesting nabla shaped X/Y pad: by positioning the icon that represents the source module closer to a corner it’s possible activate just the convolution engine that represents that corner; for example, top left is the W engine, top right the X and bottom the Y. Manually moving the icon gradually introduces contributions from the other engines, and double clicking on the icon makes all convolvers contribute equally to the wet sound, by positioning them to the center of the nabla. The convolution mixer Finally, each convolver has a control that allows to change the output level of the convolution engine before it reaches its envelope shaper. Spitfire Audio has released a very interesting flow diagram that shows the signal path in detail, which is linked below for reference. BT Phobos signal path In addition to the controls just described, the main GUI has basic controls to tweak the source material with an ADSR envelope which is directly accessible below each of the main sound sources as well as the convolutions modules, but it’s possible to have access to more advanced settings by clicking on the number or the letter that identifies the module name. The advanced controls interface An example of such controls is the Hold parameter, which let the user adjust the time the sound is held at full level before entering the Decay phase of its envelope; another useful tool is the sampling and IR offset controls, which allow to tweak parameters like the starting point of the material or the quantisation and its Speed (the playback speed for the samples, and is a function of the host tempo); there is also a control to influence the general pitch of the sound; finally a simple but effective section is dedicated to filtering – although a proper EQ is missing – as well as panning and level adjustments. All those parameters are particularly important settings when using loops, but also contribute to shaping the sound with the pitched material, and can be randomised for interesting effects and artefacts generated from the entropy (you can just randomise the material selection only as opposed to all the parameters). Modulation is also present, of course, with various LFOs of various kind that can be used to modulate basically everything. You can access them either by clicking on the mappings toggle below the ADSR envelope of each section, or by using the advanced settings pages. The amount of tweaks that can be made to the material in both the source and the convolution engines is probably the most important aspect of BT Phobos, since it gives an excellent amount of freedom to create new sounds from what’s available, which is already a massive amount of content, and allows to build wildly different patches with a bit of work, but it’s definitely not straightforward and needs time to understand the combined effects that each setting has on the whole. Since the material is polyphonic, the Impulse Responses for the convolution are created on the fly, and in fact, one interesting characteristic of BT Phobos is that there is no difference between a material for the convolution engines and one for the source module,  both draw from the same pool of sounds. BT Phobos beautiful GUI There is a difference on the type of material though, where loop based samples are, well, looped (and tempo sync’ed), and their pitch does not change based on the key that triggers them (although you can still affect the general pitch of the sound with the advanced controls), “tonal” material are pitched and change following the midi notes. One note about the LFOs: the mappings are “per module”. In other words, it is possible to modulate almost every parameter inside a single module, be it one of the four input sources or one of the three convolution engines, but there seem to be no way to define a global mapping of some kind. For example, I found a very nice patch from Mr. Christian Henson (which incidentally made, at least in my opinion, the best and most balanced overall presets), and I noticed I could make it even more interesting by using the modulation wheel. I wanted to modulate the CC1 message with an LFO (in fact, ideally it would be even better to have access to a custom envelope, but BT Phobos doesn’t have any for modulation use), but I could not find a way to do that other than using Logic’s own Midi FX. I understand that MIDI signals are generated outside the scope of the plugin, but it would be fantastic to have the option of tweaking and modulate everything from within the synth itself. All the sources and convolvers can be assigned to separate parts of the keyboard by tweaking the mapper at the bottom of the GUI. It is not possible to map a sound to start from an offset in the keyboard controls – for example to play C1 on the keyboard but trigger C2, or any other note – but of course you can change the global pitch so this has effectively the same result, and as said before it can also be modulated with an LFO or via DAW automation, for more interesting effects. Keyboard mapping tool Indeed, the flexibility of the tool, and the number of options at disposal for tweaking the sounds are very impressive. Most patches are very nice and ready to be used as they are, and blend nicely with lots of disparate styles. Some patches are very specific though, and pose a challenge to be used. Generally, I would consider these as starting points for exploration, rather than “final”. When reading about BT Phobos in the weeks before its release many people asked whether you could add your own sound to it or not. It’s not possible, unfortunately. At first, I thought that wasn’t a limitation or a deal breaker. I still think it’s not a deal breaker, but I see the value added that BT Phobos has even just as a standalone synth, as opposed to recreate the same kind of signal path manually with external tools, to give your own content the “Phobos treatment”, which is something that is entirely possible of course, for example just with Alchemy and Space Designer (which are both included in MainStage, so you can get them for a staggering 30 euros if you are a Mac user, even if you don’t use Logic Pro X!), but of course, we would be trading away the immediacy that BT Phobos delivers. That, maybe, is my main criticism to this synth, and I hope Spitfire Audio turns BT Phobos into a fully fledged tool for sound design over time, maybe enabling access to spectral shaping in some form or another, so we can literally paint over (or paint away!) portions of the sound, which is something you can do with iZotope Iris or Alchemy and is a very powerful way to shape a sound and do sound design in general. Another thing that is missing is a sound effect module, although I don’t know how important that is, given that there are thousands of outstanding plugins that do all sort of effects from delay to chorus etc… And, in fact, many patches benefit for added reverb (I use Eventide Blackhole and found that works extremely well with BT Phobos, since it’s also prominently used for weird sound effects). But it may be interesting to play by putting some effects (including a more proper EQ section) in various places in the signal path, although it’s all too easy to generate total chaos from such experimentation, so it’s possible the Spitfire Audio simply thought to leave this option for another time and instead focus on a better overall experience. And there’s no arpeggiator! Really! The number of polyphonic voices can be altered. Spitfire Audio states that the synth tweaks the number of voices at startup to match the characteristics of your computer, but I can’t confirm that, since every change I do seems to remain, even if I occasionally hear some pop and cracks at higher settings. Nevertheless, the CPU usage is pretty decent unless you go absolutely crazy with the polyphony count. I also noted that the numbers effect the clarity of the sound. This is understandable since an higher count means more notes can be generated at the same time, which means more things are competing for the same spectrum, and things can become very confusing very quickly. On the other end, a lower polyphony count has a bad impact on how the notes are generated. I feel sometime that things just stop generating sound, which is counter intuitive and very disturbing, especially since it’s very easy to have a high polyphony count with all those sources and convolvers. Also to note is that, by nature, some patches have very wild difference in their envelopes and level settings, which means it’s all to easy to move from a quiet to a very loud patch just by clicking “next” (which is possible in Logic at least with the next/prev patch buttons on top of the plugin main frame). The synth does not stop the sound, nor does any attempt to fade from one sound to the next, instead, the convolutions simply keep working on the next sample in queue with the new settings! I still have to decide if this is cool or not, perhaps it’s not intentional, but I can see how this could be used to automate patch changes in some clever way during playback! And indeed, a was able to create a couple of interesting side effects just by changing between patches at the right time. More on the sounds. The amount of content is really staggering, and simply cycling through the patches does not make justice to this synth, at all! What BT Phobos wants is a user that spends time tweaking the patches and play with the source material to get the most out it, however it’s easy to see how limiting this may feel at the same time, particularly with the more esoteric and atonal sounds, and there’s certainly a limit on how good a wood stick convolved with an aluminium thin can may sound, so indeed some patches do feel repetitive at times, as the source material does. There are quite a few very similar drum loops for example, or various pitches “wind blowing into a pipe” kind of things. This is a problem common to other synths based on the idea of tweaking sounds from the environment, though. For example, I have the amazing Geosonics from Soniccouture, which is an almost unusable library that, once tweaked, is capable of amazing awesomeness. Clearly, the authors of both synths – but this is especially valid for BT Phobos I think – are looking at an audience that is capable of listening through the detuned and dissonant sound waves and shape a new form of music. This is probably the reason why so many of the pre assembled patches dive the user full speed into total sound design territory; however, and this is another important point of criticism, this is sound design that has already been done for you… A lot of the BT patches, in particular, are clearly BT patches, using them as they are means you are simply redoing something that has already been done before, and, despite with a very experimental feeling still strongly present, it’s not totally unheard or new. For example, I also happen to have Break Tweaker and Stutter Edit (tools that also originally come from BT), and I could not resist to the temptation to play something that resembles BT work on “This Binary Universe” or “_” (fantastic albums)! While this seems exciting – BT in a box! And you can also see the democratising aspect of BT Phobos, I can do that in half hour instead of six months of manual CSound programming! – it’s an unfortunate and artificial limitation on a tool that is otherwise a very powerful enabler, capable of bringing complex sound design one step closer to the general public. Having the ability to process your own sounds would mitigate this aspect I think. I do see how this is useful for a composer in need of a quick solution for an approaching deadline even with the most experimental tones, though: those patches can resolve a deadlock or take you out of an impasse in a second. The potential for BT Phobos to become a must have tool for sound design are all there, especially if Spitfire Audio keeps adding content, perhaps more varied (and even better, allow to load your own content). The ability to shape the existing sounds already make it very usable. I don’t think it’s a general tool at this stage, though, and definitely it should not be the first synth or sound shaping processor in your arsenal, especially if you are starting out now. But it’s not just a one trick pony either, it does offer you quite a lot of possibilities, and the more you work on that, the more addictive it becomes, and I can see Spitfire Audio offering soon this synth within a collection comprising of some of their more experimental stuff like LCO and Enigma, which would be very nice, indeed. It’s unfortunate that Spitfire Audio does not offer an evaluation period: contrary to most of their offering, BT Phobos needs time to be fully grasped and it’s all but immediate (well, unless you are happy with the default patches or you really just need to “get out of troubles” quickly, but be careful with that because the tax is on the originality), but it can, and does, evolve, as its convolutions do, over time and it can absolutely deliver total awesomeness if used correctly. Most patches are also usable out of the box, and especially by adding some reverb or doing some post processing with other tools, it’s possible to squeeze even more life out of them. Overall, I do recommend BT Phobos, is a wonderful, very addictive synthesiser. [Less]

[NOTE: This article talks about commercial products and contains links to them, I do not receive any money if you buy those tools, nor I work for or I am affiliated to any of those companies. The opinion expressed here are mine and the review is ... [More] subjective] This is my attempt at a review of Spitfire Audio BT Phobos. Before diving into the review, and since I know I will be critic particularly on some aspects, I think it’s fair to assess the plugin right away: BT Phobos is an awesome tool, make no mistakes. BT Phobos is a “polyconvolution” synthesiser. It is, in fact, the first “standalone” plugin produced by Spitfire Audio, which is one of the companies I respect the most when it comes to music production and sample based instruments. The term polyconvolution is used by the Spitfire Audio team to indicate the simultaneous use of three convolvers for four primary audio paths: you can send any amount of each of those four primary sources (numbered 1 to 4) outputs to each of the three convolution engines (named W, X and Y). Source material controls There is lot of flexibility in the mixing capabilities; there are, of course, separate dry/wet signal knobs that send a specific portion of the unprocessed source material to the “amplifier” module, control how much of the signal goes to the convolution circuits, and finally how much of each of the convolution engines applies to each of the source sound. This last bit is achieved by means of an interesting nabla shaped X/Y pad: by positioning the icon that represents the source module closer to a corner it’s possible activate just the convolution engine that represents that corner; for example, top left is the W engine, top right the X and bottom the Y. Manually moving the icon gradually introduces contributions from the other engines, and double clicking on the icon makes all convolvers contribute equally to the wet sound, by positioning them to the center of the nabla. The convolution mixer Finally, each convolver has a control that allows to change the output level of the convolution engine before it reaches its envelope shaper. Spitfire Audio has released a very interesting flow diagram that shows the signal path in detail, which is linked below for reference. BT Phobos signal path In addition to the controls just described, the main GUI has basic controls to tweak the source material with an ADSR envelope which is directly accessible below each of the main sound sources as well as the convolutions modules, but it’s possible to have access to more advanced settings by clicking on the number or the letter that identifies the module name. The advanced controls interface An example of such controls is the Hold parameter, which let the user adjust the time the sound is held at full level before entering the Decay phase of its envelope; another useful tool is the sampling and IR offset controls, which allow to tweak parameters like the starting point of the material or the quantisation and its Speed (the playback speed for the samples, and is a function of the host tempo); there is also a control to influence the general pitch of the sound; finally a simple but effective section is dedicated to filtering – although a proper EQ is missing – as well as panning and level adjustments. All those parameters are particularly important settings when using loops, but also contribute to shaping the sound with the pitched material, and can be randomised for interesting effects and artefacts generated from the entropy (you can just randomise the material selection only as opposed to all the parameters). Modulation is also present, of course, with various LFOs of various kind that can be used to modulate basically everything. You can access them either by clicking on the mappings toggle below the ADSR envelope of each section, or by using the advanced settings pages. The amount of tweaks that can be made to the material in both the source and the convolution engines is probably the most important aspect of BT Phobos, since it gives an excellent amount of freedom to create new sounds from what’s available, which is already a massive amount of content, and allows to build wildly different patches with a bit of work, but it’s definitely not straightforward and needs time to understand the combined effects that each setting has on the whole. Since the material is polyphonic, the Impulse Responses for the convolution are created on the fly, and in fact, one interesting characteristic of BT Phobos is that there is no difference between a material for the convolution engines and one for the source module,  both draw from the same pool of sounds. BT Phobos beautiful GUI There is a difference on the type of material though, where loop based samples are, well, looped (and tempo sync’ed), and their pitch does not change based on the key that triggers them (although you can still affect the general pitch of the sound with the advanced controls), “tonal” material are pitched and change following the midi notes. One note about the LFOs: the mappings are “per module”. In other words, it is possible to modulate almost every parameter inside a single module, be it one of the four input sources or one of the three convolution engines, but there seem to be no way to define a global mapping of some kind. For example, I found a very nice patch from Mr. Christian Henson (which incidentally made, at least in my opinion, the best and most balanced overall presets), and I noticed I could make it even more interesting by using the modulation wheel. I wanted to modulate the CC1 message with an LFO (in fact, ideally it would be even better to have access to a custom envelope, but BT Phobos doesn’t have any for modulation use), but I could not find a way to do that other than using Logic’s own Midi FX. I understand that MIDI signals are generated outside the scope of the plugin, but it would be fantastic to have the option of tweaking and modulate everything from within the synth itself. All the sources and convolvers can be assigned to separate parts of the keyboard by tweaking the mapper at the bottom of the GUI. It is not possible to map a sound to start from an offset in the keyboard controls – for example to play C1 on the keyboard but trigger C2, or any other note – but of course you can change the global pitch so this has effectively the same result, and as said before it can also be modulated with an LFO or via DAW automation, for more interesting effects. Keyboard mapping tool Indeed, the flexibility of the tool, and the number of options at disposal for tweaking the sounds are very impressive. Most patches are very nice and ready to be used as they are, and blend nicely with lots of disparate styles. Some patches are very specific though, and pose a challenge to be used. Generally, I would consider these as starting points for exploration, rather than “final”. When reading about BT Phobos in the weeks before its release many people asked whether you could add your own sound to it or not. It’s not possible, unfortunately. At first, I thought that wasn’t a limitation or a deal breaker. I still think it’s not a deal breaker, but I see the value added that BT Phobos has even just as a standalone synth, as opposed to recreate the same kind of signal path manually with external tools, to give your own content the “Phobos treatment”, which is something that is entirely possible of course, for example just with Alchemy and Space Designer (which are both included in MainStage, so you can get them for a staggering 30 euros if you are a Mac user, even if you don’t use Logic Pro X!), but of course, we would be trading away the immediacy that BT Phobos delivers. That, maybe, is my main criticism to this synth, and I hope Spitfire Audio turns BT Phobos into a fully fledged tool for sound design over time, maybe enabling access to spectral shaping in some form or another, so we can literally paint over (or paint away!) portions of the sound, which is something you can do with iZotope Iris or Alchemy and is a very powerful way to shape a sound and do sound design in general. Another thing that is missing is a sound effect module, although I don’t know how important that is, given that there are thousands of outstanding plugins that do all sort of effects from delay to chorus etc… And, in fact, many patches benefit for added reverb (I use Eventide Blackhole and found that works extremely well with BT Phobos, since it’s also prominently used for weird sound effects). But it may be interesting to play by putting some effects (including a more proper EQ section) in various places in the signal path, although it’s all too easy to generate total chaos from such experimentation, so it’s possible the Spitfire Audio simply thought to leave this option for another time and instead focus on a better overall experience. And there’s no arpeggiator! Really! The number of polyphonic voices can be altered. Spitfire Audio states that the synth tweaks the number of voices at startup to match the characteristics of your computer, but I can’t confirm that, since every change I do seems to remain, even if I occasionally hear some pop and cracks at higher settings. Nevertheless, the CPU usage is pretty decent unless you go absolutely crazy with the polyphony count. I also noted that the numbers effect the clarity of the sound. This is understandable since an higher count means more notes can be generated at the same time, which means more things are competing for the same spectrum, and things can become very confusing very quickly. On the other end, a lower polyphony count has a bad impact on how the notes are generated. I feel sometime that things just stop generating sound, which is counter intuitive and very disturbing, especially since it’s very easy to have a high polyphony count with all those sources and convolvers. Also to note is that, by nature, some patches have very wild difference in their envelopes and level settings, which means it’s all to easy to move from a quiet to a very loud patch just by clicking “next” (which is possible in Logic at least with the next/prev patch buttons on top of the plugin main frame). The synth does not stop the sound, nor does any attempt to fade from one sound to the next, instead, the convolutions simply keep working on the next sample in queue with the new settings! I still have to decide if this is cool or not, perhaps it’s not intentional, but I can see how this could be used to automate patch changes in some clever way during playback! And indeed, a was able to create a couple of interesting side effects just by changing between patches at the right time. More on the sounds. The amount of content is really staggering, and simply cycling through the patches does not make justice to this synth, at all! What BT Phobos wants is a user that spends time tweaking the patches and play with the source material to get the most out it, however it’s easy to see how limiting this may feel at the same time, particularly with the more esoteric and atonal sounds, and there’s certainly a limit on how good a wood stick convolved with an aluminium thin can may sound, so indeed some patches do feel repetitive at times, as the source material does. There are quite a few very similar drum loops for example, or various pitches “wind blowing into a pipe” kind of things. This is a problem common to other synths based on the idea of tweaking sounds from the environment, though. For example, I have the amazing Geosonics from Soniccouture, which is an almost unusable library that, once tweaked, is capable of amazing awesomeness. Clearly, the authors of both synths – but this is especially valid for BT Phobos I think – are looking at an audience that is capable of listening through the detuned and dissonant sound waves and shape a new form of music. This is probably the reason why so many of the pre assembled patches dive the user full speed into total sound design territory; however, and this is another important point of criticism, this is sound design that has already been done for you… A lot of the BT patches, in particular, are clearly BT patches, using them as they are means you are simply redoing something that has already been done before, and, despite with a very experimental feeling still strongly present, it’s not totally unheard or new. For example, I also happen to have Break Tweaker and Stutter Edit (tools that also originally come from BT), and I could not resist to the temptation to play something that resembles BT work on “This Binary Universe” or “_” (fantastic albums)! While this seems exciting – BT in a box! And you can also see the democratising aspect of BT Phobos, I can do that in half hour instead of six months of manual CSound programming! – it’s an unfortunate and artificial limitation on a tool that is otherwise a very powerful enabler, capable of bringing complex sound design one step closer to the general public. Having the ability to process your own sounds would mitigate this aspect I think. I do see how this is useful for a composer in need of a quick solution for an approaching deadline even with the most experimental tones, though: those patches can resolve a deadlock or take you out of an impasse in a second. The potential for BT Phobos to become a must have tool for sound design are all there, especially if Spitfire Audio keeps adding content, perhaps more varied (and even better, allow to load your own content). The ability to shape the existing sounds already make it very usable. I don’t think it’s a general tool at this stage, though, and definitely it should not be the first synth or sound shaping processor in your arsenal, especially if you are starting out now. But it’s not just a one trick pony either, it does offer you quite a lot of possibilities, and the more you work on that, the more addictive it becomes, and I can see Spitfire Audio offering soon this synth within a collection comprising of some of their more experimental stuff like LCO and Enigma, which would be very nice, indeed. It’s unfortunate that Spitfire Audio does not offer an evaluation period: contrary to most of their offering, BT Phobos needs time to be fully grasped and it’s all but immediate (well, unless you are happy with the default patches or you really just need to “get out of troubles” quickly, but be careful with that because the tax is on the originality), but it can, and does, evolve, as its convolutions do, over time and it can absolutely deliver total awesomeness if used correctly. Most patches are also usable out of the box, and especially by adding some reverb or doing some post processing with other tools, it’s possible to squeeze even more life out of them. Overall, I do recommend BT Phobos, is a wonderful, very addictive synthesiser. [Less]