The Beginning Of The End Of Cross Platform Software

With the spread of software walled gardens for smart phones, tablets and now general purpose computers, it is rapidly getting harder to write cross platform software.

Currently, it is possible for an software developer to code an application using any cross platform tool like Gtk, Qt, or Java on Linux and have users download the application and run it on Windows, Mac and Linux. That's going to get harder and harder to do.

For one, in Windows 8, you will only be able to install Metro apps from the Windows Store. You can download "legacy" applications for now, but most users will probably never go beyond the Windows Store. And on ARM, you will only be able to run Metro apps.

And now Mac OS X Mountain Lion's Gatekeeper joins in on the action by preventing the user from installing an application downloaded from the Internet. The Mac OS App Store also does not allow applications to be dependent on third party libraries like the Java runtime. A workaround would be to bundle the JRE with your application, increasing the size of your application. No idea if that would work in practise, and for how long.

Linux will always be free of course. But if only Linux users can use your software, you will be locked out from the bigger Windows and Mac software markets.

So instead of Write Once Run Everywhere, we are moving back to Write Once Port Everywhere. Back to a time when applications mostly existed on only one platform as only the biggest software vendors could afford to port their applications to multiple platforms.

Besides killing cross platform software, there are other consequences of these walled gardens:

* Software developers will lose the freedom to develop any kind of software, using any kind of technology they want. They will only be able to provide software that is approved by the "gatekeepers".

* Software developers will not be able to distribute their applications without paying the "gatekeepers" a yearly fee and/or 30% of their revenue.

* The next generation of kids will never have the joy of learning how their computer works as both the hardware and software will be locked down.

The loss of software development freedom and the loss of freedom to tinker with a computer greatly trouble me. Ironically, the companies that are now taking away these freedoms are the very same ones that were once built on them.

The Next Ubiquitous Platform - Part II

I started penning my thoughts on the next ubiquitous platform in July of 2007. I eventually posted it a year later as The Next Ubiquitous Platform. Since then, a lot of things have happened to the major players in the mobile world:

1. Nokia Symbian

In the past year or so, Nokia aquired Symbian, open sourced the platform, and released a new version. Symbian still has almost half of the global market share, but it is slowly losing ground to rivals.
Global market share: 2009: 46.9% 2008: 52.4%
Verdict: The #1 feature phone platform.

2. RIM Blackberry

RIM released a new version, stayed out of controversies, and continued to remain a solid second to Symbian.
Global market share: 2009: 19.9% 2008: 16.6%
Verdict: The #1 corporate messaging device.

3. Apple iPhone

Apple released a new version, lost a couple of prototypes, picked fights with Adobe, Nokia and HTC, and continued to dictate what users and developers can and cannot do with their iPhones including banning porn and the use of third-party libraries. Sales may have slowed down lately but it is still very popular with consumers.
Global market share: 2009: 14.4% 2008: 8.2%
Verdict: The #1 consumer Smartphone.

4. Microsoft Windows Mobile

Microsoft released a new version, but continued to bleed market share.
Global market share: 2009: 14.4% 2008: 8.2%
Verdict: Still as uninspiring as ever.

5. Google Android

Google released many upgrades, it's partners released many devices.
Global market share: 2009: 3.9% 2008: 0.5%
Verdict: The fastest growing mobile platform, eating away at the market share of other Linux platforms and Windows Mobile.

6. Palm WebOS

Palm released an impressive new platform. But it was too, too late. Unable to sustain itself, Palm was acquired by HP.
Global market share: 2009: 0.7% 2008: 0%
Verdict: Too many missteps along the way has made this one time leader into a niche player.

7. JavaFX Mobile

It's been 3 years since JavaFX Mobile was announced. Much was promised, but there still no devices shipped.
Global Market share: 2009: 0% 2008: 0%
Verdict: With SUN no more - having been absorbed into the borg that is Oracle, I pronounce JavaFX Mobile DOA.

In July 2007, in The Next Ubiquitous Platform I postulated:

It's clear that the next ubiquitous computing platform is going to be a mobile one. It's also clear that it won't be Apple's iPhone since it is a proprietary closed platform, and historically, only open platforms like the Apple II and the IBM PC have attained ubiquity. The last pretender to the throne was Palm, but delays in incorporating modern features like multi-tasking and multimedia support, have relegated it to an also-ran. It also seems likely that the next ubiquitous computing platform will incorporate the two heavy weights of the Open Systems world - Linux and Java.

Almost 3 years later, I can say that the Next Ubiquitous Platform is Android. I hate the fact that even though you code in Java, it's not really Java. And that Google doesn't seem to listen to it's users or developers and has done nothing to improve device fragmentation or fix the issues with it's marketplace. But there's no denying the fact, that with 34 different handsets being shipped in 49 countries, at the rate of about 65,000 a day, Android is the clearly the Next Ubiquitous Platform. And it incorporates both Linux and Java. Somewhat.


Credits: Global Market share stats by Gartner (2010)

Noughts & Crosses

When I started learning J2ME in 2005, the first game I wrote was a Noughts & Crosses game. Since then I've been working on a platform game, but as it's taking so long to complete I've decided to polish up the old Noughts & Crosses game, and release it:

Noughts & Crosses

Features:

• Play against a human opponent or against the phone.
• Three difficulty levels.
• Ability to enter player names.
• Ability to choose starting player.
• Touch screen support.

System Requirements: Java (MIDP 2.0, CLDC 1.0)
Genre: Puzzle | Strategy

Watch Gameplay Movie

Play Demo Online

Download Demo: xno.jad xno.jar

You can view the demo game play movie on YouTube, or you can play the demo online. I would really appreciate it, though, if you could download the game to your phone and test it and let me know how it works. Any feed back is very welcome.

A J2ME Mobile Game (Contd)

A small update to my previous post:



Some new effects and a new monster. Also, added music created using ModPlug Tracker.

A J2ME Mobile Game

Here's a sneak peek at a J2ME mobile game I've been working on in my spare time:





It's the first proper game I've ever tried to write and I hope I'm able to complete it. I drew all the images in Gimp and laid out the level in Mappy. The screenshot and video is from the first level running in a little tester I wrote that lets me test out the animations, tile maps and levels, using my very own 2D tile engine.

The Next Ubiquitous Platform

** I had written this post on 07/10/2007, but never published it. Scarily, it still seems valid a year later... **


It's clear that the next ubiquitous computing platform is going to be a mobile one. It's also clear that it won't be Apple's iPhone since it is a proprietary closed platform, and historically, only open platforms like the Apple II and the IBM PC have attained ubiquity. The last pretender to the throne was Palm, but delays in incorporating modern features like multi-tasking and multimedia support, have relegated it to an also-ran. It also seems likely that the next ubiquitous computing platform will incorporate the two heavy weights of the Open Systems world - Linux and Java. So, could the next ubiquitous computing platform be JavaFX Mobile?

It's been two months since Sun announced this confusingly named JavaFX Mobile product at JavaOne 2007. Based on technology aquired from SavaJe Technologies, JavaFX Mobile is a "Java Phone" product from Sun that consists of a proprietary application layer, a CDC Personal Basis Profile and a small Linux kernel. Contrary to what you might believe, JavaFX Mobile is not part of the JavaME family of specifications. Unfortunately, Sun did little to clear up this confusion at JavaOne, often equating JavaME to JavaFX Mobile. In reality, JavaFX Mobile is actually an implementation of a JavaME + Linux stack, with proprietary extensions. (Besides equating JavaME to JavaFX Mobile, Sun also equated JavaSE with Netbeans and JavaEE with Glassfish. Very Annoying!)

JavaFX Mobile is so named, because it will be able to run applications written in JavaFX Script (formerly known as F3). This aspect of JavaFX Mobile was hyped no end at JavaOne, even though the support for JavaFX script was actually hacked together only a couple of weeks before. It showed, when the demos failed spectacularly on stage. Hopefully in the future we will be able to see a working implementation to judge if it lives to the hype.

Sun intends to license JavaFX Mobile as a binary product to phone manufacturers. Sun claims that this will decrease fragmentation, as phone manufacturers will now have a "standard" JavaME implementation to use in their phones. But Tier-1 phone manufacturers like Motorola and Nokia have already decided their Linux + JavaME stacks. At the most, second tier phone manufacturers looking to clone the iPhone may license JavaFX Mobile. So if anything, JavaFX Mobile will increase fragmentation by adding another JavaME implementation into the mix.

SavaJe Technologies had been working on this Linux + JavaME stack since 1999, but was unable to get any device manufacturers to adopt it. What makes Sun think that they will do any better? Do they really think that by simply adding support for JavaFX Script device manufacturers would be lining up to license it? And how do they intend to compete against mobile Linux distributions like OpenMoko, Access Linux Platform, UbuntuMobile, Greensuite, WindRiver and Mobilinux? Or against mobile application frameworks like Qtopia, Hiker and Maemo? Or even against IBM's J9 CDC implementation?

JavaFX Mobile is not all bad. The technology behind it is certainly impressive - it even implements telephony services in Java! And it looks visually stunning. Who knows? Maybe Sun will even deliver on the support for JavaFX Script and other multimedia technologies. But the question remains: How is Sun going to get JavaFX widely adopted?

I think it's possible, but not in it's current incarnation. IMO, Sun needs to target mobile Linux distributors instead of device manufacturers. For that, they need to break JavaFX Mobile into it's component parts: Linux kernel + CDC implementation + application layer, and license them individually. That way, mobile linux distributors can choose the parts they're interested in and integrate them into their distribution. Having just the JavaFX Mobile CDC implementation be the standard JavaME implementation for all mobile Linux distributions would go a longer way towards solving the problem of fragmentation than Sun's current approach. Finally, Sun needs to start acting like a responsible member of the mobile Linux community and join the standards organizations like LiPS, LiMo, MLI, and CELF. When you're too late in the Mobile Linux game to compete, you must collaborate!

In conclusion, I don't think JavaFX Mobile will be the next ubiquitous computing platform. But if it is broken up, I'm sure that the next ubiquitous computing platform will incorporate parts of this cool technology.

What do you think will be the next ubiquitous platform?

How Many Sun Engineers Work On Swing?

After reading JavaLobby's "JavaFX Script vs. Swing: Are You Still Concerned?", I started wondering how many Sun Engineers still work on Swing. From what I could count from blogs, projects and mailing lists, the only folks left on the Swing team are Richard Bair, Amy Fowler, Thorsten Laux, Alexander Potochkin, Jasper Potts and Shannon Hickey (Swing Team Lead). The rest of the Java desktop team are either working on Java 2D, Consumer JRE, Netbeans, OpenJDK, or JavaFX; or have left Sun. That's six people working on Swing! And this is after the new desktop focus from Sun. Shudder to think what the team was like after Sun had abandoned Swing for server-side Java. To put the size of the Swing team in perspective, even a small company like Trolltech has over 40 people working on the development of the Qt toolkit! So the next time you feel like abusing the Swing team for the failings of Swing, please, blame the short-sighted Sun management instead.

Apple Finally Releases iPhone SDK

First there was no need for an iPhone SDK:

"We have been trying to come up with a solution to expand the capabilities of the iPhone so developers can write great apps for it, but keep the iPhone secure. And we've come up with a very. Sweet. Solution. Let me tell you about it. An innovative new way to create applications for mobile devices... it's all based on the fact that we have the full Safari engine in the iPhone."

"And so you can write amazing Web 2.0 and AJAX apps that look and behave exactly like apps on the iPhone, and these apps can integrate perfectly with iPhone services. They can make a call, check email, look up a location on Gmaps... don't worry about distribution, just put 'em on an internet server. They're easy to update, just update it on your server. They're secure, and they run securely sandboxed on the iPhone. And guess what, there's no SDK you need! You've got everything you need if you can write modern web apps..."

Steve Jobs, June 2007

Then there was going to be an iPhone SDK after all:

"Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers."

Steve Jobs, October 2007

I had predicted back in June 2007 that Apple would release an iPhone SDK:

http://enaiel.blogspot.com/2007/06/iphone-j2me-and-vendor-lock-in.html

I predict that Apple will go the BREW route: they will release an SDK, but you will need to pay big bucks to Apple to get your app/game certified so that it will even run on the iPhone. And consumers will only be able to buy these apps/games from iTunes. In the end, it's not about closing the iPhone for the consumer experience, or for the carriers - it's about proprietary vendor lock-in. When Microsoft does it, it's illegal, when Apple does it, it's cool??!!

Now that the details of Apple's iPhone SDK are out today, let's break down my predictions and see how well I did:

Apple will release an iPhone SDK.
Developers will need to pay money to Apple to get their applications certified for the iPhone.
Uncertified applications will not be able to run on the iPhone.
Consumers will only be able to buy iPhone applications from iTunes.
It was all about proprietary vendor lock-in after all.

I think I did pretty good there in second-guessing "His Steveness"!

Where Has The Java Community Gone?

A few years back, the Java community was really strong. You had JavaRanch for the newbies, JavaLobby for the veterans, TSS for the server side guys, and J2MEForums for the mobile guys. The news was always exciting, and there were pages of discussions on even the most mundane topics. Fast forward to today and TSS has turned into a vendor propaganda site plus editor blog, J2MEForums activity is at an all time low, and JavaLobby has self-destructed into a blog-roll. The combined discussions among all these sites today is a fraction of the discussions on even one of these sites before. So where has the Java community gone? Did they abandon ship because Java is dying? Hard to believe as there are more Java developers today than ever before. Are they quiet because the hype machine has moved to Ruby? Not likely as I haven't seen any Ruby community sites that are more active either. So what happened?

I blame the rise of the blogosphere for the death of the Java community. When everyone has their own soap box, there's no single place to congregate and discuss. But when the community is composed of a few small discussions scattered across a few thousand blogs, it may as well be dead. So maybe JavaLobby is doing the right thing - the community is dead anyway, might as well accept it and move on. But JavaLobby was the last bastion of the Java community, and it will be sorely missed.

Joy Of Programming

"Everything should be made as simple as possible, but no simpler."
Attributed to Albert Einstein

When I first used Java many years ago, I was amazed how amazingly easy (and fun) it was to create applets and applications that did file I/O, networking, multi-threading, and later, remoting and database access using just AWT, java.io, java.net, RMI and JDBC. The language was easy to read and program and the JDK was free to download. Best of all, it came with these amazing libraries built-in! And knowing those libaries and Object Oriented Programming was all you needed to know to get a job in Java. I and thousands of other developers left the overly complicated world of C++, MFC/Motif and COM/CORBA for the simple elegance of Java, and never looked back. Luckily for us, the birth of Servlets made Java the server-side language of choice for Enterprises. It may have spawned a million web frameworks, but Servlets by themselves were brilliantly simple and elegant, and a lot more fun than the alternative of Perl CGI that I had suffered through before.

Since then, Java has been getting increasingly complicated. First with the additions of Swing, DynamicProxies, NIO, and Generics, and now with Closures, Java is getting more powerful, but at the same time, definitely more harder to program. Even worse, we now have hundreds of APIs, and have even more on the way. Inorder to get a job in Java today, you need to know Swing, EJB/Spring, JMS, JTA, JSP, Servlets, HTML, Javascript, SQL, JDBC, Hibernate/JDO/JPA, Ant, Eclipse/Netbeans/IntelliJ, Struts/JSF, UML, XML, jUnit, SOAP, Tomcat/Weblogic/Websphere, and the millions of Open Source libraries! These days I write more SQL and XML than I write Java. It's gotten to the point that writing business software in Java, what most of us do for a living, is no fun any more.

The reason why programming in Java has become so painful today is that Java designers are sacrificing simplicity and elegance for power and flexibility. This attitude is best embodied by Swing, an abomination that is neither a widget toolkit like AWT, nor an application framework like MFC. It maybe the most flexible GUI framework ever made, but it's also the most hardest to work with. It has a steep learning curve due to it's excessive inheritance hierarchy and it's convoluted version of MVC, while it lacks basic features like data binding and a proper component model. Since Swing, Sun has given us EJB, JMF, Java3D, and JSF, all APIs that make doing the easy things hard, and the difficult things really really hard. That was exactly the mistake that C++ made before, and just like C++ programmers like me quit C++ for Java, Java programmers have started abandoning ship for simpler alternatives like Ruby and Python.

"Designers are not typical users – they become so expert in using the object they have designed that they cannot believe anyone else might have problems; only interaction and testing with actual users throughout the design process can forestall that."
Donald Norman in The Design Of Everyday Things.

The initial Java language and libraries were designed with a user's perspective. And it shows. Bill Venners calls it Designing for Usability. Since then, the new APIs have been designed by vendors and expert users, for other vendors and expert users, without any consideration for the actual users of the APIs: those that have to work with them every single day. If every new JSR had to go through user trials before being made into a specification, we would never have to suffer through the complexities of EJB.

All is not lost, yet. J2ME offers the same refreshing simplicity of the early Java APIs. And there are new Java libraries out there that are brilliantly simple and elegant. For example, I needed to convert some XML files into Java beans. Sounded simple enough, till I tried Apache BeanUtils, JAXB, and Castor. The first two were too complicated, while the last one had too many problems to work around. And then I found XStream. Amazingly easy to get started with, and yet supported even the most advanced scenarios. What a joy to use! Why can't all Java libraries and APIs be this way? Here's a plea to all those who design Java APIs - think of your users, and bring back the joy of programming to Java.

How To Write Software In The Finance Industry

Here are some tips to help you write cutting edge software in the Finance Industry:

1. Store some of your configuration in properties files, some in XML files, some in the database, and some as static variables in your code.
2. Use reflection and dynamic proxies wherever possible. Where not possible, use byte code manipulation.
3. Never ever use assertions. Catch all exceptions and errors, and keep running. Don't ever send an error back to the user. Unless it's a NPE.
4. Log either nothing or everything. When logging everything, include verbose output from all your third party libraries.
5. Always wrap your exceptions. Log the stacktrace from your wrapped exceptions only.
6. Loosely couple all your classes using XML configuration. When you realize that you need to somehow call those classes, provide instance accessors using public static variables.
7. Re-invent the wheel as often as possible. Write your own ORM. Your own remoting. Your own cacheing. Your own GUI framework. Your own testing framework. Your own widget toolkit. Your own scripting language. Make up excuses and benchmarks to show why you needed to re-invent the wheel.
8. Make your code base as huge as possible. Include classes that were never used or tested. Use an abandoned experimental product to compile your classes. Make it impossible to compile in an IDE, and painful to compile from the command line.
9. Create many sophisticated disparate systems. Integrate by FTP. Using flat files with pipe delimited data.
10. User experience is not important. Create a slow, ugly GUI that uses a massive 2 gigs of RAM. Make 4 GB desktops mandatory for users.

Please feel free to add tips from your own experience.

Ten Steps To Becoming A J2ME Game Developer

In line with JavaLobby's Java Gaming celebration month, I present Ten Steps To Becoming A J2ME Game Developer:

1. Buy and read J2ME Game Programming by Martin J. Wells. If you're short of time, read chapters 7 through 16. This book will help you wrap your head around the different concepts in game programming.
2. Download and install the JDK, the WTK, your favourite IDE (Eclipse or Netbeans) and the J2ME plugins for your IDE (EclipseME or Netbeans Mobility Pack).
3. Download and install Ant and Antenna (J2ME tasks for Ant). The only way to deal with device fragmentation is to create a flexible build script that allows you to use device configuration files and a preprocessor to create device specific jar files.
4. Download and install Proguard. You will need to obfuscate your code to fit into the operator limited jar size.
5. Download and install the latest SDKs and Emulators from Nokia, Motorola and Sony Ericsson. You will need to test on these emulators as well as on some actual devices.
6. Download and install GIMP for graphics, Audacity for sound effects, and AnvilStudio or RoseGarden for MIDI music.
7. Download and install Mappy to create your 2D tilemaps. You don't even have to write your own level editor these days.
8. Create your 2D tile based game. Besides the book mentioned above, the forums at J2MEForums has all you need to know to write your first game.
9. Submit your game demo to the GetJar's beta testing program. This will allow you to identify any remaining device compatibility issues.
10. Publish your game with mobile game portals like ClickGamer, and advertisement wrapping portals like GameJump and Hovr.
11. Profit ?!?!

For a hobbyist, J2ME is the best platform to begin writing games: free and excellent tools, easy to program, easy to deploy, and a friendly community too. Anyone and their dog can write a game in 3 months that's as good if not better than some of the games being churned out by the big game studios. So follow my Ten-Step program and start writing J2ME games today!

The Star7 PDA Prototype

I just uploaded the video of the Star7 from James Gosling's blog to YouTube. I hope he doesn't mind...

Right Shift Considered Harmful (Again)

CLDC 1.0 has no support for floats. So J2ME programmers generally use fixed point maths to represent decimals. The basic idea is that you multiply the integer by the precision factor you need, and then divide by that precision factor to get back your integer. By choosing a precision factor that's a power of 2, we can use left bitshift to covert to fixed point and right bitshift to get back the integer. This is a common optimization since integers are stored in binary format and left bitshift is equivalent to multiplying by 2 and right bitshift is equivalent to dividing by 2. So, for example a typical fixed point math class would look like this:

public final static int PRECISION = 16;
public final static int FACTOR = 65536;

public final static int toFp(int a){ return (int)((long)a << PRECISION); } 
public final static int toInt(int a_fp){ return (a_fp >> PRECISION); }
public final static int addFp(int a_fp, int b_fp) { return a_fp + b_fp; }
public final static int subFp(int a_fp, int b_fp) { return a_fp - b_fp; }
public final static int mulFp(int a_fp, int b_fp) { return (int)((((long)a_fp * (long)b_fp)) >> PRECISION); }
public final static int divFp(int a_fp, int b_fp) { return (int)(((long)a_fp << PRECISION) / b_fp); }

But then while writing my first J2ME game using fixed point math, I had the weirdest problem: motion in directions where sin/cos was negative was always greater than in directions where sin/cos was positive. Debugging, I found that the problem was with right shifting negative integers: right-shifting a negative integer is not equivalent to dividing by 2 because negative integers are stored in 2's complement form!

To understand the problem, lets try a simple example:

int a = 3/2;           // = 1
int b = -3/2;          // = -1
int c = 3 >> 1;        // = 1
int d = -3 >> 1;       // = -2!!!
int e = -3 >>> 1;      // = 2147483646!!!

System.out.println("a="+a+" b="+b+" c="+c+" d="+d+" e="+e);

I had to understand what was going on here! So here's what I found out:

Since integer is a 32 bit binary in Java:
3 is represented as: 00000000 00000000 00000000 00000011

3 >> 1
= 00000000 00000000 00000000 00000001 (1) (Right most bit 1 is shifted off)
= 2^0 = 1

-3 is represented as: 00000000 00000000 00000000 00000011
 then 1's complement = 11111111 11111111 11111111 11111100
 then add 1 (2's complement) = 11111111 11111111 11111111 11111101 (Left most bit is sign bit)

-3 >> 1
= 11111111 11111111 11111111 11111101 >> 1
= 11111111 11111111 11111111 11111110 (1) (Right most bit 1 is shifted off and sign bit is retained)
= -(2^0 + 1) = -2 (Converting from 2's complement)

-3 >>> 1
= 11111111 11111111 11111111 11111101 >>> 1
= 01111111 11111111 11111111 11111110 (1) (Right most bit 1 is shifted off but sign bit is also shifted)
= (2^(32-1) + 2^0 + 1) = 2147483646 (Converting from 2's complement)

Apparently this problem is a very old one. I found this interesting paper by Guy Steele in 1976 that explains it in detail: Arithmetic Shifting Considered Harmful. At the time, right shifting instead of dividing by 2 was a common compiler optimization and compiler writers either did not grasp or did not document the difference. What amazes me is that 30 years later, I faced the exact same problem because this difference is still not properly documented. Ironically, even the Java Language Specification which was co-authored by Guy Steele has only a very cryptic reference to this issue. Of course the situation in Java is still better than C/C++ where the result of right shifting a negative integer is compiler/platform dependent.

iPhone, J2ME And Vendor Lock-In

So the latest news is that the iPhone will feature YouTube. Not using Safari, Flash or J2ME, but as a non-portable iPhone app. That reminded me of the reason that Apple gave for not opening up the iPhone to third party developers:

"You don’t want your phone to be an open platform, You need it to work when you need it to work. Cingular doesn’t want to see their West Coast network go down because some application messed up."
Steve Jobs, Interview, January 2007

So why doesn't Apple include J2ME on the iPhone? Cingular already has millions of J2ME phones that have not brought down their network! Besides, consumers today do not download J2ME apps/games from the web - they buy them from the carrier decks. That translates into real revenue for the carriers. Why would any carrier say no to millions of dollars in revenue? Oh right, the reason why the iPhone does not include J2ME is:

"Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain."
Steve Jobs, Interview, January 2007

Really??? Let's look at the evidence, shall we?

• All Tier-1 phone manufacturers support J2ME in a big way.
• Most major carriers support J2ME in a big way.
  
• RIM has completely embraced J2ME for their Blackberry.
• Almost all Windows Mobile phones today come with J2ME pre-installed!
• Palm, the last J2ME hold-out has finally licensed IBM's J9.
• Microsoft, Yahoo and Google have released their mobile applications using J2ME.
  
• J2ME being opensourced has ensured that every future Linux phone will ship with J2ME pre-installed.
• Globally, and even in the land of BREW (US), more J2ME enabled phones are sold today than any other platform.
  

So what is the real story? For that we need to understand why J2ME is the dominant mobile platform today. J2ME's phenomenal success has been due it being an open platform from a neutral vendor (i.e. not Microsoft and not another Telecom company). Besides Sun, every major phone manufacturer (and carrier) is involved in J2ME's specifications. Anyone (and I really mean anyone) can write J2ME apps/games using the many free tools available. And (in theory at least) anyone can download these apps/games and run them on their phones. As BREW found out, it's really hard for a proprietary platform to compete against such an open platform. Vendors, developers, publishers, distributors and consumers tend to flock towards open technologies, creating a thriving marketplace. And even though the carriers are doing their best right now to control the J2ME marketplace, it's still in a hell of a lot better shape than any of the alternatives. So the real story, IMO, is that Apple looks at J2ME (and Flash for that matter) as a competitor to it's very closed and proprietary iPhone platform. Come to think of it, if the iPhone had J2ME, why would Google have become an iPhone partner?

I predict that Apple will go the BREW route: they will release an SDK, but you will need to pay big bucks to Apple to get your app/game certified so that it will even run on the iPhone. And consumers will only be able to buy these apps/games from iTunes. In the end, it's not about closing the iPhone for the consumer experience, or for the carriers - it's about proprietary vendor lock-in. When Microsoft does it, it's illegal, when Apple does it, it's cool??!!
** Updated to include iPhone image.