This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: class.forName() and java.sql
- From: "Erik Poupaert" <erik dot poupaert at chello dot be>
- To: "Fernando Lozano" <fernando at lozano dot eti dot br>
- Cc: <java at gcc dot gnu dot org>
- Date: Mon, 27 Jan 2003 17:30:34 +0100
- Subject: RE: class.forName() and java.sql
>>>> I never tried this trick with JDBC Drivers, but it
>>>> worked for other classes I had to load using Class.forName().
I've actually linked the entire rdbserver into the application, not just its
driver; and I'm connecting in-process to it; not through a network protocol.
Eventually, I'd like to expose a network-based API that internally works
with an embedded sqlserver. The clients can't retrieve data through SQL
directly. They use the server network API. I'm not sure I will use hsql
(maybe, I'll switch over to libmysqld).
Adding the line:
private static Class c3 = org.hsqldb.jdbcDriver.class;
forces GCJ to link this class (and the classes it refers to itself) into the
statically-linked executable, and ensures that the line:
mConnection = DriverManager.getConnection ("jdbc:hsqldb:" + DBFILE, user,
pwd);
works as expected.
>>>> So you should compile it's driver to the shared library
>>>> "lib-org-hsqldb.so".
The shared object's name doesn't have any effect, apparently. It's the fact
that you dynamically link to this library, that seems to force GCJ to expose
all symbols in the .so. In the case of statically linking, GCJ seems to
clean up all unused classes. As far as I'm concerned, that's perfect. I
wouldn't want it differently. I just didn't know it, until Lars pointed it
out to me.