Java Library for ASCII PLists



The JPList project provides a Java library to parse and build ASCII Property lists to and from Java objects. The design of the API is heavily influenced by the JDOM API, which provides a library to parse and build XML documents to and from JDOM Document objects. However, the JPList API is significantly smaller, since its objective is to solve a much smaller problem.

Java programmers who are looking for a text-based object serialization mechanism that is lightweight and expressive would find JPList useful. Java programmers frequently choose XML as a configuration and text-based serialization mechanism, even though it may be overkill for their needs, simply because tools are available to parse and build XML. Some programmers go to the opposite extreme and choose CSV (comma-separated values), preferring to embed the logic to parse the CSV in their application code. PLists provide a mechanism that is text-based, as expressive and considerably more lightweight than XML, and the JPList library provides the tools to build and parse PLists from ASCII streams, so the programmer is free to choose the right tool for the right job.

The JPList library is small and has no external dependencies. Simply drop the jplist.jar file into your classpath and you have access to an API that is so similar to JDOM that there is almost no learning curve.


What are PLists?

PList stands for Property Lists. It is a data format introduced by Apple Computers in their OpenStep (later Cocoa) frameworks to represent arrays and dictionary objects as structured ASCII text. Apple later abandoned this format in favor of an XML variant of PLists called XML PLists. XML PLists are used in Mac OSX and FreeBSD to represent application configuration, much like .properties files used for Java and .ini files for Windows applications.

PLists can contain four basic types of data structure - String, Data, Array and Dictionary. Each type is formatted in a specific way, as described below:

More information about the PList format (both ASCII and XML) can be found at the Apple Cocoa Developer site.



Here are some (admittedly not very scientific) benchmarks I ran to compare the performance of JPList with ASCII PLists and JDOM with XML PLists. If you have concerns about these numbers, you should run your own benchmarks that reflect your application environment.

The numbers are generated from the BenchmarkTest JUnit test. The File Size columns compare relative file sizes between ASCII PLists and XML PLists to represent identical data. The actual files can be viewed by clicking on the file size links. The Build time columns compare the time in milliseconds to build an internal Java object (net.sf.jplist.core.Document for ASCII PLIsts and org.jdom.Document for XML PLists) from these files. The Output time columns compare the times taken to serialize the internal Java object back to a text string using JPList and JDOM respectively.

List of File Size (#-chars) Build Time (ms) Output Time (ms)
Strings 57 173 33 111 26 19
Data 117 161 2 8 1 0
Arrays 133 432 2 10 0 1
Dictionaries 169 389 3 7 1 2
Arrays of Arrays 173 587 1 15 1 1
Arrays of Dictionaries 137 442 2 11 1 3
Dictionaries of Arrays 223 681 2 8 1 3
Dictionaries of Dictionaries 321 1004 4 33 2 4

Overall, we see that ASCII PLists are approximately 3 times smaller than equivalent XML PList files. Smaller sizes of data mean that more data can be transferred using the same network bandwidth. The time taken to build JPList Document objects from ASCII PLists is also approximately 3-4 times higher than the time taken to build JDOM Documents from XML PLists. The time taken to serialize it back to either an ASCII PList or XML PList is about the same in either toolkit, so there is no significant penalty to using JPList with ASCII PLists with regard to increased computation time to serialize and deserialize.



JPList is distributed under the GNU Lesser General Public License. This means that you are free to use the JPList library as part of a commercial or open source application, without having to contribute anything back to the community. However, if you do contribute back to the JPList project any improvements or bug fixes you have made, they will be gratefully accepted and credit given.




Future Directions/Roadmap

JPList is a fairly stable specification, so I do not see a need to evolve the software along with change in specifications. If you find a bug, or have an idea for new Builder and Outputter classes, either implement them and contribute them, or let me know and I can do it.