java 1.5 - generics "unchecked cast" suppression

Thread view:

Steven Buroff - 26 Sep 2004 14:51 GMT

Is there a way to suppress the "unchecked cast" message for a particular
statement rather than an entire file. There are times when you can't really
avoid the cast. In my case, I'm reading back in a previously serialized
object. I need to cast it. Thanks in advance.

Steve

Reply to this Message

Paul Lutus - 26 Sep 2004 18:03 GMT

> Is there a way to suppress the "unchecked cast" message for a particular
> statement rather than an entire file. There are times when you can't
> really avoid the cast. In my case, I'm reading back in a previously
> serialized object.

The answer is simple -- do not try to use serialized data from a prior
version of Java.

You may wonder, if you cannot use data from a prior version of Java, why
there are serialized objects in the first place. That's a good question.

1. Save only data of the most temporary, volatile kind, disposable data, in
serialized form.

2. Never save important data, data that must persist, in serialized form.
For actual data, data of any consequence, data you would prefer not to
lose, use plain-text format.

Signature

Paul Lutus
http://www.arachnoid.com

Reply to this Message

Steven Buroff - 27 Sep 2004 00:31 GMT

This is actually serialized data from the current version of java.
I'm saving arbitrary objects using java.util.prefs.Preferences.
I do it by writing the object to a ByteArrayOutputStream and
then using Base-64 encoding to get a string. It seems to work
fine. The restore works fine too except for the warnings.
Comments or suggestings? Thanks.

Steve

> > Is there a way to suppress the "unchecked cast" message for a particular
> > statement rather than an entire file. There are times when you can't
[quoted text clipped - 13 lines]
> For actual data, data of any consequence, data you would prefer not to
> lose, use plain-text format.

Reply to this Message

Paul Lutus - 27 Sep 2004 08:17 GMT

> This is actually serialized data from the current version of java.
> I'm saving arbitrary objects using java.util.prefs.Preferences.
> I do it by writing the object to a ByteArrayOutputStream and
> then using Base-64 encoding to get a string. It seems to work
> fine. The restore works fine too except for the warnings.
> Comments or suggestings?

Same comment. Don't use serialized objects.

Signature

Paul Lutus
http://www.arachnoid.com

Reply to this Message

Steven Buroff - 27 Sep 2004 13:57 GMT

> > This is actually serialized data from the current version of java.
> > I'm saving arbitrary objects using java.util.prefs.Preferences.
[quoted text clipped - 4 lines]
>
> Same comment. Don't use serialized objects.

Easy to say. How do you suggest I save objects as preferences (eg. Colors,
Fonts, etc.)?
I think there is a Java 1.5 problem here. There should be some
way to indicate that the cast is OK or a method to call where I can
specify the class to cast to as a separate argument. It could fail or
throw an exception if the cast is wrong.

Steve

Reply to this Message

Stefan Schulz - 27 Sep 2004 15:12 GMT

>> > This is actually serialized data from the current version of java.
>> > I'm saving arbitrary objects using java.util.prefs.Preferences.
[quoted text clipped - 7 lines]
> Easy to say. How do you suggest I save objects as preferences (eg.
> Colors, Fonts, etc.)?

Break Color down into its three valences (or HSB of you care for it),
save these in a Properties object. Use the storeToXML method in the
Properties Object to save, and loadFromXML to load. Recreate your
Color from the String representation. Same goes for Fonts. Get
the Font's name and size, store these as strings... You see the
pattern? ;)

Signature

Whom the gods wish to destroy they first call promising.

Reply to this Message

Steven Buroff - 28 Sep 2004 14:06 GMT

> >> > This is actually serialized data from the current version of java.
> >> > I'm saving arbitrary objects using java.util.prefs.Preferences.
[quoted text clipped - 14 lines]
> the Font's name and size, store these as strings... You see the
> pattern? ;)

Yes, I see the pattern but I certainly don't like it. The problem is that
I need special code for each object I want to save. But I'm building a
package for others to use. I don't know anything about their classes.
I think its OK to require the classes to be serializable. Requiring them
to write some sort of "toTextString/fromTextString" methods doesn't
seem reasonable.

In addition, I'm using Preferences (java.util.prefs.Preferences), not
properties. there is no XML support there.

Steve

Reply to this Message

Stefan Schulz - 28 Sep 2004 14:15 GMT

> I think its OK to require the classes to be serializable. Requiring them
> to write some sort of "toTextString/fromTextString" methods doesn't
> seem reasonable.

Requiring them to be Serializable is actually a rather strong requirement
if you
_mean_ it. Just typing "implements Serializable" is by far not sufficient
to
actually make a working implementation. In fact, you at the very least
force
them to think about two Methods: readObject() and writeObject().

> In addition, I'm using Preferences (java.util.prefs.Preferences), not
> properties. there is no XML support there.

In that case, let me introduce you to the beautiful Method called
exportSubtree(OutputStream os) in the Preferences class. :) It does just
that.

Signature

Whom the gods wish to destroy they first call promising.

Reply to this Message

Paul Lutus - 28 Sep 2004 17:06 GMT

/ ...

>> Break Color down into its three valences (or HSB of you care for it),
>> save these in a Properties object. Use the storeToXML method in the
[quoted text clipped - 5 lines]
> Yes, I see the pattern but I certainly don't like it. The problem is that
> I need special code for each object I want to save.

No, this is false. Using an approach based on reflection, you can parse a
wide range of objects expressed in object form, and recreate the original
objects. The reason? Most Java objects are expressed by toString() in much
the same way. As I said earlier, I have a class that uses reflection to do
this for the general case.

> But I'm building a
> package for others to use. I don't know anything about their classes.

How exactly is this an argument for direct object serialization? You haven't
said whether your users will be changing Java versions sometime down the
road. That will kill off all their previously saved serialized objects in a
stroke, but text form will not. And if the objects might be communicated
between Java versions, them you very simply must not even consider direct
object serialization.

> I think its OK to require the classes to be serializable. Requiring them
> to write some sort of "toTextString/fromTextString" methods doesn't
> seem reasonable.

No, you have to do that. You're the creator of the class.

> In addition, I'm using Preferences (java.util.prefs.Preferences), not
> properties. there is no XML support there.

Not a problem. You need to realize any difficulties you can name for
text-based persistence are multiplied if you choose direct object-based
persistence.

Signature

Paul Lutus
http://www.arachnoid.com

Reply to this Message

Paul Lutus - 27 Sep 2004 17:11 GMT

Each of these classes has a ToString() method. Writing them is easy, reading
them is only slightly harder.

import java.awt.*;

public class Test {

public static void main(String[]args)
{
Font f = new Font("monospaced",Font.PLAIN,12);
System.out.println(f);
}
}

result:

java.awt.Font[family=monospaced,name=monospaced,style=plain,size=12]

> I think there is a Java 1.5 problem here.

No, there is a serialized-object problem here. Serialized objects are not
provided with sufficient identification to allow their reliable retrieval
-- but that has always been true. The difference is 1.5 broadcasts this
information to the world.

In my line of Java applications, I must save all kinds of user preferences.
I save them as text, I then read the preferences back from the user file.
This means users of my applications can download a new version with the
expectation that their prior saved preferences will be correctly read and
used.

> There should be some
> way to indicate that the cast is OK or a method to call where I can
> specify the class to cast to as a separate argument. It could fail or
> throw an exception if the cast is wrong.

Yes. Or you can save yourself months, possibly years, of effort and
heartache by saving your objects in a more reliable way.

Signature

Paul Lutus
http://www.arachnoid.com

Reply to this Message

Steven Buroff - 28 Sep 2004 14:06 GMT

> >> > This is actually serialized data from the current version of java.
> >> > I'm saving arbitrary objects using java.util.prefs.Preferences.
[quoted text clipped - 25 lines]
>
> java.awt.Font[family=monospaced,name=monospaced,style=plain,size=12]

There are two problems here. The main one is that I'm writing a package for
use by others. I need to be able to save arbitrary objects, not just those I
know about. I don't think its unreasonable to require the classes to be
serializable but recreating them from the "toString()" representations is
another
matter. I don't know how and I don't think its reasonable to expect my users
to supply that information. I don't even think its always possible,
especially
for arbitrary classes implemented by my users or my users users. Thanks
for the suggestion though.

Steve

> > I think there is a Java 1.5 problem here.
>
[quoted text clipped - 16 lines]
> Yes. Or you can save yourself months, possibly years, of effort and
> heartache by saving your objects in a more reliable way.

Reply to this Message

Paul Lutus - 28 Sep 2004 16:59 GMT

/ ...

>> Each of these classes has a ToString() method. Writing them is easy,
> reading
[quoted text clipped - 18 lines]
> for use by others. I need to be able to save arbitrary objects, not just
> those I know about.

That is not at all difficult, and I must tell you the problem is worse if
your choose direct object serialization.

Find out which kinds of objects will be saved and write code that will
handle each kind. For my own programs, I have written a class that uses
reflection to solve this general case.

> I don't think its unreasonable to require the classes
> to be serializable but recreating them from the "toString()"
> representations is another
> matter.

Yes, it is another matter. It is the proper way to do this. It is simpler,
it is more robust, it doesn't care about Java versioning changes.

> I don't know how and I don't think its reasonable to expect my
> users to supply that information.

They will have to tell you which specific classes will be handles by the
parser, just as they would haver to tell you in the case of object
sertialization, but for the latter, they also must tell you which Java
versions you can expect, because serialized objects cannot reliably be
transferred between Java versions.

> I don't even think its always possible,
> especially
> for arbitrary classes implemented by my users or my users users.

Then forget about object serialization, and start working on a robust
text-based class for object representation. Anything that is true for
text-based backup is doubly true for object seralizations. Why do you think
XML is beginning to be the preferred form for object persistence?

Signature

Paul Lutus
http://www.arachnoid.com

Reply to this Message

java 1.5 - generics "unchecked cast" suppression

Free Magazines