Puzzling warning message

[Roedy Green]

I have code like this:

ArrayList<ZD>allZips = (ArrayList<ZD>)ois.readObject();


It complains:

Type safety: The cast from Object to ArrayList<ZD> is actually
checking against the erased type ArrayList.

What do I do to get it to stop complaining, and what is it concerned
about?

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roedy Green]

On Sun, 31 Jul 2005 01:36:58 GMT, Roedy Green

// Reading a serialised ArrayList generates
// this puzzling error message:
// "The cast from Object to ArrayList<E> is actually checking
// against the erased type ArrayList."

ArrayList<ZD>allZips = (ArrayList<ZD>)ois.readObject();

// To get rid of the warning message, you must code it like this:
ArrayList<?>temp = (ArrayList<?>)ois.readObject();

ArrayList<ZD>allZips = new ArrayList<ZD>( temp.size() );
for ( Object o : temp )
{
allZips.add( (ZD) o );
}

The (ArrayList <zd>) cast can't properly check that the object coming
in is truly an ArrayList full only of ZDs. The type erasure did not
leave enough info in the serialised stream to detect that.

So to be completely safe, you must read in just a generic ArrayList
which the the cast can check, then test yourself, element by element
that every Object in the ArrayList was of type ZD.

It is much simpler to read and write serialised arrays than
ArrayLists. They don't have this problem since you are not relying on
generics for your type information. The problem is of course you may
not be able to switch formats in mid stream.
--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Thomas Hawtin]

ArrayList<ZD>allZips = (ArrayList<ZD>)ois.readObject();

// To get rid of the warning message, you must code it like this:
ArrayList<?>temp = (ArrayList<?>)ois.readObject();

ArrayList<ZD>allZips = new ArrayList<ZD>( temp.size() );
for ( Object o : temp )
{
allZips.add( (ZD) o );
}

Christ, don't do that. The formatting is terrible. You are replacing one
cast with a lot of code and another cast. I hope at some point javac
will acquire a lint warning for any cast.

The correct way to go is to add @SuppressWarnings("unchecked").
Unfortunately it was a late feature for 5.0 so is not used by Sun's
javac. It at least shows to humans that you have thought about the
method (possibly).

Perhaps it's worth feeding -Xlint warnings back into a version control
system. Pity there is no easy way to adjust line numbers. You could keep
the number of warnings and casts down with the odd utility method, I
think. Perhaps readObject should have be generified that way.

/**
* @throws ClassCastException
* @see ObjectInputStream#readObject
*/
@SuppressWarnings("unchecked")
public static <T> readObject(
ObjectInputStream in
) throws IOException, ClassNotFoundException {
return (T)in.readObject();
}

Tom Hawtin

 

[Roedy Green]

/**
* @throws ClassCastException
* @see ObjectInputStream#readObject
*/
@SuppressWarnings("unchecked")
public static <T> readObject(
ObjectInputStream in

Many thanks. I was just living with the warnings cluttering up my
Eclipse "problems" section. I refused to write that silly loop.
SuppressWarnings fixed it. I was thinking last night as I was falling
asleep about asking Sun to invent some way to mark warnings as "ok".
And I woke up to find they have already done it.

That is a strange syntax. It looks like JavaDoc but it is not. Further
there is no semicolon. That syntax is called an annotation.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Tim Tyler]

@SuppressWarnings("unchecked") [...]

That is a strange syntax. It looks like JavaDoc but it is not. Further
there is no semicolon. That syntax is called an annotation.

Sun finally bit the bullet - and went for the "worse sorts of
irregularity" they mentioned here:

``Still, the compiler has heretofore ignored and should generally ignore
documentation comments. This is an admittedly irregular exception to
that practice. But the other design options for deprecation involve
worse sorts of irregularity.''

- http://java.sun.com/j2se/1.4.2/docs/guide/misc/deprecation/deprecated.html

As a result they now have two sorts of irregularities - comments with
syntactically-significant information *and* annotations.

Maybe now they should deprecate the "@deprecated" Javadoc tag.

I wonder how they might do that ;-)

 

[Thomas Hawtin]

Maybe now they should deprecate the "@deprecated" Javadoc tag.

There is an @Deprecated annotation as well. But it takes no arguments,
so it can't replace the JavaDoc tag.

I must admit that I am confused by the duplicate approach.



The absence of semicolons can be explained by the fact that
syntactically annotations can be applied to any declaration including
variables (although it doesn't make any sense for non-parameter, local
variables).

Tom Hawtin

 

[jan V]

@SuppressWarnings("unchecked") [...]

Sun finally bit the bullet - and went for the "worse sorts of
irregularity" they mentioned here:

``Still, the compiler has heretofore ignored and should generally ignore
documentation comments. This is an admittedly irregular exception to
that practice. But the other design options for deprecation involve
worse sorts of irregularity.''

For goodness sake... what kind of incompetent Sun managers give the green
light for crap like that?

 

[Tim Tyler]

@SuppressWarnings("unchecked") [...]

That is a strange syntax. It looks like JavaDoc but it is not. Further
there is no semicolon. That syntax is called an annotation.

Sun finally bit the bullet - and went for the "worse sorts of
irregularity" they mentioned here:

``Still, the compiler has heretofore ignored and should generally ignore
documentation comments. This is an admittedly irregular exception to
that practice. But the other design options for deprecation involve
worse sorts of irregularity.''

For goodness sake... what kind of incompetent Sun managers give the green
light for crap like that?

Since they eventually added annotations, the @deprecated tag looks
like a particularly short-sighted move retrospectively.

However, at the time, the Java language lacked competition - and
seemed more frozen.

If deprecation was going to be the last bit of meta-information
they would want to add to Java, the approach they took does make
/some/ sense - at least it doesn't screw up existing parsers like
the annotations do.

Both annotations and the deprecated javadoc tag look like signs
of evolution to me. If one was starting again, wouldn't attributes
such as "deprecated" and "override" be best placed in modifiers?

 

[Thomas Hawtin]

[Tim Tyler wrote:]

``Still, the compiler has heretofore ignored and should generally ignore
documentation comments. This is an admittedly irregular exception to
that practice. But the other design options for deprecation involve
worse sorts of irregularity.''

For goodness sake... what kind of incompetent Sun managers give the green
light for crap like that?

What would you suggest instead?

Constraints include:
o You really don't want to introduce a keyword.
o javacoc should pick up a comment for it.
o The syntax needs to be simple, obvious and blend in.
o Details of Java compiler implementation are not a concern for almost
all users.
o javadoc and javac should share as much code as possible.

Tom Hawtin

 

[Chris Smith]

Both annotations and the deprecated javadoc tag look like signs
of evolution to me. If one was starting again, wouldn't attributes
such as "deprecated" and "override" be best placed in modifiers?

Annotations make a lot of sense as something other than keywords.
Keywords are necessarily used at the language level, and many of the
concepts that they can be used to represent should not exist at the
language level. Many possible uses of annotations are domain-specific.

On the other hand, I agree that override, and perhaps deprecated as
well, possibly ought to have been a keyword. They are special cases.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[jan V]

For goodness sake... what kind of incompetent Sun managers give the
green

What would you suggest instead?

My reaction stems from believing that language comments are no place to
start stuffing compiler directives in. Any Java compiler should IGNORE all
comments. What Sun have done is to blur the age-old black/white *simple*
distinction between comments and non-comments, and that's totally wrong.

I have comments syntax-highlighted in a color different from all other code,
and I don't want to start having bloody rainbow effects WITHIN comments to
complicate my life. Comments should be programmer-readable text for human
consumption, NOT compiler directives. Comments are places where programmers
can come up for air and read familiar human language.

Constraints include:
o You really don't want to introduce a keyword.

I'd rather see new keywords than a messy, fundamental concepts undermining
"enhancement"

 

[Tim Tyler]

My reaction stems from believing that language comments are no place to
start stuffing compiler directives in. Any Java compiler should IGNORE all
comments. What Sun have done is to blur the age-old black/white *simple*
distinction between comments and non-comments, and that's totally wrong.

Java has single-line comments, multi-line comments, Javadoc comments and
annotations.

I reckon I'd prefer just two categories - a single-line comment and
an annotation.

IMO, machine-generated documentation (and anything else requiring
mechanical parsing) should be handled by "doc" annotations - rather
than by comments.

Also, typically a compiler shouldn't have to read annotations just to
compile code - annotations should really only be needed for customised
lint tools and the like, not basic compilation/execution of the code.

 

[Roedy Green]

Comments are places where programmers
can come up for air and read familiar human language.

going back to Algol-68 they made the distinction between comments and
outside the language hints with the pragma keyword.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Dale King]

My reaction stems from believing that language comments are no place to
start stuffing compiler directives in. Any Java compiler should IGNORE all
comments. What Sun have done is to blur the age-old black/white *simple*
distinction between comments and non-comments, and that's totally wrong.

Well for deprecated it really isn't much of a compiler directive. It is
metadata and not necessary for compiling. I know the compiler looks at
it and generates metadata for it, but it really isn't a necessary thing
for building so it is not truly evil.

My guess on how it came about was that it probably started out as only a
doumentation thing and was only used by javadoc. Then somebody came
along later and suggested that the compiler could generate attributes
for the methods and generate warnings. By that time the use of the
javadoc tag was well entrenched in the source code and it was too late
to do it better.

 

[Tim Tyler]

jan V wrote:

Well for deprecated it really isn't much of a compiler directive. It is
metadata and not necessary for compiling. I know the compiler looks at
it and generates metadata for it, but it really isn't a necessary thing
for building so it is not truly evil.

My guess on how it came about was that it probably started out as only a
doumentation thing and was only used by javadoc. Then somebody came
along later and suggested that the compiler could generate attributes
for the methods and generate warnings. By that time the use of the
javadoc tag was well entrenched in the source code and it was too late
to do it better.

Some signs of deliberation exist:

``We considered introducing pragmas, and using them for deprecation (e.g.,
<*deprecated*>) but this would open the door very wide to many sorts of
incompatible extensions and, possibly, to serious abuses. [...]
Since the human is the primary user of the data, it belongs in comments.''

- http://java.sun.com/j2se/1.4.2/docs/guide/misc/deprecation/deprecated.html

Now we have pragmas. Have they opened the door very wide to many sorts of
incompatible extensions and, possibly, to serious abuses?

 

[Thomas Hawtin]

Now we have pragmas. Have they opened the door very wide to many sorts of
incompatible extensions and, possibly, to serious abuses?

Neither @deprecated or annotations effect the compiler generation of
code or the runtime interpretation of it, so I think they skirt the
pragma issue. Doesn't mean we can't abuse the @Hell out of them, if in a
more limited way than AOP.

Tom Hawtin

 

[Raymond DeCampo]

Neither @deprecated or annotations effect the compiler generation of
code or the runtime interpretation of it, so I think they skirt the
pragma issue. Doesn't mean we can't abuse the @Hell out of them, if in a
more limited way than AOP.

Tom Hawtin

I don't see how you can say that @deprecated or annotations do not
effect the generation of code. Perhaps I am misinterpreted your
statement. But both @deprecated and annotations result in artifacts in
the .class file, as evidence by the compilers ability to issue
deprecated warnings without the source of the deprecated class and the
ability to access annotations at runtime.

Ray

 

[Chris Uppal]

I don't see how you can say that @deprecated or annotations do not
effect the generation of code. Perhaps I am misinterpreted your
statement. But both @deprecated and annotations result in artifacts in
the .class file [...]

They are represented in the .class file, and tools that understand the
classfile format (such as the compiler) can read them. However then are not
part of the generated code -- the bytecode sequences (and a few related things)
that the JVM uses to execute the class at runtime.

The classfile format is quite rich, there's a fair bit of stuff in there (and
scope to add a lot more) that is not connected with specifying the behaviour
of running programs.

-- chris

 

[Raymond DeCampo]

Raymond DeCampo wrote:

I don't see how you can say that @deprecated or annotations do not
effect the generation of code. Perhaps I am misinterpreted your
statement. But both @deprecated and annotations result in artifacts in
the .class file [...]

They are represented in the .class file, and tools that understand the
classfile format (such as the compiler) can read them. However then are not
part of the generated code -- the bytecode sequences (and a few related things)
that the JVM uses to execute the class at runtime.

OK, so my misunderstanding was just a terminology issue.

The classfile format is quite rich, there's a fair bit of stuff in there (and
scope to add a lot more) that is not connected with specifying the behaviour
of running programs.

-- chris

Ray

 

[Roedy Green]

They are represented in the .class file, and tools that understand the
classfile format (such as the compiler) can read them. However then are not
part of the generated code -- the bytecode sequences (and a few related things)
that the JVM uses to execute the class at runtime.

I wonder if eventually class files will contain meta-info, e.g. needed
properties, version of JDK class is coded for, whether the enclosing
jar needs to be signed etc. so that you effectively manage you build
scripts with annotations.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes