step closer to the coveted write once run anywhere ideal. Starting with Codename One version 3.0, you will
Log into the Codename One build server.
Download the application as a .zip archive that will run on any web server – or try the app instantly in your
browser using the “Preview” link.
I mention above that this is an alpha release because
not all features have yet been implemented. The port is still
under active development, and most/all of the Codename One platform features will be implemented over the
next few months. If you build an app and it doesn’t work, it is likely due to a feature not being implemented yet.
I have created a Project Status page for the project to record
the status of each feature.
The goal is for this port to work in all modern browsers, but development has primarily occurred on Chrome,
Safari, and Firefox (on the desktop), with mobile testing on Android’s Chrome browser and iOS’s Safari browser.
Once all of the features are complete, I will focus on ensuring support for the other major browsers (i.e. IE).
When I first started working on the port, I didn’t know whether it would even be viable, performance-wise. I feared
that we might finish the port and find that the interface was sluggish, unresponsive, and clunky. The single-threaded
main thread to lock and block the UI, causing the dreaded “This page is unresponsive” alert in the browser.
I am happy to say that our fears were unfounded. Performance, on the desktop, seems comparable to the current
JavaSE port – and in some cases it is even better. The true test of performance, however, is on mobile devices.
On newer devices (e.g. iPhone 6, iPad Air 2) the port is quite responsive; Animations and transitions are smooth –
though not quite as smooth as in the iOS port. On the previous generation of devices (e.g. Nexus 5, Nexus 7),
I would describe the port as “usable”, but animations and transitions are a little jerky. As we move into even older
devices, the apps remain usable, but the slow responsiveness, animations, and transitions become more
So… at present, your apps should work very well in desktop browsers and quite well in new mobile devices.
The Secret Ingredient: TeaVM
had been working for years on solutions to try to add threading to the browser, but no full solution existed. And
Codename One needed a full solution. It needed all of the bells and whistles of Java’s threading features:
The turning point was when Alexey Andreev told me that he had a way to support threads in TeaVM
using a sophisticated transformation of the Java code into continuations. This break-through was nothing short of
amazing, and it paved the way for Codename One in the browser. One of the most surprising things is how
performant TeaVM is able to be despite these transformations. Alexey has taken great care, each step of the way,
have shown the code to be as fast or faster than GWT on the same code – though we can’t really test that on
Codename One since GWT doesn’t support threads – and thus can’t run Codename One.
Shai always reminds me to just take this one step at a time, and not to get ahead of myself. But let’s cast that
aside for a moment and ruminate on the future potential of Codename One now that it can run inside the browser.
I believe that Codename One is currently the closest thing to an heir-apparent to Swing that exists; and indeed
the API is quite similar to Swing. It was carefully crafted to be easily portable to other platforms. Many suggested
features or APIs have been rejected by Codename One because they wouldn’t be portable, or wouldn’t fit into the
Being able to run inside the browser opens up a whole array of possibilities for us Codename One developers.
Enterprise applications that must target the “web first”, can now be written entirely in Java. No more messing
provide native application bundles for users that require the enhanced experience of a native app.
This port could also provide a gateway to some of the more niche platforms like Firefox OS and Chrome OS
where the small user-base makes it hard to justify a full native port.
Ultimately, the future direction will depend on you, the developers who are using Codename One to realize your
creative solutions. How do you see web deployment fitting into your development cycle? How can the port be
improved to meet your needs? We want to hear from you.
which means you can’t connect to a server other than the one the app was delivered from. Since resources
by just opening a file. So you can’t download the build result zip, extract it and run it in your browser, you
need to place it in a webserver for it to work.
As part of that work we also included a special servlet that will allow you to open a connection request to
any destination. All requests will be proxied thru that servlet and thus allow you to connect to any domain
you choose seamlessly.
However, we wanted developers to be able to preview their build results easily without requiring a specific server
setup. To that end we generate a monolithic HTML file build result that we provide as a “preview” that you can
open using the QR code or preview link as a result of the build. Its not as optimized as the actual result but you
can see it instantly without setting up a server.
technology. Once the port enters beta status it will become an enterprise only feature since it was the funding
from enterprise customers that allowed this work to happen.
Continued support from enterprise accounts is crucial for the growth of Codename One, it will allow us to build
more offerings such as this and expand/bolster our existing offerings.
Have you got any demos that can be downloaded ?
Good point. We will add some demos to the website.
Great work !
As it provides a J2ME layer, It could avoid to write a specific port for IO and graphic primitives.
Nevertheless, not sure the project is as mature as TeaVM
I wasn’t familiar with that project. Interesting.
Either way I think the TeaVM approach is probably superior in terms of compatibility to newer Java language features rather than CLDC limitations, good to know about it regardless…
It is good to see js support but if it is only for the enterprise (the “rich”) customer, it is not so good (bad for biz)
Enterprise subscribers paid for this port so it wouldn’t exist without them.
More enterprise subscribers == more developers == more features and capabilities for everyone.
So its great this is an enterprise only feature as it will make some developers upgrade and make us a stronger/larger company. Even if you can’t afford this particular feature I’m sure you can benefit from that.
hope u hv a lot more enterprise cust than professional cust for i am abt to sub as prof. enterprise is bit too much for now.
Hi, Because of “same origin policy”, if my js apps need to do http request to origin server, should I hardcode the server domain/ip inside the apps? If not, how do I open the http request?
ConnectionRequest r = new ConnectionRequest();
r.setUrl(“http://www.abcdefg.com/hello.php”); // Possible not to hard code the domain name?
* Can I ask here? Or where should I?
You can also use pro support if you signup for pro.
Can I use the Display.getInstance().getProperty(“[browser.window.location.host](http://browser.window.location.host)”, “DEFAULT”) to get the host/domain name? I tried, but it just return “DEFAULT” ..
Still not implemented?
Why do you you expect that to be in Display?
Thanks, I am clearer now. Have to go through the developer guide again.