We Keep Coding

How to create a mobile oriented, multiplatform, shared library in Java?

I have a Java application that runs on BlackBerry (JDE 4.5). I want to port this application to Android, and be able to maintain the 2 applications simultaneously. I may also want to port this application to other Java platforms (J2ME ?).
I understand that a good part of the code will have to be specific to each platform (UI and other stuff). But I also feel that a lot of the code could (should) be shared (domain related classes).
What is the best way to achieve this, and what are the pitfalls to avoid?
I have been able so far to create a JAR with all my shared classes, that I have been able to integrate into my BlackBerry application (using preverify and rapc). But:
The JAR is a J2SE library. How can I make sure that it will run (or even compile) on BlackBerry, Android or J2ME?
I am also using a JSON library targeting J2ME (https://github.com/upictec/org.json.me/). This library seems to make use of some kind of preprocessing directives (CLDC, see https://github.com/upictec/org.json.me/blob/master/src/main/java/org/json/me/JSONObject.java#L392). How can I use (or convert) this library using the right preprocessing definitions?

This is likely to be difficult:
As you have already identified, the UI code will have to be different for each platform.
There are major differences between Java SE / Android and Java ME-based platforms. For example, ME doesn't have the Collections framework, or the java.io or java.nio stacks.
It is hard to predict from the information you've provided, but there's a fair chance that you'll spend more time fighting the platform dependencies than you are saving by sharing the code-base.

These days, the biggest stumbling block to sharing code this way is that the BlackBerry VM and Android VM both support different versions of the Java language. BlackBerry uses a subset of Java 1.3, Android uses a subset of Java 1.5. (As an aside, neither platform implements a Java VM, both use their own VMs. Java is used as the programming language. Java bytecodes must be transformed to the appropriate native VM format before they can run on the platform.)
The biggest difference you will find as a library implementor is that the BlackBerry lacks the things that were introduced in 1.5, very important things like generics and enums. Even worse, the Collections classes are missing from the BlackBerry. It is unfortunate, but that is the way it has been for a long time now.
This means that to be truly portable you have to write to the lowest-common denominator, which means using (very) old-style classes like Hashtable and Vector, not having generics, rolling your own enums (as in the 1st edition of Effective Java) and so on.
Or you build two libraries, a modern version for Android and a stripped-down version (with just the bare stuff you need) for the BlackBerry.
Hard to say what`s right for you.

Rather than prepackage your shared library, I would consider sharing the library project and having it as a dependency in your mobile applications' build process. That would allow you to share the code base, but have it built by the appropriate builders for your target devices. With a bit of IDE magic and some attention to detail, you should be able to pick up errors before anything is shipped out.
Alternatively, set up your library project to use two separate builders to pick up errors. That would allow cleaner distribution, but you may run into problems trying to convince your IDE to treat the project as being device specific in order to identify problem areas.
It would be likely that you would end up supporting the lowest common denominator device (cough Blackberry), and forgoing the additional facilities of the more extensive Java implementation on Android.
Unfortunately the answer will be one of experimentation. Try it and see what happens.

The article Porting Android code to BlackBerry has some good detail on how to work with code shared between the two platforms.

it will be very difficult to create shared library for blackberry and android.
if you want simple method, create your application as web app.
using
phonegap with jQtouch

How much of Java can I really use with GWT?

I'd like to learn GWT, and I like the fact that it compiles to Javascript. My question is, how much of Java I can really use with GWT? My guess would be that limitations apply mostly for client side, while on the server side I should be able to make use of any existing Java library, right? Or, will I be only able to use a small subset , because of the compilation to Javascript thing?
What are it's limitations? I am interested in what it's not able to do, or things that require too many workarounds to implement. I need to know if learning GWT is a good choice for a possible freelance carrier in web development.

The GWT website has this documentation exactly to answer that question.

See the JRE emulation docs. Those are the supported out of the box emulated classes that you can use.
"Google Web Toolkit includes a library that emulates a subset of the Java runtime library. The list below shows the set of JRE packages, types and methods that GWT can translate automatically. Note that in some cases, only a subset of methods is supported for a given type."
You can also provide your own emulation for other classes using <super-source/> in your gwt.xml to point to a package that will provide replacement Java classes for those that can't be directly compiled to JavaScript.

Can Java SE class libraries be used on mobile devices?

I am relatively new to Java, and am developing a Java implementation of a class library I have already written in .NET and Objective-C. The library in Java is primarily being aimed at Android devices (or any device which supports Java) - would a standard Java SE library be compatible with Java ME? The only data types being used are the standard base types, including String, and possibly StringBuffer from the java.text package.

You'll have to look exactly at the class library present on each specific target device. There are different Java ME profiles, and Android is something else entirely (has nothing to do with Java ME). But the classes of java.lang (and that's where StringBuffer lives, not java.text) are of course present on all of them.

Android is mostly Java SE with a few Android extensions. But it sounds like your use case will work fine.

The compatibility of the library would depend on what does it actually use from Java API. Bear in mind that some classes that exist in both SE and ME don't have the same set of methods (i.e. ME has less).
As a general case, I'd say the answer is no, however the best way to find out is to actually try.
Also, as a sidenote:
If you need the library for some heavy lifting operations, it might not be wise to do that on the mobile device. If your app is supposed to communicate with a server, you'll probably want to put more resource-heavy operations there. Another benefit of that design is that the server side application is using Java SE and may use any Java library whatsoever.

Starting with Android: Java or Python (SL4A)

I just ordered an Android smartphone and want to start playing around with creating my own applications. Now the question is which language to use, the native Java or Python using SL4A (former ASE).
I tend to Python, as I know it much better than Java, but I'm wondering what I would be missing using a "second class" language on Android. On the SL4A website it is also stated to be alpha quality software, which is not exactly encouraging.
I'm also not quite sure what the limitations of the scripting environment are and if they would be problematic.

At the moment you cannot create a releasable program with Python (or any other scripting language) using SL4A. I have heard rumours that this is something Google is working on, but even if they do enable it Python apps are likely to be slow and power-hungry compared to Java. Also the scripting API only gives you access to a limited subset of the native Java API. I would not consider using SL4A for serious development work at the moment, only for one-off scripts and prototyping.
Take a look at Scala. It is a statically typed language on the JVM, but uses type inference to remove most of the noise that you get in Java. It also fully supports functional programming, and has a lot of pythonish features. Because it is statically typed it is as efficient as straight Java with none of the disadvantages. IMHO it is the language that Java should have been in the first place.
A lot of people are blogging about using Scala on Android, so Google around for more information.

More likely will depend what type of applications you will develop.
I would start with Java to become familiar with Android SDK. Anyway first you need to look into some examples, tutorials. Most of them are done in Java, and only a few, probably on the dev site of SL4A for that.
Also there is native development Android NDK, that can be programmed with C++.
But anyway Java rules for general applications.

Adding an update to Dave Kirby's answer:
Issue 55, Distribute scripts as APKs, in the issue tracker at SL4A deals specifically with that.
There is a solution being worked out (may be complete by now) described at SharingScripts. The only issue seems to be that you need to have a interpreter APK already installed.

you may want to check out Ruboto it is a framework for developing Android apps based on JRuby which means your JRuby code can call Android APIs and can also be called back from the Android Java side.
Here is an introduction article .

Consider ising Kivy, if you want to write Android apps with Python. The process of packing script to .apk file is described here.
The problem is, resulting .apk will be big (~7Mb for 300Kb data). It is obvious, because you need to pack there Python runtime and all libraries.
Another solution I have heard of, is Pygame for Android, but it works on lower lewel, so you need to draw graphics manually.
Unfortunately, I have not tried any of this ways yet, but it looks, that I'm going to start using kivy soon.

Is there any language other than Java that will work as ubiquitous on mobile?

I'm trying to write a rogue-like game for my blackberry and hopefully
any other phone that supports some sort of JVM.
Because I use Java in my job I'm looking to write the game in another language but I cannot find a language that will work on multiple phones.
Am I stuck with Java?

If you're programming for Android, you could for example use Scala, see Scala on Android. Scala compiles to Java bytecode. There are also other languages which can be compiled to Java bytecode; I don't know how well-suited they are for Android programming.

You could try to use another language for the Java platform. Unfortunately you'll be rather limited there as well, because J2ME is based on a rather ancient version of Java SE and most modern languages for the Java VM need either Java 5 or at least Java 1.4.

Lua runs very well on small devices (I use it on my handheld), but it is designed to be coupled into a C API. You may well have to write glue code yourself, which is easy, but if the official APIs are Java APIs and there is no C API, you'll be out of luck.

Actually C++ is pretty universally supported at this point. However you are completely stuck with Java for Blackberry.

Technically, I think the second (JavaME being first) most widely deployed runtime worldwide is Flash Lite.
Whether it would be a good idea to use it for your game development is another matter entirely of course.
Number three is Symbian OS C++ but that won't work on your Blackberry.