The hardware and bandwidth for this mirror is donated by dogado GmbH, the Webhosting and Full Service-Cloud Provider. Check out our Wordpress Tutorial.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]dogado.de.
My own experience with document preparation has been in part an exercise in locating references lost under a stack of papers in some office of mine. I have found that I waste a lot of time looking for that perfect reference, and often just give up in the search. To make this situation a little better, I have tried to write a reference manager. The first incarnation was a simple database under MicroSoft Access. This was O.K. for storing the information, but rather useless for anything else. When I began to use LaTeX, I found that the Access program was just a waste of hard disk space, as I ended up working in Linux. Thus began my attempt to build a nice GUI front end for BibTeX.
The first incarnation of JavaBib was a command line based processor that could search and modify databases. I stuck some GUI components on top of this, but overall it was not all that effective. A second pass was built from the ground up to be a GUI application. It was somewhat better, but remained a little buggy. Rather than fix the bugs, I vowed to develop a third version that both fixed the bugs and dealt with some issues not appropriately handled in the first version. These issues included the fact that Java can be quite slow when filling memory with arrays of non-native Java objects. JavaBib and JavaBib II both loaded an entire JavaBib file into memory as a vector of BibTeX records. This can be quite slow to load. Since most of the time using JavaBib is simply adding extra entries to an existing file, the speed issue proved to be a great inconvenience.
JavaBib III follows a completely different format. Rather than reading an entire file into memory, it builds an index for the file. This index allows access to specific entries in the file. Once the index has been built, it is all that is loaded for subsequent uses, so long as the underlying data file is not changed. Startup is much faster this way, and most operations are not slowed up too much by accessing the file on the disk. The two operations that are considerably slowed by this approach are finding and searching. However, I think this is an appropriate tradeoff given the other benefits.
At this point, JavaBib displays a blank main window. In front of this window a startup dialog is shown. This dialog lists the names of up to ten previously opened files. You can select one of these, or choose to open a new or unlisted file. Once it has a file name, JavaBib checks to see if there is an index file to go along with the file you selected. Index files have the extension '.bdx'. If it finds an index file, the index information is loaded. The index file stores the last modification time and file size of the BibTeX file to which it refers. If these match the conditions of the file, then the index is used to locate the first entry, which is displayed in the main window.
If an index file is invalid or cannot be found, then JavaBib will construct one. To construct an index, JavaBib reads the entire BibTeX file. The index contains the file position of the first character after a valid record, the key of the next record in the file and the key of the last record in the file. Once the index is built, then the first record is displayed. If the file itself cannot be found, then a new file is opened and made ready to receive records.
Records are copied from the file to the display panel. One copy is maintained in memory, and another displayed. When the user chooses to add a new record or display a different record, the information in the display panel is converted into a BibTeX record which is compared to the one in memory. If they do not match, then the user is asked about saving the changes. Before saving, the record is checked for validity. All required fields must contain information, and the record must have a unique key. If there is a cross reference entry, it must exist and it must not be nested.
When writing new entries or changes, these are appended to the end of the file. For records that have been changed, the record in the file is deleted. Deleting an entry consists of replacing its information with a line of '%' symbols. TeX and BibTeX consider the '%' as a marker for comments, and thus ignores these lines. If the new record contains a cross reference entry, then the information for the cross reference is deleted from the inside of the file and rewritten at the end of the file. This operation is required to ensure that any entry which is referred to in a cross reference appears after the reference. Also, when a referenced record is moved, the field 'BOOKTITLE' is added. Clearly, using cross references extensively will result in a file that is full of empty records. To clean up such a file, the compress operation recreates the file and removes any extraneous material between records. Since BibTeX records are written to the file with each edit, if JavaBib does crash, only the record being worked on will not be recorded. All previous work will have been added to the file.
Search and find operations proceed through the file. Find operations move forward from record to record as they are displayed in the list on the left side of the main window. Since the alphabetical list need not reflect the order in the file, this operation involves much disk access. The search operation is a little more efficient. It begins by constructing its own index with the keys ordered by file position. The search then begins at the beginning of the file and reads forward through this index list. The file pointer is always moving in one direction. If the system on which JavaBib is run reads ahead and buffers disk information, this search should not be too slow.
Cutting, copying, and pasting records is done via a clipboard. On a Windows system, the system clipboard is used. Thus, the text representation of BibTeX records can be copied and pasted between JavaBib and other applications. Note that this can be dangerous if information being pasted into JavaBib does not conform with the required BibTeX record format.
When JavaBib shuts down, it closes the BibTeX file. It then reads the last modification date and file size which it stores in the index file. The index file is written to the disk as a text file. Once completed, the window is closed. On exiting the program, the parameter file is written to the disk.
Note: You may need to right click on the link and then select 'save link as' to get the download to work.
These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.
Health stats visible at Monitor.