I agree with Jonathan, Dennis and Jim, however I think Patrick has
raised a good point.
Retrotranslator allows you to use new Java l.5 language features which
require compiling on jdk 1.5 or later, the class files compiled by Jdk
1.5 or later once Retrotranslator has altered them, will run on jre 1.4
or even jre 1.3 since Retrotranslator packages additional compatibility
classes into the jar file, but only those required. The question is
then; what are the memory limitations of JavaME 1.4.2 CDC Devices?
It would be no longer possible to compile with jdk 1.4 however still
possible to run on jre 1.4. It also means that once we drop support
for jre 1.4 we have all the performance benefits of the new concurrency
libraries with the latest JRE.
We might also (at some later date, I think it's ambitious) be able to
use the Retrotranslator JIT class compiler to translate classes from
code repositories on the fly for earlier jre's participating with later
versions in a heterogeneous environment, while allowing the later jre's
to make use of newer library performance advantages without sacrificing
compatibility.
I had a look at Java PhoneME Advanced J2ME CDC 1.4.2:
http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedGSGWinMobile
There's an optional setting there to set the Device Emulator RAM
size to 256MB
Then on http://www.8mobile.org/blog/?cat=2 :
An Early Access release of the new Java Platform Micro Edition Software
Development Kit 3.0 is available for download. This SDK supports CLDC,
CDC, and Blu-ray Disc Java (BDJ) development. Emulation is a major
focus: on-device deployment, on-device debugging, integration with
devices running Windows Mobile and integration with third-party
emulators are just a few of the new features in this preview
Windows Mobile 6.0 platform installed on a target device with
network connectivity, 32-bit RISC based microprocessor, and minimum 64
MB RAM.
Ricoh Photocopiers also have J2ME CDC, they actually may be able to
perform some very useful functions with River?
Anyone on the list have more experience with Small Devices? Do we need
to decide what the minimum J2ME CDC device requirements are? Do we pick
a Sun J2ME CDC emulator and test on that?
Perhaps there is a Subset of Java 1.5 features we can use? If we can
determine a compact subset, agree upon it and post it on the Rivers
Developers page, we might be able to have the best of both worlds?
Cheers,
Peter.
Jonathan Costers wrote:
I agree with Dennis and Jim. We should be looking foward, not backwards.
To add to Jim's point, I believe there are probably more urgent things to do
than upgrade the complete River distribution to be using post-1.4 features.
Then again, when introducing new things, we should not limit ourselves to
1.4.
Best
Jonathan
2009/3/27 Jim Waldo <[email protected]>
I have to agree with Dennis. Most of us are now using 1.6; 1.7 is underway.
I don't think the small device space should be much of an issue; most of
those devices won't support a full Jini function anyway, since they lack
class loading (that's why we did the surrogate architecture).
Going back and upgrading to post-1.4 features throughout can probably wait.
But that is no reason not to use them when they make sense in new code.
Jim Waldo
On Mar 27, 2009, at 7:45 AM, Dennis Reedy wrote:
On Mar 27, 2009, at 720AM, Patrick Wright wrote:
Just because the current River codebase is limited to 1.4 doesnt mean new
work should be constrained to that right?
I think one has to be careful with compatibility across small-device
VMs, which, AFAIK, in some cases are 1.4 compatible (cf. JavaME).
Well, and IMHO, keeping the core of River based on a technology that is in
it's EOL transition period (http://java.sun.com/j2se/1.4.2/) for the sake
of *possible* use for small device deployments may not be ideal.
Dennis
