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.
-Joe
-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
