-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Java flow dsl lower bounds #24575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java flow dsl lower bounds #24575
Conversation
Test FAILed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I guess
* | ||
* {{{ | ||
* Source<Apple, NotUsed> apples = null; | ||
* Source<Orange, NotUsed> oranges = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps use Source.empty
in such examples instead of null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ups, yes, indeed, copy pasta from the test.
@@ -14,7 +14,8 @@ final class BidiFlow[-I1, +O1, -I2, +O2, +Mat]( | |||
override val shape: BidiShape[I1, O1, I2, O2] | |||
) extends Graph[BidiShape[I1, O1, I2, O2], Mat] { | |||
|
|||
def asJava: javadsl.BidiFlow[I1, O1, I2, O2, Mat] = new javadsl.BidiFlow(this) | |||
def asJava[JI1 <: I1, JO1 >: O1, JI2 <: I2, JO2 >: O2, JMat >: Mat]: javadsl.BidiFlow[JI1, JO1, JI2, JO2, JMat] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's some signature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
;(
Test PASSed. |
Test PASSed. |
Test PASSed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the change is the right way to go, the question is under which conditions we can pull it off.
I also tried things back when @johanandren was working on it to find out whether there are better solutions but it seems that Java doesn't offer anything better. I guess the main reason why there is no better support in Java is that most collections are mutable and therefore must be invariant so the support for covariant data types is just too limited.
I wonder though, if this isn't a bug in the Scala compiler as well because it creates unsafe generic signatures. Shouldn't it create generic signatures that are just not usable from Java instead of bailing out and silently allowing unsafe usage?
Needs, rebasing/merging btw. |
c70ec44
to
2ef76a6
Compare
Test FAILed. |
2ef76a6
to
c09e274
Compare
Test PASSed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I see how removing these lower type bounds also required removing co/contra ascriptions from the type parameters in Source/Flow/Sink/etc.
Also needs a rebase.
c09e274
to
342ff0a
Compare
Test PASSed. |
Fixes #24368
A bit on the fence about this, not source compatible and quite invasive.
However, the current situation is that methods that looks like they have a bound actually do not provide any type safety at all, for example this compiles fine and blows up later: