I'm not the greatest expert on generics (in particular, in terms of
issues of retrofitting generics into existing public code without
breaking compatibility), but I'll note that the properties on an image
were always "documented" to be String->Object, but that was well before
generics and so we just accepted bare hash tables everywhere. Is it
possible to have at least some of the declarations of various properties
objects to be declared as <String, Object> even though we are loose on
the acceptance criteria in various constructors - or would that just
completely break compatibility. I know that we use type erasure so we
would never break binary compatibility, but there may be some places
where we can have them more strongly typed internally for now, but more
accepting at the external API level and then possibly consider improving
the externally-visible typing in future versions when a source
incompatibility is more appropriate?
(I'm asking because I don't understand all of the compatibility issues
that this might cause...)
...jim
On 10/2/13 3:02 AM, Artem Ananiev wrote:
java.awt.image is one of the Java2D packages, so I'm adding 2d-dev to
CC. Please, wait for at least one approval from Java2D team.
For easier review, I put the webrev here:
http://cr.openjdk.java.net/~art/srikalyc/8025684.00/
It looks fine to me. There is one "unchecked" warning still left, at
BufferedImage.java:645, it can be fixed by introducing a local variable
and @SuppressWarnings("unchecked"), but I'm not sure it's worth doing.
Thanks,
Artem
On 10/2/2013 1:51 AM, srikalyan chandrashekar wrote:
Hi team , could someone review the fix
Bug : https://bugs.openjdk.java.net/browse/JDK-8025684
Webrev :
https://github.com/srikalyc/JDKfixes/blob/master/java.awt.image.raw_unchecked_webrev.zip
Fix : Raw and unchecked warnings in AWT image classes fixed
