The Outer Limits

Not all available Java code, of course, will work well with Android. There are a number of factors to consider, including the following:

• Expected Platform APIs : Does the code assume a newer JVM than the one Android is based on? Or does the code assume the existence of Java APIs that ship with J2SE but not with Android, such as Swing?

• Size : Existing Java code designed for use on desktops or servers need not worry too much about on‑disk size, or even in‑RAM size. Android, of course, is short on both. Using third‑party Java code, particularly when pre‑packaged as JARs, may balloon the size of your application.

• Performance : Does the Java code effectively assume a much more powerful CPU than what you may find on many Android devices? Just because a desktop computer can run it without issue doesn’t mean your average mobile phone will handle it well.

• Interface : Does the Java code assume a console interface? Or is it a pure API that you can wrap your own interface around?

One trick for addressing some of these concerns is to use open‑source Java code, and actually work with the code to make it more Android‑friendly. For example, if you’re only using 10% of the third‑party library, maybe it’s worthwhile to recompile the subset of the project to be only what you need, or at least to remove the unnecessary classes from the JAR. The former approach is safer in that you get compiler help to make sure you’re not discarding some essential piece of code, though it may be more tedious to do.