We just released an updated NetBeans plugin (Eclipse coming soon) yesterday, it includes one of the bigger changes yet to our architecture: Support for a subset of Java 5.
This effectively means we will enable you to use a large portion of java.util's collections as well as generics, enums, for-each and many other features of Java 5 as part of building an application that will still work on RIM/J2ME devices (and obviously iPhone, Android etc.).
This support is complicated and isn't without its faults/limitations, I ran into some issues with anonymous inner classes that aren't recognized by the bytecode processor. We are working on resolving these but it isn't trivial.
To use Java 5 features you will need to either create a new Codename One project or copy the CLDC jar from a new project to your current project and update the source level in the project properties. You will also need to copy the build XML from a new project to replace your existing build.xml.
Additionally we now have builtin crash-protection support available for paying users (we limit this to paying users due to cloud server costs). You can use the crash-protection code by using something like this:
Log.setReportingLevel(Log.REPORTING_DEBUG);
DefaultCrashReporter.init(true, 2);
This will effectively check every two minutes if there is a change to your log data and if so send it to the server which will email you a link with the log content. Alternatively you can use Log.REPORTING_PRODUCTION to indicate that you only want the log when explicitly sent or with uncaught exceptions. A log can be sent using the Log.sendLog() method.
In order to write information to the log one needs to use the API Log.p(String) or Log.e(Throwable) etc.
Most mobile platforms don't support great Java features like printStackTrace(OutputStream), even those that do (well done Android) don't work well with obfuscated code.
That is why we allow the "crash_protect=true" build argument (again works only for paying users) this will effectively allow a form of poor mans stack traces that work well on all devices even with obfuscated binaries.
We call them "poor mans stack traces" because they don't provide the accuracy and detail of the "real" java stack traces, however they still allow you to trace a stubborn exception that is only reproduced on the device (which unfortunately is something unavoidable for some cases). The stack traces contain only methods that are a part of Codename One e.g. if we invoke a Java API that is not a part of Codename One it will not appear in the stack. Line numbers etc. aren't included in the stack.
Unfortunately this functionality doesn't come cheaply, performance is noticeably impacted by crash_protect at the moment which means we can't use it for production (using logging is just fine though). For now this is mostly practical for debugging, but we intend to improve the performance of this feature as we move forward and make it viable for production systems as well.
