Jeremy Boynes wrote:
In order to support J2ME, JDK 1.3, JDK 1.4 and JDK 1.5 we have to build code that works in those environments, how it is packaged to run is separate.
The challenge we face is taking advantage of the capabilities of each environment; I do not think we want to be constrained by the lowest common denominator. There are features in the later platforms that are simply not available in the earlier ones, features not just in the runtime environment but in the bytecode itself; we can gain advantages by compiling for a specific platform level but the price is a loss of compatibility with prior levels.
In the end it comes down to what users want, and we need to adapt the development process to meet those requirements.
If the most important factor for users is a single jar for all platform levels, then we can continue to do that. Minor issues here are a more complex build and perhaps no integration with Gump (although surely that can be fixed). The big issues though are the constraint of 1.3 level bytecode, code bloat due to multiple implementations, longer development times to provide all features on all VMs, and a huge monolithic project that contains the kitchen sink collection of modules.
On the other hand users may prefer a model where there are jars for each VM platform containing identical feature sets but tuned for that platform. This is going to be a lot of work for developers as we need to implement every feature on each platform, and some will be easier than others. It also leaves users with the kitchen sink problem in that the configuration will contain major modules they don't need/want.
A third alternative is that we make it easy to generate custom configurations and as part of the build make produce the ones that users actually want. For example, one build could be a single-user embedded J2ME with JSR169 containing just core database functions; another a standalone enterprise server with network access, LDAP integration, high concurrency, JMX support, ... These two builds may need to use different JVMs, different bytecode levels, different library classes, and different Derby modules.
I prefer the third option - it provides users with what they want (whatever that is), and we get to choose on a feature by feature basis whether to stick with the lowest common platform, to use all the features of a newer one, or to experiment in the new world and work with users on the effort of backporting. I think this provides a reasonable balance that allows a rapid development process for new features that users want but at the same time continues to support the existing user base.
Above all, let users decide. -- Jeremy
