Back to newsletter 116 contents

One study found that 86% of downtime in production systems was due to resource leaks. That covers memory leaks, obviously, but also files not closed, connection pools that get depleted, runnning out of disk space, locks that aren't released, and so on. Of course there are many more issues that occur in production, but those other issues tend to cause other types of incidents rather than downtime.

Not all resources can be managed by the JVM, but it can certainly try and help out where possible. So Josh Bloch's "Automatic Resource Management" proposal for Java 7 is spot on in trying to target this area. The actual implementation targets objects which define Closeable or AutoCloseable, automatically closing the object when it is finished being used.

When I first heard about this applying to Closeables, I misunderstood it to mean that all classes that implement Closeable will automatically have the close method called on the instance when the object goes out of scope. But that is already easily done by simply adding a finalize method for the class which calls close (and is implemented just that way for many classes, e.g. FileOutputStream). No, this proposal is about having the compiler do what the programmer should do but often forgets - closing resources right after you have finished using them.

A note from this newsletter's sponsor

To achieve this the language is changing very slightly in JDK 7 to add in a new form of the try block where you can define and create a Closeable instance:

try (Something x = new Something()) { ...

(Have a look at the example here).

Usually I'm quite neutral about language changes, but this time I'm really enthusiastic about this one. The improvement in readability is great, but that's just the icing on the cake of excellent proper handling of Closeable resources.

Now on with this month's newsletter. We have all our usual Java performance tools, news, and article links, though still no Javva The Hutt as sadly Glastonbury proved too much for his constitution and he's not yet recovered. Over at fasterj we have a new cartoon showing ClassNotFoundException; and, as usual, we have extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• Java Performance Tuning Event on August 16th in London
• you need to clear threadlocals when you add a thread back to the pool.
• Java 7 has really good support for filesystems. One particularly nice performance addition: File system change notification.
• GroundWork Open Source releases GroundWork Monitor Enterprise 6.2 with Java monitoring
• 20 PB/day processed through Hadoop. That's pretty good scalability
• Java is much faster than C slide from Jazoon
• update on Closeable
• JDK 7 New Features, including Automatic Resource Management
• JDK 7 New Features (efficient listing of directories, and useful comment: "Multiplexed I/O is a great choice when mapped to operating systems with highly scalable and performant polling interfaces - Linux and Solaris are examples. Asynchronous I/O is a great choice when mapped to operating systems with highly scalable and performant asynchronous I/O facilities - newer Windows operating systems come to mind")

Tools

Java performance tuning related tools.

• GroundWork Monitor Enterprise
• Using Enumerations in for-each statements
• on-line monitoring service for Tomcat, Glassfish, JBoss, Jetty and Openfire including offline alerting and Java statistics.
• using jvisualvm

A note from this newsletter's sponsor

Articles

• 5 things you didn't know about ... Java performance monitoring, Part 1 (Ted Neward/IBM)
• 5 things you didn't know about ... Java performance monitoring, Part 2 (Ted Neward/IBM)
• The Sleek EnumMap and EnumSet (Dustin Marx/marxsoftware)
• DateFormat in a Multithreading Environment (Justin Cater/javacodegeeks)
• Thoughts on scalable web operations (Royans Tharakan/royans)
• Creating Scalable Digital Libraries (Tavis Hampton/highscalability)

Jack Shirazi

Back to newsletter 116 contents