file w/ multilines?

L

lallous

What is a good way to store ID, Val1, Val2 in a file using Java?

I would use 'Properties', but Properties only understands Key=Value.

Also, Val1, Val2 might contain \n.

Also concatenating Val1+SpecialSeperator+Val2 and storing as:
Id=Val1+Sep+Val2 is another option...

Any suggestions are welcome.
 
C

Chris Smith

lallous said:
What is a good way to store ID, Val1, Val2 in a file using Java?

I would use 'Properties', but Properties only understands Key=Value.

Also, Val1, Val2 might contain \n.

Also concatenating Val1+SpecialSeperator+Val2 and storing as:
Id=Val1+Sep+Val2 is another option...

You shouldn't have much trouble finding a CSV parser/writer for Java.
It would be ideal for tabular data of this sort. If you can't find an
existing library to do this, then I'll post some code for it.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
L

lallous

I was trying to write something small and simple, just to complete my
assignment.
Finally, I resorted to using such structure:

class Entry implements Serializable
{
public String s1;
public String s2;
public int id;
}

Then storing lots of entries inside a Vector (which is also serializable)
then using ObjectInput/OutputStream to write/read the whole Vector.

Btw, does 'Entry' have to implement Serializable? Or just because every
member inside it is serializable then the whole class would be serializable?

Guess this method is okay unless there are inherent problems that can't be
seen by a newbie?!
 
C

Chris Smith

lallous said:
I was trying to write something small and simple, just to complete my
assignment.
Finally, I resorted to using such structure:

class Entry implements Serializable
{
public String s1;
public String s2;
public int id;
}

Then storing lots of entries inside a Vector (which is also serializable)
then using ObjectInput/OutputStream to write/read the whole Vector.
Okay.

Btw, does 'Entry' have to implement Serializable? Or just because every
member inside it is serializable then the whole class would be serializable?

Yes, the class has to be serializable.

The implementation of the java.io.Serializable interface indicates your
*intent* that the data encapsulated by that class should be
serializable... meaning that it's generally independent of location. To
take an obvious example, an object that encapsulates a native file
descriptor number should not be declared to be Serializable, even though
its only field may be an int, which can be easily serialized. The
reason is that the file descriptor number is only meaningful in the
context of this process, so serializing that data to a file or network
stream would be pointless.
Guess this method is okay unless there are inherent problems that can't be
seen by a newbie?!

Nothing I'd classify as a "problem" per se. There are disadvantages of
course; but any approach you choose will have disadvantages. In this
case, the disadvantages are that the data file will be a little larger
than is absolutely necessary, it won't be easily readable by a human
being (e.g., if you're debugging and want to see what data was written
out), and it won't be very compatible with other applications (e.g.,
getting the data into an Excel spreadsheet or an SQL database is much
harder than it would be from a CSV file).

If you don't need any of that, I'd just go for it and not look back.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
L

lallous

Hello,

Chris Smith said:
serializable?

Yes, the class has to be serializable.

The implementation of the java.io.Serializable interface indicates your
*intent* that the data encapsulated by that class should be
serializable... meaning that it's generally independent of location. To
take an obvious example, an object that encapsulates a native file
descriptor number should not be declared to be Serializable, even though
its only field may be an int, which can be easily serialized. The
reason is that the file descriptor number is only meaningful in the
context of this process, so serializing that data to a file or network
stream would be pointless.


Nothing I'd classify as a "problem" per se. There are disadvantages of
course; but any approach you choose will have disadvantages. In this
case, the disadvantages are that the data file will be a little larger
than is absolutely necessary, it won't be easily readable by a human
being (e.g., if you're debugging and want to see what data was written
out), and it won't be very compatible with other applications (e.g.,
getting the data into an Excel spreadsheet or an SQL database is much
harder than it would be from a CSV file).
I noticed that whenever that the 'Entry' class is changed then the file is
not loadable any longer! that is bad too!
If you don't need any of that, I'd just go for it and not look back.
In worst cases, later a file conversion tool can be written.

Thanks for your help today.
 
C

Chris Smith

lallous said:
I noticed that whenever that the 'Entry' class is changed then the file is
not loadable any longer! that is bad too!

That can be overcome, actually.

By default, a serializable class takes responsibility for ensuring data
compatibility, and it does this by refusing to load serialized objects
whenever the class has been changed. However, you can intervene and
assume that responsibility yourself. When you do so, you need to
guarantee that you won't make any incompatible changes to the class
definition. The definition of an "incompatible" change is rather
complex, but can be found at this URL:

For details on how to assume responsibility for the compatibility of a
class, Google for "serialVersionUID" (which is the name of a static
field you will add to your class to indicate that you've assumed this
responsibility).
In worst cases, later a file conversion tool can be written.

Yes, definitely so. I was mainly speaking to it being inadvisable to
use serialization for a data file that will need to be read by other
applications as a normal matter of course. If that's merely an obscure
possibility, then it can be handled as the need arises.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,056
Latest member
GlycogenSupporthealth

Latest Threads

Top