Friday, October 05, 2007

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.

Monday, October 01, 2007

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!

Friday, September 14, 2007

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...

Thursday, September 13, 2007

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.

Monday, June 25, 2007

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.