File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Writing into DB File Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Writing into DB File" Watch "Writing into DB File" New topic

Writing into DB File

Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Hi, I am implementing my update method in my Data class, and I had a question about writing bytes into the file, that is, overwriting bytes (updating the record). Here is my code:

Basically, here's what happens. It reads through the data[] that was passed into the method. If it is null, I skip the value, meaning, do not update that field. Otherwise, it writes the bytes of data. It checks to see if there were any leftover bytes in the field length. Here is what my doc says when referring to the fields:
All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field.
So my question is, how do I write null terminating values into the field if there are bytes left over in the field? Thanks for your help!

SCJP 1.4<br />SCJD 1.4
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11776

Hi Daniel,

All the assignments seem to state that the fields are null terminated. However none of the provided data files contain null terminated fields.

This is the sort of thing you can experience in the real world, where the person writing the specification thinks one thing should be happening, whereas the person writing the other pieces of software expects another thing.

You might be interested in reading the topic "URLyBird 1.3.3 data file: Reply from SUN" for some thoughts on what to do / how to handle this.

On an unrelated topic, have you considered multi user performance in your code? All the code you have listed above must be in a synchronized block or synchronized method, and there are quite a considerable amount of work happening there. No other client could be reading or writing the file while that happens. As an alternative, you could try something similar to:This requires two synchronized blocks to achieve the same thing, but the major work is done in the "modify buffered record according to requirements", during which time other threads (clients) can be reading and writing other records. This would give you greater concurrency.

You might also want to reconsider your naming conventions. dbReader.writeBytes(data[i]); is a bit counter-intuitive .

Regards, Andrew

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Hi, Daniel. I remember pondering over the null-terminated requirement until it hit me that another report application is using the same file for reports. Now, supposedly they are only reading the data, but even then, the fact that the entries are not null-terminated suggests that application may not know how to read null-terminated entries properly... So I think in retrospect this is one of those things Sun injected quite on purpose to test how one deals with supposedly contradictory requirements and reality, but at the same time, they did provide the clue - the report application.

However, when I was actually deciding on this, let me tell you, I had a lot of doubt. This is generalizable: I had a lot of doubt on many things that seemed to address particular details of the implementation. But 1) documenting the choice helps, and 2) there could be clues interspersed in between Sun's requirements for most of these uncertainties.

Hope this helps.
[ November 26, 2004: Message edited by: Anton Golovin ]

Anton Golovin ( SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
I agree. Here's the link:
subject: Writing into DB File
It's not a secret anymore!