Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #38470 > unrolled thread

Checked casting with Generics

Started byMartin Gregorie <martin@mydomain.invalid>
First post2018-07-04 19:57 +0000
Last post2018-07-04 22:56 +0000
Articles 6 — 2 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  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

#38470 — Checked casting with Generics

FromMartin Gregorie <martin@mydomain.invalid>
Date2018-07-04 19:57 +0000
SubjectChecked 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]


#38471

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2018-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]


#38472

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2018-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]


#38474

FromMartin Gregorie <martin@mydomain.invalid>
Date2018-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]


#38475

FromMartin Gregorie <martin@mydomain.invalid>
Date2018-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]


#38473

FromMartin Gregorie <martin@mydomain.invalid>
Date2018-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