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
