db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Thu, 15 Sep 2005 02:41:05 GMT
Daniel John Debrunner wrote:
> 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.

In this model, you are assuming that there is a single classpath shared 
by all applications run by the system/user. In this mode you cannot have 
multiple versions of the client or engine present - you can only have 
one version of the client and one version of the engine.

In reality this scenario is useless in anything but the most trivial 
installation. As an application can be impacted by any other application 
that affects the system/user's classpath reliability requires that they 
be isolated from each other. You end up with two modes of operation:

* an application overides the classpath in some script before the JVM
   is started to ensure that only the jars it expects are present
* an application runs inside a server that controls the classpath for
   it and that server ensures the appropriate libraries are present

> 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.

Some of the others support this by defining compatibility contracts and 
eliminate the need for classpath ordering by not duplicating classes.

> 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).

Those application servers also define which versions are supported by 
the application server vendor. They also do not support client 10.2 and 
client 10.3 which is an equally likely combination.

> 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?

Let's recharacterize this a little. What we are contemplating with code 
sharing is extracting common functionality out into a library. By saying 
that we are not willing to accept any solution where a component depends 
on a library we are shutting ourselves off from using any external 
library or any functionality not provided by Derby itself. This dooms us 
forever to reinvent any functionality that could be provided by other 

For example, there are libraries out there that support bytecode 
generation, JMX for management, high-performance concurrency on Java 
1.4, regexp processing to support SQL patterns, ... By saying we are not 
prepared to incorporate them but instead need our own versions that can 
be morphed for client and server we dramatically reduce the 
functionality that can be made available to users.

So let me ask this: do our users want more functionality faster by 
allowing the use of libraries, or a completely standalone solution with 
tight control over the entire implementation?


View raw message