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.
Related
From what I understand, Blackberry Java Runtime runs micro-java runtime.
Which is based on Java 1.3. (thanks Andreas_D)
Blackberry supplies a few alternatives, or the micro-java supplies some alternatives.
But its such a pain. We have an App that uses android java, of which supports full Java 1.6. We were hoping for a conversion of the UI components, but now have to rewrite code?
Is there an easy way to over come this problem?
I cant get a java.io.File for example. And its not the only one..
Are there alternatives for :
java.io.RandomAccessFile
java.io.File
java.io.FileOutputStream
Missing a bit? Yes if you're comparing it to a full Java SE / EE implementation. No if you're comparing it against the Java ME reference implementation.
Java ME (J2ME) doesn't contain all the API classes you may expect in a full Java SE platform - it was never intended to. Also, mobile devices need to be able to grant and revoke specific permissions to applications etc.
Remember it's a deliberate subset for devices with limited resources and the omissions are pretty well documented. For example, file access in Java ME is done via file connection api:
File Connection API
Also see these sites (for other/general differences):
Differences between Java SE, EE and ME
Difference between Android and Java ME development
Differences between programming for a J2ME JVM, and programming for a J2SE JVM
Java ME Wikipedia Page
Java ME CLDC - Noteworthy limitations list at Wikipedia
Blackberry supports Java 1.3, not 1.4.
The cleanest way to get around those missing File-related classes would be to write some wrapper classes which just expose the functionality you need, then you can write implementations for BlackBerry using whatever's available via the J2ME and BlackBerry APIs.
Alternatively, you could just write your own versions of java.io.File etc for BlackBerry, and include those in your project. If you take this approach you'll need to be very careful to mimic the behaviour exactly or you could be opening yourself up to a whole new world of painful bugs.
There may well be libraries out there for BlackBerry which do what you want, I'll leave it up to you to do some googling on that...
It's said in the title. which Java Classes can I use when developing Android apps. Are there any exceptions, can I use the lot of the Java Library, like the whole of the standard Edition?
You can use all classes listed in the Android API for your desired API level (which corresponds to Android releases).
The Android API is roughly based on the Java SE API, but it is missing a few parts and has added significant parts of its own API.
Knowing the Java SE API can certainly help, but you shouldn't assume that everything in there is available on Android.
You can almost use all the Java Classes. The only thing you need to be aware of is that you can't use any Graphical and UI classes as Swing and AWT. Else it's pretty much the same.
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
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.
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.