Thursday August 21, 2008
Numbers that Count
Filed under:
javame

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.
Posted by dannycoward
( Aug 21 2008, 05:52:02 PM PDT )
Permalink
Tuesday August 19, 2008
Some of my favorite things about the JavaFX SDK Preview
Filed under:
javafx

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.
Posted by dannycoward
( Aug 19 2008, 07:50:01 PM PDT )
Permalink
Thursday August 14, 2008
No Mojo Mojave
Filed under:
adwatch

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 PerezHilton.com.
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.
Posted by dannycoward
( Aug 14 2008, 05:51:26 PM PDT )
Permalink
Tuesday August 05, 2008
Want your Java fast or predictable ? Java RTS 2.1 is here
Filed under:
realtime
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.
Posted by dannycoward
( Aug 05 2008, 07:50:04 PM PDT )
Permalink