Daniel John Debrunner wrote:
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.
I don't think we should regress and I don't think we should have
classpath ordering issues (sorry if my rambling mail last time was
misleading). I think that means I would vote for option 2 if we proceed
with code sharing which means no change from a customer
perspective--same number of jars and no ordering issues.
