Primitive-parametrized classes covariance with pre-existing specialized types

[Olexandr Rotan]

I have been reading through JEP 402: Enhanced Primitive Boxing, and
"Overriding, overloading, and type arguments inference (
https://openjdk.org/jeps/402#:~:text=Overriding%2C%20overloading%2C%20and%20type%20arguments%20inference)
section has caught my mind. I am here only speaking as a user, as I have
virtually no idea on how new primitives work in valhalla.

I am currently working on some Stream API enhancements and its internals
have become really complicated as time passed, mainly (imo), due to
primitive-specialized pipelines. JEP 402, at first glance, looked like
salvation, but the more I think about it, the more problems I see with
integrating legacy with new features. Specialized stream pipelines are
wired with specialized functional interfaces (ToXFunction,
XPredicate etc.). This (and also some specialized for primitive ops of
streams), make it impossible to harmlessly switch from XStream to Stream<X>
(where X is primitive).

While the second issue (specialized methods) could be addressed separately,
one thing that could certainly help with eventually moving on from
primitive-specialized types induced mess in current APIs is introducing
covariance between generic types and their specialized versions. It is
intuitive that ToLongFunction<T> is essentially the same as Function<T,
long>. I saw a note at the end of the JEP that Long! and long are not fully
interchangeable for some internal for JVM reasons, but the API that these
interfaces provide are exactly the same. I understand that if public APIs
that types provide are similar, that still doesn't mean their behaviour is
the same, but while it does not mean it, it could be the case (and is a
case in huge amounts of situations as when it comes to specialized types).

If such covariance would be present in language, huge amounts of code could
be just clamped as they are no longer needed. For example, whole
IntPipeline could be clamped to IntPipeline extends ReferencePipeline<int>
{ /* proprietary methods of IntStream */ } instead of virtually a second
ReferencePipeline class but specialized for int. This example is just the
thing that is closest to me right now, but I am sure anyone could think of
a way where this could be helpful for them.

I am not really sure how this is implementable in a way that does not
weaken the type system though. We can't just let users write that class A
is covariant to class B<X> or something like that for obvious reasons. The
easiest solution is to just add some compiler rules for a pre-defined
number of types in jdk, but this still will leave all library devs and just
users that had to write specialized types for some reason stranding. The
rules for this covariance could surely be a topic of discussion for more
experienced developers than me, but to have this feature would be a
dramatic step forward in Java.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240515/ae0b2061/attachment.htm>