Projects / JavaDBF


JavaDBF is a Java library for reading and writing dBase, Xbase, and dbf files. It does not implement JDBC interfaces, but has a simple API of its own. It is useful if you need to communicate with a legacy application which can read and write only Xbase files.

Operating Systems

Recent releases

  •  01 Apr 2004 08:12

    No changes have been submitted for this release.

    •  11 Feb 2004 14:38

      Release Notes: JavaDBF can now handle optional character sets. No changes were made to the existing parts of the API, but two methods have been added to set and query character sets. A few minor bugfixes were made.

      •  17 Aug 2003 15:40

        Release Notes: 0.3.1 and lower versions could not really handle fields of length greater than 127, though DBF specifications allow up to 255. This has been fixed.

        •  01 Jul 2003 11:43

          Release Notes: A bug on the Reader class, which caused an exception while reading numeric fields with decimal places defined, has been fixed.

          •  23 Jun 2003 15:06

            No changes have been submitted for this release.

            Recent comments

            10 Jan 2005 09:59 anilx

            Re: good api with a small, confusing bug?

            I'm surprised to hear that my email ID is not working!

            I'm working toward to unify it. Later versions of DBF talks about two types of numeric fields: Numeric and Float. Of which Numeric is more versatile and can hold really big values. So I mapped it to Double (the biggest available in Java) and I mapped the Float to java.lang.Float.

            The documentation in DBFReader.html seems to be incorrect; I'll correct it in my next release --which is due with memo field support.

            Lately I heard from a user saying that he needs BigDecimal to hold the values of a Numeric field.

            Thanks for pointing it out. Send your mails to anil at linuxense dot com because I seldom check my freshmeat page.



            07 Dec 2004 16:59 wagnerstefan

            good api with a small, confusing bug?
            Hi hanil,

            Your email seems not to work, so I post here...

            I'm glad to be able to use your api.

            I have to work on a project which uses some kind of dBase-Files, to store data - don't know which version, but one tool (dbview 1.0.0) reported version 4.8 for one file (and refused to open it).

            There are hundrets of files, and on work I have to use WinXp, which isn't much fun. So I looked for an API and found yours (beside others) on freshmeat.

            Your api was easy to use, well enough documented to step into, and opened every silly file.

            Excel and Access refused to open some of them, and I was a little suprised, to find such a small project being able to open them :)

            I wrote a small Swing-Gui/ JTable - Viewer, using your API, to view the files, and will release it to the public too, when a little more documentation is done, and some private comforts for me (where to look for the files) are eliminated - aka: replaced by a common possibility, to do so, without recompiling.

            One thing is wondering me: The differece between N and F Fields:

            In 'javadbf-0.4.0/doc/javadbf-tutorial.html' you tell:


            3.1. Data Type Mapping

            In version 0.3.2, JavaDBF supports almost all XBase data types except Memo field. While reading, those types are interpretted as appropriate Java types. Following table shows the mapping scheme.

            XBase Type XBase Symbol Java Type used in JavaDBF

            ---------- ------------ ---------

            Character C java.lang.String

            Numeric N java.lang.Double

            Double F lava.lang.Double



            But in 'javadbf-0.4.0/api/com/linuxense/javadbf/DBFReader.html' you tell:


            The nextRecord() method returns an array of Objects and the types of these Object are as follows:

            xBase Type Java Type

            C String

            N Integer

            F Double



            Finally in '' we find the truth:


            case 'F':

            // ...

            recordObjects[i] = new Float( new String( t_float));

            // ...

            case 'N':

            // ...

            recordObjects[i] = new Double( new String( t_numeric));

            // ...


            Without knowing any internals of the dbX-Format, I changed it to:

            use Double instead of Float for 'F'-Datatyp, and

            use Long instead of Double for 'N'-Datatyp,

            because I was confused by seeing all the numeric data layed out as Double in my JTable (0.0, 3.0 where 0, 3 was expected).

            It seemed to work for the few files I opened.

            Perhaps float and integer are big enough - I only tried to use the most secure fast solution. And I don't expect to find a value to big for a float or int in my data.

            If you like to explain something I will lend you my ear.

            I would be happy to get a reply.

            Thanks for your patience.


            Project Spotlight


            A Fluent OpenStack client API for Java.


            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.