Blowing the doors to Palm - Java programming for Tungsten handhelds

[Carlos Bazzarella]

Hmm, yes, a nicely specialised application. However I can
instead download YACAS (Yet Another Computer Algebra System), an
open source C/C++ program which has already been ported to my
PDA.

Sure, but we have over a thousand users that preferred to paid for and
use our sofware possibly due to the nice user interface and ease
of use. Most CAS are command line based and very hard to use and
even more so on a device without a keyboard and with a tiny screen.
Also our CAS provides step-by-step solutions that matches hand
based calculations. Hey not bad for a Java based PDA app !!! Go to
Handango.com and check out the comment we got on the Sony Ericsson
P800 version of Formulae 1 from an user that previously used the
Sharp Zaurus version. 'Asj' take a tranquilizer before you read
those comments


Carlos.

 

[Carlos Bazzarella]

ahhh...thanks for clarifying. so you're saying that you can create c++
apps that do this in a motorola i95cl for example, but which MIDP cannot
handle (due to the graphics?)...

Yes but mainly due to speed. We can work around implementation bugs but
this becomes a huge concern since there are hundreds of different cell
phone types and we don't want to code and test for each one separately.
Java for hardcore developers is known as 'code once, test and adjust
everywhere'.

As another example of performance, back in 1996 we had a C++ version
of Formulae 1 for Windows CE called appropriately Formulae 1 CE. This
version loaded and run extremely fast on a Cassiopeia A10 which is
basically a 40Mhz SH3 CPU machine with 2 Megs of RAM. The app size
was around 240kb. Now for comparison purposes Formulae 1 for PocketPC,
Sharp Zaurus or P800 is Java based and the compressed-obusfucated jar
file is over 500kb for about the same functionality more or less.
Performance wise, the Java code running on a 200Mhz machine today doesn't
even come close to the C++ code of back then !!!

i noticed you do your work in MIDP or personal java in the company
website....so why not skip over and do them in c++ then if you think
this language will serve it better? these are just tools after all, and
you choose the one that serves you best.

Yes, everything has its pros and cons and we picked Java for its major
advantages and we are sticking to it. I just think that facts about
the problems with Java should be discussed and solutions searched for
instead of just saying it is great and the best thing since sliced bread.
People should know the problems (specially new developers) to avoid
major disappointment after trying to develop something. Current J2ME
performance prohibits the development of powerful apps like what we
want to do on handhelds.


Carlos.

 

[asj]

For PDAs/smartphones my vision would be to make them much more powerful than
the software available on handheld calculators. So interesting apps to
me would be a mini CAS with a nice interface, or a mini circuit simulator
(analog or digital), or a mini chemical drawing package, a mini dynamic
geometry package, etc, etc. Basically software for scientists, engineers
and students. These apps require the client device (PDA, cellphone) more
processing than what is currently expected from J2ME apps but we could today
implement them fine in C++.

ahhh...thanks for clarifying. so you're saying that you can create c++
apps that do this in a motorola i95cl for example, but which MIDP cannot
handle (due to the graphics?)...

i noticed you do your work in MIDP or personal java in the company
website....so why not skip over and do them in c++ then if you think
this language will serve it better? these are just tools after all, and
you choose the one that serves you best.

 

[asj]

Yes, everything has its pros and cons and we picked Java for its major
advantages and we are sticking to it. I just think that facts about
the problems with Java should be discussed and solutions searched for
instead of just saying it is great and the best thing since sliced bread.
People should know the problems (specially new developers) to avoid
major disappointment after trying to develop something. Current J2ME
performance prohibits the development of powerful apps like what we
want to do on handhelds.

sounds good to me....what possible solutions would you recommend?
is the recent news that intel and sun would optimize j2me for xscale
processors a good first step?

also, given the range of devices that midp runs on (from beepers to
medium-power cellphones), since there will ALWAYS be devices in the
midp range that won't have the processing power you need. perhaps you
should commit your advocacy to getting the CDC profiles in line with
the popularity of midp?

 

[username]

Yes, everything has its pros and cons and we picked Java for its major
advantages and we are sticking to it. I just think that facts about
the problems with Java should be discussed and solutions searched for
instead of just saying it is great and the best thing since sliced bread.
People should know the problems (specially new developers) to avoid
major disappointment after trying to develop something. Current J2ME
performance prohibits the development of powerful apps like what we
want to do on handhelds.

sounds good to me....what possible solutions would you recommend?
is the recent news that intel and sun would optimize j2me for xscale
processors a good first step?[/QUOTE]

probably, but of course it more like "just another step". If performance is
an issue, and you need recent hardware do get that performance, forget about
Java, visual basic, .net and other "interpreted" languages (non-native
binaries). Of JVM, runtimes, whatever will be developed and optimized for
the new hardware, but it will take years before they show reasonable
performance.

also, given the range of devices that midp runs on (from beepers to
medium-power cellphones), since there will ALWAYS be devices in the
midp range that won't have the processing power you need.

of course

perhaps you
should commit your advocacy to getting the CDC profiles in line with
the popularity of midp?

of course he can do that, I wouldn't waste time, if there are tools
available that already do the job.

 

[RaBi]

i doubt that it's simply on a CD, and you would need to synchronize it
to the palm. that's almost as bad a solution as the "need to download"
one.

There is no best way to do it:
If it's on the CD you can't excpect it to be on the handheld. Just like
bundling a JVM with your app.
If it's in ROM you are going to see several JVM version on the same Tungsten
model as they won't be able to make it perfect the first time.

Reminds me of the versioning chaos that happened with the Java browser
plugin. This was solved by distributing each app with it's own JVM
(WebStart - which introduced other issues but that's a different story).

I guess the only way to solve this is to have a compiler that creates
platform specific binaries. Sacrifices platform independence but solves
versioning problems and may enhance speed.

#rb

 

[Roedy Green]

There is no best way to do it:
If it's on the CD you can't excpect it to be on the handheld. Just like
bundling a JVM with your app.
If it's in ROM you are going to see several JVM version on the same Tungsten
model as they won't be able to make it perfect the first time.

They could use a flash ROM like BIOS's do. I don't know if that is
feasible in battery devices though.

 

[Roedy Green]

Unless the speed problems of Java are improved and also the proper
compatibility testing is resolved, Java on handhelds will never
take off. Java apps NEVER run the same on different devices (pocket
pc, sharp zaurus, Sony Ericcson P800) and cell phones (nokia,
motorola, sharp, etc).

My Dad used to say, don't worry about where you are, look at the
derivative.

How fast are these JVM bugs and incompatibilities being ironed out?

What does a graph of speed of processor and RAM in a $100 hand held
look like over time? Is it improving rapidly enough that Java will
prevail before something else comes along substantially more
parsimonious with resources?

Compare desktop or Applet Java in 2000 with 2003. A lot got done in
those years to clean up troubles. These are smaller systems, and in
theory, there is less to clean up.

Perhaps what may be done is a pair of cpus will be installed, one a
specialized Java that needs only a minimal JVM. One or the other
processor sleeps to conserve power.

 

[asj]

My Dad used to say, don't worry about where you are, look at the
derivative.

How fast are these JVM bugs and incompatibilities being ironed out?

What does a graph of speed of processor and RAM in a $100 hand held
look like over time? Is it improving rapidly enough that Java will
prevail before something else comes along substantially more
parsimonious with resources?

gotta admit, roedy's dad is one sharp cookie.

 

[Roedy Green]

Oh yes it is. Defined as a rare from of naivety (which is itself described
as an Anglicized version of naiveté)

what are you guys doing playing dictionary dominance games in a
discussion on Tungsten handhelds. Why are you doing this? Simply to
put the other guy down. Please stop.

 

[username]

My Dad used to say, don't worry about where you are, look at the
derivative.

How fast are these JVM bugs and incompatibilities being ironed out?

What does a graph of speed of processor and RAM in a $100 hand held
look like over time? Is it improving rapidly enough that Java will
prevail before something else comes along substantially more
parsimonious with resources?

Compare desktop or Applet Java in 2000 with 2003. A lot got done in
those years to clean up troubles. These are smaller systems, and in
theory, there is less to clean up.

Perhaps what may be done is a pair of cpus will be installed, one a
specialized Java that needs only a minimal JVM. One or the other
processor sleeps to conserve power.

You mean Java specific hardware? That would work of course, but then you
lose the claimed platform independency of Java......

 

[asj]

For a 200Mhz ARM based Palm machine, the annoucement deal with Palm &
IBM is sad because on such hardware Palm should get full PersonalJava
(JDK 1.x, J2ME Personal Profile) support instead of just MIDP. MIDP
doesn't even support floats, not to mention the huge amount of applets
out there that can run on top of PersonalJava (or replacement) but

i believe the reason for that may be that ibm/palm realize that the
momentum right now is all behind midp (something which i too regret) and
not on personal java/personal profile...there are just so many apps
being written for midp, the carriers want midp apps (they even forced
microsoft smartphones to use midp), and this j2me profile will simply
get better over time and more capable.

for example, the games playable using midp have gotten pretty
sophisticated since i last looked mid-year 2002:

http://wgamer.com/gamedir/?section=cingular
http://wgamer.com/gamedir/?section=sprint

let's see how
many of the 3 million Java developers will go with that.

quite a lot probably (although obviously not 3 million, or even 50,000 -
the market will be the judge of that, not sun's hype)...just looking at
some javablogs, quite a few developers are at least experimenting with
it.

 

[John D.]

what are you guys doing playing dictionary dominance games in a
discussion on Tungsten handhelds. Why are you doing this? Simply to
put the other guy down. Please stop.

You are getting it way too personal. The folks at the "discussion on Tungsten
handhelds" were deadlocked on whether there is such a word as "naiveness".
I cross-posted to alt.usage.english to get the facts straights. Isn't it
that what all discussions are about?

 

[Carlos Bazzarella]

gotta admit, roedy's dad is one sharp cookie.

The irony here is that we develop math software in Java for handhelds
that calculates derivatives too Yes, but the derivative here is
approaching zero and not infinity !!! When it comes to handhelds
(possibly due to battery life and other issues) things don't move
as fast as on a desktop/laptop system. For how many years did Palm
basically sell the same hardware (68k chip at around 16-32Mhz) ?
That is just unheard of on PCs. Now JVM bugs and incompatibilities
are getting bigger due to many more implementations of JVMs for
small devices and not enough test cases and applications for JVM
developers to test against !!!!


Carlos.

 

[Carlos Bazzarella]

Did? You say that in the past tense as though those PDA's aren't still for
sale. You can still buy a brand new Palm Zire running the Dragonball
processor (derivative of the 68k) at a screaming 16MHz.

That's the same hardware as the original Palms dated back to 1996 right ?
So for 7 years consumers were happy to buy the same thing packaged
differently. Wow, the definition of 'milking the cow' on Webster's
dictionary should definitively mention Palm Is this progress ?

Carlos.

 

[asj]

That's the same hardware as the original Palms dated back to 1996 right ?
So for 7 years consumers were happy to buy the same thing packaged
differently. Wow, the definition of 'milking the cow' on Webster's
dictionary should definitively mention Palm Is this progress ?

carlos:

white castle is still selling the same burger after several decades,
cars probably have less horsepower on average than the behemoths of
yesteryear, and touch tone phones have basically been stagnant for
years...what's your point? there is a market for a handheld at that
price range (price being affected by the cost of making the
handheld)....at the same time, palm has expanded its range of products
towards the higher end to accomodate users who want more processing
power.

the only argument to the above would be that construction costs have
gone down, in which case the cost of the palm zire should (on average)
be less than what palm III and others cost awhile back. i bought a palm
vx for $300+ several years ago, which i think has those specs you
mentioned...the zire i believe has a much lower price ($120?), BUT with
similar specs i think and additional gadgetry to boot.

 

[Guest]

That's the same hardware as the original Palms dated back to 1996 right ?
So for 7 years consumers were happy to buy the same thing packaged
differently. Wow, the definition of 'milking the cow' on Webster's
dictionary should definitively mention Palm Is this progress ?

If a product basically works and handles my needs as supplied,
then as a consumer I'm not particularly interested in some minor
incremental improvement that costs me time to install and money.
I'll replace the product when it gets really old and starts to
fail to cope with my increased demands, if my demands ever
increase.

Many of the "improvements" I've seen in Windows (TM) have been a
time wasting pain in the arse, especially the incompatible ones
ones where you had to work around them to recover past
productivity. I'm interested in buying a new product when, and
only when, it offers major advantages over the old product. My
business related demands on PDAs basically haven't changed a
whole lot from when I bought my first one, nor do I see any great
reason why they would change dramatically. Trading reduced
battery life and greater complexity for better game playing
ability just isn't all that attractive to me.

 

[username]

carlos:

white castle is still selling the same burger after several decades,
cars probably have less horsepower on average than the behemoths of
yesteryear, and touch tone phones have basically been stagnant for
years...what's your point?

the point is: consumers don't care about technology, only functionality.
That's why all your arguments in favor of Java, are just technobabble,
irrelevant to consumers.

 

[asj]

the point is: consumers don't care about technology, only functionality.
That's why all your arguments in favor of Java, are just technobabble,
irrelevant to consumers.

heh, and this is something you discovered, when?
the usage of java is irrelevant to consumers, obviously (although the
brand "java" is starting to become associated with downloadable apps,
games, and ringtones), but it is hardly irrelevant to me or to the
millions of other java programmers.

you were confused about this before, so let me point out again that the
more java is used in apps, the better for java programmers because this
means more work.

i would hasten to point out that by learning to program in java, you
free yourself from the boundary of programming for just one particular
os or hardware product. it is an AMAZING feeling to see my apps running
on both my palm vx and my motorola i95cl color javaphone, and to know
that they could run just as well in any nokia/samsung/whatever
java-enabled phone, rim blackberry, or even wince (after installing the
jvm)!

 

[username]

heh, and this is something you discovered
no

when?

when what?

the usage of java is irrelevant to consumers, obviously (although the
brand "java" is starting to become associated with downloadable apps,
games, and ringtones), but it is hardly irrelevant to me or to the
millions of other java programmers.

you were confused about this before, so let me point out again that the
more java is used in apps, the better for java programmers because this
means more work.

obviously. but this holds for everything, so what's your point?

i would hasten to point out that by learning to program in java, you
free yourself from the boundary of programming for just one particular
os or hardware product.

so? my users don't care about that, as long as our software runs on their
machines (it does) at a sufficient speed (it does) at low costs (it does).

it is an AMAZING feeling to see my apps running
on both my palm vx and my motorola i95cl color javaphone, and to know
that they could run just as well in any nokia/samsung/whatever
java-enabled phone, rim blackberry, or even wince (after installing the
jvm)!

congrats!