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:47:17 GMT
Daniel John Debrunner wrote:
> 
> Also Jeremy said this approach (using modules) would lead to an ever
> growing number of modules, that tends not to be the case, since as I
> think Rick pointed out, at some point environments are dropped from
> support, such as Derby used to support JDK 1.1 and no longer does. Most
> of the split between 1.1 and 1.3 code has been removed.
> 

Sure - but with JDK1.5 we are again reentering an era where there are 
major differences between VM levels. The only bytecode level difference 
between 1.3 and 1.4 was assert which IMHO was not compelling; however, 
with 1.5 we have generics, annotations, changes to String concatenation, 
foreach, autoboxing and more, never mind the changes in the libraries. 
I'm sure JDBC4.0 will use some of these features so what will we do next 
year?

What I also meant by the growing number of modules was that we would be 
using them for features that a good number of users consider optional or 
unnecessary. Back to the example of analytics - wanted by OLAP users, 
pretty much irrelevant to embedded users. Or take JMX support - wanted 
by enterprise users, but 1.3 and 1.4 would require an additional 
library, and it wouldn't even run on CLDC J2ME due to the need for 
reflection. Or spatial - that might be useful in a location aware 
embedded device but not others. Object types - could that reduce the O/R 
complexity in applications? In-tx replication, useful only with a good 
pipe between servers. External security policy definitions? XML data 
types? And so on ...

To me, the number of modules is only going to grow and one-size-fits-all 
is not a good long-term approach.

--
Jeremy

Mime
View raw message