Ex-Sun Employees Are Taking Java To iOS

An anonymous reader writes "Ex-Sun employees did what Sun/Oracle failed to do since the iPhone launched. They brought Java to iOS and other mobile devices. They are getting major coverage from Forbes, DDJ, hacker news and others. They are taking a unique approach of combining a Swing-like API with a open source and SaaS based solution."

Comments

Not entirely useful

[medcalf]

Just to be clear, this does not allow users to run Java apps on their phones. It makes it easier for Java developers to port Java apps, though.

Re:Not entirely useful

[binarylarry]

Why would you want a desktop app on a phone anyway?

Except for certain very narrow use cases, it's better to have an app written for phones.

Re:Not entirely useful

[aaaaaaargh!]

There hundreds of thousand Java apps that are not desktop apps, like e.g. every Android app. So what's your point?

Re:Not entirely useful

[sl4shd0rk]

Why would you want a desktop app on a phone anyway?

Java is a portability option (if you are mindful). You can write a single Java based application and run it on any platform supporting the version you compiled for. This gives you instant portability to other platforms without having to wonder about ended-ness, hardware, file structure and myriad other things. Imagine writing a game on Linux and automaticaly, it would run on Windows, Mac and any other Java supported platform.

Now, all this ease does come at a cost. It takes an extra layer of software (java VM) and more CPU power and RAM than a native application but this is the tradeoff. If you are wise, you can get acceptable performance out of modern hardware.

In reality, developers haven't always coded Java with portability in mind. Some platforms (won't mention any names) have been suspect of "hobbling" the stability of Java on purpose because said platform had their own implementation to market, but that's beside the point. Java portability is a keen aspect of the language which sometimes gets overlooked. It can offer some very real benefits under favorable circumstances but is by no means the end-all many would like. It has it's drawbacks too but the portability is a big one.

Re:Not entirely useful

[Anonymous Coward]

It will work for android. Rather than trying to run Swing on the native platform, It compiles down to whatever the native platform is. Basically in C1 you are building a meta app using their libraries. Then when it compiles, for iOS it will generate Obj-C, for Android it will generate a UI using standard Android widgets (I know Android is java, but not sure what their UI framework is called).

I'm a Java/iOS developer and have been playing around with it a bit. IMO, it has a long way to go before being useful, but it's exciting to see that what they are doing is possible. Currently their API is pretty sparse and their design tools are very primitive, so I think to match what a lot of apps are doing today, you would still end up writing a lot of native code. They have their own version of JNI that let's you do that.

I think if they keep working on it though, create a cool UI builder, add more wrappers around more core platform services (location services would be a good one to add next I think) I think they will get there.

It's neat stuff! I'm still going to do my iOS apps in Obj-C though for the time being.

Re:Not entirely useful

[Bogtha]

Android applications aren't Java applications. They are written in the Java language, but they are then compiled to run on the Dalvik VM. Even if they were Java applications, you couldn't simply drop them onto any old Java VM and have them work; they need all the runtime libraries present on Android to work.

Re:Not entirely useful

[owlstead]

That is certainly true, but most of the libraries that are used for core functionality of applications (at least if your application is not just a GUI or Android specific) are fully compatible with the Java runtime after compilation, and almost any third party lib can be compiled and run. The only problem is that many applications are too dependent on the GUI - in other words if they are badly written.

Swing like API?

[HornWumpus]

Is that any API that basically doesn't work?

Java Stack Traces

[doubleplusungodly]

I hope iPhone users don't freak out when their Java apps suddenly start printing 500 line stack traces.

Re:Java Stack Traces

[blackfrancis75]

The fact that iDevice users in general aren't accustomed to error messages whatsoever brings up a philosophical question..
If an App falls over and no one sees an error message, did it really fail?

Re:No, thanks.

[gbjbaanb]

Um.. you realize that every Android application is written in Java, and there are quite a few exceptional Android applications.

I think you'd be surprised at how many of those are written using the NDK. Download addon detector and look for yourself (its an app typically used to check an app doesn't include some dodgy notification-based ad networks, but it also shows you a load of other interesting info). 80% of the games I have on my phone are NDK based, they're the ones that are responsive and fast.

Separation of model and view

[tepples]

Then write a Swing front-end, which runs on J2SE platforms, using the same application logic as your Android application. If your application's model and view are separated correctly, this shouldn't be hard.