Sun JavaFx

Jim Thompson jim at
Fri May 11 05:05:43 CEST 2007

Terrence Barr - Evangelist, Java Mobile & Embedded wrote:
> Shawn,
> I have been very involved in this area at Sun now for a couple of
> years. Let me add come comments:
> Hardware accelerated Java is actually fairly common already, at
> least in the Java ME space using ARM's Jazelle technology. It does
> have some benefits in very constrained platforms but in general
> advanced VMs with dynamic adaptive optimizations, compilation,
> and improved garbage collection perform better than H/W acceleration
> and at reasonable incremental cost (memory footprint, in particular).
> I think what we are seeing here is a general trend in the IT industry
> as general-purpose processors become more and more powerful they
> displace dedicated hardware solutions because software solutions are
> more flexible and lower cost. A notable exception, of course, is
> graphics acelleration but Java implementations typically use those
> when available.
> Specifically to Sun's Java chips (picoJava/microJava): I worked on them
> and the performance was quite good. But it is very hard, if not
> impossible, to keep up with performance improvements of general
> purpose processors together with the increasing amount of memory
> available. That technology evolution relegates Java hardware
> acceleration to niche status. Many companies have invested in Java
> H/W acceleration and fell into that trap.

It turns out to be difficult to make Java go really fast on specialized 
hardware.  Java wasn't designed to be fast, it was designed to be 'safe' 
for large groups of programmers to use.  You can get single order of 
magnitude speed-ups for some bytecode streams, but you won't see two.

I (too) looked at doing a Java chip (very early, back in 1996 or so).

Moore's law continues to march on, only now instead of (super)-linear 
speed-up on a single core, we're getting multiple cores.  Java will be 
OK with 'multi-core', but won't survive the transition to 'manycore' (> 
100 cores), nor will Python, PHP or Perl.

This may not matter on a phone platform, but the desktop and server will 
distance themselves from co-operating sequential processes before too 
much longer.

> As for the comparison of JavaFX Mobile with the iPhone: Sure, at
> first it looks like a "me too" play, but I think this applies to
> the whole mobile industry. The iPhone was a major wake-up call to
> the industry and so I think you will see many "iPhone knock-offs"
> over the next 18 months simply because the iPhone is leading the
> way.

The only question is if the rest of the industry 'woke up' enough to see 
the light of cracking the phone wide-open.  If not, they are doomed. 
Bill Joy explained it a long time ago.

Lemma 1: # smart employees = log(# of employees)
--> there are more smart people outside your organization than inside it

Lemma 2: Innovation will occur
Lemma 1 tells us that it will occur elsewhere.

Question: How do you take advantage of innovation that occurs outside 
the organization?

Answer: Open Source

Of course, FOSS is one answer, there are others, but stating the answer 
without knowing the question is Jeopardy!

> However, JavaFX Mobile is distinctly different in that it will
> be an open system (not closed as the iPhone) and will be part of
> a multi-screen approach that delivers content across desktops,
> TV, and mobile. Only Java currently has that market reach so Sun would
> be ill-advised *not* to capitalize that.

Even then, Java, even JavaFX is not the web.


More information about the community mailing list