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.