Planet Classpath

I support the Software Freedom Conservancy because they provide a virtual home for Free Software communities. In their own words:

Software Freedom Conservancy is a not-for-profit organization that helps promote, improve, develop, and defend Free, Libre, and Open Source Software (FLOSS) projects. Conservancy provides a non-profit home and infrastructure for FLOSS projects. This allows FLOSS developers to focus on what they do best — writing and improving FLOSS for the general public — while Conservancy takes care of the projects’ needs that do not relate directly to software development and documentation.

Some projects receive support from or are managed by companies or trade associations that benefit from the software the community produces. That is great as long as the community objectives and the company profit motives are aligned. Free Software is a good way for companies to work together. The services that the Conservancy provides allows projects to define their own terms and conditions for the community to work together. And companies can then join on equal terms. Making sure the project and community will work together for the public benefit.

Please support the Software Freedom Conservancy by donating so they will be able to provide a home to many more communities. A donation of 10 US dollars a month will make you an official sponsor. Or donate directly to one of their many member projects.

Software Freedom Conservancy Member Projects

Software Freedom Conservancy Member Projects

I’m winding down for a month away from Infinity. The current status is that the language and note format changes for 0.0.2 are all done. You can get them with:

git clone

There’s also the beginnings of an Emacs major mode for i8 in there too. My glibc tree now has notes for td_ta_thr_iter as well as td_ta_map_lwp2thr. That’s two of the three hard ones done. Get them with:

git clone -b infinity2

FWIW td_thr_get_info is just legwork and td_thr_tls_get_addr is just a wrapper for td_thr_tlsbase; td_thr_tlsbase is the other hard note.

All notes have testcases with 100% bytecode coverage. I may add a flag for I8X to make not having 100% coverage a failure, and make glibc use it so nobody can commit notes with untested code.

The total note size so far is 720 bytes so I may still manage to get all five libpthread notes implemented in less than 1k:

Displaying notes found at file offset 0x00018f54 with length 0x000002d0:
  Owner                 Data size	Description
  GNU                  0x00000063	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::__lookup_th_unique(i)ip
  GNU                  0x00000088	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::map_lwp2thr(i)ip
  GNU                  0x000000cd	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::__iterate_thread_list(Fi(po)oipii)ii
  GNU                  0x000000d2	NT_GNU_INFINITY (inspection function)
    Signature: libpthread::thr_iter(Fi(po)oiipi)i

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.6.x series with an additional October 2015 security fix from OpenJDK 7 u91.

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

Full details of the release can be found below.

What’s New?

New in release 2.6.3 (2015-11-13)

  • Security fixes
    • S8142882, CVE-2015-4871: rebinding of the receiver of a DirectMethodHandle may allow a protected method to be accessed
  • Backports

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

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

SHA256 checksums:

  • 89183993d3dd794b4e2a428a8a0a35f1ce77c4ae64563e53f3a08c058ea134cc icedtea-2.6.3.tar.gz
  • 2d1b8e71739cc0d3c0afbab61a2093fb501ffa28b92f6d2630c684ae9ac48551 icedtea-2.6.3.tar.gz.sig
  • d89fea821068d38f1ca9e34bbc08ca1f6da985589d7064d7a5734d66dfd20c4f
  • df38aa10b4d30f3bae089dcc72f4c32fb2385cb541491791c12829960f53c612 icedtea-2.6.3.tar.xz
  • b7c377c64bcc20865a063b397b4c1cd44dad782a433d6da0ce89b690e54a6c94 icedtea-2.6.3.tar.xz.sig
  • f9373d52f121b97330f77e06064753eca949e703a5b32e501a70fd1dd8f007c0

The checksums can be downloaded from:

A 2.6.3 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 icedtea-2.6.3.tar.gz


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


$ mkdir icedtea-build
$ cd icedtea-build
$ ../icedtea-2.6.3/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 October 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.9 (2015-11-13)

  • Security fixes
  • Import of OpenJDK6 b37
    • OJ64: Backport hashtable to map changes from jaxp
    • OJ65: Remove @Override annotation on interfaces added by 2015/10/20 security fixes
    • OJ66: Revert 7110373 & 7149751 test removals now 6706974 is present (krb5 test infrastructure)
    • OJ67: Fix copyright headers on imported files
    • OJ68: Ensure SharedSecrets are initialised
    • S6570619: (bf) DirectByteBuffer.get/put(byte[]) does not scale well
    • S6590930: reed/write does not match for ccache
    • S6648972: KDCReq.init always read padata
    • S6676075: RegistryContext (com.sun.jndi.url.rmi.rmiURLContext) coding problem
    • S6682516: SPNEGO_HTTP_AUTH/WWW_KRB and SPNEGO_HTTP_AUTH/WWW_SPNEGO failed on all non-windows platforms
    • S6710360: export Kerberos session key to applications
    • S6733095: Failure when SPNEGO request non-Mutual
    • S6785456: Read Kerberos setting from Windows environment variables
    • S6821190: more InquireType values for ExtendedGSSContext
    • S6843127: krb5 should not try to access unavailable kdc too often
    • S6844193: support max_retries in krb5.conf
    • S6844907: krb5 etype order should be from strong to weak
    • S6844909: support allow_weak_crypto in krb5.conf
    • S6849275: enhance krb5 reg tests
    • S6853328: Support OK-AS-DELEGATE flag
    • S6854308: more ktab options
    • S6856069: PrincipalName.clone() does not invoke super.clone()
    • S6857795: krb5.conf ignored if system properties on realm and kdc are provided
    • S6857802: GSS getRemainingInitLifetime method returns milliseconds not seconds
    • S6858589: more changes to Config on system properties
    • S6862679: ESC: AD Authentication with user with umlauts fails
    • S6877357: IPv6 address does not work
    • S6888701: Change all template java source files to a .java-template file suffix
    • S6893158: AP_REQ check should use key version number
    • S6907425: JCK Kerberos tests fail since b77
    • S6919610: KeyTabInputStream uses static field for per-instance value
    • S6932525: Incorrect encryption types of KDC_REQ_BODY of AS-REQ with pre-authentication
    • S6946669: SSL/Krb5 should not call EncryptedData.reset(data, false)
    • S6950546: “ktab -d name etype” to “ktab -d name [-e etype] [kvno | all | old]“
    • S6951366: kerberos login failure on win2008 with AD set to win2000 compat mode
    • S6952519: kdc_timeout is not being honoured when using TCP
    • S6959292: regression: cannot login if session key and preauth does not use the same etype
    • S6960894: Better AS-REQ creation and processing
    • S6966259: Make PrincipalName and Realm immutable
    • S6975866: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest started to fail since jdk7 b102
    • S6984764: kerberos fails if service side keytab is generated using JDK ktab
    • S6997740: ktab entry related test compilation error
    • S7018928: test failure: sun/security/krb5/auto/
    • S7032354: no-addresses should not be used on acceptor side
    • S7061379: [Kerberos] Cross-realm authentication fails, due to nameType problem
    • S7142596: RMI JPRT tests are failing
    • S7157610: NullPointerException occurs when parsing XML doc
    • S7158329: NPE in
    • S7197159: accept different kvno if there no match
    • S8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported
    • S8005226: java/rmi/transport/pinClientSocketFactory/ fails intermittently
    • S8006534: CLONE – TestLibrary.getUnusedRandomPort() fails intermittently-doesn’t retry enough times
    • S8014097: add doPrivileged methods with limited privilege scope
    • S8021191: Add isAuthorized check to limited doPrivileged methods
    • S8022213: Intermittent test failures in java/net/URLClassLoader
    • S8028583: Add helper methods to test libraries
    • S8028780: JDK KRB5 module throws OutOfMemoryError when CCache is corrupt
    • S8058608: JVM crash during Kerberos logins using des3-cbc-md5 on OSX
    • S8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the information about the domain combiner of the stack ACC
    • S8072932: Test fails with access denied (“” “getDomainCombiner”)
    • S8078822: 8068842 fix missed one new file
    • S8079323: Serialization compatibility for Templates: need to exclude Hashtable from serialization
    • S8087118: Remove missing package from files
    • S8098547: (tz) Support tzdata2015e
    • S8130253: ObjectStreamClass.getFields too restrictive
    • S8133196, RH1251935: HTTPS hostname invalid issue with InetAddress
    • S8133321: (tz) Support tzdata2015f
    • S8135043: ObjectStreamClass.getField(String) too restrictive
  • Backports
    • S6440786, PR363: Cannot create a ZIP file containing zero entries
    • S6599383, PR363: Unable to open zip files more than 2GB in size
    • S6763122, PR363: ZipFile ctor does not throw exception when file is not a zip file
    • S6929479, PR363: Add a system property to disable mmap use in ZipFile
    • S7105461, PR2662: Large JTables are not rendered correctly with Xrender pipeline
    • S7150134, PR2662: JCK api/java_awt/Graphics/index.html#DrawLine fails with OOM for jdk8 with XRender pipeline
  • Bug fixes
    • PR2513: Reset success following calls in LayoutManager.cpp

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

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

SHA256 checksums:

  • 41baf774c52c1d2a0a094a6355635942e8ecb80cf7853fb6827da80f7818ba33 icedtea6-1.13.9.tar.gz
  • 49a01399630b5477af4ac7e240aaddb04d93578d54d659b560f5f02e687fd98c icedtea6-1.13.9.tar.gz.sig
  • 3a18bb1e540a0694ca1359e5adebaa5e1af66b4ba739b4e0d3ea733683a8330a
  • 61e0fb2ed0fc2d793a42e24d2192423f8a7ccb04f130d82d5889a0ecf52bc965 icedtea6-1.13.9.tar.xz
  • bf4c66cd3f64c2ca7510f8584c7bdd67012f4307d73e1f6232a1475df64c1caa icedtea6-1.13.9.tar.xz.sig
  • 51acad266f7c8a6cfd0662a1deab21a91acea88c46af2de2521897e81077b902

The checksums can be downloaded from:

A 1.13.9 ebuild for Gentoo is available.

The following people helped with these releases:

  • Andrew Hughes (all backports and bug fixes, release management)

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

To get started:

$ tar xzf icedtea6-1.13.9.tar.gz


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


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

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

Happy hacking!

In case you hadn’t noticed, I8C 0.0.1 was released last week. As well as the note compiler, this package contains I8X, an interpreter for unit testing compiled notes.

In case you had noticed and you’ve been working with it, please note there’s some compatibility-breaking source language and note format changes in the pipeline.

Infinity has a mailing list, and I want you to subscribe to it. Infinity isn’t just my project–anybody who might either produce or consume Infinity notes has a stake in this:

  • If you’re working on a debugger or other tool that might consume Infinity notes then you have a stake.
  • If you’re working on a library that might expose some API via Infinity notes then you have a stake.

I don’t know every issue that Infinity will have to solve, and you know things I need to know. So don’t sit on the sidelines! Send an empty message to and get involved.

At JavaOne, I'll be at the

OpenJDK Adoption Group BOF [BOF3377]

Monday, Oct 26, 8:00 p.m. | Hilton—Continental Ballroom 4

See you there!
Today I finally moved out of my lovely Ubuntu 10.04 LTS I was so proud in 2012, sad to read. That there are no longer any updates for it, only half of the problem. Many projects I am interested in started to fail during compilation because the toolchain is getting old. I was not updating because I did not like Unity, say whatever you want about it. I could learn it, of course, I have learned lots of way more sophisticated things (what about building GNU Classpath?). But I do not like the attitude, do not like decisions being made the way they are. Design must follow the user demands. Not in reverse. I gave a try to Gnome 3 as well with Fedora 22, played for some time but was not very impressed either and decided to drop after discovering that while it is possible to install the Gnome 2 - like Mate desktop, it is very difficult to actually switch into it.

My next distribution will be Ubuntu Mate. Value your freedom otherwise you will lose it!

Unexpectedly there were significant problems during updates . While in 2012 Linux installed no problem for me, now both Ubuntu Mate and Fedora 22 have booted in UEFI mode, raising lots of esoteric complains. It took half of the day for me to find where to switch of these UEFI beaties off in my wondercard, and another half to discover that the wondercard does not remember this setting, spontaneously reverting to "UEFI on". I cannot switch into UEFI, I have two other Linux distros on the same machine and do not want to loose. But now seems done.

This month I've released Orson PDF version 1.7, a compact and fast API for creating PDF content in Java through the standard Graphics2D API. This release features:

  • support for transparent images;
  • an implementation of the create() method to better support use against existing Java2D code;
  • addition of the GNU General Public License version 3 as the default license (a commercial license remains available for those that prefer it);
  • various bug fixes;
While Orson PDF has been created to provide PDF export for any Java2D-based code, my own use for it is within JFreeChart and Orson Charts. To provide an example, here is a chart that was exported with Orson PDF being viewed within Acrobat Reader: chartpdf.png

With the new GPLv3 license option, I've now also made the OrsonPDF repo at GitHub public, which will make it easier for other developers to work directly with the source code. You can also use GitHub to report any bugs or other issues.

The original version of this blog entry is published at

It’s been a long while since I posted anything. In the meatime we’ve made lots and lots of progress with Shenandoah. The most important news of the week is that Shenandoah has now been accepted as an official OpenJDK project. We’ve got a website, a mailing list, mercurial repositories, and a wiki page. The code hasn’t been moved yet, I am in the process of doing it. It will first land in our JDK9 forest (as we’re doing our main development there) and will be backported to JDK8 in a while.

Just to give you a summary of what happened in the last 1.5 years since I posted anything (bad me): we’ve implemented all that we wanted (runtime, interpreter, C1 and C2 barriers, weak-reference support, JNI critical regions support, System.gc() support, and lots of other smallish things), it’s fairly stable (still expect bugs here and there, but should run quite a lot of your code), performance looks good (on average, ~90% of what G1 does, some benchmarks as bad as ~70% relative to G1, some beat it by ~150%), pause times on largish heaps are significantly better than with G1 (but still not quite where we want it to be).

If you’re interested, subscribe to the new list, watch out for the code to land (or grab it from IcedTea in the meantime), and give it a try! Any feedback is welcome, as always! :-)

DataBasin's Select-Identify, an invaluable tool for many working with, showed erratic behaviour: extremely hard to reproduce even by sometimes re-running the same query on the same data set, the operation would just stop without any error in the console log, trapped exception or else.

After extensive debugging I found the problem in the queryMore method of the API implementation in DataBasinKit. If queryMore had to return just one record, it would malfunction.
Technically this happened because the size reported by in the queryMore is not the size of the objects of the queryMore, but of the original query.

The problem affects thus anything using queryMore: If you would select and had a batch size in download of 500, you would get a problem with 501, 1001, 1501 records and so on. 500 or 502 would just work fine. Combine this that the query size of the selectIdentify is dynamic and you get the idea on how difficult it was to reproduce.

Now it is fixed and the upcoming 0.9 version will have this fixed. All currently released DataBasin versions are affected by this bug.

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:


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.

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:

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.

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

gohai publish daily builds using his bot at:

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 {
int width; /* This is necessary because dispmanx elements are not queriable. */
int height;

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!

Xerxes Rånby

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


  • 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:

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'm happy to announce that JFreeSVG version 3.0 has been uploaded to SourceForge. JFreeSVG is a fast and lightweight API for creating SVG content in Java. This release features:

  • new handling for BasicStroke cap, join and miterlimit;
  • a new ZIP option when writing SVG to files;
  • a demo for exporting Swing UIs to SVG;
  • removal of the CanvasGraphics2D implementation (to focus on SVG only);
  • a fix for handling of PathIterator.SEG_CLOSE;
  • a fix for y-coordinate bug in drawImage();
  • a workaround for ClassCastException when exporting Swing UIs on MacOSX with Nimbus L&F.

To ensure that JFreeSVG provides a fully functional Graphics2D implementation, I tested it using the Swingset3 demo with modifications to redirect the screen output directly to JFreeSVG to produce SVG output. I've always liked the way that Swing uses the Java2D API to cleanly separate its rendering from having any direct knowledge of the actual output target. Here is an example:

SVG not supported in your browser!

This turned out to be an effective test, because it uncovered a bug in one of the drawImage() methods that has remained undetected in all previous JFreeSVG releases.

One last thing...the JFreeSVG repo at GitHub is now public, which will make it easier for other developers to tweak the code for experimentation or bug fixes (if you spot a bug though, please report it to me).

If you'd like to give feedback on this post, please comment via the JFreeSVG forum.

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'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:

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.

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