[OpenJDK 2D-Dev] JDK 9: RFR: 8033716: Fix raw and unchecked lint warnings in com.sun.imageio

[Phil Race]

BMPMetadata.java

  
  94     // Fields from CommentExtension
   95     // List of byte[]
  96     public List<byte[]> comments = null; // new ArrayList();

hmm .. how did you decide this was correct, other than trusting the comment?

The thing is I can't actually see where this field is used and I'm inclined
to think this was a copy/paste from the GIF code.

It would seem the right thing to do is delete these lines.

In the case of GIFImageMetadata they are used but you left the comments
saying

// new ArrayList();

since it looks like you use the diamond operator now that should
not be completely true. Either remove the comment or, since it
seems it was intended to be informative update it to say
// new ArrayList<>();

I will have to look at all the subsequent files later ..
  

-phil.

On 2/7/2014 1:54 PM, Henry Jen wrote:
> Thanks Joe for reviewing.
>
> I would like to get 2d developer review as well before pushing this, 
> let me know if that's not necessary.
>
> Also there was a discussion ealier on whether such change should go to 
> client or jdk9/dev repo, do we have a conclusion?
>
> Cheers,
> Henry
>
> On 02/05/2014 06:01 PM, Joe Darcy wrote:
>> Hi Henry,
>>
>> On 02/05/2014 12:19 PM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review the webrev to clean up raw and unchecked warnings in
>>> com.sun.imageio packag at,
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8033716/0/webrev/
>>>
>>> The more significant change in this webrev is that I have changed the
>>> clone() method of MarkerSegment-derived classes to return exact type
>>> rather than Object. Otherwise, it's basically add type information and
>>> eliminate cast no longer needed.
>>>
>>> Cheers,
>>> Henry
>>
>> I looked over the changes and they generally look good. I've taken a
>> closer look at the clone-related changes.
>>
>> The types SOSMarkerSegment, SOFMarkerSegment, MarkerSegment, etc. are
>> call package-private and all have had their Object-returning clone
>> methods replaced with a self-type returning clone method, a covariant
>> override.
>>
>> Since there are no other potential subclasses of these com.sun.* type
>> that would already have had a covariant override of clone, I believe the
>> changes to clone on these three methods is fine. (This avoid the hazards
>> outlined in JDK-7140820: (coll) Add covariant overrides to Collections
>> clone methods.)
>>
>> Thanks,
>>
>> -Joe