Porting Java ME to Open JDK

[Eric Bresie]

I am sure I'm over simplifying this so I appreciate all your help to
help me understand some of this.

On 4/21/08, Dalibor Topic <dalibor.topic at googlemail.com> wrote:
> On Fri, Apr 4, 2008 at 4:34 AM, Eric Bresie <ebresie at gmail.com> wrote:
> >  I would like to propose porting (maybe more appropriate, merge of)
> >  Java ME to OpenJDK.
> >
> >  Since the idea would involve migrating the ME platform specific (at
> >  least the VM) with some additional build logic (a build task to build
> >  only ME specific elements) into the Open JDK side, I thought posting
> >  here would be appropriate.
>
> We looked at generating different 'profiles' of GNU Classpath every
> now and then,
> and it turned out to be non-trivial, since there are differences in core library
> behavior from SE release to SE release that would be quite hard to maintain
> in the same tree, without resorting to a lot of preprocessing. I would imagine

What kind of differences and in what core libraries?   Would they be
good candidates for developing some wrapper interfaces to hide these
differences?  Stuff like graphic tool kits and audio toolkits could be
abstracted and then implementation specific would make use of these?

> the boundary between SE and ME to be much higher, so that would seem to

This is probably a question I need to read up some more, but maybe you
can answer in a few words.  Isn't ME based on SE 1.4.x source?  What
kind of divergence (besides the VMs, hardware specific optimizations,
and subsets or extensions for use with small footprints) occurred?  I
always thought ME was basically a subset of SE with a smaller
footprint VM (for small resource devices).

> me to require a significant amount of non-trivial build logic to accomplish, if
> you are after building certifiably compatible ME and SE releases from the same
> tree.

That was basically my thought.  Kind of like the linux kernel which
has platform specific areas with the basic kernel abstracted on top of
it with defined interfaces/apis.

> A simpler project could be to try to make the OpenJDK class library work
> with the PhoneME VM.
>
> cheers,
> dalibor topic

My thinking was more to write as much in java as low as possible and
refactor out of the VM level to try and find common interfaces that
are implemented as much into usable components as possible then
isolate the platform specific in the VM as the location of the
differences.  So to integrate the phoneME VM into the OpenJDK with

My thought here in the end was that the Java ME represents a whole new
suite of use cases for Java that could help in optimizing Java as a
whole to reduce memory usage and improve performance for lesser
performing platforms and avoid having to maintain 2 separate source
trees.  It also allows the ME to leverage off the Java 5/6/7 a lot
sooner.

By the way congradulation on you new Java job by the way...

-- 
Eric Bresie
ebresie at gmail.com