Home > Archive > Java Help > September 2004 > java 1.5 - generics "unchecked cast" suppression
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
java 1.5 - generics "unchecked cast" suppression
|
|
| Steven Buroff 2004-09-26, 3:57 pm |
| 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
| |
| Paul Lutus 2004-09-26, 3:57 pm |
| 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
| |
| Steven Buroff 2004-09-26, 8:57 pm |
| 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
>
| |
| Paul Lutus 2004-09-27, 3:57 am |
| 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
| |
| Steven Buroff 2004-09-27, 9:07 am |
|
"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
>
| |
| Stefan Schulz 2004-09-27, 4:02 pm |
| 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.
| |
| Paul Lutus 2004-09-27, 4:02 pm |
| 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
| |
| Steven Buroff 2004-09-28, 4:13 pm |
|
"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.
| |
| Steven Buroff 2004-09-28, 4:13 pm |
|
"Paul Lutus" <nospam@nosite.zzz> wrote in message
news:10lgespscproqc4@corp.supernews.com...
> Steven Buroff wrote:
>
Colors,[color=darkred]
>
> 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
>
| |
| Stefan Schulz 2004-09-28, 4:13 pm |
| 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.
| |
| Paul Lutus 2004-09-28, 4:13 pm |
| Steven Buroff wrote:
/ ...
> reading
>
> 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.
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?
--
Paul Lutus
http://www.arachnoid.com
| |
| Paul Lutus 2004-09-28, 4:13 pm |
| Steven Buroff wrote:
/ ...
>
> 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.
--
Paul Lutus
http://www.arachnoid.com
|
|
|
|
|