Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #38470 > unrolled thread
| Started by | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| First post | 2018-07-04 19:57 +0000 |
| Last post | 2018-07-04 22:56 +0000 |
| Articles | 6 — 2 participants |
Back to article view | Back to comp.lang.java.programmer
Checked casting with Generics Martin Gregorie <martin@mydomain.invalid> - 2018-07-04 19:57 +0000
Re: Checked casting with Generics Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-07-04 17:22 -0400
Re: Checked casting with Generics Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-07-04 17:37 -0400
Re: Checked casting with Generics Martin Gregorie <martin@mydomain.invalid> - 2018-07-04 23:03 +0000
Re: Checked casting with Generics Martin Gregorie <martin@mydomain.invalid> - 2018-07-05 15:38 +0000
Re: Checked casting with Generics Martin Gregorie <martin@mydomain.invalid> - 2018-07-04 22:56 +0000
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2018-07-04 19:57 +0000 |
| Subject | Checked casting with Generics |
| Message-ID | <phj8qt$hpp$1@news.albasani.net> |
I have a problem with casting Generics. Been searching around but haven't
found and solutions that work (and even 'solutions' that don't
compile(!). Anyway, here's the problem:
I'm handling email using javax.mail classes. The code was originally
written with Java 6 and it has run untouched until now, when I changed
some code and recompiled the app using Java 8 (OpenJava 1.8.0). Its all
fine apart from a couple of casts in unrelated code.
The immediate problem is that I need to handle the list of header in part
of a multipart message. The statement:
Enumeration<Header> e = m.getAllHeaders();
compiled without any fuss under Java 6, but when compiled now it issues a
warning:
[javac] /home/marchive/marchive/org/gregorie/mailarchive/internals/
HeaderBlock.java:52: warning: [unchecked] unchecked conversion
[javac] Enumeration<Header> e = m.getAllHeaders();
[javac] ^
[javac] required: Enumeration<Header>
[javac] found: Enumeration
Writing it as a simple cast by adding (Enumeration<Header>) after the
assignment operator has no effect and nothing I've adapted from examples
using isinstanceof or inherited Class.isInstance() does anything except
throw compilation syntax errors.
I can run with it like this, but would really like to handle this
unchecked conversion, partly to get rid of the compiler warning and
partly so I understand how it should be done.
--
Martin | martin at
Gregorie | gregorie dot org
[toc] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2018-07-04 17:22 -0400 |
| Message-ID | <phjdqv$2ve$1@dont-email.me> |
| In reply to | #38470 |
On 7/4/2018 3:57 PM, Martin Gregorie wrote:
> I have a problem with casting Generics. Been searching around but haven't
> found and solutions that work (and even 'solutions' that don't
> compile(!). Anyway, here's the problem:
>
> I'm handling email using javax.mail classes. The code was originally
> written with Java 6 and it has run untouched until now, when I changed
> some code and recompiled the app using Java 8 (OpenJava 1.8.0). Its all
> fine apart from a couple of casts in unrelated code.
>
> The immediate problem is that I need to handle the list of header in part
> of a multipart message. The statement:
>
> Enumeration<Header> e = m.getAllHeaders();
>
> compiled without any fuss under Java 6, but when compiled now it issues a
> warning:
> [javac] /home/marchive/marchive/org/gregorie/mailarchive/internals/
> HeaderBlock.java:52: warning: [unchecked] unchecked conversion
> [javac] Enumeration<Header> e = m.getAllHeaders();
> [javac] ^
> [javac] required: Enumeration<Header>
> [javac] found: Enumeration
Nothing definite, just a few things you might want to check:
1) What is the class/interface type of `m'? The point of looking
into this is (a) to disambiguate among the six different getAllHeaders()
methods, and (b) to make absolutely certain-sure it's a javax.mail
class and not some accidental interloper. (I recall a questioner who
couldn't get `@Override' to work; it turned out he was trying to use
it in a class named `Override' ...)
2) Similarly with `Header': Is it really javax.mail.Header, and
not some kind of illegal immigrant? (I'd guess this one would lead to
a different symptom, but you might as well double-check.)
3) Is your javax.mail installation up-to-date, or reasonably so?
If nothing's been touched since the Java 1.6 days (7-12.5 years ago),
perhaps you've got an ancient javax.mail that can't keep up with the
much younger JDK. (Current javax.mail version is 1.6.1, which I think
has nothing at all to do with Java 1.6 or indeed with Java 1.anything.)
4) Is it an OpenJDK problem? What happens if you build with
Oracle's JDK? (Even if you don't want to use Oracle's in production,
a cross-check might help identify a bug.)
> Writing it as a simple cast by adding (Enumeration<Header>) after the
> assignment operator has no effect and nothing I've adapted from examples
> using isinstanceof or inherited Class.isInstance() does anything except
> throw compilation syntax errors.
Adding a cast shouldn't silence the warning, since the conversion
from plain `Thing' to `Thing<Whatsit>' (which takes place even without
the cast) is still unchecked.
> I can run with it like this, but would really like to handle this
> unchecked conversion, partly to get rid of the compiler warning and
> partly so I understand how it should be done.
Unless something else turns up, the best I can suggest is to add
`@SuppressWarning("unchecked")' and an extensive comment ...
--
esosman@comcast-dot-net.invalid
Nine hundred thirty-one days to go.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2018-07-04 17:37 -0400 |
| Message-ID | <phjenc$83o$1@dont-email.me> |
| In reply to | #38471 |
On 7/4/2018 5:22 PM, Eric Sosman wrote:
> [...[
> Unless something else turns up, the best I can suggest is to add
> `@SuppressWarning("unchecked")' and an extensive comment ...
`@SuppressWarnings("unchecked")', of course (sorry)!
^
Also, I notice that javax.mail's public API wasn't generified until
version 1.6, which seems to have come out about one year ago. If your
version is older than that it probably doesn't grok generics at all.
--
esosman@comcast-dot-net.invalid
Nine hundred thirty-one days to go.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2018-07-04 23:03 +0000 |
| Message-ID | <phjjo1$jak$2@news.albasani.net> |
| In reply to | #38472 |
On Wed, 04 Jul 2018 17:37:46 -0400, Eric Sosman wrote:
> On 7/4/2018 5:22 PM, Eric Sosman wrote:
>> [...[
>> Unless something else turns up, the best I can suggest is to
>> add
>> `@SuppressWarning("unchecked")' and an extensive comment ...
>
> `@SuppressWarnings("unchecked")', of course (sorry)!
> ^
>
> Also, I notice that javax.mail's public API wasn't generified until
> version 1.6, which seems to have come out about one year ago. If your
> version is older than that it probably doesn't grok generics at all.
A quick scan of the Javadocs makes that likely: I didn't spot any
generics in places where I'd expect them, e.g. the Folder class is
subclassed rather generified. and the same applied to in interface I
spotted.
--
Martin | martin at
Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2018-07-05 15:38 +0000 |
| Message-ID | <phle20$k4r$1@news.albasani.net> |
| In reply to | #38472 |
On Wed, 04 Jul 2018 17:37:46 -0400, Eric Sosman wrote: > Also, I notice that javax.mail's public API wasn't generified until > version 1.6, which seems to have come out about one year ago. If your > version is older than that it probably doesn't grok generics at all. > The generified V1.6 fixed it - thanks. However, finding 1.6 was a bit of a trek. Annoyingly, the Fedora package for OpenJava 1.8 JavaMail is only up to v1.5, though at least it had a downloadable set of Javadocs, which isn't generified. Then it turned out that the Oracle 1.6 version had migrated to Github and is apparently about to move elsewhere 'real soon now' and, along the way, it has already shed downloadable Javadoc API documentation and the Design principles document. Fortunately I was able to find a downloadable design doc and a linkable set of Javadocs, so all is now good. -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2018-07-04 22:56 +0000 |
| Message-ID | <phjjao$jak$1@news.albasani.net> |
| In reply to | #38471 |
On Wed, 04 Jul 2018 17:22:38 -0400, Eric Sosman wrote:
> On 7/4/2018 3:57 PM, Martin Gregorie wrote:
>> I have a problem with casting Generics. Been searching around but
>> haven't found and solutions that work (and even 'solutions' that don't
>> compile(!). Anyway, here's the problem:
>>
>> I'm handling email using javax.mail classes. The code was originally
>> written with Java 6 and it has run untouched until now, when I changed
>> some code and recompiled the app using Java 8 (OpenJava 1.8.0). Its all
>> fine apart from a couple of casts in unrelated code.
>>
>> The immediate problem is that I need to handle the list of header in
>> part of a multipart message. The statement:
>>
>> Enumeration<Header> e = m.getAllHeaders();
>>
>> compiled without any fuss under Java 6, but when compiled now it issues
>> a warning:
>> [javac]
>> /home/marchive/marchive/org/gregorie/mailarchive/internals/
>> HeaderBlock.java:52: warning: [unchecked] unchecked conversion
>> [javac] Enumeration<Header> e = m.getAllHeaders();
>> [javac] ^
>> [javac] required: Enumeration<Header>
>> [javac] found: Enumeration
>
> Nothing definite, just a few things you might want to check:
>
> 1) What is the class/interface type of `m'? The point of looking
> into this is (a) to disambiguate among the six different getAllHeaders()
> methods, and (b) to make absolutely certain-sure it's a javax.mail class
> and not some accidental interloper. (I recall a questioner who couldn't
> get `@Override' to work; it turned out he was trying to use it in a
> class named `Override' ...)
>
Its javax.mail.Part.getAllHeaders() and returns an Enumeration - which is
a bit wild seeing thats only defined as an interface.
> 2) Similarly with `Header': Is it really javax.mail.Header, and
> not some kind of illegal immigrant? (I'd guess this one would lead to a
> different symptom, but you might as well double-check.)
>
Yes, it is.
> 3) Is your javax.mail installation up-to-date, or reasonably so?
> If nothing's been touched since the Java 1.6 days (7-12.5 years ago),
> perhaps you've got an ancient javax.mail that can't keep up with the
> much younger JDK. (Current javax.mail version is 1.6.1, which I think
> has nothing at all to do with Java 1.6 or indeed with Java 1.anything.)
>
Good point. It may well be 1.4. The weather is looking better, so I'm
going flying tomorrow and hopefully won't be around to check/update for a
day or three, but I will have the latest version before coming back to
this.
> 4) Is it an OpenJDK problem? What happens if you build with
> Oracle's JDK? (Even if you don't want to use Oracle's in production,
> a cross-check might help identify a bug.)
>
I don't think so. I haven't had any problems I can trace to it being
OpenJava since I switched somewhat almost a year ago. And anyway, I
though its source was maintained bt Oracle - or at least that they had a
fairly large control over it.
>> Writing it as a simple cast by adding (Enumeration<Header>) after the
>> assignment operator has no effect and nothing I've adapted from
>> examples using isinstanceof or inherited Class.isInstance() does
>> anything except throw compilation syntax errors.
>
> Adding a cast shouldn't silence the warning, since the conversion
> from plain `Thing' to `Thing<Whatsit>' (which takes place even without
> the cast) is still unchecked.
>
>> I can run with it like this, but would really like to handle this
>> unchecked conversion, partly to get rid of the compiler warning and
>> partly so I understand how it should be done.
>
> Unless something else turns up, the best I can suggest is to add
> `@SuppressWarning("unchecked")' and an extensive comment ...
Good point. Thanks.
--
Martin | martin at
Gregorie | gregorie dot org
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.java.programmer
csiph-web