db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 20:05:48 GMT
Daniel John Debrunner wrote:
> 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

Mime
View raw message