Type safety warning...

G

grz01

Hi,

This code:

String s = "a;b;c";
List<String> l = Arrays.asList(s.split(";"));

gives me a warning:

Type safety: The expression of type List needs unchecked
conversion to conform to List<String>

Can someone pse help me correct the second line to avoid this warning
(without using "@SuppressWarnings") ?

TIA / grz01
 
A

Andreas Leitgeb

grz01 said:
This code:
String s = "a;b;c";
List<String> l = Arrays.asList(s.split(";"));
gives me a warning:
Type safety: The expression of type List needs unchecked
conversion to conform to List<String>

It doesn't for me. (jdk 1.6.0_16 here)

import java.util.List;
import java.util.Arrays;
public class Test {
public static void main(String[] a) {
String s = "a;b;c";
List<String> l = Arrays.asList(s.split(";"));
}
}

No warnings on compile. Which jdk do you use, and
do you compile from command-line, or through some
IDE, like eclipse and netbeans? They are known to
complain about much more, but can be configured
not to barf at not-really-barfworthy things.
 
G

grz01

No warnings on compile.  Which jdk do you use, and
do you compile from command-line, or through some
IDE, like eclipse and netbeans? They are known to
complain about much more, but can be configured
not to barf at not-really-barfworthy things.

Hi,

Yes, I am building in Eclipse.
jdk is 1.6.

/ grz01
 
Q

Qu0ll

grz01 said:
Hi,

Yes, I am building in Eclipse.
jdk is 1.6.

You can configure Eclipse to not produce a warning in such situations by
going to Preferences -> Java -> Compiler -> Errors/Warnings -> Generic types
and change "Unchecked generic type operation" to "Ignore".

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]
 
G

grz01

You can configure Eclipse to not produce a warning in such situations by
going to Preferences -> Java -> Compiler -> Errors/Warnings -> Generic types
and change "Unchecked generic type operation" to "Ignore".


OK.
But would still be nice to understand exactly *what* it is actually
warning abt?
Generally, I definitely prefer "type-safe" programming, if possible,
rather than just turn off the warnings :)

How are you actually supposed to write the assignment above?

/ grz01
 
G

grz01

What version of Eclipse? Mine does not give any warnings. Looks like it is a
bug in Eclipse JDT compiler.
Although not necessary because the compiler should be able to infer right
types you can try:

List<String> l = Arrays.<String>asList(s.split(";"));


Sorry, just discovered I had imported Arrays from the wrong package!
Oh well...
Thanks, anyway
 
A

Andreas Leitgeb

grz01 said:
OK.
But would still be nice to understand exactly *what* it is actually
warning abt?

about a wrongly imported Arrays class, of course!

(just kidding, saw your posting in the other subthread :)
 
L

Lew

Qu0ll said:
You can configure Eclipse to not produce a warning in such situations by
going to Preferences -> Java -> Compiler -> Errors/Warnings -> Generic
types and change "Unchecked generic type operation" to "Ignore".

TERRIBLE advice! Do not follow that advice! Bad, bad, bad advice!
 
Q

Qu0ll

Lew said:
TERRIBLE advice! Do not follow that advice! Bad, bad, bad advice!

I didn't say they *should* do it, merely that they *could* do it if the
warning was a problem for them. Personally, I have all the warnings turned
on but YMMV.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]
 
W

Wojtek

grz01 wrote :
I agree Lew... but no need to shout ;)

Oh yes there is.

Things like turing off compiler checks and @SuppressWarnings should
come with a loud noise.

While they are there for a reason, it is much like using funky pointer
arithmatic in C. Yes it IS possible, but it should not be used unless
you realize the full implications of using it.

So while I do use @SuppressWarnings (with lots of comments and a TODO
task) and I do have some compiler checks turned off, I am cognizant of
what may happen if I am wrong, and they were not used lightly.

A newbie has no such practical experience to draw upon.
 
L

Lew

I agree Lew... but no need to shout   ;)

I assessed that there was. :)

I was acting for your protection, grz01, and others who read this
thread. When someone is trying to put out a fire and someone else
says, "Just put your bare hand into the flame and smother it,"
wouldn't you shout, "NO! Don't do that!"?

Colorful analogies aside, Qu0ll has since explained that it was not
advice, despite being presented exactly as advice in a context where
it would be taken as advice without disclaimer that it was not
advisable, but mere information about a possible, though bad,
practice. I shall ignore the sophistry of that backpedaling and
acknowledge that he gave good information, though it would make for
bad advice.

Phew! Crisis averted.
 
L

Lew

Wojtek said:
So while I do use @SuppressWarnings (with lots of comments and a TODO
task) and I do have some compiler checks turned off, I am cognizant of
what may happen if I am wrong, and they were not used lightly.

Properly used, @SuppressWarnings("unchecked") would never come with a
TODO because there would be nothing else to do.

Joshua Bloch discusses this annotation in /Effective Java/, chapter 5,
available for free from
<http://java.sun.com/docs/books/effective/>

The proper use of @SuppressWarnings("unchecked") is in places where
you cannot impose compile-time restraints, say casting the result from
a third-party library or certain operations involving arrays, but
where you have taken other steps to ensure that you cannot get a
ClassCastException.
 
W

Wojtek

Lew wrote :
Properly used, @SuppressWarnings("unchecked") would never come with a
TODO because there would be nothing else to do.

Joshua Bloch discusses this annotation in /Effective Java/, chapter 5,
available for free from
<http://java.sun.com/docs/books/effective/>

The proper use of @SuppressWarnings("unchecked") is in places where
you cannot impose compile-time restraints, say casting the result from
a third-party library or certain operations involving arrays, but
where you have taken other steps to ensure that you cannot get a
ClassCastException.

It may be possible, however unlikely, that a future language change
will make that @SuppressWarnings unnecessary.

I like to leave in these little markers so I can go over them whenever
I upgrade the Java version.
 
D

Donkey Hottie

Wojtek said:
Lew wrote :

It may be possible, however unlikely, that a future
language change will make that @SuppressWarnings
unnecessary.
I like to leave in these little markers so I can go over
them whenever I upgrade the Java version.

JPA Query for example is not a Query<T> but plain Query.

Query.getResultList() requires @SuppressWarnings("unchecked") no matter
what.

Sun is to blame, its their interface.
 
Q

Qu0ll

Lew said:
I assessed that there was. :)

I was acting for your protection, grz01, and others who read this
thread. When someone is trying to put out a fire and someone else
says, "Just put your bare hand into the flame and smother it,"
wouldn't you shout, "NO! Don't do that!"?

Colorful analogies aside, Qu0ll has since explained that it was not
advice, despite being presented exactly as advice in a context where
it would be taken as advice without disclaimer that it was not
advisable, but mere information about a possible, though bad,
practice. I shall ignore the sophistry of that backpedaling and
acknowledge that he gave good information, though it would make for
bad advice.

Phew! Crisis averted.

Lew, I try to help where I can given that I have received so much help from
this group over the years. I don't always get it right and unfortunately
the caning I receive when I don't quite hit the mark tends to discourage me
from making further such attempts in the future.

You are absolutely correct that it was bad advice but, as I have already
explained, it was more an an effort to point out a feature in Eclipse than
suggest a recommended practice. I couldn't see any reason for the warning
in the code presented so I wanted the OP to know that they did have the
option to ignore the warning if it was resulting from a bug in the Eclipse
compiler.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]
 
L

Lew

Qu0ll said:
Lew, I try to help where I can given that I have received so much help from
this group over the years.  I don't always get it right and unfortunately
the caning I receive when I don't quite hit the mark tends to discourage me
from making further such attempts in the future.

You are absolutely correct that it was bad advice but, as I have already
explained, it was more an an effort to point out a feature in Eclipse than
suggest a recommended practice.  I couldn't see any reason for the warning
in the code presented so I wanted the OP to know that they did have the
option to ignore the warning if it was resulting from a bug in the Eclipse
compiler.

"Caning"? WTF? You let someone's addition to information that you
incompletely expressed bother you that much?

FWIW I understood your explanation upthread, and referenced it in my
later response. I don't think anyone misunderstood it.

You've been reading and writing to this newsgroup for a while. I can
guess that you've read my posts before. If I were doing any
metaphorical "caning" it would have been directed to you, not to
flawed comments. You would have no doubt that there was a "caning"
going on.

What you saw above was a comment on what looked like bad advice, and
was at least information that did not include any disclaimer or
warnings that what was recommended, er, described had significant
dangers. It would have been irresponsible to let that information go
out without an alert as to its red flags.

I do recommend that you be clear when discussing options if there are
major dangers to the options you appear to recommend. I also
recommend that you do not take factual disagreements or corrections as
"caning" in this newsgroup. The purpose is to get the facts straight
and the implications explicit.

You must expect wrong or incomplete information to trigger responses.
If you're going to get all sensitive when people add to what you've
said, as I did, or disagree with what you've said, then you are really
not well suited to this environment. One of the great benefits to
this and similar forums is that one gets one's own misunderstandings
clarified. It's certainly happened to me any number of times.

Grow a thicker skin lest you sacrifice the reception of truth.
 
Q

Qu0ll

Lew said:
"Caning"? WTF? You let someone's addition to information that you
incompletely expressed bother you that much?

FWIW I understood your explanation upthread, and referenced it in my
later response. I don't think anyone misunderstood it.

You've been reading and writing to this newsgroup for a while. I can
guess that you've read my posts before. If I were doing any
metaphorical "caning" it would have been directed to you, not to
flawed comments. You would have no doubt that there was a "caning"
going on.

What you saw above was a comment on what looked like bad advice, and
was at least information that did not include any disclaimer or
warnings that what was recommended, er, described had significant
dangers. It would have been irresponsible to let that information go
out without an alert as to its red flags.

I do recommend that you be clear when discussing options if there are
major dangers to the options you appear to recommend. I also
recommend that you do not take factual disagreements or corrections as
"caning" in this newsgroup. The purpose is to get the facts straight
and the implications explicit.

You must expect wrong or incomplete information to trigger responses.
If you're going to get all sensitive when people add to what you've
said, as I did, or disagree with what you've said, then you are really
not well suited to this environment. One of the great benefits to
this and similar forums is that one gets one's own misunderstandings
clarified. It's certainly happened to me any number of times.

Grow a thicker skin lest you sacrifice the reception of truth.

My skin is as thick as it needs to be. I thoroughly deserved the response I
received to my comment as it was not expressed very well. I describe it as
a "caning" but it could have been worse. Let's leave it at that.

BTW, I don't need you to assess or comment on my suitability for Usenet. I
am well aware of the pros and cons of the environment.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]
 

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

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top