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 (√) notifications@github.com 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 notifications@github.com
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" notifications@github.com 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 notifications@github.com
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.