As a newcomer to the world of Symbian, I’ve been faced with the daunting but immensely exciting task of mapping out the future of Symbian platform runtimes. With the annual JavaOne conference opening in San Francisco next week, it seems like a good time to reflect on Java.
Back in 2000 I was an excitable developer creating tiny databases in Silicon Valley. I’d play around with Java on Psion netbooks dreaming of a day that I’d be able to use this technology to get my database on the phone of every corporate road warrior. A year later at JavaOne 2001 my geeky dream was realised and the database was being showcased on the Motorola i85 handset. MIDP 1.0 created a huge industry buzz, Java technology was embraced by the mobile industry and the pace of innovation was unprecedented.
8 years on as MIDP 3.0 comes to the end of its long and tortured development; it faces an industry questioning its relevance. Microsoft has never shipped Java as standard, Apple has an enviable application store without a Java application in sight and the Android platform has side-stepped Java with the Dalvik virtual machine. Developers are also finding Java-alternatives more innovative, simpler to deploy and ultimately more commercially attractive. So what has gone wrong for Java..?
One of the biggest issues for Java has been the commercially motivated JCP governance model. This model was once the poster-child for collaborative development, but the JCP has been used as a lever for political and commercial gain, leaving the broader industry out in the cold. Slow innovation, fragmented implementations and confused routes to market are a huge turn-off for developers. Equally, license agreements that give lawyers and finance directors cold-sweats don’t wash with device manufacturers in the face of strong competition.
So what does this mean for the Symbian Foundation and the future of Java? Open-source has always been the friendly face of collaborative software development. Throw a commercially friendly licensing model into the mix and the Java way of doing business looks outdated and ugly. Without a shift in governance and business model, a slow and painful death for Java is inevitable. If Java can’t be persuaded to change, switching off its life support may be best for everyone.
21 Comments
Thanks for the update!
How about future of HTML5 and JS on Symbian?
When will Symbian phones get HTML5 native in the OS?
When can be develop, deploy and run HTML5 apps alongside with native .sis apps (cf. Palm Pre)?
Google IO 2009 HTML5 demos looked really nice.
iPhone and Pre are *up there* with html5.
When’s symbian going to follow?
At a conference a year or so ago, I witnessed a frustrated Sun engineer explaining why Java implementations are so fragmented, giving the platform the unfortunate tag line, “Write Once, Debug Everywhere.” His explanation was that the open source process, as implemented by Sun, put the community in control, and that control was what developers wanted.
Open source strategy seems to be like rearing children: some parents let their kids do whatever they want, while others are strict disciplinarians. Sun’s Montessori-style governance is clearly not working, from at least the fragmentation perspective. Google’s method of governance is perhaps too controlling: rumour has it that when a developer submits a contribution, Google decides whether to accept it or not, and if they do accept the idea in concept, they rewrite the code from scratch. My optimistic hope is that Symbian Foundation will find a good balance, the “sweet spot” of governance that inspires innovation and yet keeps fragmentation to a minimum.
> Without a shift in governance and business model, a slow and painful
> death for Java is inevitable.
For Java on mobile, yes. Java in the PC / corporate environment looks to be thriving (at least from the jobs always on offer).
Like Vasra I’m also extremely interested in HTML5 support and personally think that should be at or near the top of things the OS must support ASAP.
Do you have an opinion on this?
http://google-opensource.blogspot.com/2009/05/web-storage-portability-layer-common.html
Do you think Symbian should support Gears?
This is pretty sad news… J2Me (in the form of OperaMini) is the only reason I read this blog. Would definitely change my perception of S60 if it had to come minus Java!
I agree: Java on Symbian and it’s promise of “Running Everywhere” is a total lie/mess.
I personally believe that is WAY MORE PRODUCTIVE to develop DIRECTLY in Symbian C++, separating properly UI from Core functionalities, and then adapt the UI for the particular platform/final phone.
@Vasra: I’m wondering about exactly the same thing. I can give you some info.
S60WebKit, the porting of WebKit to S60 done by Nokia, is OUT of DATE, BUGGY and EXTREMELY SLOW. This will change only in 2 cases:
- Some one (us?) takes care to rewrite completely S60WebKit, wrapping properly WebKit and it’s powerful/fast new JS engine
- Nokia does it!
The second it’s very unlikely: we sent a long list of bugs to Nokia directly, obtaining only some few minor bugfix.
One example: It’s impossible to instantiate MORE THAN ONE WebView/Control on the screen per application. Yes, I swear!
Indeed, may Java ME be a lesson to us all.
I’ve spent the last few months debugging Java code on both Blackberry and S60 and we’ve had to fork the code – even the “MIDP compliant” code behaves so differently.
The reality of MIDP is that you write and test for one device at a time. The notion of targeting a vast platform is a myth.
I’m particularly frustrated that I’ve spent a few months finding memory leaks in the S60 implementation which simply can’t be worked around (that is leaks in the native code which won’t be freed up by the garbage collector).
The ubiquitous mobile platform is like something out of Greek Mythology. It temps developers and funding with the promise of economies of scale and re-use but the reality is that people who set off developing an app for all phones all become experts in the various bugs and limitations that plague each platform.
> The ubiquitous mobile platform is like something out of Greek Mythology.
> It temps developers and funding with the promise of economies of scale
> and re-use but the reality is that people who set off developing an app
> for all phones all become experts in the various bugs and limitations that
> plague each platform.
Does that mean we should give up or try and find a way to make it work better…?
Have to link http://www.tbray.org/ongoing/When/200x/2008/07/18/Mobile-Net-Gloom here.
Well, somebody has to disagree. It might as well come from a former member of the Symbian Java team.
Let’s look at the reasons why JavaME is fragmented:
- bad specifications: Sometimes, it really looks like nobody actually reads through JCP specs before they are published
- low interest from handset manufacturers: Java is for games only, it’s not going to really help us sell phones, let’s just buy the cheapest VM available and not spent much time adapt it to our form factors.
- insufficient testing: how many times were TCK released with bugs? How many times were handsets released without passing the TCK tests?
- inconsistent operator requirements: because they each have their own focus on a different strategy to differenciate themselves, which, by the way, doesn’t necessarily match what happens at the JCP or manufacturer level.
This things would kill any technology yet JavaMe is still the only possible choice when it comes to targetting as many handsets as possible.
Neither Flash, C++, Objective-C, QT, Dalvik, Ruby, Python nor Web Runtime comes even close.
With the recent spotlight shun from the App Store trend, I would say JavaME won’t die for a fairly long while.
Of course, it’s a pain to develop for properly but that shouldn’t be much of a disincentive for software developers who are supposed to take pride in their achievments. No pain, no gain.
Michael, you’re disagreeing, but you seem to be making a case for a switch to and Android/Dalvik VM:
Bad specs – no problem, all consistent design and implementation driven by Google (although this itself might not be seen as a good thing)
Low Interest – not that case here, definitely not just for games and lots of interest from operators and some manufacturers
Insufficient testing – the jury is out, plus no real attempt to spread across platforms or certify implementations yet
Inconsistent requirements – see bad specs above, risk of forking is moderately high if operator requirements aren’t met though
The fact that people still use Java ME is really just an artifact of there being no alternative. The industry agreed to make Java ME a cross-platform standard but have failed to make that happen. Since the governance of Java ME via the JCP is acknowledged as one of the failures, why not try an alternative! Java is a very widely used language, so Dalvik/Android seems like an obvious choice.
I can’t really see why Android/Dalvik will end up any different if there are any cross platform aims.
Java ME fails because it is trying to effectively be an OS platform without buy in from those who deploy it i.e. the kind of service you expect from an OS vendor. Obviously it fails because of it’s licensing terms as well.
Put cross platform standards into perspective.
30 years of standards like POSIX have barely brought us to a place where you can write a simple multi-threaded app which does some networking and non-gui based interaction which would work on every platform claiming standards compliance.
Michael hits the key point. What is the price of failure to implement to a certain standard correctly? Very little because all standards need to be enforced softly because it would be impractical to have a standard that was backed up by the only effective means available i.e. legal enforcement.
I expect you’re right. Actually I think write once compile everywhere (i.e. the Qt approach) sets up expectations better and has more of a chance of working (because one company driving it is actually trying to deliver their own services across all platforms) than any Java-based write once run everywhere approach. However, just because it isn’t all that likely to succeed, does it mean we should give up? It seems that the result is hardly likely to get worse.
Vasra,
I’m planning to address web runtimes in my next posting, so I don’t want to give too much away just yet…
In the context of this posting; the ubiquity, features and relatively unconstrained innovation in the browser-space is a significant threat to Java – especially for quick, fun applications. HTML5 goes one step further in augmenting the “rich client” experience inside the browser. Equally, the JavaScript performance race is well and truly underway, which can only be a good thing for web programmers.
David,
I completely agree with your first comment. Java is very strong in the enterprise space and has found good niches with consumers. This is why Java is consistently popular as a programming language and why there is an unrelenting desire from the mobile industry to tap into Java’s huge community of developers.
HTML5 and Gears…watch out for my next posting…
Rob
Louw,
As an open operating system driven by an open community, it would be difficult for anyone to eliminate Java without the wholehearted backing of the community.
Even if the community took that bold step, there is nothing to stop the creation of an Open Source Java implementation under the Eclipse Public License – although there would still be a few TCK issues to sort out…. Equally, the Eclipse Public license allows commercial innovation on top of the platform, leaving the door open to manufacturers to add Java or direct-to-consumer solutions.
I would love to see Symbian adopt a worthy language as a Java successor and promote it to mobile development. There is a very nice modern language out there: Scala! Many Java developers already jump on this bandwagon. Scala is powerful, elegant, object-oriented, functional, and JVM-compatible. It even has a useful web framework (Lift).
Symbian Foundation could come to terms with its developers at EPFL and help shape Scala’s future while promoting mobile and embedded applications.
—
I hope to see a Symbian future based on Qt (for native, mission-critical applications) and Scala/Lift (for everything else). Widgets and scripts could complete the picture!
Very interesting discussion!
I’m currently the Community Manager for Sony Ericsson Developer World but this is all my personal opinion. I have been working with mobile Java since 2004. For Sony Ericsson it has always been extremely important to reduce fragmentation problems for developers as much as possible.
That was a problem that we focused a lot of resources on and I think we succeeded fairly well, building a consistent platform that developers can trust works the same on different phones from us and as close as possible to phones from other vendors.
And, looking back, things _have_ improved throughout the industry. There are excellent UI frameworks available and the early bugs in the phones have been fixed. I think we all can agree that if you build a Canvas-based midlet that only uses networking it will run on most devices out there with few, if any, modifications. Right?
The problems are mostly in some areas of some JSRs. They are unfortunate, but one has to remember the incredible growth of the Java platform on mobile in a relatively short period of time. That is growth both in terms of volume and in terms of features. In 2004 color displays were still uncommon and only a few phones had cameras in them. The web browsers were quite frankly a joke and the multimedia capabilities laughable compared to todays standard. And that was just 5 years (and about a billion or so phones) ago!
So, yes, there are problems, but there are also parts working good and stable.
Looking ahead, I think what the current app store successes have taught us is that a complete ecosystem requires 1) a consistent platform with a large enough install base 2) good developer tools and 3) a deployment and payment mechanism that makes it easy for the end user to find and purchase applications (aka an app store).
Java ME is strong in 1 and 2 but has been lacking in 3. As I said, this is my personal opinion, but it’s clear that Sony Ericsson (and, may I add, the rest of the industry with us) focused very much on #1 and too little on #3.
That is now changing. We’re improving our application shop and so are other vendors. Finally, the last piece of the puzzle is getting in to place.
The future for mobile applications is extremely bright and Java ME is still by far the largest platform out there with arguably the best developer tools, frameworks, books – and developers.
Add that third and oh so important last piece of the puzzle to that and I think you will have a very fertile ecosystem that will bring many opportunities for its’ inhabitants in the years ahead.
that’s funny cause if it wasn’t for Java on my n95-3 running s60 v3rd FP1 I wouldn’t have some apps on my phone that the developers didn’t feel the need to make a dedicated app for s60 ( I guess lack of support for a symbian system.) For example my local newscast ( Los Angeles metropolitan area) has a traffic cam app that supports apple, WinMo, Android, Blackberry but not for s60 so I get a Java app to use on my phone. Skypelite is also java based too butthey don’t have a dedicated s60 app. So I’m very grateful for java otherwise I wouldn’t have as many apps to choose from for my phone. Now even less though since I’m stuck on FP1 I know most new apps will be for FP2 now…….But No wonder you guys are screaming for and bating developers with free phones for s60 or symbian platform. Keep working hard though!
Lu, there are hardly any FP2 only applications. S60 3rd Edition feature packs have backwards compatibility and S60 5th Edition shares that compatibility. The newer versions have new features and using those can break compatibility – this isn’t very common though.
Unfortunately, being in the US where S60 penetration is extremely low, you’re not likely to get local apps. However, for Skype you should try the native Fring client on S60, it’s very much better than Skypelite.
Hi all, I am a bit surprised with this post and some of the discussion. There seems to be a a general lack of reference – e.g. most of posters are not happy with J2ME – but don\’t really compare it with some other way of developing and delivering apps for as many phones?
What would be an alternative from the developers point of view?
I wrote three mobile apps in the last few weeks. The Symbian.org widget using Symbian Web Runtime, a Mirror app using front camera with J2ME and a visual Hello world with a Symbian logo graphics in Symbian C++. There is no comparison – J2ME still offers unparalleled tools, elegance and portability. Web Runtime is great but suffers from many teething problems and does not even try to be portable to other plaforms.
Granted, there are some problems with J2ME – and licensing is perhaps the most important of them. However, most other problems discussed are not as acute as they have been made out to be – especially compared to other environments.
But let\’s set that aside for the moment and look at the other side of the coin. What\’s good about J2ME and why it had huge success in drawing crowds of developers:
- J2ME is the ONLY runtime environment with a consistent specification and usable feature set which also allows targetting very large numbers of phones from different manufacturers
- There is diversity in implementations but this is dealt with by efforts such as J2ME Polish (see j2mepolish.org)
- There is an immense number of resources available for J2ME – documentation, books, sample code, snippets etc.
- Development tools are plenty and mostly free
- For many models J2ME is the only way to deliver applications
- There is a huge pool of skilled developers
- The investment into J2ME has been huge – for developers, manufacturers and operators alike.
These last two should be read and re-read carefully. Poking developers and publishers who have invested into J2ME with \’letting j2me die\’ won\’t help Symbian. There is no question that J2ME will remain in handsets of most manufacturers – including those who use Symbian – for many years to come. It is simply too valuable and too useful to be dismissed.
I heard OVI store is dominated by java apps.
4 Trackbacks
[...] on the Official Symbian Foundation Blog, they recently posted an interesting read on why they might consider dropping Java Support in [...]
[...] L’articolo per intero sul blog di Symbian Foundation [...]
[...] Symbian Blog] Tags: java, [...]
[...] if you look to Runtime Bob’s latest post on Symbian Foundation blog, it seems that neither at Symbian, where Java was meant to be a first class citizen, [...]