Chronus Documentation

Documentation

Welcome to Chronus, the user-friendly object persistance layer for Java.

a) What is Chronus?

Chronus is an easy to use Object Persistance Layer for Java objects. Chronus is completely transparent, which means that their is no editing of your code neccesary in order to save your objects.

b) What is a Persistance Layer, you may ask?

Simply put, Chronus can save and load ANY object for you, without you having to worry about any of the details.

c) What can I use Chronus for?

Chronus can save any java object, for example: plain objects, datastructures, beans, and even complete instances of a program.

d) Why is Chronus different than existing solutions?

Chronus differs from existing products in four ways: Chronus is EASY, it's FAST and it requires NO SETUP and it's FREE!

If you would like to save Java Objects there are a few alternatives available, for example:

1. Manually extract the information from the object to be saved and write the information to a database or to a file(s). This approach has several drawbacks. Firstly you will be "reinventing the wheel", because there are already products that can do this. If you are using the database approach you will be faced will the task of database setup and table design, not even to mention all the SQL statements that will have to be embedded in your code. As you might know, string concatenation involved in producing the SQL statements can be quite a resource-intensive operation, affecting the overall performance of your program. If, however, you will be using the file based approach, then you will be faced with quite a different set of dillema's. You will have to choose whether to use one single file or a file for each object. You would have to devise a file format and you whould have to create code to write to and parse from the file. File IO is also extremely slow compared to memory operations.

2. You could use existing Object/relational persistence programs. These programs allow the persistance of objects to SQL tables without the knowledge of SQL statements. The program basically generates the SQL statements for you. The problem is however that although free software is available for this task it requires the objects to be "mapped" to the database. This involves among other things: database setup, table creation and driver registration with your mapping program. Description of your objects and the mapping of their variables to certain columns. This usualy happens with the use of xml files. This requires some knowledge of SQL and XML. Some programs even have their own alternative to the SQL language wich has to be learnt. In my experience this involves a substantial learning curve. This option is still unneccesarily slow because an sql statement is performed for each field inside each object and proves unwieldy in comparison with Chronus.

You could use Chronus. This involves adding the Chronus.jar to your classpath and using it as you would a hashtable. Chronus takes care of the rest!

e) How does Chronus work?

Chronus 2.0 implements the map interface, wich means that its use is exactly the same as the use of any other map-implementing objects, like hashtables and hashmaps.

Chronus stores a object by serializing it into a database and saving it under a its name. When you want to save an object you call the put method with a key and your object. The encoded object is then saved into an autmatically created HSQL database under its key. When you want to load your object at a later time you call the get method, giving it the key to your object, you then cast it to your object type and Voilla! Your object is ready to use.

The only requirement that chronus makes is that all custom objects implement the Serializable interface. This, however, does not involve any actual implementational programming, its simply a process of adding the line "implements java.io.Serializable" to your class definition.

f) How about performance?

Chronus currently uses HSQL for object persistance and is therefore exceptionally fast, averaging 0.5 milliseconds to save a String object and 0.02 milliseconds for loading the same object. This is during multiple saving and loading, which minimizes initial connection overhead. For single saving and loading the initial database connection overhead is higher although performance is still very fast.

g) Isn't this too simplistic?

Chronus's philosophy is to provide a non-intrusive way to solve the persistance problem. We also believe in extensibility. We are currently working on ways to make Chronus extendable while providing default implementations so you do not have to worry about details if you don't want to...