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
