Focus on three core runtimes for the Symbian Platform

Fully agree with the benefits of a simple runtime story. It harms adoption that new developers are faced with a bewildering set of runtimes with inconsistent levels and approaches to support.

I like the idea of defining two levels of runtimes:

• Tier1 - SF Platform. The runtime is in the SDK. Most importantly - the SF takes responsibility for the end-to-end support of developers for these environments. This doesn't mean that SF starts writing API reference docs for all Tier1 languages, but it does mean that I can go to developer.symbian.org and it takes of me from "what is this Symbian thing" to "I just sold my 1,000,000th app".
• Tier2 - Supported. You can use this runtime on Symbian, but the SF doesn't take responsibility for end-to-end support, it can't guarantee that it is supported on all devices (it won't be), and basically this is going to be more work. (challenge here with security having after-market installed runtimes - but I'm sure Craig can sort that out)

Why bother with both levels? Tier1 is for 95% of people. Tier2 is for a vocal (and influential) set of people who really don't want you to say that they can't use (e.g.) Python on Symbian devices. Means you don't ever need to get into a "but platform ABC supports it why don't you".

I think that the Tier1 languages are:

• QT
• Javascript
• Dalvik? It's clearly either Dalvik or JavaME. Given the current competitive landscape I'd be tempted to go for Dalvik. It generates a very interesting conversation if Android apps run on Symbian devices. Makes people question what Android is again. BTW - I know that everyone likes to say "JavaME is dead/dying", but there are two interesting points that shouldn't be ignored in our haste to make this statement true because it suits us. (1) Java is the world's most known programming language. (2) The use of Java-like as the appdev environment is sited by many as a core reason for some of Android's success and I think this is credible.
• .NET; I think that this is easy to achieve (Red5Labs will do all the work) and is a key ingredient to get in to the enterprise space and generally as a nice positioning thing against Blackberry and WiMo.

BTW - personally I'm not a big fan of the "signature runtime" thing. Not sure what benefit it gives SF to say that QT is "more Symbian" than Javascript (or whatever the respective runtimes are). I think it creates a link that has little benefit to SF, but has several downsides.

2    0

Mark Wilcox - May 21, 2009

Beaten to the post...

But Java ME IS dying as far as smart mobile devices are concerned, even if not for the whole mobile market.  Most serious development houses have been doing a native Symbian version and a Java version for everything else for years already.  Building a nice UI in Java ME is still hard (despite recent attempts to remedy that) and the JSR process is just too slow.

Most Java developers recognise this and are noticing that their runtime isn't getting the investment and attention that it used to.  The Google move to select a 'Java-based' language for Android was very smart indeed.  Lots of disillusioned mobile Java developers (and desktop/enterprise Java developers) looking for a good mobile platform to target... tada, Android... an obvious choice.

Dalvik on Symbian is extremely interesting for a number of reasons!

How to integrate with the Android security model... now there's a really interesting problem for Craig to get his teeth into.

 

3    0

Reply

mike bradshaw - Sep 20, 2009

I would be tempted to vote to have .NET on T2 for now alongside Python, and if it becomes really popular, it could be promoted to T1

 

I think that it could also be worth having a Tier3 - known to work on some devices. This in turn implies a slight promotion of T2 languages, e.g. some testing is done by SF to check that it still works?

The thought behind this is it allows people to start gathering around the next great language for mobile, or to show that there really is support for that runtime in the community.

The only thing that SF has to do then is maintain a list of these T3 languages & runtimes

0    0

Reply

I like the principle, I can forsee issues.  Here's how I see it.

1) Is clearly going to be Qt (with some Symbian C++ hybrid stuff for a while yet).

2) Can't be Java ME - it has no real future for smart mobile devices.  We can't take it out yet, nor can we replace it yet (as we don't have an alternative).  To me an Android compatible framework (a port of Dalvik & Android APIs) is the obvious replacement and is likely to be very popular with network operators (and probably some OEMs).

3) The biggest problem area - what do you propose?  The current WRT and future WebKit based extensions?  What about Flash?  There's a lot of investment for Flash on our platform going on at the moment.  Flash can't be the only one - tools are too expensive and not functional enough for bedroom coders.  Of course Flash isn't an official part of the platform, and can probably re-use the same native bindings as the web runtime, so I guess you could consider them one runtime and that's your 3.

Personally I'd like to see a fourth official runtime, a scripting language with native extension support that's not web-oriented.  Either Python or Ruby.  Python being the clear leader at the moment.  There are a lot of developers that probably would use Python IF the interpreter were part of the platform, but the fact that it isn't drastically limits their distribution opportunities, so they don't.  Python also provides an excellent learning path for developers in universities (they use it at MIT for instance), whereas web runtimes don't - JavaScript isn't much like "real coding".  That said, the last argument doesn't depend on a built-in interpreter - aftermarket install is fine.

Another point is that the future is likely to see a lot of hybrid development, particularly as this will be relatively easy with Qt WebKit and web scripting languages.  As such, the distinction between the runtimes becomes a bit blurred.

2    0

I can't decide if I agree or disagree. I see all those points, but then these other thoughts come rushing into my head...

1. There are a squiillion perl programmers with a bazillion things already written in perl that they will probably want to run on Symbian.
2. There's already a perl runtime with people using it for some of these bazillion things.
3. Same for python, ruby, etc.
4. Different runtimes will have different fan-bases who may be happy to put the work into implementing their favourite language (elisp? :-D ) but who won't be interested in helping with any of our chosen "priority" systems.
5. Isn't there a strong argument that the very philosophy of "choosing to prioritise" in an open-supply community is really an outmoded central-control oriented approach - "spider instead of starfish" - ant it's inconsistent with our new Open approach? Wouldn't all these open-source evangalists say a list like this just shows we still have a "closed corporate mentality"? Would anyone suggest limiting the number of runtimes on other open-source platforms (say, Linux)?

As I say, I can see both sides of the argument, so I'm not sure if these thoughts should be seen as just the "devil's advocate" working in my head, or if we should take them as serious issues. But I'm starting to think it's the latter.  So, for now at least, I think my vote is against it.

1    0

Mark Wilcox - May 21, 2009

I haven't voted either way yet...

I think the key issue is the Tier 1/Tier 2 distinction that Antony makes.

There are the runtimes that are a mandatory part of the platform for compatibility purposes, and then there are the runtimes that are supported.

We can't allow all the runtimes to be a mandatory part of the platform because the firmware will bloat beyond belief!  I think we have to have a policy on this.

You can install Linux without support for Python, Java, Perl etc.

 

Perhaps what we need to do is update the installer (and possibly SIS file format?) so that it can detect what type of application you're trying to install, alert you if the relevant runtime is missing and ask if you want to download and install it?  That way, other runtimes are less like 2nd class citizens.  If we sign and host the latest versions of the relevant runtimes for downloading purposes then we can guarantee that this process will work... much like repositories for Linux distributions.

 

3    0

Reply

I'm enjoying the comments and discussion here.

I think Mark's last comment paraphrases the spirit of this idea very well.

The idea is not intended to exclude anything from the platform - we're an open platform and open source as such should always encourage and enable innovation on top of the platform.

However, a level of pragmatism regarding the the runtimes that are part of the core Symbian distribution is vital to prevent bloat, provide a solid foundation for developers to innovate from and to simplify the support activities of the Symbian foundation.

It sounds like Java has quite a bad name round here, so let's not get hung up on the specific languages choices. Please assess this idea in the spirit of simplification rather than the spirit of alienation. I like Mark's idea of detecting and installing appropriate runtimes at install-time...maybe we need to pull this out as a separate idea....?

0    0

Hi, I have been working in Nokia with Java ME tech and S60 Java for many years for now. Currently I'm doing product management and requirements work for Java in Nokia Symbian Devices org. That's to say I may have bias to Java... ;-)

I guess because of Java runtime things are bread and butter to me I find it rather strange that many people here are talking that Java ME is dead and so on. In technical terms Java ME is not real runtime but a marketing term for various different style implementations (CDC, Blueray java, MIDP, MHP ...). But of course with Java ME you are really talking of MSA (MIDP + selected extra APIs) style Java ME implementations that are available in majority of the mobile phones. I don't mean to be picky but really point this out since the basic phone MIDP+MSA could evolve to something totally different and still we could call it Java ME. In my mind that's also what we are working with in Nokia.

Generally there hasn't been too much new JCP JSR APIs being introduced to these Java Runtimes from different vendors recently. I guess the reason has been that implementation teams have been more focused on performance and functional behavioral aspects of existing API implementations (that's at least what Nokia has been doing mostly) as well as more focused API features for some key use cases like how to fill gaps of mobile device integration of Java apps. In fact that has been in past year the top-most "feature wish" from nearly all commercial mobile java developer houses we have been in touch with: don't add any more JSRs but focus on performance and functionality of existing APIs. On the other hand, JCP is often complained that it's too slow but then there's many interesting JSRs that haven't been even yet implemented. One thing I have felt wrong with JCP is the waterfall style of development where a community does the API spec without real implementation and more importantly without feedback from real app use cases being verified they work with the API or with the implementation(s).

I feel it's pretty much too early to say that "Java ME" is dead. I feel it's really on it's prime time currently as there's nowadays really huge number of applications including a number of excellent ones used by millions of people: Opera Mini, Gmail to name a couple. On the other hand, Java ME could evolve to something more too.

Current Java MIDP based runtime implementations could evolve to something more advanced. Like to one having Android/Dalvik style APIs. For example, the Java Runtime implementation of S60 devices is already now very modular implementation: you can add new API extensions to it (JNI), you can run CDC or CLDC based configurations. If there's will there nothing preventing to implement something more, for example, Java SE or Android like APIs in that. One may change the underlying VM similarly to have register based Dalvik VM. (This is probably a larger refactoring though...). Then if the new runtime would be called "Java" is of totally different story as it's more of the branding thing: does one want to market it as being "Java" or just as a platform that one can program with Java programming language. Symbian foundation could just provide technologies without even branding or claiming anything and then leave users of SF code to decide if they want to still use Java brand.

What I think is Symbian Foundation (or SF based devices) must go forward and not just adopt bare MIDP+JSR APIs. Of course having this kind of implementation is bare minimum for now just to be able to run all those cool existing applications that's out there. And many of the apps are really operator services, various applications for niche markets but there's just sheer amount of them.

I'd like to point also to some earlier posts to this audience of what's actually cooking within Nokia.

We've recently re-implemented the Java Runtime core parts to be more cross-platform and modular, and released that to Nokia Beta Labs. Look what the Register has to say of S60 Java when this release was done: http://www.theregister.co.uk/2009/07/01/nokia_java_runtime/

"Java applications on S60 are largely indistinguishable from native apps, something which is far from true on competing platforms."

We have also talked of our near future plans of how to evolve current Java, it includes e.g. how to use CSS for styling java apps etc. The UI changes in upcoming Symbian releases (Qt+Orbit intro) has called us to start re-implementing the UI layers of Java implementation. Actually we looked for cross-platform UI solutions even earlier than this change was evident. This change has allowed us also to start thinking of what to add and Animations API, styling with CSS and a better 2D Graphics API to utilize 2D HW acceleration has been on our focus list for now.

Couple of our blogs highlight those "themes":
http://blogs.s60.com/category/developing-on-s60/java
http://www.gorkem-ercan.com/

Regarding Android as app runtime, does anyone have some concrete things what makes it good? Some of the Android APIs are so intertwined to the application model of Andoird and they may not work that well on an application model of upcoming Orbit release. What I know is that there's at least highlevel widgets like Maps and so on to integrate to Google services. Similar APIs have been specified for Java in JCP (not yet implemented) but they tend to be much lower level so app developer has to do more in order to make functional user interface. On the other hand in Symbian Foundation one has "system" level APIs in the for of native C++ APIs from old Symbian and in future also in form of Qt style APIs. Android has some system level APIs as Java APIs as java is the only programming language for apps. Some of these things need not to be visible in runtimes if it's not common app to need such access. Runtimes just need an extension mechanism so that app developer needing such access can do it with native APIs but still do majority of the app with the runtime APIs. In Symbian most runtimes have such extension mechanisms including Java (on S60 it has been there from S60 3rd ed fp 2 onward).

The idea of re-architecting SIS/installation to cover on-demand style downloading of dependent components is a good idea. IMO there's some initial level support already in the IAD concept from Nokia (don't know if that's part of SF though). Then again also runtimes need such facilities themselves for inside runtime extensions.

5    0

Mark Wilcox - Aug 19, 2009

Unfortunately I was already aware of all of the things you pointed out (apart from the eSWT on Qt project being open source really soon) when I made my comments above and my opinion is unchanged.

My problem with the current Java Runtime is that it seems to be getting squeezed out between native and Web Runtime.  You can fairly easily produce a better and more dynamic UI in a Web Runtime (eSWT just seems to be catching up with old-style desktop Qt Widgets when we're moving on to Orbit and more dynamic UIs).  With the advent of a Qt WebKit based web runtime with much richer APIs (and easy hybrid programming), what are the reasons for having a Java-based environment:

1) Java is the most popular programming language

2) Cross-platform compatibility with other devices

i.e. It's not really the first choice in terms of technology for any kind of app - you only select it for availability of programmers or portability.

I think (1) is enough on it's own to keep a Java-based language of some kind.  For (2), do you want compatibility with feature phones, or another smartphone platform?

As I see it, the Android APIs make it easier to do a wide range of things - they tend to be higher level.  Access to system APIs without leaving Java is also important - if you're a Java developer you don't learn C++ just so you can add a single feature.  Additionally, if you go for Android compatibility you essentially leverage all of Google's development and marketing efforts in this space.

However, I do concede that integrating an Android runtime with Qt/Orbit well is likely to be very difficult.  As such it may make more sense to stick with and improve what we've already got, but...

>> This change has allowed us also to start thinking of what to add and Animations API, styling with CSS and a better 2D Graphics API to utilize 2D HW acceleration has been on our focus list for now.

How would these new APIs be defined?  Through the JCP, or just Nokia implementations (which are hopefully open sourced).  The problem with this kind of evolution is that we lose one of the primary reasons for choosing Java ME - the cross-platform compatibility (purely cross-Nokia platforms doesn't count!).

 

1    0

Reply

Aleksi Uotila - Aug 20, 2009

Yeah, for backwards compatibility MIDP+MSA based Java is needed. There's so much investment done by different companies for Java based applications on phones, including Symbian based smartphones, that it would be cold cloth on their faces if that would be dropped. But I guess the talk is more about evolution of the tech.

In our mind from Symbian Devices Java team of Nokia (earlier S60 Java Runtime) we think Java needs to evolve so that also the existing applications now done can evolve, as well as new business cases can be realized e.g. by operators and app vendors targeting multiple devices from different vendors (crossing multiple OSes). We are daily in contact with different vendors from all around the world planning for apps and services using Java. They use it because of the install base it has. They say that they can use some new API features that are avaialble in certain devices to optimized the service to a particular device but they do not have business cases to rewrite the entire service e.g. using some native technologies. One aspect is for these companies tell us is that then they can get the same service also to Nokia Series 40 devices which anyway are having stupendous "user base" compared to e.g. Symbian devices.

Regarding open sourcing our tech: We have been preparing for this for some years already. We see that it's no point to have cross platform runtime technologies for which the implementation would be closed. Many of the fragmentation issues of Java ME are actually due to differencing implementations and one could even simplify to different bugs. Because in SW bugs are plenty so different implementations have different of those bugs. And that simply creates at least most annoying differences between implementations. For the core parts re-write I discussed above one of the reasons was to get a code base which we could contribute others with EPL like license. Lately it has been more talk on where this contribution should happen. We are seeking internal acceptance for it. As you found out some parts we've already open sourced earlier: eSWT/Avkon based implementation has been on Eclipse Foundation and we're in process now on getting eSWT/Qt based one there.

Regarding the new features like CSS styling and animations etc. On the core parts those are of course relying on W3C specs but then for the APIs we are participating in the Eclipse Foundation projects where Java based APIs for such things are defined. CSS styling in the widgets doesn't necessarily need any new APIs even. Görkem Ercan is technical contact from our team for those aspects. The implementation is of course partly from Nokia and partly from other companies involved with those projects.

For the more advanced 2D graphics APIs we are looking into OpenVG bindings API which will be available from Eclipse as well as the Advanced Vector Graphics API part of 287. Both are valuable for different application use cases depending on business backgrounds and needs. They are also important APIs when 2D GPUs will be mainstream as with MIDP 2(/3) Graphics APIs one has to code a lot in the app i.e. graphics code gets more executed on CPU side rather than in GPU leaving the graphics HW unused.

So out of these OpenVG is already open sourced with EPL thus Nokia changes to it will be too. Also we have no reason currently to keep 287 implementation closed, let's see. Anyway these are future release items and it takes time for them to really materialize.

2    0

Reply

Mark Wilcox - Aug 20, 2009

Thanks, it's interesting to get the view from the inside.

I talk to a lot of developers too, particularly from smaller companies.  A common question from Java ME developers these days is "Which runtime should I switch to?".  The reasons for switching seem to be:

1) The Java ME fragmentation not getting any better (and in some cases worse).

2) Perception of reduced investment and interest from OEMs in the technology (where was the Java ME content at the Nokia Developer Summit this year? How long has MIDP3 taken to come to market and how late is it?!)

3) Java Verified could have been great but has become an abomination, it makes the current Symbian Signed look exceptionally friendly and developers already complain about that.

4) All of the new platforms coming to market don't support Java ME (Apple iPhone, Palm WebOS, Android - although this last one could have a compatibility layer).

As I hinted at above, if you're going to do cross-platform, it makes more sense to do a feature phone version in Java ME and then as few smart mobile device versions as you can to cover the high-end platforms.  Symbian's a bit different because it reaches further into the mid-range than the other platforms, however since we're looking forward, the percentage of "smartphones" is expected to increase significantly over the next few years, with some estimates suggesting 40% of the market by 2012, and in terms of consumers with money to spend on apps, this will be a much, much higher percentage of the market, so the huge market share of Series 40 gets less and less relevant.

 

1    0

Reply