db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Single JDK14 compile model?
Date Sat, 05 Mar 2005 01:14:24 GMT
If the current situation (as I am beginning to understand) prevents us 
from taking advantage of numerous JDK 1.4 and 1.5 features, then I think 
this going to become more and more of a burden.  As well as what Jeremy 
mentioned, there is exception chaining, and NIO support, and others I'm 

If the current situation also constrains our ability to add features 
because we're worried about overall size of the JAR for J2ME, this is a 
problem too. 


Jeremy Boynes wrote:

> Daniel John Debrunner wrote:
>> The trick I then use is to modify the class file sometime after
>> compilation to mark it concrete by modifying the byte code in the .class
>> file (using Derby's class file utilities). This does not cause any
>> problems with the JVM (though there are some issues with the current
>> version of jikes that Derby uses).
> This really really worries me and I am very uncomfortable with it.
>> So is this direction ok for Derby? Along with Jeremy checking in the
>> Apache jar files required by Derby, it would make downloading and
>> compling Derby much easier.
>> Looking at the two approaches, here are the trade-offs:
>> Mulitple JDKs
>> + enforces correct sub-setting at development time, enforced by the
>> compiler, e.g. correct methods in JDBC implementations, not using JDK
>> 1.4 classes in a JDK 1.3 environment, not using non J2ME classes in J2ME
>> code.
>> - tricky (maybe impossible with J2ME) to work with Gump
>> - tricky for the developer to get started on Derby
>> - J2ME libraries not (easily) available
>> Single JDK
>> - correct implementations only enforced by testing in the given
>> environment, e.g. JDK 1.3 J2ME.
>> - requires more awareness for contributors working in the code
>> (e.g. not to use JDK 1.4 classes in code that might be used in J2ME).
>> + simple for Gump (hopefully)
>> + simple for the developer to set up
>> Comments?
> A lot of the problems here arise because we are trying to support 3 
> different JVM revision levels with one output JAR. Is this time to 
> consider generating multiple output JARs, one for each VM?
> This would also allow us to tune the implementations for each VM 
> configuration e.g. eliminating code entirely for features not 
> supportable/wanted in J2ME environments (reducing the code footprint), 
> replacing SANE/INSANE with assertions in 1.4 and up, native support 
> for regex using j.u.regex from 1.4, or leveraging features only 
> available in JDK1.5 such as j.u.concurrent?
> The testing burden for this is no different as production releases 
> would need to be tested on all VMs anyway. It is a higher burden for 
> developers as fixes would need to be done in all code-lines (assuming 
> some divergance).
> -- 
> Jeremy

View raw message