Thursday Aug 21, 2008

Numbers that Count

For those of you who know me, I can still get a little freakish about numbers. So, from a really interesting article about mobile devices and Java ME I saw over the last week, two numbers stood out for me. For developers trying to figure out how to reach a wide audience for their application, those numbers are: 2.7 million and zero.

2.7 million is the number of mobile phones that were sold, on average, every single day in 2007 around the world. Now, I \*heart\* my iPhone, its a wonderful device, but the iPhone reached the million mark 74 days after its launch. That's 74 days to sell as many iPhones as it took just 9 hours to sell as many mobile devices.

Zero is the cost of entry to develop an application for Java ME, which is deployed today on many of that staggering number of devices (for a complete list, see here). No complicated agreements to get the Java ME SDK, the development of the platform is out in the open, so everyone sees it unfold at the same time. Better still, the free visual development environment for Java ME has been pretty great for some time now.

Two numbers that add up to a great way to reach a lot of people.

Tuesday Aug 19, 2008

Some of my favorite things about the JavaFX SDK Preview

I'm sure you all saw that our JavaFX team released a preview of the SDK at the end of July. I've been happily tinkering with it for the last few days. If you are hacking with AJAX, moonlighting with Silverlight, or fumbling with Flex, I think you should get up close and personal with it too, and see what its all about.

We've been talking about JavaFX in various ways for some time now, so you probably already know that its for building rich client applications, that it itself is built using Java, and that it will span multiple devices - from small mobile phones through TV settop boxes to the PC desktop and browser. Most importantly, if you are a traditional Java programmer (I include myself), you will notice there's a paradigm shift. A shift moving from the Java programming environment, whose generality spans quite an astonishing range of applications, to a programming environment specially designed for those amongst us with more developed visual design skills than technical ones (sadly, I cannot include myself). Those who are focused on one kind of application: interactive and fabulous looking.

Looking ahead a little, the plan here is to release the final version of the SDK for the desktop at the end of this year and a preview of the mobile version next March or so. I say or so, not just because schedules are schedules, but because we are ready to adjust based on the feedback we get from this preview release.

Anyhow, some of my favorite things about this preview release are:-

The Language: JavaFX Script

Described in full in the language guide included in the SDK, this new language is highly declarative (i.e. it says what its going to do, rather than saying how to do it), with features like data binding to let you to bind one variable to another variable. Like,

let oneVariable = bind anotherVariable;

(I did say it was declarative). Or like the triggers feature, so that when the value of one variable is replaced, you can have something else happen at the same time.

attribute oneVariable
    on replace doSomethingElse();

To a Java programmer its going to be an easy new language to pick up because it shares much of its syntax with the Java language. To a designer, its going to be an easy new language to pick up because its clean, straightforward and does on the screen what it says in the code. And it has no baggage to carry.

The APIs

Neatly divided into two profiles (which you can see here) - the common profile for all the APIs that will be available on every device, and the desktop profile for all the APIs that make sense only for applications on a desktop. There's a mobile profile to come of course in the mobile release next year, which will have the common profile plus APIs that make sense on mobile devices.

As part of the common profile, you have the scene graph and the media JavaFX APIs. The GUI of an application is modeled as a graph of visual nodes, (each node being a shape, line, piece of text, GUI widget or embedded media), that moves, twists, rearranges as the user interacts with it. The scene graph API in JavaFX is especially well suited to the transition effects and animations that make all the difference between a user experience and a captivating user experience. The media supported in the scene graph includes a player control and support for OS native formats. You'll remember we inked a deal with On2 to provide cross device media support in May. Well that will have to wait a little longer before we can put that in. But we're all crossing our scene graph nodes that it will be soon.

The desktop profile includes the common profile, plus some desktop specific extras like...many of the tried and tested Swing widgets we know and love: buttons, combo boxes, lists and so on. So no shortage of the basics you need there.

And of course, being built in Java and on Java, you can always reach down into the underlying Java APIs for your favorite Java API if you would like to use that in your application too.

NetBeans integration and Project Nile Plugins

Naturally, the SDK is available pre-integrated with NetBeans 6.1 which is how I've been looking at it, as have others. The language and APIs are supported in the IDE with all the things you would expect like syntax coloring and checking, debugging and so on. Together a tutorial and a range of samples. The samples are generally short and to the point. Want to see how to draw polygons ? There's a sample just for that. Want to see how to use keyframe animation to bring life to randomly moving particles ? There's a sample just for that. Transparency, color gradients, bounce a ball ? Check, check, check.

Also included in the SDK is a collection of plugins (codenamed Project Nile) to Adobe Photoshop and Illustrator so you can keep working on the art there, and use Project Nile to export it into your JavaFX application and bring some life to it.

My other favorite thing is that this is all running on Java SE. So applications created in JavaFX aren't just running on any old VM, its running on a supremely stable, scalable and high performing runtime. But I don't have time to tell you about all that just now.

There's more to the SDK than just my favorite things. If you've been curious about JavaFX, now is a good time to take a look for yourself.

Friday Aug 15, 2008

Makeovers for Java ME applications

One of my Top 10 Rich Client things from JavaOne this year was the Java ME Lightweight UI Toolkit (LWUIT). And the team just open sourced it yesterday.

If you're looking for a quick and easy way to add some fit and finish to a Java ME mobile application for use on the version of Java ME that is deployed today on billions of devices, you need to check it out.

It takes some of the familiar core ideas of Swing - some of the widgets, layouts, themes - and shrinkwraps them into something good looking, powerful, small and easy to get started with.

See it in action for yourself.

Thursday Aug 14, 2008

No Mojo Mojave

I'm wondering who's hiring the ad agencies up in Redmond these days.

Hot on the heels of the 'No-one wants to look dumb' campaign for MSN, the Mojave Experiment is squarely from the Pepsi/Coke taste test school of thought. You know, showing people like you and me reacting to the product, that kind of thing. This time, with the additional blindfold that the people testing Vista don't know that it is Vista, just that it is the next version of Microsoft's OS.

For the insomniacs amongst us, the underpinning of the campaign is of late night informercial genre - you know, the parade of unpaid customers of the product each of whom has some unique way in which the product for sale has touched their lives in a profound and meaningful way. You don't really believe that they are being truthful, but somehow you can't look away. Each echoing the same key messages of the previous one, like a rat caught in a wheel.

A blind test of an OS does not lend itself to before and after photos. Nor apparently in this campaign, of ever showing a single pixel of Vista in action. Instead, in the Mojave Experiment, the exposition is in the reality TV style, the reality being the reaction of ordinary people to it. Except that, as most reality TV shows, the reality is selectively edited. Of the claim of 22 hidden cameras (why hidden ? why 22?), only one or two ever appear to be in use. Worse, the captured reactions are mostly of the subject watching the screen while the off camera interviewer drives the demo. The subjects never touch the computer. They never have to figure out why their wireless connection isn't working, or where they saved their Word document, or whether they can trust a download that magically popped up in their face while they were reading

You obviously never see them doing this.

The goal of this campaign is I suppose to show that Vista is surprisingly good. But it just acknowledges that, whether right or wrong, many people think its surprisingly bad.

Almost as surprisingly bad as the choice of campaign.

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.




« August 2016