<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div dir="ltr" class="">
<div class="">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.
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Slight correction: the internals were complicated from day 1, for this reason. This is not something that “happened over time”; the hand-specialization was part of its fundamental complexity. </div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<div dir="ltr" class="">
<div class="">JEP 402, at first glance, looked like salvation</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>You are mistaking JEP 402 for the full sweep of the Valhalla project. Indeed, Valhalla grew out of the observations of the painfulness of hand specialization (among other challenges). But before we can get to full generic specialization with both layout
and code specialization, we have to cover some fundamentals first. There are many steps along the way here. We walk before we can run. </div>
<div><br class="">
</div>
<div>What you are asking for is to blur the distinction between nominal and structural function types, allowing Predicate<T> and Function<T, boolean> to be considered “the same” in some way. While this is in some sense natural, this sort of “anything goes”
flexibility that incorporates both nominal and structural subtyping creates new problems, and even if not, is unlikely to move us very far in the direction of “IntStream is-a Stream<int>”. </div>
<div><br class="">
</div>
<div>Rest assured that we share your goal, but the path to get there is somewhat longer.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<div dir="ltr" class="">
<div class="">, 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). </div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.<br class="">
<h1 style="font-size: 13pt; padding: 0pt; margin: 0ex 0.5ex 1ex 0pt; font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica;" class="">
<br class="">
</h1>
</div>
<div class="">Regards</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>