views:

668

answers:

5

I want to port some existing j2se libraries (e.g. Apache Compression libs) to use for Blackberry development, but there is a catch (and not just one).

First, most java libs extensively use j2se collections and data types that are typically missing on j2me platforms — but that's theoretically solvable thanks to open-source j2se api implementations like Apache Harmony. The bigger problem is that, it seems, Blackberry JDK is based on java 1.4, so any code that uses generics and other 1.5 features, like Enums, is not effortlessly compilable on Blackberry.

Which raises an interesting question of whether there are any existing tools or projects out there that would do automatic 1.5->1.4 conversion, while supporting j2me-bastardized bytecode :)

One project I was able to find is Retroweaver, but I'm not quite sure how active that project is.

I'm sure the problem of 1.5->1.4 automatic conversion isn't unique -- so does anybody have any experience with it? :)

Muchas gracias!

+1  A: 

I've used retroweaver in the past (J2RE, not J2ME) - it worked really well. The cost of using it is a couple extra runtime dependencies.

ptyx
J2RE? you probably mean SE, right?
Paul Milovanov
You're right - J2SE (or J2SE JRE?).It's Friday... :)
ptyx
+5  A: 

Have you tried Retrotranslator? I read that it does a better job than Retroweaver.

Mihai Fonoage
that's fantastic, thanks! this seems to have much better documentation than retroweaver. I'll have to play with it a bit :)
Paul Milovanov
my only concern, I guess, is how these tools are affected by the bytecode differences in class files produced for j2me platforms by the compiler.
Paul Milovanov
Since I can't comment on comments made by others in a post (don't have 50 reputation yet), I'll post them here: - regarding compiling using 1.5 for source and 1.4 for target, it will only work if you do not use any 1.5 features in your code (surprised it worked for generics though, but I can see why since generics 'disappear' at run time), hence it is not helpful.- regarding other tools you found I do hope that at least one helps you with all aspects of your problem.
Mihai Fonoage
+1  A: 

Here's something else I found here on stack overflow:

Compiling with the regular javac and targeting an older JVM will give you proper bytecode for generics at least

Which absolutely makes sense to try.

Paul Milovanov
I can't remember exactly, but I think generics are ok but enums/new for syntax weren't supported. It might have been fixed in later javac, but at the time I looked, it was barely usable. That was one of the reason I ended up using retroweaver instead.
ptyx
Unfortunately, this does not work. javac does not accept a higher source than target version, so you merely have the choice between a failure to compile and a result that won't run on your target platform.
Michael Borgwardt
A: 

Here's two more tools that I found (linked to from Retrotranslator's page):

Paul Milovanov
A: 

So here's what I ended up doing so far: Declawer + some custom code for enumeration classes generation.

The one differentiating thing about Declawer is that, although it's very simple and, frankly, a bit of a hack (it relies on an undocumented capability of JavaC), its output is actual Java code as compared to enhanced or converted Java bytecode. That's very precious for mobile java-based development as, frankly, bytecode modification/instrumentation is not at all as developed for j2me platforms as it is for j2se, and there are just no guarantees that things are going to work out of the box the way they do with j2se where these tools have already been used by quite a few developers.

Declawer's functionality is limited (no love for 1.5 enums or autoboxing), so I had to add a python script to automatically generate classes equivalent in functionality to 1.5 enums from simple descriptors. This generation happens at build time.

This addresses my concerns so far, with the only exception of finding a good j2me-friendly IoC container to use for my app (once you try these guys, it's so hard to give them up.)

But that's a discussion for a different thread.

Paul Milovanov