RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]

[Joe Darcy]

On Wed, 23 Oct 2024 00:53:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add equals/hashCode implementation; tests to follow.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 60:
> 
>> 58:  * either {@link Float}/{@link Double} or {@link Math}/{@link
>> 59:  * StrictMath}. Unless otherwise specified, the handling of special
>> 60:  * floating-point values such as {@linkplain #isNaN(Float16) NaN}
> 
> That said, and given Float has "equivalenceRelation" and "decimalToBinaryConversion" anchors, do we need similar anchors here that redirects to the Double ones?

Reasonable suggestion; I'll put the same kind of pointers into java.lang.Double sections as java.lang.Float has.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 405:
> 
>> 403:      * @return the {@code Float16} value represented by the string
>> 404:      *         argument.
>> 405:      * @throws NullPointerException  if the string is null
> 
> Should we move this NPE clause to the class specification, i.e. `Unless otherwise specified, all methods in this class throw {@code NullPointerException} when passed a {@code null}`? I think this applies to the APIs taking `BigDecimal` and static methods taking `Float16`. (Note we need to explicitly exclude `equals`)

Hmm. I'm trying to keep parity between Float16 and java.lang.{Float, Double}. Float/Double don't include the class-level statement so I wouldn't include on in Float16 until they do. Writing Float16 has prompted several other improvements to Float/Double, so a null-handling statement is something worth considering.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813577592
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813570930