Java 7 What`s New, Performance Benchmark 1.5 1.6 1.7

Java is one of the language which has overhauled it’s underneath technology ground-up. Even though, the basic concept of running inside JVM holds good, the way JVM handles Objects, Memory management has completely been revamped.

A lot  changed over 1.4 to 1.5. There were critical compile-time improvements, Runtime smartness and with Java 6 more performance optimizations; Java 7 – the modularity.

Let’s start discussing each aspect of Java 7 which makes it go Loud –

• Modularization – JSR 294 or Project Jigsaw
• JVM Support for dynamic languages
• More New I/O APIs which are nearly finished, includes true asynchronous I/O  and finally a real file system API – JSR 203
• The native language support for XML. (probable)
• Safe rethrow – Allows a broad catch clause, with the compiler being smarter on what you’re allowed to rethrow based on what is thrown from the try block. (I had not seen this before but it looks nice)
• Null dereference expressions – Null checks with ‘?’ syntax similar to Groovy… lettign developers avoid a nest of null checks.
• Better type inference – Example around generics instantiations, but it was not clear how far the inference would be taken (the more the better in my opinion).
• Multi-catch – Allows a comma separated list of disjunctive exception types in catch clause.
• JSR 296 – Swing application framework – It still needs to be easier to create Swing apps.

Update: As per Sun Blogs

After much discussion it’s become clear that theSwing Application Framework API as it is today hasn’t reached consensus and we feel still needs further design work done.

Since the SAF API was committed to milestone 5 of JDK7 and that time is already here, this date is now impossible, and we need to decommit SAF from any specific JDK 7 milestone.

The “Small” Sun changes are:

• Upgrade class loader architecture – Work started in Java 5 and continues to evolve. There are some deadlock issues today in classloader delegation that will be addressed.
• XRender pipeline for Java 2D – This was an Open JDK Integrators Challenge project,and is an analog to the OpenGL pipeline but much more portable across x11.
• Swing Updates – JXLayer, DatePicker, CSS styling (maybe) that Ethan Nicholaus (sp?) has been working on
• JavaFX

Update: Few new Small changes of  “Project coin” are available here.

The “Fast” changes from Sun (This refers to performance improvements):
Hotspot run-time compiler enhancements

• A couple of concurrency (JSR 166) tweaks (Better support for Multicore)
• G1 Garbage collector- Leads to much smaller pause times and hopes to replace CMS (Concurrent mark sweep) GC
• Compressed pointer 64 bit VM
• MVM-lite – Multiple Virtual Machines will help run isolated applications and allow a kill -9 on a Java application. Mark said it is not clear what problem would be solved, and original project was extremely ambitious, but desire to drag apps out of browser plugin presents a good usage and need for MVM. (This could be moved to a later release)

The Theory and Practical

As far as what changes you’ll see in your day-to-day work, my guess is that the major impact will be stuff like JSR 203 which overhauls the file system API. If JSR 310 is included, then it would also have a major impact on how you interact with any aspect of the date and time APIs. Many of the other JSRs will only impact you if you happen to already do something in that particular area (JMX – JSR 255, concurrency – JSR 166, etc).

The biggest thing most people will notice may be performance. This is my favorite. And that is exactly what I thought about writing, and it expanded the scope to features aswell. As usual, each JDK brings a whole new set of performance optimizations. We’ve already seen some very encouraging results in String performance, array performance, and a new concurrent garbage collector (G1). I suspect many people will find that their existing code will work and run noticeably faster than it did in the past.

Performance

I saw this one about the new features in Java 7:

http://www.ibm.com/developerworks/java/library/j-jtp03048.html

They use MergeSort as an example of how to exploit multiple CPUs for sorting. Java 7 has the nice feature, that it can now decide at runtime, how many threads should be used to solve a particular problem (see the coInvoke part).

However, there is this tricky constant, SEQUENTIAL_THRESHOLD, which is used to decide whether to enforce sequential processing or not. How do you set this value? Well, you set it at design time, even though the example was meant to show how Java adapts at runtime…

The next thing is that the whole array is passed as parameter. No matter what programming language you use, this is a bad design. If Java doesn’t copy the memory, you may have 2 CPUs looking at the same RAM area. If Java has a runtime optimization that detects that 2 CPUs are looking at the same area, and decides to copy the data, it will copy too much data…

I’m not sure this example would perform better on a 4-CPU machine than on a single-CPU machine with the same CPUs…

The basic problem in all this is, that it is extremely hard to find real world examples of parallelization of algorithms that can be optimized to any kind of parallel hardware. Good multi-threading must be done on a functionality level, not on the algorithm level.

Also, every time we add multi-threading to code, we make it more complex. In other words, it comes at a cost. I predict that some of the future performance gains don’t come from making algorithms more threaded, but from changing data structures, reducing memory footprint and simple optimizations. As the price of more performance increases, efforts will be spent where most speed can be gained at the lowest price.

> java -version
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b66)
Java HotSpot(TM) Client VM (build 16.0-b06, mixed mode, sharing)

And the Result The Winner is … Java 7

Java 5 <=== 18% faster=== < Java 6 < ===46% faster===< Java 7

Note – This was totally based upon my tests, doesn’t necessarily means it’s for overall Java. The results may vary for different kinds of computations.

Alright, When is Java 7 coming ? 🙂