>From: "Gary James" <garyjames_at_flashmail.com>
> I hate to see this Java bashing (especially off topic Java bashing).
It's quite unfair to characterize cogent and objective discussions
of some of Java's shortcomings as "bashing".
Although this thread may have recently drifted off topic
by discussing Java security or scalability, the original thread
was and is on topic (and not bashing by the way) which was related
to Sun's false claim that Java is "write once run anywhere".
And if Java main strength of "write once run everywhere" is
not substantiated then it makes the other issues - security,
scalability more important
That knowledge let's those using Java (some may be product
or project managers without hands on Java experience or
non-technical customer who are buying a Java-based product
on this belief) understand and objectively and realistically plan/budget
for additional costs, development, QA and time to market issues.
> Yes, maybe you can't write one application and make it run on every
> single Java handset in existence, but Java isn't that far off (at least
> much closer than it's competitors).
You've just agreed with my point. Java isn't "write once run anywhere".
It doesn't matter "why" only that it "is". And this is true on the desktop
> The problem isn't Sun or Java, it's
> the carriers (particularly DoCoMo) and manufacturers. We've got a big
> mess of standards. Any serious content providers have to optimize their
> contents for every handset.
Then Sun needs to say that. They don't. Many people (especially in
managerial positions who don't have hands on programming experience)
believe Sun's hype -- no wonder they are upset when the prime premise of
advantages turns out to be an empty cup of coffee.
> Take the ringtone industry as an example, it's a complete mess. We've
> got at least 5 different polyphonic ringtone formats (MFi, SMAF, CMX,
> SMD, MIDI) and yet even though all DoCoMo handsets share the same
> format, you have to make separate files, each optimized for each
> handset! To support all major handsets used in Japan you need to make
> at least 30 different files for just one song.
This is true, but by the same token, I don't see people marketing this as
"compose tunes once, ring anywhere".
> Now compare that to Java. It's possible to make 3 applications that
> together will work on all Java handsets in Japan. One for DoCoMo, one
> for J-Phone and one for AU. That's 3 applications to support roughly 20
> or 30 different handsets. Sure, you need to tweak the application so
> that it looks best on each handset to account for different screen sizes
> and handset "peculiarities" but that's not Java's fault, but the weak
> standards setting of the carriers.
It's also not Java fault when a JVM is buggy or broken. But it doesn't
change the fact that the the promise of Java fails, because Java is
still a semi-interpreted language and requires the JVM to function.
I similarly can show HDTV quality MPEG-2 movies in a 19.2 mbps
stream from my server today. You can watch them and pull at that
rate and the server won't hiccup or drop frames. That doesn't mean
you'll have a good viewing experience or not have frames dropped
due to factors outside of my immediate control since it's not my fault
that the networks and last mile usually can't handle anywhere near this
bitrate. The bottomline, though, is that in both cases the promise is
> My point is that Java is capable of "write once run anywhere" but that
> can only be possible with decent standard setting from the carriers and
> manufacturers. Don't blame Sun, blame DoCoMo!!!
In theory or in the lab, Java may be able to "write once, run anywhere"
but in practice it doesn't exist. Period.
Does that mean that Java is worthless? Of course, not. In many instances
it may or may not be the language of choice. But it depends on what
you are trying to do and it is not the silver bullet that McNealy has
made it out to be. That is not bashing, that is objective reality and it
that Sun/McNealy and all Java supporters should welcome.
A U D I E N C E T R A X
Received on Sat Sep 7 22:09:43 2002