The ComponentColorModel implementation is a meaningless wrapper around
super.equals/hashCode(). Why does it not test CCM-specific fields?
The ComponentSampleModel.hashCode() method should be upgraded based on
the recommendations in Effective Java like the other methods here.
On 4/25/16 8:48 AM, Sergey Bylokhov wrote:
On 23.04.16 4:59, Jim Graham wrote:
So, I'd recommend that CM.equals() tests getClass() == getClass() at the
base level and then all others will use super.equals() and get the same
protection. It means you can't have a subclass of CCM be "equals" to
This version of the ICM.equals() method starts with casting the unkown
obj to ICM, which may throw a cast exception. That cast needs to be
moved down after the call to super.equals() ("this == cm" can just be
"this == obj").
In the ICM hashcode function, is there a reason that the hash
This all snowballed pretty far and wide. The original fix to Swing
icons was trivial in comparison. In retrospect it might be better to
simply offer the helper method from the original bug fix as a Toolkit
solution and force applications to adopt it when dealing with MR sources:
Hi Prahalad,
One potential portability issue - you have a "DeclareAndInit" macro for
the new "choose which blend factor" macro in the middle of a block.
Some C compilers allow declaring a new variable in the middle of a
block, but not all. Since it would be hard to move the declaration to
On 04/22/2016 06:56 PM, Jim Graham wrote:
Hi Jay,
It looks like it will work, but there are some inconsistencies in the
code that we should address and a couple of optimizations.
First, there is a mixture of using "int" and "jboolean" for the type
of the new boolean parameter. It would be
Phil and other client reviewers,
Please review this change from core libs which impacts client libs
implementations. In brief, deprecating a method in core reflection
requires uses of that method to have a @SuppressWarnings("deprecation")
annotation. The typical way to minimize the scope of
The patch is also available at
http://cr.openjdk.java.net/~aivanov/dmitry.batrak/8146035/jdk9/webrev.00/
The fix has been integrated into 9/client
https://bugs.openjdk.java.net/browse/JDK-8146035
and to 8u-dev
https://bugs.openjdk.java.net/browse/JDK-8154232
Regards,
Alexey
On 12.04.2016
