I must concur; in the past Derby had a single focus (embedded use) and a 
single set of developers building to that focus.  Now that it's in open 
source, any number of folks will want/need to take it in different 
directions, both smaller (CLDC) and larger (enterprise environments).  
We'd either have to be vigilant about a single focus, risking smaller 
takeup, or the development environment/model will need to adapt to that 
reality...

David

Jeremy Boynes wrote:

> 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