Summary
A billion Java-enabled devices in use, and the many more non-PC devices through which billions of people will experience the Internet, represent a potentially big opportunity for developers. Yet, relatively few developers work on Java ME applications today. What makes it hard to develop for mobile Java devices?
Advertisement
At this year's JavaOne conference, I was invited by Sun's JCP program office to moderate a panel discussion on the future of Java ME. While by no means an ME expert, I always had great interest in Java on devices. As Sun CEO Jonathan Schwartz pointed out in his JavaOne keynote, non-PC devices are the mechanism most people around the world would use to connect to the Internet. Indeed, we at Artima hope to one day reach our readers on cell phones, PDAs, and other devices.
And Java ME means much more than phones and PDAs. When I first got interested in Jini some years ago, it was primarily because of the great promise of billions of connected devices, some as tiny as mobile sensors and RFID tags, all either running Java or proxied by Java objects—a notion very much at the heart of early Jini excitement.
As I was fielding questions and moderating the panelists' replies, I could not help but feel the tiny push in my pocket from my own cell phone, reminding me that while the JVM on my cell phone is perhaps the VM I spend the most time with in terms of physical proximity, I never managed to develop any sense of intimacy with that VM—certainly nothing close to the relationship I have with the JVM on my laptop, for example. Although I chose this phone partly because it came with a JVM, developing a useful application for it seemed hard. And the prospect of distributing that application so that anyone with a Java-enabled phone could download and use it, loomed like a Byzantine path not be explored by the uninitiated.
In his 2006 JavaOne keynote, Jonathan Schwartz suggested that the over one billion Java-enabled mobile devices represented opportunities to developers orders of magnitude bigger than desktop and enterprise Java did. That may well be so. But the cell phone in my pocket still has the same number of Java applications it had when I purchased the phone. And that's not because of my lack of interest in mobile Java. If that phone represents a developer's opportunity, no one has taken advantage of that opportunity yet.
In a 1986 speech at Bell Labs, You and Your Research, Richard Hamming noted that it is helpful to ask three basic questions to guide one's career: What is the most important problem in your field today? What have you been working on lately? If the two are not the same, why?
Paraphrasing Hamming's admonition, mobile Java seems like the biggest opportunity for Java developers today, yet my sense is that relatively few developers work on Java ME applications compared to the number of developers working on enterprise and even desktop Java applications.
In this blog post, I'd like to ask, why. From your perspective, what are the main challenges in developing for mobile Java devices today? What are your Java ME pain points, really?
The main painpoint for Java ME is that it isn't "write once, run anywhere". Even apart from the different MIDP and CLDC versions, there are many differences in the various devices that support Java ME. Screen size and colors, maximum application size, available memory, etc. are all different. In addition not all phones support all features correctly or completely. This makes it very difficult to create an interesting application (e.g. with some graphics, for a wide range of devices. You either have to develop for the lowest common denominator, or create different versions for different (groups of) devices. This is either very constraining, or very costly.
A second painpoint is that the Java ME libraries are mostly low level. It is easy to understand the reason behind this, but it makes development more difficult and expensive for relatively common tasks such as storing data on the device, sending/receiving data over the air or displaying data.
If combine the developer painpoints with those of the user/customer, it's no wonder the number of Java ME applications is small and mostly games.
I agree with J. Heijmans that the lack of 'wo,re' is what's keeping JME back. I'm currently in the middle of writing a JME application that should run on the top twenty phones in Europe, and I can tell you it is hell. It's like developing for 20 completely different operating systems. The issues:
- Phones differ in the number of optional api's they support. - The MIDP spec leaves room for interpretation, leading to slightly different JME implementations. JME implementations differ between brands, models, firmwares, etc. - There is no phone that has no bugs. - Testing must be done in REAL devices, not emulators. But who can afford 20 high-end phones (let alone 350)?
Combine this with the thousands of models and you get a combinatorial explosion of variations.
Some tools, like J2ME Polish help developers in circumventing all these issues, but they make programming a lot less fun. And if it's not fun, not many developers will be persuaded to programm against the platform. Who wants to write an application that will only run on one model phone (and only one specific firmware)?
Compared with the Windows Mobile 5 version of the application I had to build as well, the java version requires orders of magnitude more effort. The fact that there is a lot less variation in WM devices makes it a breeze to develop.
I must say that the most fun for me is programming in Python for Nokia Series 60 phones. Although it is unfortunately only for a small set of phones, your code just always runs. Combine that with the joy of programming Python and you understand why that is so much fun.
I don't think the biggest barrier to ME development is technical, although the technical barriers are real.
The "walled garden" networks of the mobile phone carriers are a huge problem for entrepreneurial developers who would deploy custom cell phone apps. Each network offers different services, and each offers their own barriers to getting new stuff onto the phones in the field.
The networks are a little fragile, it seems, both technically and economically, and the carriers don't want to give up control.
I did a lot of ME development about 4 or 5 years ago. I agree with all that has been written regarding pain points and barriers. What I find stunning is that it hasn't changed.
> I did a lot of ME development about 4 or 5 years ago. I > agree with all that has been written regarding pain points > and barriers. What I find stunning is that it hasn't > changed.
It seems pretty ironic that devices were the original target for Java but now that devices are actually becoming a major market, Java ME is stagnant and neglected.
> It seems pretty ironic that devices were the original > target for Java but now that devices are actually becoming > a major market, Java ME is stagnant and neglected.
Indeed. In fact it appears very much like the powers that control Java are only able to concentrate on trying to catch up with one thing at a time. And catching up seems to be the primary motivator for changes to get into the language. One year generics get shoe-horned in, another year EJBs are cleared up a bit, maybe this year Swing will be tweaked, maybe next year it's media capabilities will receive some attention.
It seems to be all reactive tweaking with little or no real overall strategy or ambition.
> Indeed. In fact it appears very much like the powers that > control Java are only able to concentrate on trying to > catch up with one thing at a time.
But most of the problems that afflict the use of Java ME seem to beyond the reach of those powers (Sun etc).
> > Indeed. In fact it appears very much like the powers > that > > control Java are only able to concentrate on trying to > > catch up with one thing at a time. > > But most of the problems that afflict the use of Java ME > seem to beyond the reach of those powers (Sun etc). > > They don't make phones or run mobile networks.
Yes, but on the otherside, I don't think that SW should rule the world - look at those big companies spreading only their own platforms on top of specific HW. I agree on the point that if somebody commited himself to implement some standard, he should fulfill it at his best. And that's not often the case. The attiude is "just to have it". Sun has made a big effort to a big commitment and support thousands of devices is not easy for anybody. The biggest painpoint for Java ME developer is to make the build scripts for tens of phones. That's a great success.
You guys need to stop complaining and start coding. If you actually look at the Java ME MIDP apps being offered you'll find an ecosystem that's probably much larger than the Java desktop one. You've got 3d games that are actually being used in large numbers, Java browsers that are top of the class and ubiquitous, mail apps, social networking apps, utility apps (e.g. FTP, remote desktop), widget portals, etc, etc, etc. By comparison, the Java desktop ecosystem is woefully poor and under-represented. Stop crying.
My personal peeve is the fact that most carriers cripple handsets; unless I pay money to buy an unbranded handset, or even more money for a certificate, I cant access the network.
One of the conclusions of the JCP panel was that there are two types of fragmentation in the ME market place currently:
The first type is the result of manufacturers implementing varying sets of ME APIs in handsets. Hence, developers couldn't count on a consistent platform across handsets. This is being addressed by JSRs 248 and 249, aka Mobile Services Architecture (MSA). These JSRs define a broad base platform that includes the most important ME standards needed to write interesting mobile apps (location API, SVG, etc). MSA-based phones will become available later this year.
The second type of fragmentation is due to different handsets serving different consumer needs. In addition, ME is used in devices other than handsets. That type of fragmentation is a natural consequence of the market place, and won't go away.
The biggest issue that many in the audience brought up was that carriers, especially in the US, greatly limit the usefulness of features in handsets, and also limit how developers can distribute applications to handsets. In the SE and EE worlds, you just publish a WAR file on a server, or a JNLP file, and anyone with an Internet connection can use, or download, your app. In the ME world, you can't just upload a MIDP file to a Web server and hope that people will find and download that file to their handsets.
While carriers obviously want to remain the gatekeepers for what goes onto their subscribers' phones, there are also good technical reasons why they don't want people to just download anything users find onto handsets. One of them is security. Even though MIDP provides a sandbox environment for applications on the handset, security and support issues could arise if users were downloading apps to handsets in a manner similar to how people download applications to their desktops. I'm not sure how valid an argument that is, but it's something to consider (there are a lot fewer phone-based viruses than there are Windows viruses, for instance).
Some people informally expressed hope (after the panel, in private conversation) that Apple's iPhone will change a lot of that. The perception (Apple hasn't announced this yet) is that users will buy software for the iPhone through iTunes, Apple effectively bypassing the carrier (ATT), and becoming a direct conduit between developers and users.
The result may be that, in a few years, iPhone users will have all the nice apps, at which users of other phones (and carriers) will look at with envy. This may force other carriers to similarly provide easier access to their subscribers' phones.
"is that users will buy software for the iPhone through iTunes, Apple effectively bypassing the carrier (ATT), and becoming a direct conduit between developers and users. "
Well, actually, what you have is Apple being the company in between the developer and the consumer.
"In the SE and EE worlds, you just publish a WAR file on a server, or a JNLP file, and anyone with an Internet connection can use, or download, your app. In the ME world, you can't just upload a MIDP file to a Web server and hope that people will find and download that file to their handsets."
Actually, it's almost the same. What's to stop you from telling people on your website to use their mobile browser to go to your JAD file and download it?
Flat View: This topic has 41 replies
on 3 pages
[
123
|
»
]
Previous Topic
