Sun JavaFx

[Jim Thompson]

Shawn,

I'm more than happy to engage and debate these points, but its likely 
off-topic (or at least not "in scope") for the list (which is about 
openmoko and/or the community that surrounds openmoko).

Topics such as:
"why is Java slow" (and how to construct hw to make it go fast

concurrency models (threads or not)

programming of same, and

Java's lack of a process model

aren't related (much) to openmoko, so I suggest we take these off-line, 
unless 'the list' decides they would rather watch/join the discussion 
here.  (And yes, I agree that I contributed to the discussion going 
off-track.)

The topic of Apple being open or closed, especially as it relates to the 
iPhone, seems at least peripheral to the discussion here.

I think it likely to be mere months before some rudimentary linux kernel 
is running on the iPhone, and likley less than a year from then until 
some dedicated group of hackers make the OpenMoko environment run on the 
iPhone in much the same way that the Mac and the "AppleTV", and even the 
iPod now run specialized linux kernels to 'enable' a degree of openness 
that Apple expressly did not plan.

If OpenMoko is found to be a better environment than (or for) the iPhone 
(as well as other phones)... "success!".   If Sun's "JavaFX Mobile", 
well... "success"!

Jim

Shawn Rutledge wrote:
> On 5/10/07, Jim Thompson <jim at netgate.com> wrote:
>> 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'
> 
> Why is it so hard?  What are the tough problems that are always going
> to be slow?
> 
> What's wrong with taking some shortcuts, like the way KVM depends on
> pre-verified bytecodes so that it doesn't have to do the verification
> at load time?
> 
>> 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.
> 
> I think you are saying that the thread model of concurrency has
> limits, right?  Or just that programmers will balk at having to manage
> hundreds of threads?  Well what do you think is the future then, to
> get more parallelism?
> 
>> 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.
> 
> Yeah that's a big one.  I think Apple's view is that their
> applications are always best-of-breed anyway, and they can satisfy 90%
> of the users' needs themselves, so why be open to having third-party
> security holes, usability problems, bugs and so on, which will sully
> the reputation of the phone.  But I also think a lot of the success of
> the early Palms was the wide variety of extra software you could
> install on them.  I doubt that Apple will really keep the iPhone
> closed forever, but we'll see.  Nowadays it's not like it was in the
> Palm era though... there are so many choices for development platform.
> Java, Brew, Windows Mobile, Palm, Symbian, Linux/QT, Linux/X, etc.
> Java has not been the unifying force that it should have been.  I'm
> not very optimistic that is suddenly going to happen; the window has
> probably been missed.  But I guess it's worth a try.  If nothing else
> at least OpenMoko might be able to run Java games or something.
> 
> I think one unsolved problem, which has probably hampered Java a lot,
> is the lack of a process model.  If a Java VM was pre-loaded, and all
> of the Java applications could run in one VM, the overhead for each
> one would be much less, right?  I know, I've heard the excuse... well,
> the OS is caching files anyway, each class's instructions are only
> being loaded once, and a separate VM increases security.  But if a
> phone's top priority at bootup was to just to get all of the necessary
> classes into memory as fast as possible, and get the VM running, get
> the UI up and be ready to do the basic phone stuff (calls, phonebook
> etc.) maybe it could be fast.  But Java has always been an adjuct.  On
> the desktop, first you have all the overhead of the OS and its own UI,
> and then there is Java.  Anytime I run a desktop Java app my reaction
> is ugh, you can always recognize a Java app by the startup time, the
> amount of memory it's taking up, and the paint idiosyncracies and the
> way the UI looks.  And the installer typically put its own VM in place
> along with the app.  So you will be running a different VM for every
> app.  This is not a platform!  And the phones I have worked with are
> just limited to one Java app at a time because they can't afford the
> system resources for more than one.  Whereas if the emphasis 10 years
> ago had been to make Java into a real platform, keep the VM thin and
> light, pre-load and re-use as much as possible, have the security be
> good enough that you can actually run multiple apps in one VM without
> worrying about them stepping on each other.... then pipe dreams like
> the Java OS, JavaStation, and 100% Java cell phones would be
> practical.
> 
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community