As Jonathan Schwartz, the famous blogging COO of Sun Microsystems, steps up to take over the big job from Scott McNealy, it’s a good time to ponder where “Java Platform, Micro Edition” as we must now call it, or J2ME as it used to be known, is actually going.
The concept of a platform like J2ME (sorry, the new name is just SO cumbersome) is that a developer can produce one application and then port it across many different handsets with ease. But anyone who has ever done any J2ME development knows that, in practice, this is simply not the case and the vision falls far short of reality by a very long way indeed.
In non-technical terms, developing in J2ME is like trying to change a bicycle tyre for the first time. Firstly, it’s difficult enough in its own right. But when you do manage to get the inner tube inside the tyre, you have to work it in all the way round. And when you get back to the beginning, it’s popped out somewhere else, so you have to start all over again.
20% of the time and effort in developing a J2ME app goes into the first iteration of the code. And 80% of the work goes into porting it across all the handsets that you want it to run on. This can be a cripplingly expensive, not to say, time-consuming process.
I was chatting to Mark Curtis of Flirtomatic (great service, if you haven’t checked it out) and he launched the product in J2ME only to abandon it within a few weeks. In Mark’s case, it was partly as the WAP version proved to be better than expected and proved to be very popular with users. But partly as Java isn’t suitable for rapid application development.
If you launch a mobile application or service, you need the ability to make changes all the time as you work out how customers are using it and as you learn more about the product. Changing a WAP site is pretty simple. Changing a J2ME application is easy too, but then you have to roll those changes across all the different handsets and test them. This means the pace of change and innovation crawls to a snail like pace. Or maybe that’s unfair to snails.
Whichever way you look at things, when a high profile product like Flirtomatic, led by a tech veteran and thought leader like Mark abandons a development platform altogether, it’s not good news.
So who is to blame? If only it was that simple. I spoke to Tom Hume of Future Platforms and J2ME and all-things-mobile guru and while Sun could definitely do a better job, the main issue is the widely differing specs among handsets. As Tom says:
But I don’t see how we can persuade a disparate group of handset vendors to make their phones the same - these guys have to differentiate themselves from each other.
So where does this leave J2ME and Jonathan Schwartz, as he ponders Sun’s future? Well, apart from coming up with a better name, the future doesn’t look encouraging. J2ME can do lots of things that the mobile web can’t do - yet. But, I bet in many cases, those extra features are nice-to-have and not truly essential.
I think we’ll see more and more products and applications which should, by rights, go the J2ME route but seek work-arounds if they possibly can, by going for a WAP solution. Ironically, this is the very outcome predicted by none other than Sun’s Scott McNealy himself with his “the network is the computer”. Java is old-school rich client, WAP is the network.
However, McNealy, visionary though he undoubtedly is, didn’t go quite far enough. Actually, the network is the mobile, which doesn’t leave Sun in a great place if their main mobile product simply doesn’t deliver.
We’ve seen time and again in technology that “good enough” often beats “perfect” and I’m afraid that we might be about to see this happen all over again.
[tags]java, j2me, schwartz, mcnealy, sun microsystems, curtis, future platforms, flirtomatic[/tags]
—–>Follow us on Twitter too: @russellbuckley and @caaarlo
Russell,
Great post. Best I’ve seen to date on the whole J2ME saga. Everyone thinks J2ME is going to be a silver bullet. Write once – run everywhere (after you’ve debugged on everything).
Here’s an idea (Ignore the security implications for a moment, they can be contained). Java on the mobile device will never be the same as Java on the desktop. You’re never going to shoehorn a 150MB app into a mobile phone.
What’s common to every mobile phone is an operating system. So why not build “Target operating system aware mobile executables”… these exec-lets would be delivered in real time using HTTP (via a web server)… of course they’d need an ultra thin client to execute (where the security comes in) but the real benefit is that you get the richness of the OS to play with rather than Java.
Developers can do what they do best, build applications for a mobile OS… compile them, test them and then simply have them download in real time. You don’t need Java to do this. You have a perfectly good operating system you can leverage.
This of course facilitates on demand mobile applications which I think are going to be the future. Why? Because space is at a premium on this device. I should be able to buy one (or rent one), connect to the Internet and simply download whatever applications I need on the fly. Once done I can discard what I don’t need to free up precious resources.
All the best
Peter
Nobody thinks it’s the silver bullet but it’s the best bullet to use at this time of writing, and believe me, I’m developp
ing apps for the mobile space since quite a while and I use web, wap, J2ME and C .
The problem of J2ME is not J2ME, it is the buggy fragmentation of the different J2ME implementations, and you’ll have the same problems, when you write for the also buggied and fragmented mobile browser market.
So it isn’t SUN, it is Nokia, Siemens, Samsung, Sony or whoever implements J2ME on the device.
I can tell you a lot about the many differences in the VMs.
But I’ve written a banking and a IM application that’s tested on nearly 160 devices now, and it’s only one code and it much more used than our similiar mobile web solution.
The user can choose and he decides for J2ME…
There are many reqirements I would solve with web/wap, but the rest of the reqirements J2ME is the best way today…
Olli
Peter,
Sorry, you can’t forget the security in the the context of J2ME.
and that’s the reason why I often choose J2ME…
That’s why J2ME was made
That’s one advantage and an important one - over wap/web…
And what you are looking for is MIDP 3.0 or CDC or a kind of webstart…I’m looking for, too.
Olli
Thanks for the comments, but I didn’t say it was Sun’s fault. I quote:
“…while Sun could definitely do a better job, the main issue is the widely differing specs among handsets.”
So I guess we are in agreement.
Russell
Still not happy MobHappy?
The network is not the mobile, but mobile is part of the network.
The problem is not Java ME, but vendors going their way with their particular behaviors. And security doesn’t help developers much - vendors restrict access to APIs and resources, and security issues or restrictions will exist no matter the runtime (browser, Java, etc). Tom is right there always will be differences and proprietary APIs, but the core APIs will (should) become more stable. Obviously, once you use a proprietary API the code won’t be portable any more - that is a business decision developers must make, as anything else.
A lot of work, by many companies and individuals (the Java community) is being done as we speak - enhancing MIDP, and APIs, and enforcing consistency across handset implementations.
Java ME is not perfect, yes it can be difficult to go across vendors, and I know because I go thru this too when I develop code, but it doesn’t impede development and deployments. It makes it harder and a pain in the neck, but knowing what is coming, I know things will get better. Browser development is not perfect either, or native… It will get better with MSA and MIDP3, etc. Let’s talk again about this in 1 year and see if I was right or wrong. But going across vendors with Java is much better that Peter’s go to the OS directly approach - I guarantee it! If you only care for one platform, go native. You ignore Java and write native apps today…
All this frustration really doesn’t matter except for venting. Want a silver bullet? Let’s define “silver bullet” as how to maximize the reach to people with handsets, and the answer is: Java ME, markups, SMS/MMS… and all three are complimentary - based on the app requirements. Write the app in markup first if that is sufficient for your needs. Use Java ME (or native) if you need advanced functionality. Use SMS/MMS for offline communication and notifications. That’s it! Those are your silver bullets.
C. Enrique Ortiz
To be fair Russ - if you’re doing WAP sites, you’re not excused from the need to test them. Bugs exist in WAP and XHTML implementations on certain handsets, just as they do for J2ME. You’re right to say that working around these bugs is quicker; though as I said when we spoke, at FP we have the development cycle for new puzzle games down to a single month (including interface design and a few iterations of changes/approval, developing a reference version, porting and testing). It’s reasonable to point out that Flirtomatic is a significantly more full-featured and complex application (and does a lot under the hood which isn’t apparent to users of the service).
But there are some things which you just *can’t* do in WAP/XHTML: games, say. Or a decent electronic programme guide. For these, Java is simply your only option, if you want to launch a real service to a decent number of people *today*.
For what it’s worth, here at FP Towers we’re actually quite agnostic about individual technologies: we do SMS, MMS, WAP, XHTML, J2ME, Flash, and probably a few other disgusting things the folks here wisely keep hidden from me
So I’m not a Java cheerleader (in fact I’ve argued vehemently against doing Java portals in the past). All these, and others, have their place.
Tom - I’m not suggesting for a minute that you don’t have to test WAP
What I am saying is that if you have an idea for a product or service and it’s possible to do a basic version over WAP or an all singing and dancing version in Java, I think right now, I’d go for the stripped down WAP iteration.
Once you’d run it live for a few months and you could write a very definitive functional spec based on experience, I’d possibly move to Java at that point. But it still wouldn’t be an automatic decision.
If you have to use Java though, you got no choice…
Russell
I believe I’m throwing a bit of gasoline on the fire here, but that’s what comments are for. I’m as frustrated by the device differences as anybody else, but there are shades in hell too. All personal opinions of course.
I think we should be careful not falling into the “If it’s not perfect it’s useless” trap. All seasoned Java ME developers know it’s not WORA, so let’s get on with it. “Adopt, Adapt and Improve”, as John Cleese once said.
The KVM provider and phone brand specific differences between phones and hence the need for testing on “all” (at least very many) phones, is the biggest issue with Java ME in my opinion (more so than the overall feature differentiation/evolution specified by Sun which is a necessity; everything evolves), but it’s not a show-stopper. There are companies that specialize in such testing, by simply having most commercial handsets in their labs. In many cases such testing, especially on simple corporate client/server applications, can easily cost more than the implementation, or at least take the most time. Solutions like J2ME Polish and similar can help, provided they are used from day one.
Java ME and WAP (or HTML) are often not alternatives, as WAP has no access to local phone functionality. There’s a lot of services you can’t do without that. Maybe Flirtomatic doesn’t need it, as I guess personal photos could be sent in via MMS equally well, etc.
Especially when we start talking games (2D, isometric or whatever) it becomes apparent WAP doesn’t even come close to the interaction and functionality that’s possible via Java. I could even say WAP won’t cut it at all.
Let’s take a more pro example: You want to show a stock chart that you can scroll and scale without latency. Is WAP or even HTML suited for that? No. Is Java ME suited for that? Yes indeed, and you don’t even need any newer phone for it to work. Already MIDP 1.0 supports simple but useful vector graphics. Flash could do this, but it doesn’t exist in enough phones.
I would argue that Java ME is actually good for RAD, with a big but: Writing a client/server form-type Java ME application is incredibly easy and quick, as long as you only test it on one specific phone model initially (e.g. my Mobile Blogger only took 8 hours from waking up in the morning with the idea and to publish the first version on GetJar; it certainly doesn’t support all phones, but that wasn’t the intention as it’s free). That’s RAD to me! If we talk public “for everyone to use” services the phone differences need to be understood and handled before the service is launched. I believe many still make that mistake (I did it with another (and commercial) application that I won’t mention).
“The network is the computer” is very much about downloaded local applications (where Java was supposed to be used), so Java ME fits that description well in theory, provided it had been the same Java base implementation on all terminal devices.
The fragmentation _IS_ actually to a large extent Sun’s fault, as Sun handed out the rights to others to make KVMs and base class libraries, which resulted in a plethora of differently behaving (and also in cases quite buggy) and differently featured implementations, instead of one “if it’s a bug it’s a documented feature” single reference and implementation at the same time. They didn’t make that mistake with J2SE and J2EE, so why with Java ME?
Another drawback with Java ME, as opposed to J2SE and J2EE is that upgrading the KVM and class libraries can’t easily be done on featurephones (which is what the majoity of people use). Typically you need to upgrade the complete phone software, which pretty much nobody does. That means from a developer point-of-view that possible bugs and other oddities stay the life-time of the specific phone model. If the phone runs BREW you can in cases easily upgrade the KVM (the KVM runs on top of BREW), but BREW is much less used in phones than Java ME, so the issue is still there.
I guess I’m getting into “Messerschmitt” mode now, but J2ME is the abbreviation of “Java 2 Platform, Micro Edition”, which is even longer. I think “Java ME” as new abbreviation (no more “2″) is better from a branding perspective.
[...] The Frustrations of Java at MobHappy If you launch a mobile application or service, you need the ability to make changes all the time as you work out how customers are using it and as you learn more about the product. (tags: mobile j2me java) [...]
I think the example of Flirtomatic is perfect.
I downloaded the j2me client and, because I couldn’t believe how large it was, I had a quick look inside the jar to see how it had been written. And it had clearly beeen written by someone who was a J2SE programmer and had never written J2ME before, because it was a heavily OOP design with dozens and dozens of classes that no-one who has had J2ME experience would create - and it explains why it only ran on high-end handsets.
It was also LCDUI-based and so provided almost none of the usability benefits over wap that a well-written Canvas-based Midlet could provide: the LCDUI components give you practically as little control as wap even when you use the CustomItem.
Mobiles are small devices, and you can’t jump in and code for them as you would for a desktop with 1Gb memory and a 60Gb hard drive. You have to adopt a different coding style, and whilst J2ME is not perfect it certainly makes this possible. People who don’t spend 20% of the time coding and 80% porting - people who do spend at least 80% of a lot less time coding and 20% of the time porting.
There are cross-handset bugs in every technology related to mobile - Wap, Bluetooth, J2ME. J2ME is the most ambitious of these and so it has the most issues. This is highly frustrating for people who have just started and does generate a longer learning curve than most java programmers anticipate, but there are plenty of specialists out there who have mastered it and companies considering offering a mobile product which is suited to Java - and I agree with Tom Hume above that many projects aren’t suited to Java - should select their developer very carefully, and seriously seriously think hard before deciding to dive in and develop in-house.
Totally agreed, J2ME is not, in and of itself, a solution. Just walk into a typical mobile games company, where the QA team is twice the size of the engineering team because they have to test all the permutations of handsets.
BUT - I’m not sure it’s fair to lay the blame all at the handsets feet — after all we see the same problem with Netscape, Firefox, Safari, and IE. The only difference is that thanks to the Microsoft monopoly there are fewer choices of browsers and OSs than there are in the mobile world.
I think this is just the nature of the world, it’s just near impossible to write a low-level cross platform RAD interface as long as you rely on the handset provider to implement… what is actually needed is a subsystem to J2ME, a RAD development platform FOR J2ME. Something that interprets the handset and makes changes as necessary.
I’ve been searching hard for a start-up working on this… the closest I can find (although they are stealthy about it) is Everypoint. Their press release with Yahoo the other week talked about RAD, and their Technology page talks about single executable for all handsets.
Anyone know anything more about how they do this? I think this is really the key.
JM
The problem isn’t only with J2ME there are many other things…..Fragmentation is inherent to mobile device Application development. Sure with respect to web based apps Wap would be the ideal solution. Your implication that J2ME is a failure because WAP is better than J2ME at doing WAP things is wrong!
That is like me saying that WAP sucks and is a failure because it I can’t implement Prince of Persia mobile on it. Flirtomatic is a prime application for a serve based approach with a web client interface, but prince of Persia will never be as good as it can be if it is run on the local machine. If this was not the case then we would see next generation game consoles transmit there input via a network to some ultra powerful game-server to run. All physics, collision and rendering would be done remotely. I can see advantage of doing some computation on the server, and it makes sense for network game and persistent worlds. There will always be a place for rich clients.
I could go into the issues with J2ME/Brew/Symbian/etc…but I’m not going to. WAP is not a solution to the limitations of these environments. WAP is better than developing a rich client than any of these. But using this to fuel your argument that J2ME sucks is flawed, there is a case for development in these environments (here’s an example outside of games: Say i had some mp3s on my MMC memory card that i just plugged into my phone. Would i transmit these mp3 to the server to decode and then play it throw my browser? or would i have an application written in J2ME/Brew…or whatever to decode and play it locally??) You use the right tools for the job; I would use a WAP/(plus what ever server backbone) to implement Flirtomatic, but i wouldn’t use it to implement Prince of Persia. Why would i try to screw in a screw with wrench?
I’m also curious as to why are you targeting J2ME specifically. The issues you mentioned concerns all client side applications.
I also disagree with your point that J2ME is not suited for Rapid application development. Java is ok, but not the best for rapid application development. Compared to native development i find it much quicker. I was able to prototype a relatively complex 2d game in a week.
Wap will not take over the world…sorry to point this out dude…but there will always be a place for client side application.
Helios
http://quicklybored.com/
Regarding James’ point about “what is actually needed is a subsystem to J2ME, a RAD development platform FOR J2ME. Something that interprets the handset and makes changes as necessary. I’ve been searching hard for a start-up working on this… the closest I can find (although they are stealthy about it) is Everypoint.”
Have you checked out J2ME Polish? They also have a database of most released handsets and what Java support they have. J2ME Polish is UI focused, so it doesn’t handle other phone differences. And it’s free (for some reason).
Abiro (actually I) has been working on a Java ME communication framework for some time. This is probably not what you mean, but I’ll mention it anyway :). It’s nothing fancy, it’s just a number of classes hiding SMS, MMS, HTTP and similar accesses, so applications can focus on the information transaction. Potentially it could also compensate for phone differences and bugs, but that’s back to the comment about having a huge QA department. I don’t at the moment.
When testing an application using SMS on many phones I discovered that a simple thing like SMS Push in cases didn’t work at all, even though it’s mandated by specifications. Hence it’s not just about compensating for “flavors”, but outright bugs.
If Sun had been the only provider of Java ME KVMs that would also lessen the extensive testing now done on such KVMs. A testing that anyway doesn’t catch all serious bugs.
Russ: I think we’re in complete agreement. If you can do it in Java or WAP, and Java adds nothing over WAP, do it in WAP.
But… if WAP ain’t good enough, and you want a decent audience for your app, Java is your best option.
bob: my company developed the J2ME MIDlet, and it’s a mix of LCDUI and low-level APIs. LCDUI let us use standard components quickly, the low-level stuff gave us the control we needed to implement the Flirtomatic UI (which is one of the strengths of the service). Happy to debate this with you, perhaps by email unless you think it’s of interest to readers
Bob raised an interesting point about the number of classes in Flirtomatic, and pointed out that it is a typical J2SE programmer error.
Well, Tom and his team are very experienced, and from the grapevine, have a great reputation. I think there are places for both design/programming styles – well structured or highly optimized. Well structured programs are inherently larger. However the programmer productivity will be higher, more importantly it is much easier to maintain and to adapt a well structured program to future needs/requirements. It really depends on the requirements, and the context. Mobile games have a limited shelf life and require little maintenance and need to push the handset capability, obviously gravitate towards the highly optimized, as-few classes-as-possible style of design. However even in the mobile game space for productivity reasons there is a general trend in the major studios to start adopting a reusable architecture which comes with more classes. On the other hand in the mobile application space maintainability and extensibility are typically very highly regarded attributes.
There is a third way, it is possible to structure the program nicely for maintainability and extensibility, and then refactor automatically without modifying the source code to get rid of the baggage of OO design. Proguard 3.x merges an interface with the implementing class if there is only one implementing class. [Shameless plug begin] Our product mBooster performs all sorts of class merging and other optimizations. On many applications the number of classes can be reduced by 50%. [Shameless plug end] With an automated optimization tool you get the best of the two worlds: maintainability/extensibility and small size.
Stephen
I’m not that knowledgeable in this area so this has been a very informative thread. My overiding impression was that the big issue was incompatible implementations / problems with different hardware specifications meaning that the write once idea doesn’t exist. On top of that differential implementations of JSRs just add to the problem. I’m actually of the opinion that JME works best of mobile platforms of one sort or another. A good example of this is UIQ 3 where the rich Java implementation (JSRs etc.) mean it quite powerful. That and the fact it is standardised across the platform (only 3 phones at the moment, but that may grow). The Java development tools for UIQ are probably better than te native ones (especially for RAD). S60 i somehwat similar in that you’ve got a big range of phone that are standardised against a platform (although even here it’s not perfect). I think there’s a lot to be said for mobile platforms based phones with JME in the future. Of course that doesn’t solve the problem now…
Hi all,
I’m in charge of handsets design and development in a European mobile operator which operates i-mode service (1.5 Millions i-mode subscribers for now)
As you may know i-mode uses a different flavor of Java which is call DoJa. We have now an experience as operator for 3 years with DoJa, and we reached to get 400 different contents on our official i-mode portal, and much more in the independant world. All those contents are running on all the i-mode phones we have launched. This is a huge difference with MIDP, where operators have to indicate to their customers which content runs on which phone.
Now we do understand much more why DoJa is far superior to MIDP : software porting from one DoJa phone to another DoJa phone is an average 5 times less work compare to the same task for MIDP. There are two main reasons to this difference :
1) NTT Docomo’s specification for DoJa, given to handsets vendors, is much more precise in terms of behavior for each described API. There is no optional features as we can find everywhere in MIDP specs. One good example is application size limit that doesn’t exist in MIDP. (DoJa 1.5 is functionnally slight superior to MIDP 1.0. Doja 2.5 is functionnaly equivalent to MIDP2.0 MMAPI Messaging API)
2) Docomo ensure itself DoJa conformance for each new handsets. Those conformance tests are extremely complete : more than 8000 tests cases for DoJa 1.5 and 14000 for DoJa 2.5. This take 3 weeks to be done before handset being approved by Docomo. Including is also a performance benchmark, and we now that it is also often difficult to port software when there are huge performance gaps between phones.
Yes the effort required by handsets vendors is higher, but the benefit for content developer is huge : each API is guaranteed to have one well defined behavior. Adapting and porting then is mostly reduced to screen size differences.
With this feedback, we can deduce why MIDP is an hassle for content developers : Sun should have put much stricter certification procedure, and should have asked to specification guys not only to write programmers documentation, but detailed handset implementation documentation and get rid of all optional features.
Regards,
Rafe, your optimism is great to see, but while developing an app only for 3 UIQ phones or only S60 phones helps you develop applications quickly, it also means unless you can get a distribution deal with a handset manufacturer your app is never going to make money. No PC software vendor would ever dream of trying to break even on a Windows app that only runs on three models of desktop from one manufacturer.
The problem with developing an app specifically for a handset deal is you inevitably end up designing with the wealthy patron in mind, not the actual consumer - hence all the lame apps that showcase some whacky here-today-gone-tomorrow feature in a particular series of handset. When that handset is off retailer’s shelves, there goes your app too.
While I will not claim that Java ME does not have its problems, I think the 20/80 statement is really inaccurate if you’re using an appropriate programming paradigm and tools. Your application’s business logic doesn’t need to change from one device to the next, and that should be where most of your work and innovation is taking place.
Solutions that rely on preprocessing (such as NetBeans Mobility Pack: http://www.netbeans.org/kb/50/preprocessor-syntax.html) also simplify the code porting and management issues by letting one source serve all of the different target devices and only if/then-ing on the portions of code that really require it.
While using the latest and greatest APIs is very cool and leads to compelling apps, you can’t reasonably expect all of the devices out there to support those features. So, you can either comment those out or just target your app at a smaller selection of the devices on the market.
Fragmentation in mobiles has nothing to do with technology most of the time, it has to do with marketing devices to different consumer niches. An OEM such as Nokia doesn’t come out with 20-some devices per year because they have nothing better to do - they identify different segment requirements (or operators define them for them) and produce devices that appeal to consumers. Regardless of what application technology you are using (native, Java, browser, Flash), those physical and sw differences will have an impact. While browsers may have the smallest deltas, there are plenty of differences between them as well, especially in the mobile context.
Ultimately, it’s about taking a “lowest-common-denomitator” approach and then optimizing on the aspects and devices that matter most. That will be the case regardlesss of what language, platform or runtime is in question.
I like Peter’s idea because it’s not 100% theoretical, but has aspects of practical reality. It seesm to be the best interim solution to a very difficult issue insofar as J2ME is concerned. I’d like to see a few proposals of how this can be done…the J2ME execlet framework, I mean.
best regards,
Charlie
[...] Last week I wrote a somewhat controversial post about developing Java applications for mobile. Some people seemed to think that I was dissing Java per se, which isn’t the case at all - sometimes only Java cuts the mustard and here’s a nice example. [...]
I agree with Matt. Fragmentation in mobiles has not much to do with the underlying technology in general. While admittedly Java ME is not perfect, similar issues exist in other environments such as BREW and WAP. Unlike desktop PCs, mobile phones are personalized devices. For all the good reasons, there is a need for handset manufacturers to segment the market with different screen sizes, performance, memory, sound systems, form factors, keypad layouts etc. etc. All these contribute to fragmentation of the runtime environment. On top of that, there are also operator specific APIs (e.g. Sprint’s Game Lobby) and network related issues (e.g. certain ports are blocked on some networks – developers who had deployed network apps for multiple operators must have experienced this). All these make mobile application development a dramatically different exercise than in other environments. We should accept the fact that adaptation and optimization is a necessary step in mobile application development. It is very similar to console game development – publishers and developers have long accepted the fact that making sure the game will work on different platforms (PS, Xbox and Nintendo) is part of the cost of doing business. The difference here is that the number of mobile platforms to deal with is dramatically larger while the delta between the platforms is smaller (compare to the relative difference between PS and Xbox) but fundamentally the challenges are quite similar.
It is important for me point out that these new challenges require new techniques/technologies/solution to combat. For example, while using pre-processor can help maintain a single code base, it usually makes the source code unreadable and not maintainable if the number of devices is more than a handful. Also, it might not be very scalable as more people are added to the team. Using more modern techniques such as Aspect Oriented Programming (AOP) can help to speed up the overall development process and make it much less painful. AOP helps modularizing and reusing code snippet for device/operator specific issues or other optimizations without reverting to the lowest common denominator approach. There are many other mobile domain specific software/solutions in market to help tackle the mobile deployment challenges.
Ultimately it all comes down to finding the right solution to the problems. With the right solution, these problems are not insurmountable.
Allen
[...] There are other companies working on solutions to do much the same thing; what’s cool about SoonR is that it does this all through a browser, opening it up to so many more devices than those relying on standalone applications (nicely illustrating one of Russell’s points about Java). SoonR’s also got some other interesting plans for its business model, adding premium services (like the ability to have your data persist on its services so you can access it when your PC’s offline), as well as licensing their service to operators, both mobile and wired broadband. [...]
[...] A few months ago I wrote a piece about The Frustrations of Java, which you left a lot of comments about. My post was a rant about what a bitch Java Platform, Micro Edition (or J2ME as it used to be called) is to develop for, with a huge amount of work going into porting the application, once you’ve finished the initial build. In fact, I’d suggest that 20% of the work goes into the initial iteration of the code and 80% into the porting, which can be a shock for the uninitiated. [...]
[...] Recently there has been a lot of noise on the mobile net about the inadequacies of Java as a development platform on handhelds. Russell, has a really great set of posts on precisely this subject and you should be reading MobHappy online to get sync’ed in on the debate. [...]