Planet Classpath

Last time I mentioned that with the integration of OpenJDK 8u45 MethodHandle performance went from awful to unusable. That was pretty literal as the JSR 292 test cases that I regularly run went from taking about 8 minutes to more than 30 minutes (when my patience ran out).

Using sophisticated profiling techniques (pressing Ctrl-Break a few times) I determined that a big part of the problem was MethodHandle.asType(). So I wrote a microbenchmark:

   IKVM 8.0.5449.1  IKVM 8.1.5638
asType.permutations(1) 2108 9039
asType.permutations(2) 2476 17269

The numbers are times in milliseconds. Clearly not a good trend. I did not investigate deeply what changed in OpenJDK, but after looking at the 8u45 code it was clear that too many intermediate MethodHandles were being created. So I rewrote asType to create a single LambdaForm to do all the work at once. This improved the performance a bit, but the disturbing increase in time for the second iteration was still there. Once again I decided not to investigate the root cause of this, but simply to assume that it was because of anonymous type creation (the CLR has no anonymous types and creating a type is relatively expensive).

Avoiding anonymous type creation turned out to be easy (well, the high level design was easy, the actual implementation took a lot more time). I just had to replace the LambdaForm compiler. There is a single method that represents the exact point where I can come in and change the implementation:

static MemberName generateCustomizedCode(LambdaForm form, MethodType invokerType) { ... }

In OpenJDK this method compiles the LambdaForm into a static method in an anonymous class and returns a MemberName that points to the static method. All I had to do was replace this method with my own implementation that directly generates a .NET DynamicMethod. As I said before, the idea was simple, actually getting the implementation correct took a couple of weeks (part time).

With both these optimizations in place, MethodHandle performance is back to awful (actually, it is less afwul than it was before):

   IKVM 8.0.5449.1  IKVM 8.1.5638  IKVM 8.1.5653
asType.permutations(1) 2108 9039 314
asType.permutations(2) 2476 17269 210

The running time of the JSR 292 test cases went down to less than 7 minutes. So I was satisfied. There are many more opportunities to improve the MethodHandle performance on IKVM, but so far no IKVM user has complained about it, so it is not a priority. Note that Java 8 lambdas are not implemented using MethodHandles on IKVM.


  • Fixed performance bug. Base type of java.lang.Object was not cached.
  • Untangled TypeWrapper.Finish() from member linking to improve Finish performance for already compiled types.
  • Improved MethodHandle.asType() performance by directly creating a single LambdaForm to do the conversion, instead of creating various intermediate forms (and MethodHandles).
  • Make non-public final methods defined in map.xml that don't override anything automatically non-virtual.
  • Optimized LambdaForm compiler.
  • IKVM.Reflection: Added Type.__GetGenericParameterConstraintCustomModifiers() API.

Binaries available here:

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!

I integrated OpenJDK 8u45, so a new development snapshot is warranted. MethodHandle performance regressed from awful to unusable, so that's something I need to look into.


  • Merged OpenJDK 8u45. Special thanks to @mihi42 for helping me with the download.
  • Bug fix. Don't enforce canonical UTF8 encoding for class file versions <= 47.
  • Added support for "high contrast" desktop property. Inspired by patch from Daniel Zatonyi .
  • Handle more text sources for clipboard copy by using an appropriate Reader for the source data. Patch by Daniel Zatonyi .
  • Fixed drag-n-drop coordinates. Patch by Daniel Zatonyi .
  • Fixed Graphics.clipRect(). Fix by Daniel Zatonyi .
  • Bug fix. ReferenceQueue should not keep registered (but not yet enqueued) Reference objects alive.
  • Added Unsafe.staticFieldOffset() and Unsafe.staticFieldBase() methods.
  • sun.misc.Unsafe: Replaced (broken) TypedReference based field CompareExchange with DynamicMethod based implementation.
  • Fixed clone/finalize invocation via MethodHandle.
  • Fixed build to allow nasgen to work with 1.8.0_40.
  • IKVM.Reflection: Fixed known custom attribute handling. They should be recognized by type name, not type identity.
  • IKVM.Reflection: Added Module.__TryGetImplMap() public API to get ImplMap by token.
  • IKVM.Reflection: Added new public APIs to help deal with built-in types even when they are not defined in mscorlib: Type.__IsBuiltIn and Universe.GetBuiltInType(string ns, string name).

Binaries available here:

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.

→ originally posted on

This past few weeks I’ve been working on making remote debugging in GDB easier to use. What’s remote debugging? It’s where you run GDB on one machine and the program being debugged on another. To do this you need something to allow GDB to control the program being debugged, and that something is called the remote stub. GDB ships with a remote stub called gdbserver, but other remote stubs exist. You can write them into your own program too, which is handy if you’re using minimal or unusual hardware that cannot run regular applications… cellphone masts, satellites, that kind of thing. I bet you didn’t know GDB could do that!

If you’ve used remote debugging in GDB you’ll know it requires a certain amount of setup. You need to tell GDB how to access to your program’s binaries with a set sysroot command, you need to obtain a local copy of the main executable and supply that to GDB with a file command, and you need to tell GDB to commence remote debugging with a target remote command.

Until now. Now all you need is the target remote command.

This new code is really new. It’s not in any GDB release yet, let alone in RHEL or Fedora. It’s not even in the nightly GDB snapshot, it’s that fresh. So, with the caveat that none of these examples will work today unless you’re using a Git build, here’s some things you can do with gdbserver using the new code.

Here’s an example of a traditional remote debugging session, with the things you type in bold. In one window:

abc$ ssh
xyz$ gdbserver :9999 --attach 5312
Attached; pid = 5312
Listening on port 9999

gdbserver attached to process 5312, stopped it, and is waiting for GDB to talk to it on TCP port 9999. Now, in another window:

abc$ gdb -q
(gdb) target remote
Remote debugging using
...lots of messages you can ignore...
(gdb) bt
#0 0x00000035b5edf098 in *__GI___poll (fds=0x27467a0, nfds=8,
timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83
#1 0x00000035b76449f9 in ?? () from target:/lib64/
#2 0x00000035b76451a5 in g_main_loop_run ()
from target:/lib64/
#3 0x0000003dfd34dd17 in gtk_main ()
from target:/usr/lib64/
#4 0x000000000040913d in main ()

Now you have GDB on one machine (abc) controlling process 5312 on another machine (xyz) via gdbserver. Here I did a backtrace, but you can do pretty much anything you can with regular, non-remote GDB.

I called that a “traditional” remote debugging session because that’s how a lot of people use this, but there’s a more flexible way of doing things if you’re using gdbserver as your stub. GDB and gdbserver can communicate over stdio pipes, so you can chain commands, and the new code to remove all the setup you used to need makes this really nice. Lets do that first example again, with pipes this time:

abc$ gdb -q
(gdb) target remote | ssh -T gdbserver - --attach 5312
Remote debugging using | ssh -T gdbserver - --attach 5312
Attached; pid = 5312
Remote debugging using stdio
...lots of messages...

The “-” in gdbserver’s argument list replaces the “:9999” in the previous example. It tells gdbserver we’re using stdio pipes rather than TCP port 9999. As well as configuring everything with single command, this has the advantage that the communication is through ssh; there’s no security in GDB’s remote protocol, so it’s not the kind of thing you want to do over the open internet.

What else can you do with this? Anything you can do through stdio pipes! You can enter Docker containers:

(gdb) target remote | sudo docker exec -i e0c1afa81e1d gdbserver - --attach 58
Remote debugging using | sudo docker exec -i e0c1afa81e1d gdbserver - --attach 58
Attached; pid = 58
Remote debugging using stdio

Notice how I slipped sudo in there too. Anything you can do over stdio pipes, remember? If you’re using Kubernetes you can use kubectl exec, or with OpenShift osc exec.

gdbserver can do more than just attach, you can start programs with it too:

(gdb) target remote | sudo docker exec -i e0c1afa81e1d gdbserver - /bin/sh
Remote debugging using | sudo docker exec -i e0c1afa81e1d gdbserver - /bin/sh
Process /bin/sh created; pid = 89
stdin/stdout redirected
Remote debugging using stdio

Or you can start it without any specific program, and then tell it what do do from within GDB. This is by far the most flexible way to use gdbserver. You can control more than one process, for example:

(gdb) target extended-remote | ssh -T gdbserver --multi -
Remote debugging using | gdbserver --multi -
Remote debugging using stdio
(gdb) attach 774
(gdb) add-inferior
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) attach 871
(gdb) info inferiors
Num Description Executable
* 2 process 871 target:/usr/sbin/httpd
  1 process 774 target:/usr/libexec/mysqld

Ready to debug that connection issue between your webserver and database?

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

See you there!

GDB will be the weapon we fight with if we accidentally build Skynet.

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

What’s New?

New in release 2.5.5 (2015-04-14)

  • Security fixes
  • Backports
    • S6584008, PR2193, RH1173326: jvmtiStringPrimitiveCallback should not be invoked when string value is null
    • S6956398, PR2250: make ephemeral DH key match the length of the certificate key
    • S7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError
    • S7142035: assert in j.l.instrument agents during shutdown when daemon thread is running
    • S7195480: javax.smartcardio does not detect cards on Mac OS X
    • S8001472: api/java_awt/Window/indexTGF_* tests fail because expected colors aren’t equal
    • S8011646: SEGV in compiled code with loop predication
    • S8012637: Adjust CipherInputStream class to work in AEAD/GCM mode
    • S8016545: java.beans.XMLEncoder.writeObject output is wrong
    • S8019324: assert(_f2 == 0 || _f2 == f2) failed: illegal field change
    • S8019623: Lack of synchronization in AppContext.getAppContext()
    • S8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert
    • S8022070: Compilation error in stubGenerator_sparc.cpp with some compilers
    • S8024061: Exception thrown when drag and drop between two components is executed quickly
    • S8028616: Htmleditorkit parser doesn’t handle leading slash (/)
    • S8028617: Dvorak keyboard mapping not honored when ctrl key pressed
    • S8029837: NPE seen in XMLDocumentFragmentScannerImpl.setProperty since 7u40b33
    • S8031290: Adjust call to getisax() for additional words returned
    • S8032872: [macosx] Cannot select from JComboBox in a JWindow
    • S8032874: ArrayIndexOutOfBoundsException in JTable while clearing data in JTable
    • S8032878: Editable combos in table do not behave as expected
    • S8033113: wsimport fails on WSDL:header parameter name customization
    • S8033696: “assert(thread != NULL) failed: just checking” due to Thread::current() and JNI pthread interaction
    • S8036022: D3D: rendering with XOR composite causes InternalError.
    • S8036709: Java 7 jarsigner displays warning about cert policy tree
    • S8036819: JAB: mneumonics not read for textboxes
    • S8036983: JAB:Multiselection Ctrl+CursorUp/Down and ActivateDescenderPropertyChanged event
    • S8037477: Reproducible hang of JAWS and webstart application with JAB 2.0.4
    • S8038925: Java with G1 crashes in dump_instance_fields using jmap or jcmd without fullgc
    • S8039050: Crash in C2 compiler at Node::rematerialize
    • S8039298: assert(base == NULL || t_adr->isa_rawptr() || ! phase->type(base)->higher_equal(TypePtr::NULL_PTR))
    • S8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X
    • S8040228: TransformerConfigurationException occurs with security manager, FSP and XSLT Ext
    • S8040790: [TEST_BUG] tools/javac/innerClassFile/ fails to cleanup files after it
    • S8041451: com.sun.jndi.ldap.Connection:ReadTimeout should abandon ldap request
    • S8041740: Test sun/security/tools/keytool/ fails on Mac
    • S8041979: sun/jvmstat/monitor/MonitoredVm/ failing on all platforms
    • S8042059: Various fixes to linux/sparc
    • S8042857: 14 stuck threads waiting for notification on LDAPRequest
    • S8043123: Hard crash with access violation exception when blitting to very large image
    • S8043200: Decrease the preference mode of RC4 in the enabled cipher suite list
    • S8043205: Incorrect system traps.h include path
    • S8043206: Fix signed vs. unsigned comparison warning in copy_sparc.hpp
    • S8043207: Add const to Address argument for Assembler::swap
    • S8043210: Add _BIG_ENDIAN define on linux/sparc
    • S8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX
    • S8044602: Increment minor version of HSx for 7u72 and initialize the build number
    • S8044659: Java SecureRandom on SPARC T4 much slower than on x86/Linux
    • S8046769: Set T family feature bit on Niagara systems
    • S8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn’t work on MacOSX
    • S8049081: Increment hsx 24.72 build to b02 for 7u72-b03
    • S8049542: C2: assert(size_in_words <= (julong)max_jint) failed: no overflow
    • S8049787: Increment hsx 24.72 build to b03 for 7u72-b04
    • S8050158: Introduce system property to maintain RC4 preference order
    • S8050165: linux-sparcv9: NMT detail causes assert((intptr_t*)younger_sp[FP->sp_offset_in_saved_window()] == (intptr_t*)((intptr_t)sp – STACK_BIAS)) failed: younger_sp must be valid
    • S8050167: linux-sparcv9: hs_err file does not show any stack information
    • S8055714: Increment hsx 24.72 build to b04 for 7u72-b11
    • S8056211: api/java_awt/Event/InputMethodEvent/serial/index.html#Input[serial2002] failure
    • S8060072: Increment minor version of HSx for 7u79 and initialize the build number
    • S8064454: [TEST_BUG] Test tools/javac/innerClassFile/ fails for Mac and Linux
    • S8064532: 7u76 build failed with # 8041979
    • S8065072: sun/net/www/http/HttpClient/ failed intermittently
    • S8065373: [macosx] jdk8, jdk7u60 Regression in Graphics2D drawing of derived Fonts
    • S8065709: Deadlock in awt/logging apparently introduced by 8019623
    • S8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section
    • S8068405: GenerateCurrencyData throws RuntimeException for old data
    • S8071591: java/util/logging/ test started to fail due to JDK-8065991
    • S8072039: jdk7u79 l10n resource file translation update
    • S8072042: (tz) Support tzdata2015a
    • S8073226: Increment hsx 24.79 build to b02 for 7u79-b10
    • S8074312, PR2254, G541270: Enable hotspot builds on 4.x Linux kernels
    • S8074662: Update 3rd party readme and license for LibPNG v 1.6.16
    • S8075211: [TEST_BUG] Test sun/net/www/http/HttpClient/ fails with compilation error
  • Bug fixes
    • PR2196, RH1164762: jhat man page has broken URL
    • PR2200, G531686: Support giflib 5.1.0
    • PR2210: DGifCloseFile call should check the return value, not the error code, for failure
    • PR2225: giflib 5.1 conditional excludes 6.0, 7.0, etc.
    • PR2250: JSSE server is still limited to 768-bit DHE
  • ARM32 port
    • PR2228: Add ARM32 JIT
    • PR2297: Use the IcedTea 2.6.0 HotSpot on ARM32 by default
    • Several bug fixes to get Eclipse working
  • AArch64 port
    • Add java.lang.ref.Reference.get intrinsic to template interpreter
    • Fix implementation of InterpreterMacroAssembler::increment_mdp_data_at().
    • Remove insanely large stack allocation in entry frame.
    • S6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared
    • S8020675: invalid jar file in the bootclasspath could lead to jvm fatal error
    • S8020829: NMT tests fail on platforms if NMT detail is not supported
    • S8026303: CMS: JVM intermittently crashes with “FreeList of size 258 violates Conservation Principle” assert
    • S8029775: Solaris code cleanup
    • S8041980: (hotspot) sun/jvmstat/monitor/MonitoredVm/ failing on all platforms
    • S8042235: redefining method used by multiple MethodHandles crashes VM
    • S8044406: JVM crash with JDK8 (build 1.8.0-b132) with G1 GC
    • S8046233: VerifyError on backward branch
    • S8046289: compiler/6340864/ timeout with
    • S8048170: Test closed/java/text/Normalizer/ failed
    • S8050022: linux-sparcv9: assert(SharedSkipVerify || obj->is_oop()) failed: sanity check
    • S8054478: C2: Incorrectly compiled char[] array access crashes JVM
    • S8054530: C2: assert(res == old_res) failed: Inconsistency between old and new
    • S8054883: Segmentation error while running program
    • S8056309: Set minor version for hotspot in 7u76 to 76 and build number to b01
    • S8058583: Remove CompilationRepeat
    • S8058935: CPU detection gives 0 cores per cpu, 2 threads per core in Amazon EC2 environment
    • S8059216: Make PrintGCApplicationStoppedTime print information about stopping threads
    • S8060169: Update the Crash Reporting URL in the Java crash log
    • S8061507: Increment hsx 24.76 build to b02 for 7u76-b05
    • S8061694: Increment hsx 24.76 build to b03 for 7u76-b06
    • S8062229: Test failure of test_loggc_filename in 7u-cpu
    • S8062672: JVM crashes during GC on various asserts which checks that HeapWord ptr is an oop
    • S8064493: Increment the build value to b04 for hs24.76 in 7u76-b08
    • S8064667: Add -XX:+CheckEndorsedAndExtDirs flag to JDK 8
    • S8065618: C2 RA incorrectly removes kill projections
    • S8065765: Missing space in output message from -XX:+CheckEndorsedAndExtDirs
    • S8066045: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1
    • S8066103: C2′s range check smearing allows out of bound array accesses
    • S8066649: 8u backport for 8065618 is incorrect
    • S8066775: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1
    • S8071947: AARCH64: frame::safe_for_sender() computes incorrect sender_sp value for interpreted frames
    • S8072129: [AARCH64] missing fix for 8066900
    • S8072483: AARCH64: uses the wrong operand class for some operations

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://
  • 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://
  • Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

SHA256 checksums:

  • f05b1db06021f4cd3a39647f358a47130136d189431fb55f79855f627b1d6619 icedtea-2.5.5.tar.gz
  • 4863db17fa8afbbedf8bb4d19d9e520652d859e806b7abf27a86d71c483172f6 icedtea-2.5.5.tar.gz.sig/li>
  • 738dfcdbd59cf9093203934d4efa94281fb2e28cff1c9ec6d9b588ad42bac66f>
  • 09e7aeb739a468dec8357f4b0757624b6c7ef38065fdf50323d369deac983dc7 icedtea-2.5.5.tar.xz/li>
  • c47744296d5569a251d2ef8ed891fd91a223adb0ac460db5270583d3fa6d4288 icedtea-2.5.5.tar.xz.sig/li>
  • 61e1c6c89f3fb4623bef5a3375ecebf185d713b5460c6ca1ac87f1328cecb2a9>

The checksums can be downloaded from:

A 2.5.5 ebuild for Gentoo is available.

The following people helped with these releases:

  • Andrew Dinn (AArch64 work)
  • Severin Gehwolf (S8074312)
  • Andrew Haley (S6584008)
  • Andrew Hughes (all other backports & bug fixes, release management)
  • Edward Nevill (ARM32 work including PR2228)
  • Fridrich Strba (PR2200)
  • Jiri Vanek (PR2196)

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

To get started:

$ tar xzf icedtea-2.5.5.tar.gz


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


$ mkdir icedtea-build
$ cd icedtea-build
$ ../icedtea-2.5.5/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 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 April 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.

What’s New?

New in release 1.13.7 (2015-04-14)

  • Security fixes
  • Import of OpenJDK6 b35
    • OJ55: Synchronise whitespace in TimeZoneNames files with OpenJDK 7 versions.
    • OJ56: Update 3rd party readme and license for LibPNG v 1.6.16
    • OJ57: Remove mistakenly added patching fragment
    • S6672144: HttpURLConnection.getInputStream sends POST request after failed chunked
    • S6989721: awt native code compiler warnings
    • S7088287: libpng need to be updated.
    • S7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError
    • S7170655: Frame size does not follow font size change with XToolkit
    • S7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
    • S8019623: Lack of synchronization in AppContext.getAppContext()
    • S8040790: [TEST_BUG] tools/javac/innerClassFile/ fails to cleanup files after it
    • S8043123: Hard crash with access violation exception when blitting to very large image
    • S8051359: JPopupMenu creation in headless mode with JDK9b23 causes NPE
    • S8064454: [TEST_BUG] Test tools/javac/innerClassFile/ fails for Mac and Linux
    • S8065072: sun/net/www/http/HttpClient/ failed intermittently
    • S8065709: Deadlock in awt/logging apparently introduced by 8019623
    • S8072042: (tz) Support tzdata2015a
    • S8074662: Update 3rd party readme and license for LibPNG v 1.6.16
    • S8075211: [TEST_BUG] Test sun/net/www/http/HttpClient/ fails with compilation error
  • Backports
    • S6584008, PR2195, RH1173326: jvmtiStringPrimitiveCallback should not be invoked when string value is null
    • S7199862, PR2198: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases
    • S8074312, PR2255: Enable hotspot builds on Linux 4.x
  • Bug fixes
    • PR2197: jhat man page has broken URL
    • PR2201: Support giflib 5.1.0
    • PR2211: DGifCloseFile call should check the return value, not the error code, for failure
    • PR2226: giflib 5.1 conditional excludes 6.0, 7.0, etc.
    • PR2294: Auto-generated jconsole.desktop and policytool.desktop should not be included in release tarball

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://
  • 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://
  • Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

SHA256 checksums:

  • 1cd6dc97d729eaae8d3a102010934f171752eeb50046f609c2f3d6b0cf29fa45 icedtea6-1.13.7.tar.gz
  • f380e1fe2a1cf1a8feb8ea26fbad5cfc4c4a12b0da1b28467b6cdab4b73cb0c8 icedtea6-1.13.7.tar.gz.sig
  • f2b161bccb9bb3de06bdb7e046565272b53149cf865a123ceaa87d1793df96ab
  • a5ca64ae94ec27d28be91f4f0624164f9b4e6e92e417e52b296556005142183b icedtea6-1.13.7.tar.xz
  • 0c2c0dc60422eaef7cd30f019c9af370252a818e2d42128d6d9ab1902ba0bca7 icedtea6-1.13.7.tar.xz.sig
  • db51815eb42b72fcde286c2a68669c7007c2b4f2ddf832306c4715dd26b1e9bf

The checksums can be downloaded from:

A 1.13.7 ebuild for Gentoo is available.

The following people helped with these releases:

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

To get started:

$ tar xzf icedtea6-1.13.7.tar.gz


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


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

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

Happy hacking!

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

At Fosdem Volker presented a very great session on how to debug OpenJDK (and Hotspot) with gdb. Roman and Andrew (Dinn) did something similar while speaking about Shenandoah. In the next few days I’ll try to upload their slides on the FOSDEM website so that anyone can access that (and hopefully we will have the recordings this time as well).

There are a few things though that I keep forgetting myself and so I thought it would be useful to sum up in a blog post, hopefully general enough for most people as well as future reference for myself!

Suppose you are trying to detect some funny behaviour in your code, and that the crash is in a native library (or perhaps in some native OpenJDK code which is not hotspot).

What you would usually do with Java code is to start your debugger in Eclipse or IntelliJ or whatever, and go step by step until you figure out what’s wrong.

But when dealing with native code the thing gets complex, Eclipse and NetBeans can’t follow by default the native code, IntelliJ doesn’t even support native code at all (at least on Linux). There is an option though, first, you can still use those tools in process attach mode, they have very good debugging interfaces that make it easier to analyse quickly anything, but you can also use gdb directly, likewise in process attach mode.

Let’s see a couple of common cases here:

1. The application crashes, you want gdb launched automagically:

$ java -XX:OnError="gdb - %p" MyApplication

Roman (thanks!) show me this trick back in 2008! Honestly, I didn’t test that recently, but I suppose this still works ;)

2. You want to start a debugging session yourself rather than automatically on crash.

The trick here is to either start the application in debug mode via Eclipse/Whatever or attaching the Java debugger (including jdb if you enjoy suffering!) remotely:

$ java -Dsun.awt.disablegrab=true \
       -Xdebug \
       -Xrunjdwp:transport=dt_socket,server=y,address=1080 \

This will produce an output like the following:

Listening for transport dt_socket at address: 1080

Blocking the application until the debugger is attached.

At this point, you can set the breakpoints in your IDE and attach to the Java process remotely. The idea is to set the breakpoint right before the native call (tip: If you follow from there stepping with the java debugger, you’ll also see how native libraries are loaded).

Now to connect gdb all you need to to is to get the pid of the java process, with jps for example:

$ jps
30481 Jps
27162 MyApplication <------

And then:

$ gdb -p 27162

Set your breakpoint in the native function of choice. Remember the name mangling, so you need to look up how the methods are actually called in native code, the naming convention is:

Java_{package_and_classname}_{function_name}(JNI arguments)

But you need to double check exactly everything since there may be method overloads that dictate a slightly different convention.

If instead of using gdb from the command line you want to use your IDE the rule to follow is the same really. Afaik both Eclipse and NetBeans allow their native debugger plugins to attach to a process.

All that is needed now is to set your gdb breakpoints and issue a continue in the gdb shell in order to resume the Java process so that it can then hit the breakpoint you just set. From there, stepping in Java code until you enter the native function will magically continue the stepping inside the native function! If you use Eclipse to do both debugging this is even extremely cool since it’s just like following the program inside the same editor!

There’s one last thing to remember (other than possibly the need to set the source location in gdb or installing the OpenJDK debuginfo package for your distribution).

Hotspot uses segfaults for a number of interesting things, like deoptimise, NullPointerException etc.. Apparently, this is faster than doing specific checks and jumping around the code. This is a problem for gdb though, since it will stop every now and then to some random routines you don’t really (usually!) care about:

(gdb) cont
Program received signal SIGSEGV, Segmentation fault.

Irritating, since those are all legitimate segfaults.

To avoid that just do the following in the gdb console (or from the IDE in whatever way this is handled there):

(gdb) handle SIGSEGV nostop noprint pass

Now all the interesting work can be done without interruptions ;)

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


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


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 (, 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.


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.

Bradley M. Kuhn wrote an analysis on the recent Appeals Court Decision in Oracle v. Google. Pointing out who the real winners are and that it will now take years before we will have more clarity:

The case is remanded, so a new jury will first sit down and consider the fair use question. If that jury finds fair use and thus no infringement, Oracle’s next appeal will be quite weak, and the Appeals Court likely won’t reexamine the question in any detail. In that outcome, very little has changed overall: we’ll have certainty that API’s aren’t copyrightable, as long as any textual copying that occurs during reimplementation is easily called fair use. By contrast, if the new jury rejects Google’s fair use defense, I suspect Google will have to appeal all the way to SCOTUS. It’s thus going to be at least two years before anything definitive is decided, and the big winners will be wealthy litigation attorneys — as usual.

You will want to read the whole thing to know why from a copyleft perspective this decision will give that strange feeling of simultaneous annoyance and contentment.