This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]