>
> >
> > Execution speed and/or handset cost. Certainly it adds something to
> > the cost of a JavaPhone that it's running a garbage-collecting
> > interpreted language.
>
>Java isn't an interpreted language. Garbage collection adds to memory
>costs but not hugely, and it's better than having memory leaks. But
>as I understand things, KVM somehow sidesteps this by limiting dynamic
>memory allocation?
It is my understanding that the current deployed KVM in the IAppli phones
does not have garbage collection implemented at all.
The IAppli API is optimized to not allocate garbage for things like UI events,
but it's still hard to write a moderately complex program which doesn't
generate any garbage at all, if it dynamically generates Strings, because
String in Java is a write-once object. You can kludge with character
arrays, but they are not universally
supported by all the API functions.
I have heard the next generation of Java phones will have a working GC,
they just
didn't have room in these ones to fit it in.
[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
Received on Tue Apr 24 03:16:53 2001