gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Andrew McIntyre <>
Subject Re: derby build
Date Mon, 24 Jan 2005 11:22:38 GMT

On Jan 24, 2005, at 12:49 AM, Stefan Bodewig wrote:

> Seems you are using a
> different address for sending than you've subscribed with.

That does explain some of my problems. That will hopefully be fixed on 
my end going forward. :)

> By now you can rely on Gump running on JDK 1.4+.
> Does the build process always build against the different runtime,
> even if they are not present at all?  How?  Do you ship with JDBC
> interface classes for them?

That is a complicated question. Currently the build process for Derby 
expects multiple versions of the runtime classes to be accessible (but 
not in the classpath simultaneously). The compilation classpath is set 
in the buildfiles explicitly to reflect which version of the JDBC 
interfaces need to be accessible at any given time. Also, derby.jar 
ships with multiple versions of the same interface and the correct 
version is chosen at runtime.

To elaborate:

Short answer: The build process requires that both JDBC 2.0 (JDK 1.3) 
and JDBC 3.0 (JDK 1.4) versions of certain interfaces be present at 
specific points in the build process in order to build all the 
necessary classes needed for the product jar file. The build process is 
not currently able to handle the situation where one of those 
interfaces is not accessible. The classes for both JDBC 2.0 and JDBC 
3.0 implementations are shipped in the same product jar file, and the 
correct classes are chosen at runtime depending on the version of Java 
running Derby at that moment.

Long answer: There are implementations of both the JDBC 2.0 and JDBC 
3.0 interfaces in Derby. These public implementations use internal APIs 
to perform the work that is requested through the public 
implementations. At the moment, the JDBC 3.0 implementations are 
extensions of the JDBC 2.0 implementations, which means that the JDBC 
2.0 implementations must be correctly compiled before the JDBC 3.0 
implementations. Also, because users expect Derby to be compatible with 
both JDBC 2.0 and JDBC 3.0 at runtime, it is important to provide the 
proper version of both JDBC interfaces at runtime. Which means 
packaging all supported versions of those interfaces in the same jar 


Please allow me to pick this up tomorrow, at a more forgiving hour. :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message