With 100,000 SDK Downloads, Mobile Development Platform Codename One Comes Out of Beta With 1.0 Launch

Tel Aviv, Israel - Mobile development platform Codename One is announcing the launch of its 1.0 version on Tuesday, January 29. After releasing in beta last June, Codename One – the first software development kit that allows Java developers to create true high performance native mobile applications across multiple mobile operating systems using a single code base – has garnered over 100,000 downloads and emerged as one of the fastest toolkits of its kind, on par with native OS toolkits.

read more...

This blog has moved

Due to technical issues with our ability to customize the look of blogger we shifted the main blog here. We will still maintain this blog and try to cross post everything to the old blog but from now on we would prefer discussion and interaction on the new blog.

Why Oracle won't issue Java for iOS anytime soon

They say that today all companies are software companies. In less than 5 years all companies will be mobile companies. So why isn't Oracle "getting it", why aren't they on the iPhone, on Android and even Windows Phone?

This OTN thread has been going on for some time now with people constantly chiming in with various uninformed opinions regarding their desire for an official Java for all platforms from Oracle.
This won't happen in the next two years or so, don't delude yourselves.
No we don't have a vested interest here, if Oracle issues Java FX for iOS it will be great for us. We will be able to use their implementation (if it were any good, more on that below) and still provide value.

Read below for more detailed explanation from a former insider as to why this just won't happen.

Chen used to be a Sun employee and I was a Sun contractor for quite a few years, we were there for the Oracle takeover as well. I can't talk too much about what I know from within, its not so much a contractual issue  as a personal moral issue (respect the privacy of the guys paying your bills). However, there is one thing that I think no one will mind me disclosing that explains perfectly well why Oracle removed all sessions about the iPhone from Java One (except for our session which wasn't an Oracle sponsored section).

One of the early feelings we got before the merger completed was  the basic difference between Sun and Oracle and it boiled down to this:
With Sun we used to go to customers/trade shows and show the cool stuff we had that wasn't yet a product. E.g. showing off cool new JavaFX tools that didn't have an ETA yet. This was ingrained in the hacker mentality and core to Sun, why show people the stuff that's available to download?
Don't they know already?

Oracle is the exact opposite, they NEVER show something that isn't a product or won't be a product very soon. This is actually quite clever, people aren't aware of lots of the stuff that's available and if you talk about your pipe dream (which is cool) there is no "action item" to download a try it. You need people's attention focused on what they can buy (obvious why Oracle was profiting while Sun was losing).

So Oracle's removing of the JavaFX on iOS talks from Java One is simply a matter of them not having a concrete product in the pipeline (update: just to clarify, this is an educated guess not a statement of fact).

Now you may ask: Why not?

That's actually a much easier answer and as usual it divides into several different answers:

1. There is no business there - Oracle released a Java based solution for iOS backend for the ADF team. This is a tool that's only useful if you buy a server license (minimum 20k USD), so there is a clear business here.
   Java is generally an odd duck in Oracle's tools, they just don't build stuff that doesn't make business sense (like Java itself).
2. This is a consumer product - Oracle is an enterprise company. Yes they are trying to break some of that mold but old habits die hard, they don't really understand the business and they don't really know how to build consumer products.
   Sun also sucked with user facing projects so really this isn't very different (and keep in mind, that Sun never made a Java for iPhone release either despite Apple removing the restrictions WELL before the acquisition).
3. It will suck - the problem here is Apple. Apple disallows JIT's in its license (self modifying code), mostly for security reasons but probably also to block things like this. That is why you can't ship a custom built webkit with your application (no V8 JavaScript engine for Chrome on iOS which is why it sucks on iOS).
   We get around it by translating the Java bytecode to C and compiling it, this gives us native (or better) performance.
   I don't know about Oracle here, but this sort of architecture would never fly at Sun. Java is a virtual machine with a JIT, that is a religion within Sun and I assume the same is true for the Sun engineers who stayed at Oracle.
4. It will suck worse -  not only will it be slow because of the VM, it will be slow because of JavaFX (here we can actually help if Oracle chooses to do option 3 well).
   Adobe with its amazing skills in vector graphics programming is finding it remarkably hard to build a high performance vector graphics rendering engine in iOS. They complain that Apple doesn't expose the internal GPU behavior.
   Frankly, I understand Apple here. Documenting the GPU on the level Adobe needs is REALLY hard. Supporting this against potential driver issues and attacks isn't simple, that's why they have Core Animation.
   Java FX can't use Core Animation (just like Adobe can't) and will run into the exact same problems Adobe hit. I have a great deal of respect for the engineers on the Java FX team, they are pretty clever. But that's not good enough.
   We don't run into those pitfalls since we are pretty used to device limitations, we pre-render everything important as raster images (which is what most mobile developers do anyway). This might not have the same "cool" graphics geek sheik, but it actually provides amazing looks because prerendering often looks better. Sure there are compromises about what you can do, but you will find pre-rendered graphics in most of the leading iOS apps despite the availability of vector graphics. Its easier, faster and flexible enough.

So if you are looking for JavaFX on iOS, Android or Windows Phone then sorry. Just won't happen.
We are trying to help, but Java FX is a dead end technology as illustrated by the famous graph at the top of this article. Everyone will be on mobile which will exceed everything WinTel ever was and FX isn't well suited for today's mobile devices. It probably can't be fixed either since it relies on a Scene-Graph approach which just isn't very portable to device specific Scene-Graphs. It would be possible to implement it over OpenGL ES but that has many issues.

How Do I???

Answering common question is what a FAQ is usually for, but usually that's just not enough. A common presentation tip is: "Show, don't tell".
Which is why we launched the "How Do I?" section in the Codename One website, this section contains short video tutorials demonstrating how to do small things in Codename One from creating your first Codename One application to monetizing and debugging it (upcoming).
We hope to flesh out this section with more videos as time goes on, feel free to ask for future videos right here.

Survey Results With Some Comments/Thoughts

Thanks for answering our questions about what you want in Codename One 1.1, your answers were very interesting and your comments are always helpful. Before getting to the actual results I'd like to cover some of the comments made in some of the responses which I think broadcast that we need to communicate what we have better:

A frequent request is for more ad network integration "AdMob, iAd support and more" we are working on those but getting the agreements through and adapting them is difficult. These two specific networks are specifically difficult, Google is very rigid on AdMob and Apple is worse. We are constantly talking with networks about adding support for them (e.g. Zooz and Startapp which were recently integrated), but this is a time consuming slow process.

A comment asked for: "Lists that require less code to implement.". Did you checkout MultiList? Check out the up to date developer guide which covers them, they are pretty lean and also very easy to work with in the GUI builder.

One poster answered "Fast rendering on iOS (Slow performance on iPad 1 / iOS 5.5.1)" to which I would like to answer that rendering is pretty fast already. If you feel performance is slow a survey isn't the place to say that, use the discussion forum and read the developer guide tips.
Mutable images are inherently slow on iOS and drawing most graphics primitives isn't as fast, however image drawing etc. should be pretty fast.

One poster asked for "Debugging on real device directly from Eclipse/Netbeans" which we plan to do in the future and actually have all the pieces in place for this. It would just require quite a major effort from us to actually accomplish this so this isn't planned for 1.1.

We got one request for "Proximity Sensor Support", I'm guessing that we would have to implement bluetooth, NFC, sockets, motion sensor and only then proximity if at all. There is just too much ground to cover in these things.

Another commenter asked for "Annotations Support to make compilation metaprogramming". We already support static annotations, dynamic annotations won't be possible on older platforms (which might be fine) but would require some reflection capabilities. Since a mobile application is statically linked runtime annotations might be completely redundant since we know of all classes during compile time, that won't change since we translate bytecode to native.
Most of the functionality used by annotations is useful with dynamic loading, I would be interested to hear use cases though so feel free to submit issues with specific cases you would want to enable.

Lets look at the results and then I'll try to interpret them. Feel free to give your own spin in the comments below.
The first chart represents the primary feature, listed by rank below.

 

1. Windows Phone 8 support    32.56%
2. Library support    20.93%
3. New layout managers    9.30%
4. Continuous integration    6.98%
5. Improved 2D vector graphics    6.98%
6. Facebook/Google+ side menu    6.98%
7. Infinite scroll/pull to refresh    4.65%
8. bluetooth    4.65%
9. Easy web service wizard    2.33%
10. Theme customizer/colorization tool    2.33%
11. Charts API (graphs)    2.33%

Everything below this got 0 percent.

The second chart shows the options when picking one of 3 options:

1. Windows Phone 8 support    17.22%
2. Library support    16.56%
3. Charts API (graphs)    9.27%
4. Improved 2D vector graphics    7.28%
5. Infinite scroll/pull to refresh    6.62%
6. New layout managers    6.62%
7. Facebook/Google+ side menu    5.96%
8. Continuous integration    5.30%
9. Theme customizer/colorization tool    5.30%
10. Automatic device testing    4.64%
11. Matisse like layout in the GUI builder    3.97%
12. Easy web service wizard    3.31%
13. Support Amazon purchase & push API's    2.65%
14. IntelliJ Idea support    2.65%
15. Auto complete wizard    1.99%
16. bluetooth    0.66%

My interpretation of the data is this:

• People want Windows Phone 8 support. We are working on getting it into 1.1.
• Library support, again a major requested feature although I'm not sure people understand what it means. This doesn't mean you could take any arbitrary JAR off the internet. We already announced this feature for 1.1 so we are good here.
• New layout manager made a surprise showing at the top... I think this generally says people find layout managers difficult and hope we would have a better option. But its very likely a new layout manager will suffer from different set of problems from the current ones. I'd be happy if people who voted for this can post examples of what they would want in the comments.
• It surprised me that no one voted for the Matisse like layout manager in the GUI builder. I'm guessing people didn't understand that this meant placing components in arbitrary locations and having it "just work" (sort of).
• Continuous integration made a great showing, I really want it as part of 1.1.
• I'm guessing most people who voted for improved vector graphics assume this is about performance or maybe SVG support. If I'm wrong about this feel free to correct me in the comments below. I'd like to start some of the work for this and would especially love to add features such as perspective transform.
• It surprised me how low bluetooth scored, we will probably not have it for 1.1 either unless we get a code contribution there.
• Charts have a really high secondary option position and a really low 1st priority position. I think its an important feature but I'm still undecided since its a VERY complex feature to properly integrate.