Kathy Saunders wrote:
> > Thank you very much for the clear explanation. From a usability > perspective, I would vote for approach 2. Requiring a classpath to be > in a particular order is always an issue. However, the saving grace is > that it sounds like the ordering issue only comes up if you mix versions > of the derby.jar and the derbyclient.jar in the same classpath. I don't > believe most users put the client and engine in the same classpath > (unless there's a new requirement I don't know about), so that > definitely helps. Requiring classpath in a specific order can easily > lead to complications though, so I'm not in favor of it in general. Derby's client and engine may be in the same classpath and at different versions if the JVM is hosting more than one application, or the application installers have modified the system/user's classpath to add their required jars. The issue is that today this is fully supported because the client and engine do not share code. Some of the code sharing approaches regress Derby in this area by not supporting this, or require class path ordering for it to be supported. While it is true that multiple class loaders solve the issue, this approach is not always possible, I believe, for example, some of the major application servers do not support different class loaders for different JDBC providers (eg. the Derby client at 10.3 and engine and 10.2). Thus the argument really is, are we willing to accept regression in this area to gain code sharing, or should the code sharing solution not regress Derby? Dan.
