$Id: FAQ.html,v 1.1 1998-03-06 14:54:44+10 mbp Exp $
Home page | email@example.com
This is not an official publication of Pharos. There is no warranty of any kind on this software or document.
No. JDBC seems mainly intended for interfaces to relational databases, and GDBM is not a relational database.
However, JDBC does permit use of a subset to interface to non-relational databases. Implementing this might be interesting: let me know if it's useful to you.
No, JavaGDBM is intended to store on-disk hash tables. They solve a different class of problem to that appropriate for SQL and relational databases.
Broadly, options for data storage in Java include
Make sure you choose the right tools: there is no single `best' answer.
No. I understand that GDBM is still maintained by the FSF.
It should, but I haven't tried it. You'll need a C compiler to build the native library. Let me know if you try.
The test harness may report messages such as
caught: au.com.pharos.gdbm.GdbmException: File open error: No such file or directory? (gdbmjava.c:101)
These are expected exceptions: the test harness is making sure that exceptions are thrown when they should be.
GdbmFile.h is build by javah when the library is built.
Personally, I recommend the excellent Java series of books from O'Reilly and Associates and the Javasoft/Addison Wesley books.
If you find a bug, either have a look at the code yourself, or send e-mail to firstname.lastname@example.org. There's no warranty on JavaGDBM, but I will try to respond to your mail and problem.
Hi, I'm hoping to use your JavaGDBM api for my application, but I'm having some problems compiling the libgdbmjava.so. Here is a partial listing of the errors: gcc -o libgdbmjava.so -shared gdbmjava.o -lgdbm Text relocation remains referenced against symbol offset in file free 0x258 /usr/local/lib/libgdbm.a(gdbmreorg.o) free 0xd0 /usr/local/lib/libgdbm.a(gdbmclose.o) free 0xb8 /usr/local/lib/libgdbm.a(gdbmclose.o) free 0x218 [snipped] I have used the libgdbm.a lib before, and don't believe there is a problem with it. I'm compiling to Solaris 2.6, using JDK 1.1.4.
The solution turned out to be that the gdbm native library must be compiled with the -fpic flag to cause the compiler to generate position-independant code.
Access will be denied until the writer releases its lock.
JavaGDBM uses a shared-read/exclusive-write protocol at the OS level. However, multiple Java threads can access a file concurrently.
It should run on any platform that supports JDK1.1 or higher, JNI (Java Native Interface), and GDBM. JavaGDBM is known to run on
If you have any information on other platforms, please let me know.
It's on the `long-term' TODO list. I'd like to do it, but don't have any date in mind.
Everybody who's sent in questions or comments.
Redhat and Javasoft, and the authors of GDBM, Linux, gcc, autoconf, and other software used in building JavaGDBM.