adam bien's blog

Develop in Java, deploy on iPhone, Android and Windows Phone. What is codenameone? An interview with Chen Fishbein.

A: I'm Chen Fishbein, I've been a Java developer since the 90's and started working with Sun Microsystems in early 2000 on some of the earlier mobile projects. I also worked with several companies at the time ranging in technologies from J2EE to Swing development etc. Eventually I joined Sun Microsystem in 2004 where I started working in the operator group providing services to operators. One of our first tools was the Sprint WTK which was one of the most successful operator specific toolkits ever made. I then founded the LWUIT project within Sun that was one of the most successful open source mobile platform projects on Java.net. My colleague in Codename One is Shai Almog whose background in Java is remarkably extensive.

A: I think Java is exciting! Not in the "hot new language in town" sort of way but in the "I can do amazing things and they actually work" sort of way. Both Shai and myself are huge Java fans so we decided to work on Java as the first language Codename One supports, however since the underpinnings are a JVM we do have a grand vision of opening up to all JVM languages. This is exciting and cool. I think people often choose other languages because they don't have a choice, people choose Objective-C on iOS because that's what they have that can produce reasonable results.

A: No. It can't be and frankly we can't really say its Java legally since we aren't licensees at the moment. E.g. on Android we just use Dalvik which technically isn't Java so this alone won't pass. We don't support all the API's and don't have many abilities that just don't make sense on the device. E.g. reflection isn't supported. Reflection is bad for client coding since it requires us to package the entire VM (and performs badly), so its just out. We also need developers to use our own GUI & networking API's. Since its really hard to support the existing API's on the wildly different devices out there. However, we think we are the closest thing to Java's spirit of WORA. For us, Java is just a matter of pressing play and having everything "just work"! That magical moment when a project you developed on Windows works on your Linux server... Well, we try to take that magical feeling into mobile phones.

A: Yes, our client stack including the libraries, GUI builder etc. are fully open source under a license that allows commercial deployment. We work very hard at free community support as well, since we feel that you don't have to pay to get an answer from a developer. We also provide free quota for developers to use our paid build service, since we want to enable the hobbyist developers as well as the developers from emerging markets who might not be able to afford a monthly subscription fee. We also have a very cheap subscription option for indie developers which we intend to keep that way. As an open source company we feel it is critical to give back in that regard and the fact that our code is open keeps us "honest". Furthermore, some community members were able to build entirely from the open code without using any of our tools and they documented this fully. We however don't provide "official" support for offline building unless you are an enterprise class customer, the logic behind this is that this process is REALLY difficult and failures during this process are remarkably hard to debug (6mb error logs on iOS aren't easy to go through).

A: Yes its Java since we are big Java hackers. Our server logic is entirely on App Engine Java and uses the DataStore API, JPA and pretty much everything you would expect from App Engine. We have Mac's & Windows machines in the cloud to build the native executables using xcode, visual studio etc. there we have extensive "scripts" mostly written in Java as well, its a remarkably complex distributed system of many build serves strung together for redundancy. We use many cloud providers as well as host some of our own hardware since its remarkably expensive to host a Mac in the cloud. We work with Amazon, Azure and others for such services.

A: They say there are 3 kinds of lies: Lies, Damn Lies & benchmarks. Well we found a benchmark where the underlying XMLVM engine we used on iOS fairs better than Objective-C. Objective-C is a really bad language that merges two great but completely different languages into one Frankenstein monster (Smalltalk + C). Smalltalk (hence Objective-C) doesn't use methods, it uses messages which are remarkably slow even compared to the function pointer lookup in C which is used by XMLVM (which translates the code to C not Objective-C). iOS users don't notice that in their UI because the GUI is coded using Core Animation which is ridiculously fast GPU specific code. Startup time in iOS is actually pretty slow but the OS requires an application screenshot which creates the feeling of applications launching instantly when in fact from our benchmarks iOS devices seem to be slower that equivalent Android devices. Not to start a religious war here, I'm not saying iOS doesn't feel faster. Up to Jelly Bean on Nexus 4 it did and that probably matters more than raw performance.

A: No. That's why we have the build servers. You do need to pay to Apple though because you need to generate a certificate and a provisioning profile to deploy to your own device (seriously) unless you jailbreak it. We have some videos on the subject but the process is difficult and a tiny mistake made during the process can break everything. In the long term we would like to automate everything but you will still need to shell out 99 USD to Apple on an annual basis just for the right to build for your own device.

A: Whenever you work with an abstraction layer there are points of "leaky abstraction" things that the abstraction can't solve properly or a failure where a bug is sometimes harder to figure out (since you don't really understand the underlying native platform). We are also focused mostly on apps so things such as games will be harder to write for the platform at the moment. The upside to these is that we are dedicating a ridiculous amount of effort to support which is probably a more important task than any feature we might add. The wonderful thing is how our community also pitches in and tries to help developers alongside us.

A: We are ex-Sun guys so we are just really used to NetBeans and find working with Eclipse harder (probably out of habit). We do use Eclipse for the Eclipse plugin development (obviously) and for App Engine where the Google plugin is superior in that regard to whats available in NetBeans. Personally I think we spend roughly 90% of our time working on NetBeans.

A: As much as we can. Even with the transition towards a more mature company with a standard hierarchy we will probably keep coding. As a development tool company we can't afford not to code! We need our finger on the pulse of the developers and we don't think you can really communicate with the community without doing the heavy lifting yourself. As the CTO this would probably be easy for me to keep as we grow. Shai who is the CEO in the team is a diehard coder and won't stop coding for many years to come.

A: Thank you! Great and insightful questions, its always fun talking to developers since they ask the "right things" rather than the high level abstract business cases ;-)