RFR 8042003: java/lang/Math tests have external dependency on sun.misc.DoubleConsts and sun.misc.FloatConsts

[Joe Darcy]

On 08/19/2014 06:50 AM, Amy Lu wrote:
> On 8/19/14, 3:09 AM, Mandy Chung wrote:
>> On 8/18/14 12:49 AM, Amy Lu wrote:
>>> There are jdk tests that have dependency on sun.misc.DoubleConsts 
>>> and sun.misc.FloatConsts.
>>> This fix is to remove above internal API dependency from the tests.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8042003
>>> webrev: http://cr.openjdk.java.net/~ewang/amylu/JDK-8042003/webrev.00/
>>>
>> In addition to Joe's comment, DoubleUtils and FloatUtils are
>> needed by test/java/lang/Math/Tests.java and a few other math
>> tests.  It may be better to include them in test/java/lang/Math
>> rather than in the testlibrary.
>>
>>
>> Mandy
>>
>
> Thank you Mandy and Joe for your comments!
>
> To confirm, DoubleUtils and FloatUtils contain *only* constants that 
> are not defined in java.lang.{Float, Double}, and tests fixed by using 
> constants from 1) java.lang.{Float, Double} if constants defined 
> there; 2) DoubleUtils and FloatUtils only for additional constants 
> that are not in java.lang.{Float, Double}.
>
> DoubleUtils and FloatUtils now moved to test/java/lang/Math, the 
> updated patch:
>
> http://cr.openjdk.java.net/~ewang/amylu/JDK-8042003/webrev.01/
>

The uses of DoubleUtils and FloatUtils now look okay, but I have some 
additional comments on the contents of those types. First, I think these 
type are better named "DoubleConsts" and "FloatConsts" since they only 
have constants defined in them. As such, they should be derived works of 
the sun.misc.{FloatConsts, DoubleConsts} types:

* Inherit starting copyright dates of those types
* Use "float" and "double" to talk about the types rather than "Float" 
and "Double"
* Include the private constructor and static initializer to check for 
correctness conditions as in the sun.misc types

Changing the simple names of the new types to match the old types will 
also have the benefit of greatly reducing the size of the patch.

(In the new files, more recent javadoc conventions should be follow 
{@code foo} rather than <code>foo</code>, etc.)

Thanks,

-Joe