Why we chose Java

We made a key decision early in Kerika's product development to use Java and develop a true cross-platform collaboration system, although it would undoubtedly have been cheaper and faster to build a plain old .NET application that ran only on Windows. There were two strategic reasons for choosing the harder, but ultimately more rewarding, path:

1. Our vision was always about bringing together distributed teams regardless of where people are located or what sort of computer they are using. This narrowed our choices to Java, Flash, SVG, C++ and C. (Neither Python nor Ruby would have given us the user interface richness we considered essential for Kerika's success – at least back in 2003 when we made our language choices – to have been serious contenders.)
   
   We opted for Java because we believed that it was the richest cross-platform language available, one that would allow us to build an elegant user interface:
   
   
   • Using C or C++ would have resulted a lot of platform-specifc coding for the graphics and file management: in other words, we wouldn't be building a cross-platform application, but rather building the same application repeatedly, and painfully, for each platform.
   
   
   • Using Flash or SVG would likely have given us a great user interface, but there was, and remains, a dearth of programmers who are proficient in these platforms, which would have made recruiting a harder task, and, more importantly, there wasn't a rich ecosystem of third-party and open-source tools for Flash and SVG.
   
   
   • Using the .NET platform would have resulted in Kerika looking like just another WinForm application – in other words, looking like all our clunky competitors!


2. We were also mindful of the need to compete with Groove, and since Groove was very much a Windows-centric application – even before they were acquired by Microsoft – we needed to find terrain that would favor us should we have to go head-to-head with Groove.
   
   Although Ray Ozzie would occasionally make noises about creating a Mac version of Groove, we were fairly certain that this wouldn't happen, because the longer you develop a Windows-only application, the harder it becomes to retroactively make it a cross-platform software.

Our biggest concern as we started down the Java path was simple: was Java really going to be a build once, run everywhere application, or would it turn out to be a build once, debug everywhere application as skeptics warned us?

Our conclusion, after having written over 100,000 lines of Java: Java is really a build once, run everywhere platform!! We did find some minor glitches along the way, but these were almost always the consequence of two factors:

1. Using third-party tools, particularly open-source code, that hadn't been properly tested in the first place.


2. Trying to integrate platform-specific C or C++ code using the Java Native Interface(JNI).

Our own code, as well as code we got from more robust sources likes Piccolo, was worked just fine on multiple platforms. In fact, we were able to create a truly distributed team, with individuals programming on Windows, Mac or Linux according their preference, and then pull everything together as a single set of Jars. We do all our builds on a Mac, create installation packages for Windows and Linux, and then test all three versions simultaneously.

And it all just works...