Writing a Java library for both Java ME and Java SE with as much shared code as possible

I realise that the two Java versions are substantially different but the library I am looking to write uses standard HTTP/TCP networking and data collections to perform it's task. These are two abilities that both platforms provide, albeit to different scopes. I assume that I could write a library that works with the lowest common denominator but it would be ideal to have a Java SE version that exploits the benefits of generics and the more extensive data collections at the very least.

I am hoping that I can maintain a code base that shares as much c开发者_如何学Goode as possible between the two versions of the library, using a build script to produce a separate library for each of the Java platforms. The APIs will obviously differ slightly but if the core business logic of the library can be shared that would save time and effort.

Are their any build script/pre-processing/other techniques I can utilise to achieve this goal? Is this more hassle then it is worth?

Is this more hassle then it is worth?

Probably yes.

Preprocessing is generally frowned upon in the Java world. Preprocessors do exist, but you tend to find that they are not well supported in IDEs, build tools, etc.

For something like this, I'd recommend the following approach:

1. Figure out how much the actual differences are between the SE and ME versions of the code there really need to be. From a long term maintenance perspective, you probably want no differences at all.

2. If there are things that you simply cannot deal with using the least common denominator approach, then factor them out and design / implement an internal API that hides the platform differences. By hand.

Also, consider doing things like porting useful libraries from SE to ME. For example, if you really need a full collections stack, see if you can find a port of the SE Collections framework to ME. (But the downside of this is likely to be code bloat on ME ... and that won't make you popular.)

You need to define what you mean by JavaME. The JavaME platform consists of configurations and profiles, which combine to form the library support. For example, The JavaME Personal Profile 1.1 on top of the Connected Device Configuration (CDC) is a cut-down JavaSE 4. I have a large client application which runs without changes on both JavaSE 4 and JavaME PP 1.1, though I had to forgo a very few APIs available in SE but not in PP 1.1.

The big question is whether the functions you need are available in both JVMs.

Lately we are looking at running the same client under Android, which is a similar consideration. Provided the functions exist in both, my plan is to hide the differences in my own API library and implement a thin compatibility layer for both JVMs which implementing that API.

If you include 3rd party ported libraries, something like ProGuard will enable you to eliminate unused code to minimize code-bloat.