java 1.5 - generics "unchecked cast" suppression

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

Steven Buroff wrote:

> 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.

--
Paul Lutus
http://www.arachnoid.com

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

"Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10ldtj138chfg9b@corp.supernews.com...
> Steven Buroff wrote:
> 
>
> 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.
>
> --
> Paul Lutus
> http://www.arachnoid.com
>

Steven Buroff wrote:

> 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.

--
Paul Lutus
http://www.arachnoid.com

"Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10lffjl1fhtg5ce@corp.supernews.com...
> Steven Buroff wrote:
> 
>
> 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
>
> --
> Paul Lutus
> http://www.arachnoid.com
>

On Mon, 27 Sep 2004 12:57:19 GMT, Steven Buroff <sburoff@optonline.net>
wrote:

>
> "Paul Lutus" <nospam@nosite.zzz> wrote in message
> news:10lffjl1fhtg5ce@corp.supernews.com... 
>
> 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? ;)



--

Whom the gods wish to destroy they first call promising.

Steven Buroff wrote:

>
> "Paul Lutus" <nospam@nosite.zzz> wrote in message
> news:10lffjl1fhtg5ce@corp.supernews.com... 
>
> Easy to say. How do you suggest I save objects as preferences (eg. Colors,
> Fonts, etc.)?

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,s
tyle=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.

--
Paul Lutus
http://www.arachnoid.com

"Stefan Schulz" <terra@spacetime.de> wrote in message
news:opsezofegmq1fd9p@localhost...
> On Mon, 27 Sep 2004 12:57:19 GMT, Steven Buroff <sburoff@optonline.net>
> wrote:
> 
>
> 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? ;)

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
>
>
>
> --
>
> Whom the gods wish to destroy they first call promising.

"Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10lgespscproqc4@corp.supernews.com...
> Steven Buroff wrote:
> 
Colors, 
>
> 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,s
tyle=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
>
> 
>
> 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.
> 
>
> Yes. Or you can save yourself months, possibly years, of effort and
> heartache by saving your objects in a more reliable way.
>
> --
> Paul Lutus
> http://www.arachnoid.com
>

On Tue, 28 Sep 2004 13:06:34 GMT, Steven Buroff <sburoff@optonline.net>
wrote:


> 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.


--

Whom the gods wish to destroy they first call promising.