Tuesday Aug 05, 2008

Want your Java fast or predictable ? Java RTS 2.1 is here

When you leave work, would you rather it be likely that you get home really quickly, or would you rather be sure you will get home by a certain time ?

If you send a birthday card, would you rather they try to get it there as soon as possible, or just know it will definitely get there on the day ?

If you order something for yourself on Amazon, do you pick the cheapest delivery option because most of the time it gets there 2 days after it ships even though it doesn't say so ?

Fast, and Better Late than Never, but...

For many years, we have focussed in Java SE on making the runtime fast. Fast in a number of ways: fast to render graphics (in particular, in the upcoming 6u10 release), fast to execute server applications, fast to start up, for example. And if you follow Dave Dagastine's blog you will know that we frequently hold the gold medal for various of the races laid out by the SPEC.

But one thing the HotSpot JVM is not tuned for is hard predictability. That is to say, there is no guarantee that a certain task will take no longer than a certain amount of time. The native OS may choose to schedule something ahead of the JVM process supporting your application. Classloading or performance optimizations such as just-in-time compilations may put your application thread in the backseat. Or, probably most recognizable to users of your application, a garbage collection may kick in when you least expect it. Such non-deterministic behavior is just fine for many applications. Moreover, it allows the JVM to tune for big picture performance characteristics, like overall throughput averaged over a complete run of your application, even if one or two of your application tasks unexpectedly end up taking longer than you thought. The needs of the many outweighing the needs of the few, in Vulcan.

But anyone who has been late picking up a small child from daycare will know that there are some tasks that just have to get done within a certain time period. Even if it's at the expense of completing others you thought you might have time for.

...sometimes, Best is Never Late

So for nearly as many years as we have had been tuning performance in the JDK, Greg has been leading our real-time variant of Java SE, called the Java Real Time System (Java RTS). This implementation is at the other end of the predictability versus speed continuum, where your application may select tasks (zero to all of them) as tasks that must complete within a given time period. There is no 'better late than never' here: late equals failure for this implementation of Java SE.

Java RTS 2.1 is Released !

And Java RTS recently hit a new milestone with a significant upgrade to version 2.1, which you can check out here.

The main elements of Java RTS over the usual Java SE you are probably more familiar with are:-
  • the javax.realtime.\* APIs
In addition to the regular Java SE APIs, these APIs allow you to code parts of your application with the real-time guarantees it needs. This means Java RTS runs regular Java SE applications, but provides no realtime guarantees to any of the tasks in the application unless you adapt the application to use the javax.realtime APIs to ask for those guarantees.
  • a VM tuned for realtime behavior
For example, containing a garbage collector that runs at a lower priority than real time application threads so as not to delay them.
  • Bindings to the realtime aspects of the underlying OS
The realtime system is only as good as the underlying OS can guarantee (which is why we only offer it on Solaris and some Linux distributions). These bindings, for example, ensure that JVM threads are properly scheduled by the OS scheduler.

Our own Paul Hohensee and Brian Goetz have been writing in detail about both the additional programming APIs and the implementation, here and here.

We've got folks using the Java RTS in traditional settings like industrial automation projects, an of course in robots - where the multiple processing involved in moving a complex limb have to be coordinated, even at JavaOne.. But more recently we have a lot of interest in the financial world from folks writing trading applications, where certain timing guarantees need to be met.

In a world where even driving in a circle can get crazy, its good to know you can choose Predictable if you need it.

Tuesday Jul 08, 2008

Ask us about the 'Consumer JRE'....all week !

Ken, Richard and I are doing a special event this week over at the SDN, and its your chance to ask us anything you feel like about the upcoming Java SE 6 Update 10 release, aka the 'Consumer JRE'.

Each day we answer as many of the questions people send in, and they all get published online. Its like a slow motion chat !

Have you tried out the beta yet ? (nearly a million people already have)

Friday May 16, 2008

Top 10 JavaOne 2008 Rich Client things

Here's my top 10 list from Java on the client at JavaOne this year. Enjoy x 10 !

Top 10
What is it ?
Know more...
The JavaFX SDK is (almost) here !
Hot demos (there were quite a few) and a cool new website are all good, but signing up for the SDK to get it next month or so is going to be awesome. Its built with Java, built on Java. Its built in Java.
JavaFX can run parleys.com. Did I mention its fast ?
JDK 6 is everywhere
JDK bundled with Linux, JDK 6 for Mac
On stage, I mentioned that the JDK, from the OpenJDK JDK6 project, is bundled with the latest release of the Ubuntu distro. Since then, its started shipping inside Red Hat's Fedora 9, and Red Hat's Enterprise Lunix too. Who's next ?
And, have you tried the JDK 6 release for OS-X yet ?
The Consumer JRE
Get the latest beta of JRE 6u10, its quick, quick, quick. Quick to download, quick to install, quick to start applets.
Applets that you can pull out of the web page. Applets that can live beyond the browser and drop onto the desktop. Applets that developers can write in Java or designers can write in JavaFX Script. See and believe that applets are back.
Get the release candidate of THE single cockpit for watching, diagnosing and tuning Java applications. If you thought JConsole was cool, you need to check VisualVM out. It integrates all the management and profiling tools for Sun's JDK into a graphical environment. See it for yourself.

On2 Media and JavaFX
Cross screen video, cross device sound.
Finally, one rich media format you can depend on that spans all the devices you own. Because it'll be built into JavaFX.
JavaFX Tools
First views of new tooling.
You've had the NetBeans support for nearly a year for JavaFX Script - and Eclipse support for that matter - but we previewed a new tool called JavaFX Distiller (see here: jump to minute 14). If you've ever written a GUI, and needed a little artistic help from a visual designer, this is one you need to know about.
Making better looking applications easier on today's Java ME devices.
This is a new open source community project in early access to add some portable fit and finish to your MIDP 2.0 applications. Shrinking some of the familar core pieces of the Swing framework, all you need is the NetBean Mobility pack to get started with it.
Java SE 7 sightings
Modularity, OSGi and turbo charging multiple languages I talked with Bob about some of the pieces we'd like to include in Java SE 7 that are progressing well. Here also are my session slides with more detail. In particular, the Java Module System, and its support for OSGi in JDK 7 (which is gaining some encouraging support) and the DaVinci project for accelerating multiple language support which has started producing prototypes.
BluRay, Java and Neil Young
Java as foundation for HD content.
In January, BluRay emerged as the winner of the biggest format war for a generation. So just in case you didn't know BD-J, the programming model for interactive BluRay content (so its on all the BluRay players), is based on Java ME (Personal Basis Profile, to be precise), and Neil Young announced he's releasing his full catalog on BluRay, using BD-J to provide all the interactivity.
Java SE Performance
Latest high performance release of Java SE
Its tuned for the racetrack and breaking records !

Tuesday Mar 25, 2008

No-one wants to look dumb

Do you like drinks that taste like Pschitt ? Or is your car a Charade ? If so, you may be in the cross hairs target of the new MSN ad campaign.

My first experience of what appears to be the latest in a noble history of brand eroding, unintentionally image-savaging product advertising faux pas happened while I was driving to work on highway 101. I passed a billboard that suggested to me that MSN search could be Sherlock to my Watson.

Recalling Nigel Bruce's charming yet bumbling portrayal of Dr Watson, and the irritatingly pedantic Sherlock Holmes played by Basil Rathbone, I realised something evil was afoot for me with the underlying messaging. Bumbling I have no desire to be, still less the sidekick of a pedant; I wondered why I felt as uncomfortable as if someone I didn't know had just asked to be my friend on facebook.

You'd think playing a poor third in a lucrative search advertising market that can average 5c per search is place which requires you do kick it up a notch or two, so when I got home I made the uncomfortable discovery that what I had experienced was just a small part of a whole family of advertisments based around the concept that using MSN will make me clever.

Problem with the brand building proposition here is the tagline: 'No-one wants to look dumb'. Which may speak to those people who will engage deeply with a brand that suggests they are a) stupid and b) ashamed of it, but to me ? Not so much.

Perhaps MSN hopes to establish a newfound success by embracing those in our world with low self-esteem (and target them with products they might enjoy), and whose highest aspirations are to be informed by a vast corporation not to wear frostwash jeans on a first date.

Some ad campaigns start with the right concept, but have unintented consequences because of poor execution.

I can't even be that kind about this one: MSN wants to make me clever, but its ads are making me smart.

Friday Oct 19, 2007

Electing the JCP Executive Committee

Any of you who have been involved with any of the Java Platforms for the last 9 years may well have been involved in a Java Specification Request (JSR) or two at some point since that's how we develop APIs for the Java platforms. And any of you who have been involved in a JSR will have noticed that the JCP has an executive body of members of the JCP, called the Executive Committee, who take a vote at various stages of the development of the JSR on how its progressing.

Although the prospect of losing a vote at one of the key stages can be a worrying one, happily most of the time JSRs are in good shape and make it though. For a standards body, the JCP gets things done fairly quickly (oxymoron or miracle ? ), with about an 18 month gestation period for new JSRs, from conception to birth. It still surprises me, therefore, that in what some consider to be a high-speed dash to standardize an API (others a crawl), that there aren't more casualties of the Executive Committee reviews.

The JCP Executive Committee reforms itself on a yearly basis, with some of the seats coming up for grabs each year. One of the interesting parts of this process is the period of open election, where any JCP member can put their name forward for the ballot to be elected to the EC. That's the period we're in right now, so if you're one of the many members of the JCP, you can throw your hat in the ring.




« July 2016