If I understand this API correctly, Java won't get a distinct float16 type. It seems that they'll have 16 bit floats encoded in shorts (16 bit integers). This

If I understand this API correctly, Java won't get a distinct float16 type. It seems that they'll have 16 bit floats encoded in shorts (16 bit integers). This seems like it could be a huge footgun. A lot of methods already have an overload for short, so a completely separate set of functions are needed to do operations on them. I get that it's hard to introduce a 16 bit float as a new primitive type in the JVM, so that's most likely not an option. .NET introduced 16 bit floats as the "Half" type 2 years ago [1] and I think their approach is far superior. They're also saving it as a (u)short internally [2], but they have something that Java (still?) does not have: They made it a user-defined value type, or when using C# language: a struct. This doesn't create footguns because it is a separate type and also doesn't have any meaningful overhead. And since .NET 7 will introduce generic math [3], we'll seem to be able to use the same APIs as we've always done. IMHO, this is an API - just like Optional<T> - which could be far better designed if project valhalla would already be a thing. [1]: https://devblogs.microsoft.com/dotnet/introducing-the-half-type/ https://devblogs.microsoft.com/dotnet/introducing-the-half-t... [2]: https://github.com/dotnet/runtime/blob/d783badaa38596beedefd58b59e2f031ba37c410/src/libraries/System.Private.CoreLib/src/System/Half.cs#L95 https://github.com/dotnet/runtime/blob/d783badaa38596beedefd... [3]: https://devblogs.microsoft.com/dotnet/dotnet-7-generic-math/ https://devblogs.microsoft.com/dotnet/dotnet-7-generic-math/