Create RS <-> JDK9 bridge jar

[viktorklang]

Reactive Streams are available in JDK9 inside: java.util.concurrent.Flow.
Providing converters between org.reactivestreams.* and java.util.concurrent.Flow.* would be quite useful.

I propose to add a subproject/jar to the reactive streams project.

[akarnokd]

Sounds good but IDE support for JDK 9 is limited, at least Eclipse can't properly use a JDK 9 installment. Same may be true with travis: no oraclejdk9 yet therefore some sudo trickery may be required.

[viktorklang]

@akarnokd That's a good point, it ought to be possible to install the jdk9 from java.net and compile-package-publish locally.

[ktoso]

Figuring out how to use JDK9 with gradle may be tricky as well, though there is some support coming already https://github.com/gradle/gradle/blob/master/design-docs/jdk9-support.md
I gave it a shot for an hour but wasn't yet able to make it work yet, needs some more research how to use it.
Help from gradle gurus would be most helpful I guess :)

[viktorklang]

I wonder if sbt will be able to use jdk9 OOTB.

[ktoso]

I wonder if sbt will be able to use jdk9 OOTB.

Currently I don't think it will...

And it's a bit more than "using jdk9", we need to be able to compile module-info.java into module-info.class, AFAICS this needs additional command line params, for javac to know where to look for modules. Here's a sample project and how to use javac to compile: https://github.com/ktoso/jdk9-module-sandbox

[smaldini]

Good idea we already do that with reactor and it actually passes the normal TCK: Publishers.convert(Flow.Publisher) (not sure the other way is that useful). That would be great to get that in some common jar indeed. However I failed a few tests with SubmissionPublisher so worth having a common look!

Sent from my iPhone

On 2 Nov 2015, at 8:43 p.m., Viktor Klang (√) [email protected] wrote:

Reactive Streams are available in JDK9 inside: java.util.concurrent.Flow.
Providing converters between org.reactivestreams.* and java.util.concurrent.Flow.* would be quite useful.

I propose to add a subproject/jar to the reactive streams project.

—
Reply to this email directly or view it on GitHub.

[akarnokd]

However I failed a few tests with SubmissionPublisher so worth having a common look!

Is there something wrong with SubmissionPublisher?

[akarnokd]

Here is a single utility class that does the conversions.

[viktorklang]

Nice one, David!

It would be useful having the converters also introspected the parameters
to avoid nesting.

if (rsPublisher instanceof Flow.Publisher) return
(Flow.Publisher)rsPublisher;
else …

On Wed, Nov 11, 2015 at 4:58 PM, David Karnok [email protected]
wrote:

Here is https://gist.github.com/akarnokd/8f1a3e31882c076c704f a single
utility class that does the conversions.

—
Reply to this email directly or view it on GitHub
#294 (comment)
.

Cheers,
√

[akarnokd]

If one implements both APIs, it should show up in the type and there is no need to call the conversion methods.

[viktorklang]

toFlow(toReactive(flowA)) should return flowA

Cheers,
√
On 14 Nov 2015 15:21, "David Karnok" [email protected] wrote:

If one implements both APIs, it should show up in the type and there is no
need to call the conversion methods.

—
Reply to this email directly or view it on GitHub
#294 (comment)
.

[akarnokd]

In this case, toFlow has to check if Publisher is the bridge's own type, look into it and extract the original flow. This is not available with the current lambda form. Since both wrappings are really thin, it doesn't really matter if one goes instanceof + cast or let the JIT inline the calls.

[viktorklang]

Does the HotSpot JIT inline N-level nestings? And how would it trace this
when you pass the instance around?

On Sat, Nov 14, 2015 at 3:54 PM, David Karnok [email protected]
wrote:

In this case, toFlow has to check if Publisher is the bridge's own type,
look into it and extract the original flow. This is not available with the
current lambda form. Since both wrappings are really thin, it doesn't
really matter if one goes instanceof + cast or let the JIT inline the calls.

—
Reply to this email directly or view it on GitHub
#294 (comment)
.

Cheers,
√

[akarnokd]

By default, HS inlines something like 20 levels deep as far as I remember but this can be increased with command line parameters. But why would you want to have such pass-through wrap-unwrap in a codebase? I think the dev should recognize this as being unnecessary and simply not do it.

[viktorklang]

Having written a couple of these converters in the past, you'll be amazed
how people use them. Having things end up like a N-level nested data
structure which could be prevented with a simple branch is a cheap price to
pay in order to avoid some pretty weird error reports. :)

On Sat, Nov 14, 2015 at 8:27 PM, David Karnok [email protected]
wrote:

By default, HS inlines something like 20 levels deep as far as I remember
but this can be increased with command line parameters. But why would you
want to have such pass-through wrap-unwrap in a codebase? I think the dev
should recognize this as being unnecessary and simply not do it.

—
Reply to this email directly or view it on GitHub
#294 (comment)
.

Cheers,
√

[He-Pin]

@akarnokd It is needed,as you can take a look at the ForkJoinPool 's code.

[akarnokd]

Fine, I've updated the bridge to do the checks, casts and unwrapping if necessary.

[viktorklang]

@akarnokd Excellent! Thank you

[viktorklang]

@akarnokd Would you like to contribute it to reactive-streams-jvm?

[akarnokd]

Sure.

[viktorklang]

Fantastic! Would you mind opening a PR?

[akarnokd]

I know very little about Gradle, subprojects or how to setup a JDK 9 environment.

[viktorklang]

Same here, but having a PR means that more people can help out.
Collaborating via Gists is slightly less fun :)

On Sat, Nov 21, 2015 at 10:15 PM, David Karnok [email protected]
wrote:

I know very little about Gradle, subprojects or how to setup a JDK 9
environment.

—
Reply to this email directly or view it on GitHub
#294 (comment)
.

Cheers,
√

[akarnokd]

There is already a bridge PR waiting for Java 9/Travis/Gradle to be operational.

Also implementing both interfaces at the same time causes ambiguities, plus requires internal bridging if you don't want to duplicate logic.

interface MixPublisher<T> extends 
org.reactivestreams.Publisher<T>, java.util.concurrent.Flow.Publisher<T> { }

interface MixSubscriber<T> extends
org.reactivestreams.Subscriber<T>, java.util.concurrent.Flow.Subscriber<T> { }

MixPublisher<T> p = ...
MixSubscriber<T> s = ...

p.subscribe(s);
 ^               
  ambiguous overload

[rotilho]

Sorry I deleted my previous comment by mistake. I already took a look however add the bridge IMO will make things more complicate. My idea is make the reactive-streams extends the java9 classes, like

interface Publisher<T> extends Flow.Publisher<T> {}

and release a new module with org.reactivestreams:reactive-streams-java9

In this way we are not going to have ambiguities and it will allow all current implementation compatible with java 9 if running in java 9 environment.

The downside it will be the dependency management.

[viktorklang]

@rotilho That solution will not fly: jigsaw will choke on it and it will create classpath-order issues.

[viktorklang]

Awesome to be able to close this issue, @akarnokd! :)