Java Magazine Interview

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.

O.R.k. Remix Contest

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!

Debugging the JDK with GDB

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 😉

Another Schedule Change


Hi all,

I’ve done another small change to the schedule. Basically the “Java 9: Make Way for Modules” and “Beyond Java 9” presentations have been swapped out, this is the new schedule:

10:30 The State of OpenJDK
11:00 Java 9: Make Way for Modules!

14:00 Beyond Java 9"

The FOSDEM booklet has already been printed, so those changes will not be visible. They have been picked up by the online tool, though:

Java DevRoom Schedule changes

For technical reason and in accordance with the speakers, I changed slightly the schedule.

The “Fortress” talk has been canceled, while I switched “Building an open Internet of Things with Java and Eclipse IoT” and “Java restart with WebFX“, and this last one will get a slightly longer slot:

12:30 – 12:55  Building an open Internet of Things with Java and Eclipse IoT
17:00 – 17:55  Java restart with WebFX

The full schedule is already online:

Free Java DevRoom Speaker selection

You can find the original announcement here

It was a very a difficult choice this time and it took a bit to understand the best schedule and try to get the most tracks.

This is the list of approved talks, in no particular order. Thanks to anyone who participated, unfortunately we were not able to select every one, and the choice this year was insanely difficult!

I hope the speaker who we could not select will still join us to enjoy what we are preparing for this year Free Java DevRoom celebrations!

  • Packed Objects, Object Layout & Value Types – a Survey
  • Shenandoah – Project overview
  • Sustaining the zero assembler port in OpenJDK: An inside perspective of CPU specific issues
  • Open Heart Surgery: HotSpot Debugging at the OS Level
  • Life in the trenches
  • The State of OpenJDK
  • Java 9: Make Way for Modules!
  • Beyond Java 9
  • What Three Big Development Trends Mean for Java
  • The ARM microJIT
  • What Lies Beneath?: Lessons learned hacking the OpenJDK interpreter/compilers
  • JCP State of the Union & Progress Report
  • Diagnosing Performance Issues Using Thermostat
  • Caciocavallo, or how we ported OpenJDK from embedded to cloud and still liked it
  • Java restart with WebFX
  • The Wisdom Of Crowd Testing OpenJDK
  • InvokeBinder: Fluent Programming for Method Handles
  • OpenJDK Adoption Group Q&A
  • Fortress
  • IcedTea-Web goes offline and beyond
  • MappedByteBuffer Operations SpeedUp of 150x
  • Cache2k, Java caching turbo charged
  • Building an open Internet of Things with Java and Eclipse IoT
  • JFree – The Long and Winding Road (Ahead)
  • Jitsi Videobridge in Cryptoland: the adventures of a Java WebRTC video router on the road to supporting 1000s of video streams