Planet Classpath

I’m writing a replacement for libthread_db. It’s called Infinity.

Why? Because libthread_db is a pain in the ass for debuggers. GDB has to watch for inferiors loading thread libraries. It has to know that, for example, on GNU/Linux, when the inferior loads libpthread.so then GDB has to locate the corresponding libthread_db.so into itself and use that to inspect libpthread’s internal structures. How does GDB know where libthread_db is? It doesn’t, it has to search for it. How does it know, when it finds it, that the libthread_db it found is compatible with the libpthread the inferior loaded? It doesn’t, it has to load it to see, then unload it if it didn’t work. How does GDB know that the libthread_db it found is compatible with itself? It doesn’t, it has to load it and, erm, crash if it isn’t. How does GDB manage when the inferior (and its libthread_db) has a different ABI to GDB? Well, it doesn’t.

libthread_db means you can’t debug an application in a RHEL 6 container with a GDB in a RHEL 7 container. Probably. Not safely. Not without using gdbserver, anyway–and there’s no reason you should have to use gdbserver to debug what is essentially a native process.

So. Infinity. In Infinity, inspection functions for debuggers will be shipped as bytecode in ELF notes in the same file as the code they pertain to. libpthread.so, for example, will contain a bunch of Infinity notes, each representing some bit of functionality that GDB currently gets from libthread_db. When the inferior starts or loads libraries GDB will find the notes in the files it already loaded and register their functions. If GDB notices it has, for example, the full set of functions it requires for thread support then, boom, thread support switches on. This happens regardless of whether libpthread was dynamically or statically linked.

(If you’re using gdbserver, gdbserver gives GDB a list of Infinity functions it’s interested in. When GDB finds these functions it fires the (slightly rewritten) bytecode over to gdbserver and gdbserver takes it from there.)

Concrete things I have are: a bytecode format (but not the bytecode itself), an executable with a couple of handwritten notes (with some junk where the bytecode should be), a readelf that can decode the notes, a BFD that extracts the notes and a GDB that picks them up.

What I’m doing right now is rewriting a function I don’t understand (td_ta_map_lwp2thr) in a language I’m inventing as I go along (i8) that’ll be compiled with a compiler that barely exists (i8c) into a bytecode that’s totally undefined to be executed by an interpreter that doesn’t exist.

(The compiler’s going to be written in Python, and it’ll emit assembly language. It’s more of an assembler, really. Emitting assembler rather than going straight to bytecode simplifies things (e.g. the compiler won’t need to understand numbers!) at the expense of emitting some slightly crappy code (e.g. instruction sequences that add zero). I’m thinking GDB will eventually JIT the bytecode so this won’t matter. GDB will have to JIT if it’s to cope with millions of threads, but jitted Infinity should be faster than libthread_db. None of this is possible now, but it might be sooner than you thing with the GDB/GCC integration work that’s happening. Besides, I can think of about five different ways to make an interpreter skip null operations in zero time.)

Future applications for Infinity notes include the run-time linker interface.

Watch this space.

The first release candidate is finally available. It can be downloaded here or from NuGet.

What's New (relative to IKVM.NET 8.0):

  • Integrated OpenJDK 8u45.
  • Many fixes to late binding support.
  • Added ikvmc support for deterministic output files.
  • Various sun.misc.Unsafe improvements.
  • Many minor bug fixes and performance tweaks.

Changes since previous development snapshot:

  • Assemblies are strong named.
  • Fix for bug #303. ikvmc internal compiler error when trying to get interfaces from type from missing assembly reference.
  • Implemented NIO atomic file move on Windows.

Binaries available here: ikvmbin-8.1.5717.0.zip

Sources: ikvmsrc-8.1.5717.0.zip, openjdk-8u45-b14-stripped.zip

To debug live processes on modern Linux GDB needs four libthread_db functions:

  • td_ta_map_lwp2thr (required for initial attach)
  • td_thr_get_info (required for initial attach)
  • td_thr_tls_get_addr (not required for initial attach, but required for “p errno” on regular executables)
  • td_thr_tlsbase (not required for initial attach, but required for “p errno” for -static -pthread executables)

To debug a corefile on modern Linux GDB needs one more libthread_db function:

  • td_ta_thr_iter

GDB makes some other libthread_db calls too, but these are bookkeeping that won’t be required with the replacement. So, the order of work will be:

  1. Implement replacements for the four core functions.
  2. Get those approved and committed in GDB, BFD and glibc (and in binutils, coreutils readelf).
  3. Replace td_ta_thr_iter too, and get that committed.
  4. Implement runtime-linker interface stuff to allow GDB to follow dlmopen.

The first (non-bookkeeping) function GDB calls is td_ta_map_lwp2thr and it’s a pig. If I can do td_ta_map_lwp2thr I can do anything.

When you call it, td_ta_map_lwp2thr has four ways it can proceed:

  1. If __pthread_initialize_minimal has not gotten far enough we can’t rely on whatever’s in the thread registers. If this is the case, td_ta_map_lwp2thr checks that the LWP is the initial thread and sets th->th_unique to NULL. (Other bits of libthread_db spot this NULL and act accordingly.) td_ta_map_lwp2thr decides whether __pthread_initialize_minimal has gotten far enough by examining __stack_user.next in the inferior. If it’s NULL then __pthread_initialize_minimal has not gotten far enough.
  2. On ta_howto_const_thread_area architectures (x86_64, aarch64, arm)
    [glibc/sysdeps/*/nptl/tls.h has
      #define DB_THREAD_SELF CONST_THREAD_AREA(bits, value)
    which exports
      const uint32_t _thread_db_const_thread_area = value;
    from glibc/nptl_db/db_info.c]:

    • td_ta_map_lwp2thr will call ps_get_thread_area with value

    to set th->th_unique.

    ps_get_thread_area (in GDB) does different things for different
    architectures:

    1. on x86_64, value is a register number (FS or GS)
      ps_get_thread_area returns the contents of that register.
    2. on arm, GDB uses PTRACE_GET_THREAD_AREA, NULL and subtracts value from the result.
    3. on aarch64, GDB uses PTRACE_GETREGSET, NT_ARM_TLS and subtracts value from the result.
  3. On ta_howto_reg architectures (ppc*, s390*)
    [glibc/sysdeps/*/nptl/tls.h has
      #define DB_THREAD_SELF REGISTER(bits, size, regofs, bias)...
    which exports
      const uint32_t _thread_db_register32[3] = {size, regofs, bias};
    and/or
      const uint32_t _thread_db_register64[3] = {size, regofs, bias};
    from glibc/nptl_db/db_info.c]:

    td_ta_map_lwp2thr will:

    • call ps_lgetregs to get the inferior’s registers
    • get the contents of the specified register (with _td_fetch_value_local)

        and

    • SUBTRACT bias from the register’s contents

    to set th->unique.

  4. On ta_howto_reg_thread_area architectures (i386)
    [glibc/sysdeps/*/nptl/tls.h has
      #define DB_THREAD_SELF REGISTER_THREAD_AREA(bits, size, regofs, bias)...
    which exports
      const uint32_t _thread_db_register32_thread_area[3] = {size, regofs, bias};
    and/or
      const uint32_t _thread_db_register64_thread_area[3] = {size, regofs, bias};
    from glibc/nptl_db/db_info.c]:

    td_ta_map_lwp2thr will:

    • call ps_lgetregs to get the inferior’s registers
    • get the contents of the specified register (with _td_fetch_value_local)
    • RIGHT SHIFT the register’s contents by bias

        and

    • call ps_get_thread_area with that number

    to set th->unique.

    ps_get_thread_area (in GDB) does different things for different
    architectures:

    1. on i386, GDB uses PTRACE_GET_THREAD_AREA, VALUE and returns the second element of the result.

Cases 2, 3, and 4 will obviously be hardwired into the specific architecture’s libpthread. But… yeah.

There is a nice profile of me on the Java Magazine of this bimestre, and I am very flattened for this so let me share it right away with you.

There is one question I was expecting though but didn’t come: “When did you start working on Java?”.

So, in order to give some more context, let me play with it and answer my own question here (and without space limits!). I think this is important, because it is about how I started to contribute to OpenJDK, it shows that you can do the same… if you are patient.

JM: When did you start working on Java?

Torre: I started to work in Java around its 1.3 release, and I used it ever since. I did start working on Java quite later though, around the Java 1.5/1.6 era probably. I was working to create an MSN messenger clone in Java on my Linux box, since all my friends where using it (MSN I mean, not Linux unfortunately), including the dreaded emoticons, and no Linux client supported those at the time.

I had all the protocol stuff working, I could handshake and share messages (although I still had to figure out the emoticons part!), but I had a terrible problem. I needed to save user credentials. Well, Java has a fantastic Preferences API, easy enough, right? Except that what I was using wasn’t the proprietary JDK, it was the Free Software version of it: GNU Classpath.

Classpath at the time didn’t have Preferences support, so I was stuck. I think somebody was writing a filesystem based preferences, or perhaps it was in Classpath but not GCJ, which is what everybody was using as a VM with the Classpath library, anyway when I started to look at the problem, I realised it would have been nicer to offer a GConf based Preferences store, and integrate the whole thing into the Gnome desktop (at the time, Gnome was a great desktop, nothing like today’s awfulness).

I was hooked. In fact, I even never finished my MSN messenger! After GConf, all sort of stuff came in, Decimal Formatter, GStreamer Sound backend, various fixes here and here, and this is when I learned a lot of how Swing works internally by following Sven de Marothy, Roman Kennke and David Gilbert work.

When Sun was about to release OpenJDK, I was in that very first group and witnessed the whole thing, a lot of behind the scenes of the creation of this extremely important code contribution. OpenJDK license is “GPL + Classpath exception” for a reason. I remember all the heroes that made Java Free Software.

I guess I was lucky, and the timing was perfect.

However right at the beginning contributing actual code to OpenJDK wasn’t at all easy like in Classpath. There was (is!) lot of process, things took a lot of time for anything but the most trivial changes etc…

But eventually I insisted and me and Roman where the first external guys to have code landing in the JDK, Roman was, I believe, the first independent person to have commit rights (I think that the people that are still today in my team at Red Hat and then also SAP had some changes already in, but at the time we two were the only guys completely external).

It wasn’t easy, I had to challenge ourselves and push a lot, and not give up. I had to challenge Sun, and even more challenge Oracle when it took the lead. But I did it. This is what I mean that everybody can do it, you can develop the skills and then you need to build the trust and then not let it go. I’m not sure what is more complex here, but if you persist it eventually come. And then all of a sudden billions of people will use your code and you are a Java Champion.

So this is how it started.


The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as a PulseAudio sound driver, the ability to build against system libraries and support for alternative virtual machines and architectures beyond those supported by OpenJDK.

This release updates our OpenJDK 6 support in the 1.13.x series with the July 2015 security fixes.

If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place on the distro-pkg-dev OpenJDK mailing list and patches are always welcome.

Full details of the release can be found below.

Please Note: This release includes a backport of jdk.tls.ephemeralDHKeySize which changes the default for Diffee-Hellman ephemeral keys to 1024-bit (CVE-2015-4000). To use the previous default (768-bit keys), pass -Djdk.tls.ephemeralDHKeySize=legacy on the command-line. All current releases of IcedTea 1.x and 2.x, along with OpenJDK 8, allow the use of “matched” mode which creates an ephemeral DH key matching the size of the authentication key, or the specification of an explicit key size between 1024 and 2048 bits inclusive (e.g. -Djdk.tls.ephemeralDHKeySize=1536).

What’s New?

New in release 1.13.8 (2015-07-29)

  • Security fixes
  • Import of OpenJDK6 b36
    • OJ58: Allow OpenJDK to build on PaX-enabled kernels
    • OJ59: Only apply PaX-marking when needed by a running PaX kernel
    • OJ61: Remove translation strings for ErrorMsg.JAXP_INVALID_ATTR_VALUE_ERR which doesn’t exist in OpenJDK 6
    • OJ62, PR2552: Restrict key size of RSA certificates to >= 1024
    • OJ63: Remove @Override annotation on interfaces added by 2015/07/14 security fixes.
    • S6787645: CRL validation code should permit some clock skew when checking validity of CRLs
    • S6996365: Evaluate the priorities of cipher suites
    • S7185471: Avoid key expansion when AES cipher is re-init w/ the same key
    • S8007142: Add utility classes for writing better multiprocess tests in jtreg
    • S8008089: Delete OS dependent check in JdkFinder.getExecutable()
    • S8024861: Incomplete token triggers GSS-API NullPointerException
    • S8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector
    • S8036786: Update jdk7 testlibrary to match jdk8
    • S8042205: javax/management/monitor/*: some tests didn’t get all the notifications
    • S8042982: Unexpected RuntimeExceptions being thrown by SSLEngine
    • S8043200, PR2485: Decrease the preference mode of RC4 in the enabled cipher suite list
    • S8043201: Deprecate RC4 in SunJSSE provider
    • S8046817: JDK 8 schemagen tool does not generate xsd files for enum types
    • S8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred
    • S8050158: Introduce system property to maintain RC4 preference order
    • S8062923: XSL: Run-time internal error in ‘substring()’
    • S8062924: XSL: wrong answer from substring() function
    • S8064546: CipherInputStream throws BadPaddingException if stream is not fully read
    • S8065764: javax/management/monitor/CounterMonitorTest.java hangs
    • S8066952: [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs
    • S8073357: schema1.xsd has wrong content. Sequence of the enum values has been changed
    • S8073385: Bad error message on parsing illegal character in XML attribute
    • S8074098: 2D_Font/Bug8067699 test fails with SIGBUS crash on Solaris Sparc
    • S8074297: substring in XSLT returns wrong character if string contains supplementary chars
    • S8075575: com/sun/security/auth/login/ConfigFile/InconsistentError.java failed in certain env.
    • S8075576: com/sun/security/auth/module/KeyStoreLoginModule/OptionTest.java failed in certain env.
    • S8075667: (tz) Support tzdata2015b
    • S8076290: JCK test api/xsl/conf/string/string17 starts failing after JDK-8074297
    • S8077685: (tz) Support tzdata2015d
    • S8078348: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with BindException
    • S8078439: SPNEGO auth fails if client proposes MS krb5 OID
    • S8078666, PR2327: JVM fastdebug build compiled with GCC 5 asserts with “widen increases”
    • S8080318: jdk8u51 l10n resource file translation update
    • S8081386: Test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh test has RC4 dependencies
    • S8081775: two lib/testlibrary tests are failing with “Error. failed to clean up files after test” with jtreg 4.1 b12
  • Backports
    • S4890063,PR2306, RH1214835: HPROF: default text truncated when using doe=n option
    • S6562614, PR2555: Compiler warnings for gettimeofday in Inet4/Inet6AddressImpl.c
    • S6956398, PR2486: make ephemeral DH key match the length of the certificate key
    • S6989466, PR2555: Miscellaneous compiler warnings in java/lang, java/util, java/io, sun/misc native code
    • S6991580, PR2309: IPv6 Nameservers in resolv.conf throws NumberFormatException
    • S6997561, PR2479: A request for better error handling in JNDI
    • S7007905, PR2298: javazic produces wrong line numbers
    • S7017176, PR2479: Several JNDI tests are mssing GPL header
    • S7058708, PR2298: Eliminate JDK build tools build warnings
    • S7069870, PR2298: Parts of the JDK erroneously rely on generic array initializers with diamond
    • S7090844, PR2298: Support a timezone whose offset is changed more than once in the future
    • S7094377, PR2479: Com.sun.jndi.ldap.read.timeout doesn’t work with ldaps.
    • S7133138, PR2298: Improve io performance around timezone lookups
    • S7170638, PR2495: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
    • S8000487, PR2479: Java JNDI connection library on ldap conn is not honoring configured timeout
    • S8011709, PR2510: [parfait] False positive: memory leak in jdk/src/share/native/sun/font/layout/CanonShaping.cpp
    • S8023052, PR2510: JVM crash in native layout
    • S8039921, PR2468: SHA1WithDSA with key > 1024 bits not working
    • S8041451, PR2480: com.sun.jndi.ldap.Connection:ReadTimeout should abandon ldap request
    • S8042855, PR2510: [parfait] Potential null pointer dereference in IndicLayoutEngine.cpp
    • S8042857, PR2479: 14 stuck threads waiting for notification on LDAPRequest
    • S8065238, PR2479: javax.naming.NamingException after upgrade to JDK 8
    • S8074761, PR2469: Empty optional parameters of LDAP query are not interpreted as empty
    • S8078654, PR2334: CloseTTFontFileFunc callback should be removed
    • S8081315, PR2406: Avoid giflib interlacing workaround with giflib 5.0.0 on
    • S8081475, PR2495: SystemTap does not work when JDK is compiled with GCC 5
    • S8087120, RH1206656, PR2554: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms.
  • Bug fixes
    • PR2319: Checksum of policy JAR files changes on every build
    • PR2340: Fail early if there is no native HotSpot JIT & all other options are disabled
    • PR2342: Update README & INSTALL files
    • PR2360: Ensure all stamp targets have aliases
    • PR2391: Make elliptic curve removal optional
    • PR2460: Policy JAR files should be timestamped with the date of the policy file they hold
    • PR2481, RH489586, RH1236619: OpenJDK can’t handle spaces in zone names in /etc/sysconfig/clock
    • PR2486: JSSE server is still limited to 768-bit DHE
    • PR2508, G541462: Only apply PaX markings by default on running PaX kernels
    • PR2556, G390663: Update Gentoo font configuration and allow font directory to be specified
    • PR2559: generated directory gets confused with generated alias
    • PR2565: Replace ipv4-mapped-ipv6-addresses.patch with upstream fix 6882910
  • CACAO
    • PR829: Raise javadoc and JAVAC_FLAGS memory limits for CACAO
  • JamVM
    • PR2522: Add executable stack markings to callNative.S on JamVM

The tarballs can be downloaded from:

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:

  • PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
  • Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

I’m transitioning to the use of a new key for signing releases over the next year. Signatures made with this key are available at:

and the new key is:

  • PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
  • Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

GnuPG >= 2.1 is required to be able to handle this newer key.

SHA256 checksums:

  • 05fd1584e458ddaaf1d464842431dbcbcbaf7f9ef9f92f9cebaa180ccbbc5d1b icedtea6-1.13.8.tar.gz
  • 27fe15966c69d40f3ccec392b6725aafe81fcbd14fd698067a46eff23cb94620 icedtea6-1.13.8.tar.gz.sig
  • 1af0e21b109b58d27ce063696b42f1cdded0f829f51440f716540bec138355ed icedtea6-1.13.8.tar.gz.sig.ec
  • fcbc623957e393a00d6189cb88288fed21c21860485092ea7719a12fbbc00adb icedtea6-1.13.8.tar.xz
  • 95dad7fbcb133e461e557fbe343f0cf27aeb2972cce58ad9184c71e0bc9431c1 icedtea6-1.13.8.tar.xz.sig
  • 2b4f32188d5631c0bc3f0168099cd903b09f7b6832b82c2060b6b8003de1567c icedtea6-1.13.8.tar.xz.sig.ec

The checksums can be downloaded from:

A 1.13.8 ebuild for Gentoo is available.

The following people helped with these releases:

  • James Le Cuirot (PR829 CACAO work)
  • Andrew Hughes (all backports and other bug fixes, release management)

We would also like to thank the bug reporters and testers!

To get started:

$ tar xzf icedtea6-1.13.8.tar.gz

or:

$ tar x -I xz -f icedtea6-1.13.8.tar.xz

then:

$ mkdir icedtea-build
$ cd icedtea-build
$ ../icedtea6-1.13.8/configure
$ make

Full build requirements and instructions are available in the INSTALL file.

Happy hacking!

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 architectures beyond those supported by OpenJDK.

This release updates our OpenJDK 7 support in the 2.5.x series with the July 2015 security fixes. This is the last release in the 2.5.x series.

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.

Please Note: The backport of jdk.tls.ephemeralDHKeySize now defaults to 1024-bit keys (CVE-2015-4000). To use the previous default (768-bit keys), pass -Djdk.tls.ephemeralDHKeySize=legacy on the command-line. Both OpenJDK 7 & 8 allow the use of “matched” mode which creates an ephemeral DH key matching the size of the authentication key, or the specification of a key size between 1024 and 2048 bits inclusive.

What’s New?

New in release 2.5.6 (2015-07-22)

  • Security fixes
  • Backports
    • S4890063, PR2305, RH1214835: HPROF: default text truncated when using doe=n option
    • S6991580, PR2308: IPv6 Nameservers in resolv.conf throws NumberFormatException
    • S7124253: [macosx] Flavor change notification not coming
    • S8007219: [macosx] Frame size reverts meaning of maximized attribute if frame size close to display
    • S8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow
    • S8020210: [macosx] JVM crashes in CWrapper$NSWindow.screen(long)
    • S8021120, PR2301: TieredCompilation can be enabled even if TIERED is undefined
    • S8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector
    • S8027561: [macosx] Cleanup “may not respond to selector” warnings in native code
    • S8029607, PR2418: Type of Service (TOS) cannot be set in IPv6 header
    • S8029868: Fix KSS issues in sun.lwawt.macosx
    • S8039921, PR2421: SHA1WithDSA with key > 1024 bits not working
    • S8042205: javax/management/monitor/*: some tests didn’t get all the notifications
    • S8042982: Unexpected RuntimeExceptions being thrown by SSLEngine
    • S8043201: Deprecate RC4 in SunJSSE provider
    • S8043129, PR2338: JAF initialisation in SAAJ clashing with the one in javax.mail
    • S8046817: JDK 8 schemagen tool does not generate xsd files for enum types
    • S8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred
    • S8048212, PR2418: Two tests failed with “java.net.SocketException: Bad protocol option” on Windows after 8029607
    • S8048214, PR2357: Linker error when compiling G1SATBCardTableModRefBS after include order changes
    • S8062923: XSL: Run-time internal error in ‘substring()’
    • S8062924: XSL: wrong answer from substring() function
    • S8064546: CipherInputStream throws BadPaddingException if stream is not fully read
    • S8065238, PR2478: javax.naming.NamingException after upgrade to JDK 8
    • S8065764: javax/management/monitor/CounterMonitorTest.java hangs
    • S8066952: [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs
    • S8071668: [macosx] Clipboard does not work with 3rd parties Clipboard Managers
    • S8072385, PR2387: Only the first DNSName entry is checked for endpoint identification
    • S8073357: schema1.xsd has wrong content. Sequence of the enum values has been changed
    • S8073385: Bad error message on parsing illegal character in XML attribute
    • S8074098: 2D_Font/Bug8067699 test fails with SIGBUS crash on Solaris Sparc
    • S8074297: substring in XSLT returns wrong character if string contains supplementary chars
    • S8074761, PR2470: Empty optional parameters of LDAP query are not interpreted as empty
    • S8075575: com/sun/security/auth/login/ConfigFile/InconsistentError.java failed in certain env.
    • S8075576: com/sun/security/auth/module/KeyStoreLoginModule/OptionTest.java failed in certain env.
    • S8075667: (tz) Support tzdata2015b
    • S8076290: JCK test api/xsl/conf/string/string17 starts failing after JDK-8074297
    • S8077685: (tz) Support tzdata2015d
    • S8078348: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with BindException
    • S8078439: SPNEGO auth fails if client proposes MS krb5 OID
    • S8078562: Add modified dates
    • S8078654, PR2333: CloseTTFontFileFunc callback should be removed
    • S8078666, PR2326: JVM fastdebug build compiled with GCC 5 asserts with “widen increases”
    • S8080318: jdk8u51 l10n resource file translation update
    • S8081315, PR2405: Avoid giflib interlacing workaround with giflib 5.0.0 on
    • S8081386: Test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh test has RC4 dependencies
    • S8081475, PR2494: SystemTap does not work when JDK is compiled with GCC 5
    • S8081775: two lib/testlibrary tests are failing with “Error. failed to clean up files after test” with jtreg 4.1 b12
    • S8087120, RH1206656, PR2553: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms.
    • S8133970: Only apply PaX-marking when needed by a running PaX kernel
    • S8133990: Revert introduction of lambda expression in sun.lwawt.macosx.LWCToolkit
    • S8133991: Fix mistake in 8075374 backport
  • Bug fixes
    • PR2328: GCJ uses ppc64el named libarch directory on ppc64le
    • PR2341: Update README & INSTALL files
    • PR2367: 7 no longer builds with 6 – Util is not public in sun.management
    • PR2390: Make elliptic curve removal optional
    • PR2395: Path to jvm.cfg is wrong in add-systemtap-boot
    • PR2458: Policy JAR files should be timestamped with the date of the policy file they hold
    • PR2482, RH489586, RH1236619: OpenJDK can’t handle spaces in zone names in /etc/sysconfig/clock
    • PR2499: Update remove-intree-libraries.sh script
    • PR2502: Remove -fno-tree-vectorize workaround now http://gcc.gnu.org/PR63341 is fixed
    • PR2507, G541462: Only apply PaX markings by default on running PaX kernels
  • CACAO
    • PR2380: Raise javadoc and JAVAC_FLAGS memory limits for CACAO
  • JamVM
    • PR2500: Add executable stack markings to callNative.S on JamVM
  • AArch64 port
    • Changes to make aix compile after the merge
    • S8025613, PR2437: clang: remove -Wno-unused-value
    • S8035938: Memory leak in JvmtiEnv::GetConstantPool
    • S8058113: Execution of OnOutOfMemoryError command hangs on linux-sparc
    • S8068674: Increment minor version of HSx for 7u85 and initialize the build number
    • S8069593: Changes to JavaThread::_thread_state must use acquire and release
    • S8071423: Increment hsx 24.80 build to b08 for 7u80-b07
    • S8071807: Increment hsx 24.80 build to b09 for 7u80-b08
    • S8072639: Increment hsx 24.80 build to b10 for 7u80-b09
    • S8074349: AARCH64: C2 generates poor code for some byte and character stores
    • S8075045: AARCH64: Stack banging should use store rather than load
    • S8075136: Unnecessary sign extension for byte array access
    • S8075324: Costs of memory operands in aarch64.ad are inconsistent
    • S8075443: AARCH64: Missed L2I optimizations in C2
    • S8075930: AARCH64: Use FP Register in C2
    • S8076212, PR2314: AllocateHeap() and ReallocateHeap() should be inlined.
    • S8076467: AARCH64: assertion fail with -XX:+UseG1GC
    • S8078529: Increment the build value to b02 for hs24.85 in 8u85
    • S8079203: AARCH64: Need to cater for different partner implementations
    • S8080586: aarch64: hotspot test compiler/codegen/7184394/TestAESMain.java fails
    • S8081622: Increment the build value to b03 for hs24.85 in 8u51
  • PPC & AIX port
    • S8069590: AIX port of “8050807: Better performing performance data handling”
    • S8078482, PR2307: ppc: pass thread to throw_AbstractMethodError
    • S8080190: PPC64: Fix wrong rotate instructions in the .ad file

The tarballs can be downloaded from:

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:

These are produced using my public key. See details below.

  • PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
  • Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

I’m transitioning to the use of a new key for signing releases over the next year. Signatures made with this key are available at:

and the new key is:

  • PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
  • Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

GnuPG >= 2.1 is required to be able to handle this newer key.

SHA256 checksums:

  • 055fccbb0e5f25382c89d1bd71d50a5a34ffae32859375bb3dcc048a98ef4726 icedtea-2.5.6.tar.gz
  • e4caa7def2561918e79e5778ec9f793ed0a28fc4cafd10675fa1ed7d7133f032 icedtea-2.5.6.tar.gz.sig
  • 2f0bab310ad177669a0724aa1b0fc32094ff435e8afd930f9d132e505ab99543 icedtea-2.5.6.tar.gz.sig.ec
  • bb3c7e9fd372c737849d9d3129d935174492a0d924a2801223c822426338b8c4 icedtea-2.5.6.tar.xz
  • e5b4f9c7890051c3e209c3dd606e8da0d74e215c05d08369cf19cbdd6e57a4d5 icedtea-2.5.6.tar.xz.sig
  • ac4ed71aed0ade86a3253aae8f52f9e1e651237e5a1ae4dddfe216c58495be51 icedtea-2.5.6.tar.xz.sig.ec

The checksums can be downloaded from:

A 2.5.6 ebuild for Gentoo is available.

The following people helped with these releases:

  • James Le Cuirot (PR2380 CACAO work)
  • Tiago Sturmer Diatx (PR2328 ppc64le work)
  • Andrew Dinn (AArch64 integration work)
  • Andrew Hughes (all other backports & bug fixes, release management)
  • Omair Majid (OJ05)

We would also like to thank the bug reporters and testers!

To get started:

$ tar xzf icedtea-2.5.6.tar.gz

or:

$ tar x -I xz -f icedtea-2.5.6.tar.xz

then:

$ mkdir icedtea-build
$ cd icedtea-build
$ ../icedtea-2.5.6/configure
$ make

Full build requirements and instructions are available in the INSTALL file.

Happy hacking!

Processing 3 is running for the first time on a Raspberry Pi using Eric Anholt's Mesa3D VC4 driver!

Video of the Processing 3 RGB cube demo running on the Raspberry Pi using Eric Anholt's Mesa3D VC4 OpenGL 2 driver:
http://labb.zafena.se/jogamp/vc4/video20150710_113912325.mp4

Thanks to the free software Mesa3d vc4 driver, the raspberry pi suddenly turned from a mobile opengl es 2 system into a "desktop" opengl 2 system.

Processing 3 is using JogAmp JOGL to tap into OpenGL hardware acceleration on the armv6 Raspberry Pi 1 and armv7 RaspberryPi 2 systems.

Hold on what is going on here, how can I setup the free software vc4 driver on my Raspberry Pi system?

This is a collaboration with Eric Anholt, anholt, and Gottfried Haider, gohai, to get Processing 3 running on the Raspberry Pi.

Eric Anholt has worked about a year to implement a full OpenGL 2 Mesa3D driver for use on the Raspberry Pi by using the Video Core 4, VC4, GPU.
http://anholt.livejournal.com/

Getting Eric Anholt's Mesa3D VC4 driver running on a Raspberry Pi is easily done thanks to the work by gohai.
gohai started out roughly following Eric's notes here: http://dri.freedesktop.org/wiki/VC4/
And then put together a buildbot in Python, to produce system images for use on the Pi or Pi2.

Kernel, Mesa, XServer packages & dependencies are from git. System image produced using gohai's buildbot
https://github.com/gohai/vc4-buildbot

gohai publish daily builds using his bot at:
http://sukzessiv.net/~gohai/vc4-buildbot/build/

Myself I have contributed to fix corner-cases in JogAmp JOGL OpenGL initialization to get it all running.

What was the problem using the proprietary OpenGL ES vc4 driver on the Raspberry Pi system?

The OpenGL ES standard do not cover how the native window is initialized.
When you initialize opengl es then you must pass a platform specific EGLNativeWindowType, EGLNativePixmapType and EGLNativeDisplayType depending on the OS you use.

If you read the Khronos header for eglplatform.h you will notice that the EGLNativeWindowType is different for
Windows: typedef HWND EGLNativeWindowType;
Mac: typedef void *EGLNativeWindowType;
Android: typedef struct ANativeWindow* EGLNativeWindowType;
Unix X11: typedef Window EGLNativeWindowType;

Creating an on-screen EGL rendering surface requires you to to use the eglCreateWindowSurface function, which takes a EGLNativeWindowType parameter. On the Raspberry Pi, however this is implemented as a EGL_DISPMANX_WINDOW_T struct, which is defined in eglplatform.h as:

typedef struct {
DISPMANX_ELEMENT_HANDLE_T element;
int width; /* This is necessary because dispmanx elements are not queriable. */
int height;
} EGL_DISPMANX_WINDOW_T;

As you can see RaspberryPi using the properitary binary drivers uses a Broadcom unique native window type that is incompatible with X11.
This is the reason why we cant use the Processing code as is to pass a Java AWT Unix X11 Window to initialize OpenGL ES, EGL will return an error that you have passed an incompatible structure to eglCreateWindowSurface.

When using Eric Anholt's Mesa3D vc4 driver then EGL will expect a Unix X11 Window for its EGLNativeWindowType and this is why processing will work out of the box when Erics Mesa3D vc4 driver in use. Eric's vc4 driver also implements OpenGL 2 that can be initialized using GLX. GLX allows you to run Processing with OpenGL acceleration across remote X11 network connections!

Cheers
Xerxes Rånby

Final 8.1 development snapshot. Release candidate 0 will be next (after .NET 4.6 RTM).

Changes:

  • Updated HOWTO reference to OpenJDK 8u45.
  • Extract Windows version from kernel32.dll to avoid version lie. Idea stolen from OpenJDK.
  • Moved unused field removal optimization to a later stage in the compilation.
  • Made field removal optimization check more strict to only remove final fields and not remove fields that have annotations.
  • Added support for automatically passing in fields to "native" methods.
  • Various minor clean ups.
  • Added FieldWrapper.IsSerialVersionUID property to properly (and consistently) detect serialVersionUID fields.
  • Improved side effect free static initializer detection.
  • Improved -removeassertions ikvmc optimization to remove more code (esp. allow otherwise empty static initializers to be optimized away).

Binaries available here: ikvmbin-8.1.5666.zip

Just a couple of days ago I found out that some of my favourite musicians decided to join together to release an album, and allowed to preorder it on a crowdfunding website, Music Raiser.

The name of the band is “O.R.k.” and the founders are none but Lef, Colin Edwin, Pat Mastelotto and Carmelo Pipitone.

You probably have heard their names, if not, Colin Edwin is the bassist from Porcupine Tree while Carmelo Pipitone is the gifted guitarist from Marta Sui Tubi, an extremely original Italian band, they probably did the most interesting things in Italian music in the last 15 years or so; Lef, aka Lorenzo Esposito Fornasari, has done so many things that is quite hard to pick just one, but in Metal community he is probably best know for Obake. Finally, Pat Mastelotto is the drummer of King Crimson, and this alone made me jump on my seat!

One of the pre-order bonus was the ability to participate to a Remix Contest, and although I only got the stems yesterday in the late morning I could not resist to at least give it a try, and it’s a great honour for me that they have put my attempt on their Youtube channel:

It’s a weird feeling editing this music, after all, who am I to cut and remix and change the drum part (King Crimson, please forgive me!), how I ever dare to touch the guitars and voice, or rearrange the bass!? :)

But indeed it was a really fun experience, and I hope to be able do this again in the future.

And who knows, maybe they even like how I messed up their art and they decide to put me on their album! Nevertheless, it has been already a great honour for me to be able to see this material in semi-raw form (and a very interesting one!), so this has been already my first prize.

I’m looking forward now to listen the rest of the album!


In firefox development, it’s normal to do most development tasks via the mach command. Build? Use mach. Update UUIDs? Use mach. Run tests? Use mach. Debug tests? Yes, mach mochitest --debugger gdb.

Now, normally I run gdb inside emacs, of course. But this is hard to do when I’m also using mach to set up the environment and invoke gdb.

This is really an Emacs bug. GUD, the Emacs interface to all kinds of debuggers, is written as its own mode, but there’s no really great reason for this. It would be way cooler to have an adaptive shell mode, where running the debugger in the shell would magically change the shell-ish buffer into a gud-ish buffer. And somebody — probably you! — should work on this.

But anyway this is hard and I am lazy. Well, sort of lazy and when I’m not lazy, also unfocused, since I came up with three other approaches to the basic problem. Trying stuff out and all. And these are even the principled ways, not crazy stuff like screenify.

Oh right, the basic problem.  The basic problem with running gdb from mach is that then you’re just stuck in the terminal. And unless you dig the TUI, which I don’t, terminal gdb is not that great to use.

One of the ideas, in fact the one this post is about, since this post isn’t about the one that I couldn’t get to work, or the one that is also pretty cool but that I’m not ready to talk about, was: hey, can’t I just attach gdb to the test firefox? Well, no, of course not, the test program runs too fast (sometimes) and racing to attach is no fun. What would be great is to be able to pre-attach — tell gdb to attach to the next instance of a given program.

This requires kernel support. Once upon a time there were some gdb and kernel patches (search for “global breakpoints”) to do this, but they were never merged. Though hmm! I can do some fun kernel stuff with SystemTap…

Specifically what I did was write a small SystemTap script to look for a specific exec, then deliver a SIGSTOP to the process. Then the script prints the PID of the process. On the gdb side, there’s a new command written in Python that invokes the SystemTap script, reads the PID, and invokes attach. It’s a bit hacky and a bit weird to use (the SIGSTOP appears in gdb to have been delivered multiple times or something like that). But it works!

It would be better to have this functionality directly in the kernel. Somebody — probably you! — should write this. But meanwhile my hack is available, along with a few other gdb scxripts, in my gdb helpers github repository.

I use Emacs Unified Directory Client (EUDC) for completing email addresses from LDAP and BBDB databases. It’s nice to be able to complete names from LDAP when composing emails, obviously, but it’s also nice in Org mode to M-x eudc-expand-inline someone’s name into my notes.

When I first configured the EUDC LDAP backend for my environment — RHEL 6 ldapsearch, LDAP-over-SSL server — setup was very involved. There were lots of poor defaults, strange extra configuration files, function call requirements, and ldapsearch incompatibilities. EmacsWiki instructions were very long just to get sane “Givenname Surname <email@address>” completion in GNUS.

I filed a bug report with configuration simplifications, bug fixes and EUDC Info manual updates, and somehow I ended up as the EUDC maintainer. I’ve committed the improvements to the Emacs master branch; they’ll be released in Emacs 25.

If you’ve tried EUDC in the past and been turned off by its arcane configuration, you might want to re-read the “LDAP Configuration” section of the Info manual, and try again. If you still can’t get it working, file a bug report at bug-gnu-emacs and I’ll try to respond to it within a few days. Mention EUDC or LDAP in the subject of the report. Likewise, if you do get it working with hacks then let me know via a bug report.

I'll be back in May in Kraków to speak at GeeCON - this time about JDK 9.

See you there!
I am pleased to announce that after months of work a new release of GNUstep's IRC client, TalkSoup, is ready!
Being essentially abandoned the last released sources (alpha version)have been  imported some time ago in GAP with Andrew's consent. I also merged in some enhancements from the GIT repository code.

This new release was really started because the original code was not working at all anymore, it did not compile on certain platforms and elsewhere it crashed really often.

  • Very important Crash fixes due to Strings vs AttributedStrings
  • Native XCode port to Mac (both PPC and x86 do work), no GNUstep makefiles necessary
  • Memory leaks and fixes as recognized by clang's static analyzer
  • Tweaks to the user interface
  • Import and addition of the IGNORE plugin
  • Fixes to work on current GNUstep runtime and on MacOS
  • Preference fields send action on end editing, not enter
  • Install plugins locally inside Application resources with .bundle extension
  • Fixed myriads of crashes due to code using "id" instead of an explicit type and thus picking up the wrong methods
  • 64bit fixes with NSInteger/NSUInteger

Due to the change of plugin placement, you may need to delete your defaults.

Check more on it's GNUstep Appliction Project page, where you can download it or go to the savannah project page and learn how to check out the SVN sources.

Here the most classic and nostalgic setup: my iBook running Debian (without evil systemd) and the classic GNUstep theme and WindowMaker. Works fine!


Here instead on my other iBook, still running MacOS. Do you see some similarity? Although TalkSoup did run in the past on Mac, this is a native XCode build. Having it run on my ol' clamshell makes me feel cozy.


And something less common too, to prove the enhanced portability: GNU/Hurd on Debian, with the Sleek theme from GAP:

Here is Excorporate version 0.6.0.

New in this release:

- Support for overriding settings autodiscovery by manually configuring an EWS URL

- A check to prevent soap-client conflicts with other packages

- Handle user@sub.domain.com/autodiscover.domain.com autodiscovery case

- Support for Exchange 2013 (via the new API addition, exco-server-version)

Thanks to everyone who tested autodiscovery on the 0.5.4 release and provided feedback. I’ve listed most of you in the Acknowledgements section.

Excorporate has been accepted for inclusion in GNU ELPA but I’m still waiting on copyright assignment for one dependency before releasing it there. This release still takes the form of a tarball. First download it, then install it with M-x package-install-file.

I found out that all my debian machines switched to systemd without my consent, with just a standard apt-get ugrading.
I despise that decision.

I did not follow the latest discussion about it, I was left with the impression that it would have been installed only if needed, but evidently I was wrong.

Can you get back? Time to toss Debian? I hoped not, I know of other fellow developers who switched  distribution, but Debian is Debian.

Remove systemd and sysvinit (which is now a transitional package) and put back sysvinit-core back. I had the fear that I bricked my laptops, but it still works. For how long? I don't know.

I'm very very sad about this. If I think of GNU/Linux I think of Debian, it has been with me since 68k times, when potato was cool. Debian made a very bad decision.

Something newer than ol' sysvinit? Something modern, fast, capable of parallelism. Yes.
But something portable, light, secure, which is not a dependency hell, which does one thing. In other words, something in line with the Unix philosophy.

Not the enormous pile of rotting shit which is systemd. When I removed it, I freed almost 13Mbytes from my system. I am relieved, but it shows also how big that pile of crap is.

So, for now, Debian can stay with me, I hope it will be for a long while. Long enough that debian will revert or systemd will go away.

Last weekend I did a talk on How to start hacking on Valgrind by example at Fosdem which contain some Easy hacks for valgrind. If If you always wanted to hack on Valgrind, but haven’t yet really looked at the code yet, then this might be a nice introduction. Make sure to also read the slides for all the other Valgrind devroom talks. Much thanks to the Fosdem organization for letting the Valgrind hackers meet. It was a great weekend.

I'm looking forward to head out to Utrecht on Thursday, February 12th, to speak on JDK 9 as part of the NetBeans Day Netherlands.

See you there!

Over the last twelve months or so, one of my projects has been fixing and reviewing fixes of javac lint warnings in the JDK 9 code base (varargs, fallthrough, serial, finally, overrides, deprecation, raw and unchecked) and once a warning category is cleared, making new instances of that category a fatal build error. Ultimately, all the warnings in the jdk repository were resolved and -Xlint:all -Werror is now used in the build.

Being involved in fixing several thousand warnings, I'd like to share some tips for developers who want to undertake an analogous task of cleaning up the technical debt of javac lint warnings in their own code base. First, I recommend tackling the warnings in a way that aligns well with the build system of the project, with a consideration of getting some code protected by the compiler from some warning categories as soon as possible. While the build of the JDK has been re-engineered over the course of the warnings cleanup, to a first approximation the build has been organized around Hg repositories. (At present, in JDK 9 the build is actually arranged around modules. A few years ago, the build was organized around Java packages rather than repositories.) A warnings cleanup isn't really done until introducing new instances of the warning cause a build failure; new warnings are too easy to ignore otherwise. Therefore, for JDK 9, the effort was organized around clearing the whole jdk repository of a warning category and then enabling that warning category in the build as opposed to, say, completely clearing a particular package of all warnings and then moving to the next package.

There are two basic approaches to resolving a warning: suppressing it using the @SuppressWarnings mechanism or actually fixing the code triggering the warning. The first approach is certainly more expedient. While it doesn't directly improve the code base, it can offer an indirect benefit of creating a situation where new warnings can be kept out of the code base by allowing a warning to be turned on in the build sooner. The different warning categories span a range of severity levels and while some warnings are fairly innocuous, others are suspicious enough that I'd recommend always fixing them if a fix is feasible. When resolving warnings in the JDK, generally the non-deprecation warnings categories were fixed while the deprecation warnings were suppressed with a follow-up bug filed. The non-deprecation warnings mostly require Java language expertise to resolve and little area expertise; deprecation warnings are the reverse, often quite deep area expertise is needed to develop and evaluate a true fix.

Tips on addressing specific categories of lint warnings:

[cast]: Warn about use of unnecessary casts.
Since these warnings are generated entirely from the the contents of method bodies, there is no impact to potential callers of the code. Also, the casts analyzed as redundant by javac are easy and safe to remove; fixing cast warnings is essentially a zero-risk change.
[fallthrough]: Warn about falling through from one case of a switch statement to the next.
When such a falling through is not intentional, it can be a very serious bug. All fallthrough switch cases should be examined for correctness. An idiomatic and intentional fallthrough should have two parts: first, the cases in question should be documented in comments explaining that the fallthrough is expected and second, an @SuppressWarnings({"fallthrough"}) annotation should be added to the method containing the switch statement.

See also the discussion of switch statements in Java Puzzlers, Puzzler 23: No Pain, No Gain.

[static]: Warn about accessing a static member using an instance.
This is an unnecessary and misleading coding idiom that should be unconditionally removed. The fix is to simply refer to the static member using the name of the type rather than an instance of the type.

This coding anti-pattern is discussed in Java Puzzlers, Puzzle 48: All I Get Is Static.

[dep-ann]: Warn about items marked as deprecated in JavaDoc but not using the @Deprecated annotation
Since Java SE 5.0, the way to mark an element as deprecated is to modify it with a @Deprecated annotation. While a @deprecated javadoc tag should be used to describe all @Deprecated elements, the javadoc tag is informative only and does not mean the element is treated as deprecated by the compiler.

A element should have an @deprecated javadoc tag in its javadoc if and only if the element is @Deprecated.

Therefore, the fix should be to either remove the @deprecated javadoc tag if the element should not be deprecated or add the @Deprecated annotation if it should be deprecated.

[serial]: Warn about Serializable classes that do not provide a serialVersionUID.
Serialization is a subtle and complex protocol whose compatibility impact on evolving a type should not be underestimated. To check for compatibility between the reader of serial stream data and the writer of the data, besides matching the names of the reader and writer, identification codes of the reader and the writer are also compared and the serial operation fails if the codes don't match. When present, a serialVersionUID field of a class stores the identification code, called a Stream Unique Identifier (SUID) in serialization parlance. When a serialVersionUID field is not present, a particular hashing algorithm is used to compute the SUID instead. The hash algorithm is perturbed by many innocuous changes to a class and can therefore improperly indicate a serial incompatibility when no such incompatibility really exists. To avoid this hazard, a serialVersionUID field should be present on all Serializable classes following the usual cross-version serialization contracts, including Serializable abstract superclasses.

If a Serializable class without a serialVersionUID has already been shipped in a release, running the serialver tool on the type in the shipped release will return the serialVersionUID declaration needed to maintain serial compatibility.

For further discussion, see Effective Java, 2nd Edition, Item 74: Implement Serializable judiciously.

[overrides]: Warn about issues regarding method overrides.
As explained in Effective Java, 2nd Edition, Item 9: Always Override hashCode when you override equals, for objects to behave properly when used in collections, they must have correct equals and hashCode implementations. The invariant checked by javac is more nuanced than the one discussed in Effective Java; javac checks that if a class overrides equals, hashCode has been overriden somewhere in the superclass class chain of the class. It is common for a set of related classes to be able to share a hashCode implementation, say a function of a private field in the root superclass in a set of related types. However, each class will still need to have its own equals method for the usual instanceof check on the argument to equals.
[deprecation]: Warn about use of deprecated items.
Well documented @Deprecated elements suggest a non-deprecated replacement. When using a replacement is not feasible, or no such replacement exists, @SuppressWarnings("deprecation") can be used to acknowledge the situation and remove the warning. A small language change made in JDK 9 makes suppressing deprecation warnings tractable.
[rawtypes]: Warn about use of raw types.
[unchecked]: Warn about unchecked operations.
Both rawtypes and unchecked warnings are linked to the same underlying cause: incomplete generification of APIs and their implementations. Generics shipped in 2004 as part of Java SE 5.0; Java code written and used today should be generics aware! Being generics-aware has two parts, using generics properly in the signature / declaration of a method, constructor, or class and using generics properly in method and constructor bodies. Many uses of generics are straightforward; if you have a list that only contains strings, it should probably be declared as a List<String>. However, some uses of generics can be subtle and are out of scope for this blog entry. However, extensive guides are available with detailed advice. IDEs also provide refactorings for generics; check their documentation for details.

I hope these tips help you make your own Java project warnings-free.

I recently had occasion to scan some papers using a sheet-fed Ricoh printer/scanner/fax/copier. It seems to think that about 6 MB is as big of an email attachment as it can send so it splits up the PDFs into base64-encoded attachments. If you find yourself in a similar situation:

  • save the raw base64 text (if you’re using GMail, “show original” is your friend) and trim the extraneous text.
  • concatenate the multiple pieces together: cat part1 part2 > all.base64.
  • decode the whole thing: cat all.base64 | base64 -d > myscan.pdf.

As part of milling Project Coin in JDK 9, the try-with-resources statement has been improved. If you already have a resource as a final or effectively final variable, you can use that variable in the try-with-resources statement without declaring a new variable in the try-with-resources statement.

For example, given resource declarations like

        // A final resource
        final Resource resource1 = new Resource("resource1");
        // An effectively final resource
        Resource resource2 = new Resource("resource2");

the old way to write the code to manager these resources would be something like:

        // Original try-with-resources statement from JDK 7 or 8
        try (Resource r1 = resource1;
             Resource r2 = resource2) {
            // Use of resource1 and resource 2 through r1 and r2.
        }

while the new way can be just

        // New and improved try-with-resources statement in JDK 9
        try (resource1;
             resource2) {
            // Use of resource1 and resource 2.
        }

An initial pass has been made over the java.base module in JDK 9 to update the JDK libraries to use this new language feature.

You can try out these changes in your own code using a JDK 9 snapshot build. Enjoy!

As I wrote previously, Project Jigsaw is coming into JDK 9 in several large steps. JEP 200 defines the modular structure of the JDK, JEP 201 reorganizes the JDK source code into modular form, and JEP 220 restructures the JDK and JRE run-time images to support modules. The actual module system will be defined in JSR 376, which is just getting under way, and implemented by a corresponding JEP, yet to be submitted.

We implemented the source-code reorganization (JEP 201) last August. This step, by design, had no impact on developers or end users.

Most of the changes for modular run-time images (JEP 220) were integrated late last week and are now available in JDK 9 early-access build 41. This step, in contrast to the source-code reorganization, will have significant impact on developers and end users. All of the details are in the JEP, but here are the highlights:

  • JRE and JDK images now have identical structures. Previously a JDK image embedded the JRE in a jre subdirectory; now a JDK image is simply a run-time image that happens to contain the full set of development tools and other items historically found in the JDK.

  • User-editable configuration files previously located in the lib directory are now in the new conf directory. The files that remain in the lib directory are private implementation details of the run-time system, and should never be opened or modified.

  • The endorsed-standards override mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.endorsed.dirs or by placing jar files into the lib/endorsed directory of a JRE, will not work. We expect to provide similar functionality later in JDK 9 in the form of upgradeable modules.

  • The extension mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.ext.dirs or by placing jar files into the lib/ext directory of a JRE, will not work. In most cases, jar files that were previously installed as extensions can simply be placed at the front of the class path.

  • The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory. Class and resource files previously in tools.jar and dt.jar are now always visible via the bootstrap or application class loaders in a JDK image.

  • A new, built-in NIO file-system provider can be used to access the class and resource files stored in a run-time image. Tools that previously read rt.jar and other internal jar files directly should be updated to use this file system.

We’re aware that these changes will break some applications, in particular IDEs and other development tools which rely upon the internal structure of the JDK. We think that the improvements to performance, security, and maintainability enabled by these changes are, however, more than worth it. We’ve already reached out to the maintainers of the major IDEs to make sure that they know about these changes, and we’re ready to assist as necessary.

If you have trouble running an existing application on JDK 9 build 41 or later and you think it’s due to this restructuring, yet not caused by one of the changes listed above or in JEP 220, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com. Thanks!

For almost a year now I’ve had a Yoga 2 Pro. Despite some people thinking the name is silly and me only using the screen rotation once (on a plane), it’s a nice machine and Fedora 20 running GNOME is great on it. The only non-stock thing to do1 is, in Firefox, open about:config and set layout.css.devPixelsPerPx to 2.

When I bought it, I cheaped out and got the 256 GB disk. I shouldn’t have, so I recently bought a 1 TB mSATA disk to replace it. I also bought an mSATA -> USB3 enclosure to use for dding everything over to the new disk.

For reasons I can’t recall I have my encrypted /home *not* on a logical volume so growing it into the free space on the new disk basically just involved booting from a live USB stick, unlocking the LUKS volume, using gdisk to delete the existing partition and creating a new, larger one starting at the same offset, e2fsck, and resize2fs. If you’re going to do this yourself, you should of course back up your data first.

Physically changing the disk involved removing the 11 T5 bolts on the bottom and the pesky Phillips 00 bolt holding the SSD in place.

[1]

Well, depending upon how old your kernel is, you may also need to rmmod/blacklist ideapad_laptop.

I started hacking on firefox recently. And, of course, I’ve configured emacs a bit to make hacking on it more pleasant.

The first thing I did was create a .dir-locals.el file with some customizations. Most of the tree has local variable settings in the source files — but some are missing and it is useful to set some globally. (Whether they are universally correct is another matter…)

Also, I like to use bug-reference-url-mode. What this does is automatically highlight references to bugs in the source code. That is, if you see “bug #1050501″, it will be buttonized and you can click (or C-RET) and open the bug in the browser. (The default regexp doesn’t capture quite enough references so my settings hack this too; but I filed an Emacs bug for it.)

I put my .dir-locals.el just above my git checkout, so I don’t end up deleting it by mistake. It should probably just go directly in-tree, but I haven’t tried to do that yet. Here’s that code:

(
 ;; Generic settings.
 (nil .
      ;; See C-h f bug-reference-prog-mode, e.g, for using this.
      ((bug-reference-url-format . "https://bugzilla.mozilla.org/show_bug.cgi?id=%s")
       (bug-reference-bug-regexp . "\\([Bb]ug ?#?\\|[Pp]atch ?#\\|RFE ?#\\|PR [a-z-+]+/\\)\\([0-9]+\\(?:#[0-9]+\\)?\\)")))

 ;; The built-in javascript mode.
 (js-mode .
     ((indent-tabs-mode . nil)
      (js-indent-level . 2)))

 (c++-mode .
	   ((indent-tabs-mode . nil)
	    (c-basic-offset . 2)))

 (idl-mode .
	   ((indent-tabs-mode . nil)
	    (c-basic-offset . 2)))

)

In programming modes I enable bug-reference-prog-mode. This enables highlighting only in comments and strings. This would easily be done from prog-mode-hook, but I made my choice of minor modes depend on the major mode via find-file-hook.

I’ve also found that it is nice to enable this minor mode in diff-mode and log-view-mode. This way you get bug references in diffs and when viewing git logs. The code ends up like:

(defun tromey-maybe-enable-bug-url-mode ()
  (and (boundp 'bug-reference-url-format)
       (stringp bug-reference-url-format)
       (if (or (derived-mode-p 'prog-mode)
	       (eq major-mode 'tcl-mode)	;emacs 23 bug
	       (eq major-mode 'makefile-mode)) ;emacs 23 bug
	   (bug-reference-prog-mode t)
	 (bug-reference-mode t))))

(add-hook 'find-file-hook #'tromey-maybe-enable-bug-url-mode)
(add-hook 'log-view-mode-hook #'tromey-maybe-enable-bug-url-mode)
(add-hook 'diff-mode-hook #'tromey-maybe-enable-bug-url-mode)
Thanks to everybody who commented on the JamVM 2.0.0 release, and apologies it's taken so long to approve them - I was expecting to get an email when I had an unmoderated comment but I haven't received any.

To answer the query regarding Nashorn.  Yes, JamVM 2.0.0 can run Nashorn.  It was one of the things I tested the JSR 292 implementation against.  However, I can't say I ran any particularly large scripts with it (it's not something I have a lot of experience with).  I'd be pleased to hear any experiences (good or bad) you have.

So now 2.0.0 is out of the way I hope to do much more frequent releases.  I've just started to look at OpenJDK 9.  I was slightly dismayed to discover it wouldn't even start up (java -version), but it turned out to be not a lot of work to fix (2 evenings).  Next is the jtreg tests...

I'm pleased to announce a new release of JamVM.  JamVM 2.0.0 is the first release of JamVM with support for OpenJDK (in addition to GNU Classpath). Although IcedTea already includes JamVM with OpenJDK support, this has been based on periodic snapshots of the development tree.

JamVM 2.0.0 supports OpenJDK 6, 7 and 8 (the latest). With OpenJDK 7 and 8 this includes full support for JSR 292 (invokedynamic). JamVM 2.0.0 with OpenJDK 8 also includes full support for Lambda expressions (JSR 335), type annotations (JSR 308) and method parameter reflection.

In addition to OpenJDK support, JamVM 2.0.0 also includes many bug-fixes, performance improvements and improved compatibility (from running the OpenJDK jtreg tests).

The full release notes can be found here (changes are categorised into those affecting OpenJDK, GNU Classpath and both), and the release package can be downloaded from the file area.

Sad to receive news this morning that a long time friend and colleague, Peter Miller, had passed.

Peter Miller

“After fighting cancer for many years, finally lost”. No, not lost; if there was ever anyone who fought the battle of life and won it was be Peter. Even knowing he was at his last days he was unbowed. Visiting him last week he proudly showed us the woodworking plans and cut lists for some cabinets he was making for his wife MT. He had created the diagrams himself, writing C++ code to call manually drive a drawing library, outputting postscript. Let’s see you do architectural drawing without a CAD program. The date on the printout was two weeks ago.

“The world is a less interesting place today,” wrote another friend. No. Peter firmly believed that interest comes from within. The world is there to be explored, I can hear him saying. He taught us to go forth, wonder, and understand. And so we should.

AfC

Project Jigsaw has, for the last several years, been in an exploratory phase in which we’ve designed and prototyped one particular approach to addressing a draft set of requirements.

It’s now time to switch gears and focus on creating a production-quality design and implementation suitable for JDK 9 and thence Java SE 9, as previously proposed.

To begin this phase I’ve drafted a new document to collect goals and requirements. It reflects a new emphasis on security, as motivated by recent experience, it takes into account lessons learned from the prototype, and it’s written at a broader and more abstract level than the previous document so as not to over-constrain the solution space. This document will be one of the starting points of the upcoming Java Platform Module System JSR.

Jigsaw as a whole will bring enormous changes to the JDK; it would be unwise to wait until it’s completely finished before merging any of it. Our intent, therefore, is to proceed in large steps, each of which will have a corresponding JEP. The first three JEPs will propose a specific modular structure for the JDK, reorganize the JDK source code (but not binaries) along those lines, and then later modularize the binary images.

A fourth JEP will introduce the module system itself, which will be aligned with the module-system JSR. It may seem odd that the module system JEP comes last, but the earlier JEPs need make only minimal assumptions about its capabilities, hence work on them can proceed in parallel with work on the module-system JEP and JSR.

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.)

There’s an interesting spectrum of events in the technical space. Conferences are the mainstay obviously; usually very intense and high-calibre thanks to the hard work of papers committees and of course the presenters themselves. You become invigorated hearing the experiences and results of other people, sharing ideas in the hallway, and of course the opportunity to vehemently explain why vi is better than emacs over drinks in the bar later is essential to the progress of science.

For a given community, though, conferences are relatively infrequent; often only once a year for a given country (linux.conf.au, Australia’s annual Linux conference, say) and sometimes only once a year globally (ICFP, the international functional programming conference with numerous collocated symposiums and events taking advantage of the fact it’s the one event everyone turns up at is a notable example in computing).

More locally, those in major cities are able to organize monthly meetups, networking events, user groups, and the like. Which are fun; lovely to see friends and continue to build relationships with people you’d otherwise only see once a year.

Finally there are hackfests, often on the order of a weekend in duration. The tend to draw people in from a wide area, and sometimes are in an unusual milieu; Peter Miller’s CodeCon camping and hacking weekends are infamous in the Sydney Linux community; rent a small quiet generator, find a state forest, set up tents and hack on whatever code you want to for a few days. Blissful.

The local monthly events are the most common, though. Typically two or three people offer to give presentations to an audience of 30-50 people. And while hearing talks on a range of topics is invaluable, the fact that so many smart people are in the room passively seems a lost opportunity.

For a while now I’ve been musing whether perhaps there is something between meetups and hackfests. Wouldn’t it be cool to get a bunch of people together, put a problem on the board, and then for an hour go around the room and have a debate about whether the problem is even the right question to be asking, and different approaches to tackling the issue? Something short, relatively focused, and pragmatic; rather than being a presentation of results a consideration of approaches. If we do it in a bit of rotation, each time one person being tasked with framing the question, then over time participants each have the benefit of bringing the collective firepower of the group to bear on one of the problems they’re working.

Needs a name. Seminar? No, that’s what university departments do. Symposium? Too grand. Something more informal, impromptu, but organized. You know, like a jazz jam session. Ah, there we go: gonna call these sessions.

It might be nice to complement the monthly functional programming meetup (fp-syd) that happens in Sydney with something a little more interactive and Haskell focused. And as I’m looking to improve the depth of experience with Haskell in the Engineering group at Anchor, this seemed like a nice fit. So we’re holding the first of the Haskell Sessions tomorrow 2pm, at Anchor’s office in Sydney.

Here’s one to start us off:

Industrial code has to interact with the outside world, often on external dependencies such as databases, network services, or even filesystem operations. We’re used to the ability to separate pure code from that with side-effects, but what abstractions can we use to isolate the dependent code from the rest of the program logic?

I know we’re not the first ones to blunder in to this; I’ve heard plenty of people discussing it. So I’m going to hand around a single page with the type signatures of the functions involved at various points, freshly sharpen some whiteboard markers, and we’ll see what ideas come to light!

If you’re interested in coming, drop me a line.

AfC

Another company is refusing to issue a Java RIA code signing certificate for individual. Even if they openly declare they do in they website. Even after I provided the notary-confirmed copies of all documents they requested and they have had two phone interviews with me. Seems really the end of the project. Dalibor, are you reading this?
It was pretty easy to write a new graphical backend for Jainja using the Pepper Plugin API. So it's possible to write Java graphical user interfaces on NaCl now !

A demo is available on the Chrome Web Store.