JBoss Developer Studio freezes with XSD, WSDL, SwitchYard editors

Recently I started facing a strange issue on my ArchLinux boxes with JBoss Developer Studio (which is an enriched Eclipse under the covers). I was not able to open XSD, WSDL or SwitchYard visual editors. Part of the GUI just froze. Clicking on the close button opened the close dialog which allowed part of the interface to be redrawn.

I was quite desperate about it. It only affected my ArchLinux x86_64 boxes. I used multiple JVMs (Oracle, OpenJDK), different window managers (Fluxbox, Openbox, Gnome Shell). I verified the same Linux kernel in Fedora does not cause the issue. So what now?

What gave me some guidance was this command I found on StackOverflow (you must provide your own process number):

cat /proc/803/maps | awk '{print $6}' | grep '\.so' | sort | uniq

I compared the libraries before and after opening the problematic editor.

39a41,42
> /usr/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.so
> /usr/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-file.so
50a54,56
> /usr/lib/libcom_err.so.2.1
> /usr/lib/libcrypt-2.18.so
> /usr/lib/libcups.so.2

This was a trace of a pretty old Eclipse bug. Surprisingly, the bug is still present in Eclipse Kepler with Gtk 2.24.20.

I tried the suggested workarounds by disabling CUPS server in /etc/cups/client.conf and passing -vmargs -Dorg.eclipse.swt.internal.gtk.disablePrinting to Eclipse. Both helped a little, but did not make Eclipse completely usable.

What really helped me was installing cups-pdf package, enabling CUPS via

systemctl enable cups.service

Then I started the service with

systemctl start cups.service

And configured a PDF printer at localhost:631.

I cannot express my happines about running CUPS on my machine :-(

Book review: Well-grounded Java developer

Vital techniques of Java 7 and polyglot programming

• Publisher: Manning
• Authors: Benjamin J. Evans and Martijn Verburg
• Ranking: I would definitely recommend this book

Originally, I wanted to write a complete review of this book but I found some really good reviews already available on the internet. What I would like to say is that this book is exactly what the title reads. If you want to be a good Java developer and you mean it, you should know all the information in this book. A great thing about it is that it has a very balanced level of details. The information are presented in a compact well understandable form without wasting the reader's time. So if you did not read it yet, go to the nearest book store or library.

HashMap serialization issue

Today, we discovered an interesting behaviour in Oracle JDK 7 with my colleague. This also affects OpenJDK 7. There is a change in the implementation of the HashMap serialization. If you serialize and then deserialize a HashMap, two private fields are changed. The first is threshold and the second is table. While these changes do not seem to have any effect on the public behaviour of the class, it makes various testing a little bit harder.

For example, you developed a client/server application that exchanges some objects. These objects might hold some properties in a HashMap. To test the correctness of the communication channel, you send a serialized object from the client to the server. The server deserializes the object, changes an attribute and sends the serialized version back to the client. The client performs the same changes to its version of the object and serializes it too. Then the client compares the serialized byte arrays. With JDK 7 it finds them different and this is a problem in my opinion. Or do you find it a completely insane integration test scenario? I already found it in many projects so I suppose it is not that uncommon and bad.

A reproducer can be found at GitHub. I also logged an issue with Oracle. They are now about to review it. However, I suppose they are not going to fix the issue since it does not influence the public API. Who cares about testers...