Java is perfect also for client side.
We have a client app (a complex VoIP softphone) with different codebase for all platforms (C++ for windows, java for android, ObjectC for iOS). Right now we are in the way to reduce all this in one single codebase written in Java and the user interface in html/css/javascript, so the user interface is always running in a webview.
-Java for windows desktop (there are pretty installers which automatically download and install the JRE if not present)
-Java for MAC and Linux desktop (same as for windows desktop. the same installer tools can generate also Linux and MAC packages)
-Java for Android (with a very minor conversion for which we already wrote a converter app)
-Java for Web (currently using a java Applet which works perfectly. We plan to use GWT to transform to JavaScript in the future)
-Java for iOS (will see)
This way we plan to cover 99% of all devices with java only (with some minor transformation for some platforms).
What is your opinion on this? I am in the right direction?
This is horrible, but not because of the Java part — it's the webview that puts your desire for a single UI technology stack ahead of user's desire for a decent UX.
On mobile devices the issue is Oracle dropping the ball and leaving to third parties (RoboVM, CodenameOne,...) the work of providing JVM implementations.
This on iOS, still no story on Windows Phone, which actually happens to be over iOS on some European countries.
I am using java 1.5 features only :)
Actually i never understood this spike about language features. For me the focus is always on the problem what i am trying to solve (VoIP in this case) and never the language. Actually any language would do for me in which i can apply some encapsulation for better code management (think of java classes). The rest doesn't matter :) I was started with C and then C++, but for me C++ is still C with classes :)
>i never understood this spike about language features
You should really read about the Blub Paradox. Imagine writing all your coded in assembly. It would suck because assembly is an inferior language To those you mention. Now imagine working in a language that is higher level than what you've (yet) been exposed To.
We are working hard on making RoboVM as mature as possible. There's already plenty of applications on the App Store using RoboVM. Happy to talk if you need more info for decision making. Ping us at hello@robovm.com.
Unless you want it to look totally native client-side. The extra effort required to make a Java app look platform native is something that (near as I can tell) no one has ever attempted.
The trick is to use the Java SWT library rather than Swing. (In my case I also added a few platform-specific hacks such as having a big toolbar at the top of the main window in OS X but not Windows).
IntelliJ has historically looked pretty native on MacOS X. At least until Yosemite pointlessly reskinned Aqua to look more ugly. Now I find myself quite happy that IntelliJ is not a native Mac app because I preferred the old look anyway :)
You can make the apps look native, if you really care. But in an era when web apps are the shizzle why would you even care? No web app even tries to look native. They just do their own thing and nobody cares.
For development speed and code maintenance, this is ideal. Your team only needs to master one language and its set of tools and libraries.
You are pinioned by this choice on some practical levels. Mainly, some users and use cases demand the speed and lightweight user-experience of native apps. The native-vs-[java] experience is typically quite noticeable on all the platforms you've mentioned -- desktop, web, and mobile.
Right now I am working on the windows desktop app. I can tell you, that you don't notice any difference at all in speed (I also wrote a simple "container" app in native c++, so it is also loading instantly ..there is a ~2 sec delay to load the JVM, but meantime the user already sees the UI)
-Java for windows desktop (there are pretty installers which automatically download and install the JRE if not present)
-Java for MAC and Linux desktop (same as for windows desktop. the same installer tools can generate also Linux and MAC packages)
-Java for Android (with a very minor conversion for which we already wrote a converter app)
-Java for Web (currently using a java Applet which works perfectly. We plan to use GWT to transform to JavaScript in the future)
-Java for iOS (will see)
This way we plan to cover 99% of all devices with java only (with some minor transformation for some platforms). What is your opinion on this? I am in the right direction?