Porting Java ME to Open JDK

[Eric Bresie]

Okay guys...this may seem silly or crazy with most of the comments I
have been getting seeming to not be very hot on the idea, but I wanted
to post it none the less...

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.

Some of the benefits in favor of this are:

- Avoids two separate source baselines
- Performance increases in Java SE make it into Java ME profiles
- Helps minimize some of the problems with Java ME fragmentation
- More up to date Java ME based on the newer revisions of Java SE /
OpenJDK source
- Recent java kernel activity in the Java 6 N could use loading of
needed bundles.  This fit well with the idea of only loading Java ME
platform specific components. However, since these efforts are in the
Java SE side, the Java ME folks do not really get the benefits of this
at the moment. If they were merged, then they would.
- In this context, this would be a benefit for Java SE, because the
small memory footprints associated with ME platform may force some use
case to optimize memory at the Java SE level. I compare this to the
Linux Kernel which has platform support for just about every size
device from mainframes and 64bit platforms to pda devices and Arm
platforms.  Optimizations occur in the perspective device specific
area.
- There are optional JSR that are focused on mobile devices (I assume
item such as cell phone interfaces, PIMs, etc). But with VOIP, GPS,
and bluetooth capabilities all inclusive on laptops, I still don't see
anything that would not be appropriate in the Java SE realm as well.
- Lots of refactoring opportunities.

Some of the issue against seem to involve some of the following:

- The target profile of the Java ME have optimizations
- Optimizations for the mobile platform verses the full platform.
However the above migration task would also be to identify the
optimizations and modularize them so that an interface could be
defined such that it works on both and then implement the interface
depending upon the above mentioned build task.
- Power could be a problems. I believe this concerns that have been
mention revolves around the VM and threading technologies could result
in more power usage, but I'm not sure.

Maybe this needs to be a JSR suggestion.

I may probably over simplifying things.  Comments?

Eric Bresie
ebresie at gmail.com