Will Java have a place in the future of mobile devices?
Mobile industry is transforming rapidly. Mobile operating systems and runtime stacks are at the center of this change. Mobile Linux, Android, and the lately announced Symbian Foundation, the trend is clear. The Mobile OSs are becoming license free and in most cases open source.
The same trend can also be observed on the runtimes that run on these mobile platforms as well. WebKit, which most (S60 , iPhone, Android) of the mobile browsers and web runtimes are based on, is license free and open source. Python, license free and open source. Flash runtime, has no license fees and open source. Java, NOT free and NOT really open source for the manufacturers to ship.
Things do not look very good for Java on the innovation front as well. Manufacturers have to deal with branding and compliance test license costs for mobile Java. This is an additional cost on top of acquiring or developing the Java runtime itself. After all the costs, the end result is MIDP which is not really the bang you want to get for your buck. When the innovative value of the runtimes are questioned, I am sure MIDP product managers are having hard time to justify the resources to put MIDP on the phones. The main reason that MIDP is keeping afloat is its huge install base but it is only a matter of time where other runtimes such as WebKit makes this irrelevant.
I believe the root of the problem is mobile Java vendor(s) have no alternate business model to the license fees. They have been trying to prevent a free Java to appear on Mobile phones just to be able to keep the licensing fees. The open source license choice of Sun’s open Java is partly due to that. Do you recall Apache’s open letter to Sun? The main reason for Sun putting “field of use” restrictions on JCK is another effort to prevent a free and open source Java to appear on mobile phones. Sadly, this is in expense of mobile Java and for a business model that can not be sustained for a long time.
So what are the possibilities for the future of Java on mobile?
The obvious scenario is it will cease to exist in mobile space by time with the exception of Android. Motorola lately announced that it reduces the software platforms that it uses and will start using Android as one of its preferred platforms. This is significant for two reasons because Motorola is still one of the major phone manufacturers and it is the specification lead for the MIDP3 JSR in JCP. MIDP3 is under specification work for almost 4 years now and I guess we will be waiting for it some more. Although the features and innovation of the MIDP3 is not significant anymore but the delays of its arrival is an indication.
Android is a confusing player in the mobile space. Officially it is not Java. It uses the Java language and Sun appears to like it (I can’t really figure out why), at least Android was the main mobile demo platform in the last JavaOne. Android blend of Java is designed as an integral part of the mobile platform rather than a runtime on top of it. This makes it powerful but makes it hard to port to other mobile platforms. This actually brings us to the next scenario.
Android Java becomes so favored that OSS projects start for porting Android to other operating systems such as Symbian, Windows Mobile etc. This is a big effort, I am not even sure if it is feasible. I am sure that it requires the collaboration of at least Nokia, and Google. Also the port must be done in parallel to avoid fragmentation. So it is a low possibility for the time being.
And my last scenario of the day is another open source implementation. Let’s assume for a moment that the mobile manufacturers and the mobile Java platform providers have realized that they are in a crash course. They decide that instead of trying to implement the same old proprietary MIDP in house, they can collaborate for a MIDP implementation that everyone can also use commercially. They can then start to spare some of their resources from implementing proprietary to adding innovative features and adopting new directions to mobile Java. The biggest obstacle with this scenario is companies are not really good at creating new business models and unfortunately such a change requires new business models for Java vendors, phone manufacturers, mobile network operators and even internet service companies.
This is all the scenarios I have for the day. Like them, dislike it, have a better one ? Comments are open, fire away.
It is not so long ago that I decided to go with Java (in general - not in particular for mobile development).
Keep in mind that there is a lot of stuff rising quickly, but if those technologies get real practical in use - we will see.
For me decision was also done on the IDE's available because development times (and hence effort and money) depend strongly on the efficiency of the development tools.
I found Java to be the technology with most and best development tools available.
Since when is the mobile Flash player open source?
I did not find anything on http://www.openscreenproject.org
Talking about business models, what is Adobe's if they do not sell or license their player?
@Martin: Java is also my preferred technology as well. However Java on the devices is very different from the desktop and server Java and not that innovative. I hope industry can finally take the action to correct this.
@anonymous Adobe Flex is open source. The player was free for desktop, however device manufacturers had to license it in order to ship it. The open screen project device manufacturers do not have that anymore. I do not really know what Adobe does if they are not selling the player but they must have a business model.
@nikos I was expecting that someone would comment that Java is open source :) It is not really open source for the device manufacturers and the mobile java vendors. Device manufacturers have to pay license fees in order to ship even the open JDK. It even gets better if they participate in that project and contribute their IP. In that case, they need to license their own IP. So mobile Java is open source if you define open source as I can read the code.
Disclaimer: I work for Nokia and can only speak for myself here.
I think Java needs to (re)earn it's place in the mobile world. J2ME should be considered a legacy platform by now. Platforms such as Android basically show that most of the assumptions, and the resulting limitations, underlying J2ME are invalid for mobile phones now. You can run full Java on a mobile phone and do it efficiently. Techically, J2ME is a dead end but Java isn't.
I still think Java is a good platform for mobile. Platform independence is nice to have in a world where there are many phones, phone platforms, and where each phone is only on the market for a very short time. J2ME is the closest thing to platform independence there is for mobile, right now. Compatibility still sucks though due to vendor differences, bugs, and highly modular nature of J2ME (though this is much less of an issue nowadays).
Open sourcing of Java, J2ME and the various phone platforms, is an opportunity. Good virtual machines are available for most smart phone platforms. The main problem is that their vendors don't support them. The reason for that is Sun's source code, trademark, and IPR licensing. Basically it is a legal minefield. Sun deliberately crippled their J2ME platform by omitting the classpath exception from the GPL. This means that basically no owner of substantial amounts of proprietary code (i.e. any phone vendor) can use GPL licensed J2ME and has to buy a commercial license from Sun. Hence no J2ME on Apple (I'm sure this was fundamentally a cost driven decision).
Google's way out was to bypass Sun and that seems the best way forward. Basically as I understand it, they try to mostly stay compatible with Sun (except for the VM which is necessarily incompatible for energy efficiency reasons). This is a good strategy. They use the excellent Apache 2.0 license which maximizes freedom for those who chose to depend on Apache licensed code.
I think Android will get very popular and that other vendors will adopt/endorse/tolerate community driven ports of the Java layers to their platform.
Customers don't buy technology - they buy solutions to their problems.
If we understand that first then what we develop on is really irrelevant - the customer needs to be put first here.
Cheers,
Peter Cranstone
5o9 Inc.
Software to Power Mobile SaaS
Yes, this is true - but there are also those who get told by vendors about particular technologies bring the solution for them.
And there are also those who only hear about a lot of technologies and think due to that large amount it must be easy to solve their problems. ;-)
Anyway, you are completely right that customer needs must be put first. Second is technology from that point of view what helps the development process to be shorter by maintaining a good quality of code.
@jilles is right.
Android solves this problem by creating a new mostly-JavaSE-compatible platform that is fully open-source. Not only that, the tooling is excellent and includes full debugging amenities.
I wrote my first mobile application less than two days after I got my phone. This is literally the easiest embedded software development I've ever done.
What about eRCP (eSWT)? It's open source from eclipse.org and gives a native appearance, with a richer set of controls than Personal Profile or MIDP on J2ME.
@Peter and Martin: I guess the customers requirements is the main reason Java ME needs to reinvent itself. The features of Java ME started to fall short on except for the low end devices. The development processes have not progressed that much during the years.
@Jilles: I completely agree. Open source Java ME with a commercial friendly license presents a good opportunity for Java in Mobile. Such an endeavor can potentially link Java ME and Android for the developers.
@gopack91: I may be a bit biased but eSWT is the best thing ( possibly the only thing) that is happening on the MIDP area today. It tries to solve the long time accumulated problems of the MIDP UI. The good thing about eSWT is unlike MIDP it does not need to wait years in JCP to resolve an issue.
eRCP is a bit different though. In addition to including eSWT, eRCP provides a component model (OSGi bundles) and an application model. However it does not address the issue of backwards compatibility with existing MIDP applications. Also it does not provide any of the APIs (location, PIM, multimedia etc..) that uses the device features. I think today eRCP is a good choice for anyone looking for a new component model and an application model to include in its complete Java ME stack (like Sprint Titan). What we really need is a complete open source stack.
Hmmm, you must be reading a different Internet. Adobe Flash on my Internet is not free and open. Perhaps parts of the technology and platform are freely available but as a whole it is not. Example FAQ entry from the site you referenced:
The device porting layer APIs will be published on the Adobe website when the APIs are finalized. More details will be available in the coming months.
http://www.openscreenproject.org/about/faq.html
This is the kind of language I've come to expect from Sun when open sourcing closed technologies but in this case it comes from Adobe.
IRT FOSS Java there are examples of several open source implementations available on mobile hardware, which you must surely be aware of (nokia tablets, openmoko, etc.)
Ken, you are right it is not the Flash but the Flex that is open source. I mixed it up.
As for the open source implementations, Although VM is a central piece. Java ME is not just about VM. Also most of the VMs are under licenses that are not friendly to commercial use.
Gorkem, indeed! One project you may be interested in is Jalimo, that aims to provide a free and open JaveME stack to Linux devices. But in general, I also wonder as phone power and capability increases, how relevant are these old j2me standards are, especially when you consider the IP minefield that the mobile JSRs are.
By old J2ME standards I think you mean the optional JSRs. They are valid because they provide access to the features of the mobile devices with APIS such as Location(JSR 179), Bluetooth (JSR 82), Messaging(JSR 205) etc. You still need a way to access those features on the phone, regardless of the kind of Java you have on the devices.
