Our current IntelliJ/IDEA plugin is seriously behind the times. In our recent survey it was very easy to spot
IDEA developers who were significantly less satisfied with Codename One than the rest of the developer community.
The IDEA plugin doesn’t include basic capabilities such as:
Java 8 Support
The New GUI builder
New Default application look/themes/icon
Builtin demo apps
The Generate Native Access functionality
The certificate wizard and a lot of the UI within the preferences
A New Direction
The old plugin was developed by an excellent hacker who did a great job, but even the best code rots when
it is unmaintained. Worse, Jetbrains made some big changes between version 12 and now. The old plugin couldn’t
be compiled on the newer versions and exhibits odd bugs when running on newer versions of IDEA.
We decided to rewrite the plugin from the ground up and discard a lot of the legacy both in terms of the plugin
and in terms of Codename One functionality.
The main goal of this rewrite is reduction in code so we can have a very lean plugin with as much shared code
as possible. For that purpose the templates and builtin files are literally taken from the NetBeans plugin to facilitate
as much reuse as possible and allow for one release cycle to encapsulate everything.
Java 8+ IntelliJ/IDEA 16+
The new plugin will only work on Java 8 or newer VM’s and will implicitly create Java 8 projects.
Supporting legacy project structures doesn’t make sense for the new plugin although you could manually set that
in the generated project, this is probably unnecessary.
This might be the most controversial decision we’ve made with this plugin. Instead of using the native IDE
menu we chose to use the right click menu for a lot of features including our own preferences UI:
This launches a custom preferences UI written using Codename One that looks like this:
The value of writing the preferences UI using the Codename One API is that it makes the maintenance of this
code far easier when compared to IDE specific code. A lot of features aren’t mapped to UI within the plugins
at this time because it’s just too much of a hassle to do this 3x times for every OS/platform. Right now we
have an internal debate on whether this should be the approach we take for all platforms, in the long run I think
this would be superior to using the IDE native preferences UI.
The new preferences also allow us to integrate deeply with capabilities such as the iOS certificate wizard
which has the best most fluent integration in IntelliJ/IDEA. Personally I think it looks modern and better than the
IDE integrated approach.
The New GUI Builder
Support for the new GUI builder is builtin, as the builder is still in beta I’ll leave this as a somewhat “undocumented feature”
until we finish that work. I would like to mention though that the integration injects code directly to the AST and
dynamically updates it when the gui XML file is saved.
Normally the GUI builder updates the sources via the ant task but we could find no way to do this in IntelliJ that
didn’t break basic things.
I’ve made a quick walkthru video of the new plugin, check it out:
Migration & Availability
While we belive this should be maintained across versions we can’t be 100% sure about this. As with all rewrites
regressions probably exist. We will release the new plugin this Friday as part of our standard Friday release cycle.
If you run into regressions we suggest creating a new project with the new plugin and migrating your code/settings
by copying them to the new plugin. Be sure to let us know immediately if you run into such issues.