It is a while since I have been to JavaOne, in fact I have not been since the Oracle acquisition of Sun and the move of JavaOne from the Moscone Centre to the Hilton, so my first observations are that it was a lot smaller than the old JavaOne, with less "tracks" and of those, less were focussed on the deep down technical aspects and more of them were focussed on development frameworks. However, of the sessions that I attended, there were definitely some useful bits of information.The most interesting session I attended (other than my own, which I will talk about later) was on the SAP JVM, which is a fork of hotspot but with added features to improve supportability and diagnostics. One of the most interesting changes was that they have added a lot of information to the "core" exceptions that are often seen. So, for example an IO exception gives more details about the file that was being accessed, a ClassNotFound exception will tell you which classloader it was that failed to find the class, etc. They have also added a lot of information to thread dumps, so each thread can have additional "annotation" information associated with it, and they use this to record the user that the thread is working on behalf of, the amount of IO that has been done, and any URLs the thread is currently working with. All of this adds up to a really nice looking JVM which is unfortunately (due to licensing restrictions) only available for SAP applications. If SAP can find a way to overcome these restrictions (perhaps forking OpenJDK rather than HotSpot) I would have no hesitation in recommending that our customers consider this as their default JVM choice.
One of the other interesting sessions I attended was on Shenandoah, the garbage collector being written by Red Hat (don't worry too much, its being written by ex-sun employees who used to work on hotspot). Shenandoah is a low pause garbage collector that is looking to give lower and more consistent pauses than those offered by G1, although the motivating factor for Red Hat seems to be "because we can" and they didn't have a good set of acceptance criteria for when they would consider it ready. It is still in early stages at the moment, and while it does deliver low pauses, it has a significant overhead to performance, as to allow compaction of live memory they have introduced a "read barrier" check to all reads, which significantly slows down JVM performance. It is certainly an interesting project, but without a set of real performance figures, or customers that want to use Shenandoah (they were asking for customers to help them test it at the talk, as so far they have no real users testing it). I think it will struggle to achieve much significe. There were a number of Azul engineers at the talk who seemed to have tried all this before and decided it wasn't the most effective approach.The most interesting talk was obviously mine ;) I was running a lab on JMX, which was "sold out" to 60 attendees, and I thoroughly enjoyed it. While I have given talks before I have never done so in front of an audience that was so engaged, and so receptive to the message I was giving. It was great to see developers that wanted to add monitoring to their application before things went wrong, and were getting excited about what to me is one of the best APIs in Java (but to most developers is of no interest whatsoever).
The exhibition area was smaller than it used to be, but there were a surprising number of monitoring products around, most of them though seem to be coming at things from an end-to-end transaction monitoring approach - adding a request ID to the incoming request and propagating it all the way down into the database, then giving you timings of how long each process took. The odd thing was that none of these tools incorporated the existing JMX metrics exposed by containers into this approach, and talking to the people on the stands, none of them understood why that would be a useful thing to do. There were a couple of other interesting monitoring tools, but the one that really caught my eye was HeapStats http://icedtea.classpath.org/wiki/HeapStats (developed by NTT), which is more of a problem identification tool than monitoring. HeapStats provides real-time monitoring of the heap contents to look for problems, it seems an interesting approach, and while the tool is far from being polished it certainly shows promise.
Unfortunately this still leaves me in the position that none of the monitoring tools around fit what I feel a good Java monitoring tool should do - the ones that are trendy at the moment are gathering good information if you want to know why one particular transaction is slow in the database, but if the problem is that your AJAX requests are exhausting your mod_jk thread pool then you aren't going to see that, and you really need to.I'd like to return to JavaOne next year, when hopefully there will be some deeper dive technical sessions, and with any luck, some of the monitoring tools will do both transaction tracing and JMX monitoring.
