The Planetarium

If you're in need of a fun way to get to grips with JavaFX, then take a look at this oddly diverting extra-sensory game-cum-viral-thingy. The Janitor isn't cool enough to really understand yet, but you need to write JavaFX code and wear cool t-shirts and figure out stuff.

And just for fun, check out who's got the bragging rights for JVM performance on multi-core servers with Intel's Nehalem chip: is it IBM's J9 or Sun's HotSpot and the $500 riding who has the best open source credentials.

Another kind of mockery that lives in fable is speed mocking predictability: here's an interesting interview on the Java Real Time System.

Today, Mark posts a major update to the plan for JDK 7 reiterating the feature list first announced in December, and providing a milestone by milestone plan for when to expect each of the new features to make it into the builds for you to try out.

We're currently at milestone M2, which includes the new G1 garbage collector (with some new bug fixes) and JSR 203 aka New IO APIs 2.

There should be a nice package to play wth in M3 in time for JavaOne, which will add JSR 292, with the Java language changes in Project Coin and Swing App Framework coming by fall this year.

There are some features in the feature list that have not yet been scheduled into the plan (like the modularity work in Project Jigsaw) but stay tuned, because they will get pegged to a milestone soon.

Think of concurrent programming as nothing more than traffic management.

You may have been lucky in your programming work so far only to have to think about a single lane of traffic, relying on the road authorities periodically to raise the speed limit to allow your vehicles to go faster. But as hardware makers lay wider freeways with multiple lanes, and as your traffic gets heavier, you may need to start worrying about how to use the capacity better to get everyone where they need to be on time.

Perhaps building a thread gate, the equivalent of a traffic signal. As this article shows, and as applied to a prime number generator, a thread gate let you manage the execution of tasks where there are dependency on the completion of some of the tasks on others in your program. Just as traffic at a four-way intersection is regulated by a rule, albeit at intersections, a simple one: each two way direction takes it in turns to avoid collisions.

Or using a BlockingQueue, already part of Java SE. A BlockingQueue is something akin to the kind of smart traffic signals that tracks waiting vehicles to decide when to allow them to pass. This blog illustrates its use in bridging the gap between two intensive tasks: parsing large amounts of data from heterogenous sources, and persisting it.

Or, looking ahead to JDK7, a variant on the BlockingQueue called the TransferQueue, described in detail here. Although not a perfect anaogy, its smarter kind of traffic signal you have have seen metering traffic entering freeways, which takes into account both waiting vehicles and the flow of traffic on the freeway.

So if you're tiring of life in the single lane, maybe its time to experiment with the Concurrency Utilities in Java SE, and look further down the freeway to those coming in the future.

Update: Do check out Brian's talk about parallelism in Java from Devoxx here (How could the Janitor forget, he was in the audience). Thanks Patrick for the tip.

Whether or not you are coming to JavaOne this year, you should count having a preview of JDK7 ready for you to try. So let's check in on where the larger features on the plate are at since Mark talked about JDK7 at Devoxx in December. (And since Alex gave one of his updates).

Modularity work is progressing with proposals up for comment in Project Jigsaw.

Good stuff coming in the VM with the support to turbo-charge Java SE for multiple languages, and the new garbage collector, which made it into the latest build of Java SE 6u14.

Though not enough for some Swing developers (who might be interested in this project), we'll bring some important improvements to Swing.

Java language-wise, Joe is sifting through the small Java language proposals as part of Project Coin. Opinions still welcome. And you check out the project that will add annotations to (all) Java types by trying out the latest Checker framework.

NIO2 is tuning the new APIs for scalable IO, including the new FileSystem API, which you can get in the latest build.

If you've never dared do more that up the maximum heap size on the JVM, but have wondered which methods in your app the JIT is compiling, or have been curious about seeing what happens to your app when you change garbage collectors, you should check it out Charlie Nutter's awesome crib-sheet on some of the HotSpot JVM dials and knobs that he's been using in the quest to further improve the performance of JRuby.

And speaking of other languages on the JVM, there was an interesting interview at InfoQ about Clojure with the author of a new book on this functional language with a special penchant for concurrency. Its a language that is not object oriented (is it the past, is it the future ?), but nevertheless holds many capabilities for modularity via namespaces and multimethods.

And speaking of modularity, Alex has posted two calls for comments in regard to the modularity work for the Java language for JDK 7 in the Java language, part of Project Jigsaw. First, the problems to address, and second a statement of the requirements of the project. You read the discussions here, or get it in your inbox here by signing up to be an observer of the expert group.

In taking a week off, the Planetarium has lots to catch you up on !

JavaFX has already issued Update 1, mostly with media playback improvements, like progressive download. The Janitor was podcasting with Cote after the launch, and JavaFX found a place on the cool wall at Devoxx. And its nice to see how many people are putting up their JavaFX apps on their blogs. And making new JavaFX tools, and running the SDK on Linux, even as the JavaFX team works on the production version. So is JavaFX itself an amazing Java application ?

In Java SE-land, there's new buzz over what additions to the Java language to put in JDK 7, with votes from Devoxx and JavaEdge. Joe Darcy put up a list of guiding criteria. Meanwhile there is an early access version of the 64bit browser plugin (high on the request list for too long) for the JRE as part of the upcoming Java SE 6 Update 12. And news of some really interesting optimizations of Java SE on the AMD chipset to get the best out of its multiple-cores.

Meanwhile, a new Java ME project has popped up, literally ! Either as a MIDlet or popping up as your phone's idle screen, the Java ME On Device Portal (ODP) offers a slick way to get new Java ME apps, like Flickr clients or weather apps, onto your users' phones. Whatever the backend app store. Another reason (see TS-15) to come to the MM3D conference in the new year.

Back in 2009 !

The wonderfully scalable and high-performing engine beneath Java, JavaFX and many many other languages continues to attract attention as it tries out a the new G1 garbage collector slated for JDK 7.

Looking even further into the future, The open source, all-Java highly modular Maxine VM is a hot bed of research ideas for future iterations of the HotSpot JVM. You can watch Bernard's in depth talk about it from the recent JVM Language Summit...

...about which JRuby lead Charlie was interviewed this week, in the context of making the JVM the best engine for other languages...

...perhaps explaining why some new languages like Ioke (more here, think Smalltalk+Lisp+Ruby) are designed with only the underpinning of a JVM in mind...

...and speaking of underpinning, the HotSpot team is testing a fix for one of the gnarliest bugs in the JVM ever, which if successful, should provide reliable parallel classloading.

Just another thing the JVM is doing to scale best on multiple cores.

To get traffic flowing faster on roads, planners don't raise the speed limit, they build more lanes. That's what chip manufacturers have been doing for some time now as traffic per core has become too hot to handle.

And, all the way back since 1998 with the introduction of the E10K with 64 parallel processors, that's what the HotSpot JVM has been doing: parallelizing the work of the JVM so that garbage collection, classloading and other supporting tasks happen concurrently. Which is exactly how to get the traffic flowing faster on the multi-core superhighway.

Great for scaling Java web application performance on multiple cores, because they are inherently multithreaded (and you got your own thread to load this page). But for computing intensive apps like large monte carlo simulations, or processing massive data sets, more traffic management is needed at the application level to juice the system.

With the addition of the Java Concurrency framework back in Java SE 5.0, developers with a big gnarly task to give to a multi-core processor have an API to break it down into multiple parallel threads using, for example, task scheduling and sychronization policies. Helping them use all the lanes on the computing freeway instead of just one.

And there's more good news in the works: a new, fully concurrent garbage collector and more concurrency utilities for developers in JDK 7; and perhaps direct support for concurrency in Java EE too.