Monthly Archives: July 2012

Where to put tools.jar in JRE 7?

If you are distributing JRE with your application and you happen to also distribute tools.jar as well. The you have probably copied tools.jar to the jre/lib/ext folder.

This is viable option and have worked for me in the past (i.e. with Java 5 and Java 6). However this does not work in Java 7. If you do this in Java 7 you won’t get system compiler instance for example (i.e. executing code javax.tools.ToolProvider.getSystemJavaCompiler() will return null)

What I found out (painfully) that in Java 7 you have to put tools.jar directly to the jre/lib folder!!!

When you do this you can execute javax.tools.ToolProvider.getSystemJavaCompiler() and get a compiler instance as expected.


Updated (2012-07-10):
Oracle has accepted bug report for this problem. You can see it in Oracle’s bug database as 7181951.

Updated (2012-07-14):
Oracle has closed the bug with the following evaluation:

Closing as not a bug. That behavior was neither specified nor intended.
Posted Date : 2012-07-13 15:57:50.0

So I guess it means that the only true place for tools.jar is the jre/lib folder!


Ouch…multi-catch

In my previous post on Java 7 I’ve outlined some problems one might face when converting project to use it. Here I would like to outline issues I’ve discovered when I actually migrated code from Java 6 to Java 7.

Contrary to what I’ve been expecting, actual upgrade to Java 7 turned out to be bumpier. One of the reasons was converting code to use new Java 7 features. For that I’ve used NetBeans 7.2 RC1 and it’s “Inspect and transform” feature. (By the way Intellij IDEA also has capability of automatically converting code to Java 7)

Overall the tool did a great job and I was able to convert big project of several thousand classes in a matter of minutes. However since conversion resulted in more than 1000 classes modified it was not feasible to manually check all of them. As the result I’ve found about problems out only after nightly CI build have failed. Which brings me to the core of the post – a multi-catch conversion issues.

Multi-catch conversion pitfalls

So here is existing code from one of the classes before conversion to Java 7:

And here is the result of the conversion:

As you can clearly see the updated code is not semantically equivalent to the original code!!!

Before the change method rollbackTransaction(Throwable) would have been called in case of any exception (checked or unchecked), but after change it is called only in case if IOException or XMLStreamException is thrown.

As the result after such a change you get leaking transactions (zombies that are not closed). And this is kind of a bug that one would call a blocker or if you wish absolute top priority.

To me this conversion issue seems like a bug in NetBeans and a scary one. But it should be also a remainder to all of us to check the results of any automagic stuff that our tools are doing for us. 😉


Updated (2012-07-14):
I’ve submitted bug report to NetBeans team as Bug 215546. Let’s wait for evaluation on this one.


Latency Tip Of The Day

"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)

Psychosomatic, Lobotomy, Saw

"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)

Blog-City.com

"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)

Mechanical Sympathy

"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)