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.

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.

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!

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.