David, it looks good. Just a few comments.

* Regarding "Mixed Version Support", it might be good at some point to elaborate on "As much as possible, two applications should be able to use different versions of Derby within the same Java VM without having to resort to creating specialized classloaders." - Were you referring to 2 different Derby engines or/and Clients or/and mix of the 2 running in the same JVM? If an application is expected to run at a certain level of Derby and it is not because of class order loading issues which could cause the application not to use the appropriate level of Derby classes. Depending what the statement meant I don't think we can completely rule out specialized class loaders to isolate loading of a specific and expected level of classes for certain configuration. More clarifications on what the statement meant to say would be nice...

* As a guideline, we should try to have the <ComponentName>Info class at the top level of the package for that component (in the case of Common component, one would expect to have the class be defined under the org.apache.derby.common package. I may have missed this being mentioned in the proposal.

* Would be nice to run JVM / Derby incompatibility test harness suite when a new 'common' class is introduced (not just a new package).

+1

--francois


Reply via email to