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 file.
...
Please allow me to pick this up tomorrow, at a more forgiving hour. :-)
andrew
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
