[OpenJDK 2D-Dev] JDK 9: RFR: 8033716: Fix raw and unchecked lint warnings in com.sun.imageio
joe.darcy at oracle.com
Fri Feb 7 23:51:49 UTC 2014
On 2/7/2014 2:20 PM, Phil Race wrote:
> Yes, it should get 2d review and I will look at this soon as priorities
> permit but the *conclusion* is that the client team
> ask that such changes go into the client forest. If this is a problem for
> you then we will do it on your behalf. We do not want client changes
> directly into dev. That is a very polite but firm request.
If such changes are going to go into the client forest rather than dev,
there has to be some bounded timeline for the fixes to get integrated
from client into dev.
The client and dev forests were created back in December 2013. Since
then, there have been two promoted builds of JDK 9. The client forest
has not integrated yet into dev; in contrast, the HotSpot forest has
integrated into dev at least twice.
An implication of using a separate client forest for client library
fixes is that the forest has to be actively maintained, both syncing
down changes from dev regularly and integrating changes into dev regularly.
> 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?
>> On 02/05/2014 06:01 PM, Joe Darcy wrote:
>>> Hi Henry,
>>> On 02/05/2014 12:19 PM, Henry Jen wrote:
>>>> Please review the webrev to clean up raw and unchecked warnings in
>>>> com.sun.imageio packag at,
>>>> 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.
>>> 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
>>> Since there are no other potential subclasses of these com.sun.* type
>>> that would already have had a covariant override of clone, I believe
>>> changes to clone on these three methods is fine. (This avoid the
>>> outlined in JDK-7140820: (coll) Add covariant overrides to Collections
>>> clone methods.)
More information about the 2d-dev