core: remove reactive supports from jooby core

[jknack]

Today:

• Pipeline.java checks for return types using reflection and automatically setup a specific handler for rxjava, reactive, etc.

We want:

• Remove reflection usage from core for reactive types
• Move rxjava, reactive, etc to his own module

Solution 1:

• Use the existing response handler to discover new supported types (rxjava, reactive, etc) via service loader registry

Solution 2:

• Introduce a new reactive router

{
   ReactiveRouter router = Rxjava.newRouter(reactive -> {
      reactive.get("/rx", () -> Single
        .fromCallable(() -> "Single")
        .map(it -> "Hello " + it
     );
  });

  // Add to application
  mount(router);
}

In general want to remove the return type checks from core (ideally removing ASM from core) and reflection usage (check for loaded classes).

This will open the door to new/custom reactive libraries, see #1921

@imeszaros thoughts?

[imeszaros]

From user point of view, I would prefer solution 1. I don't think we should make the user responsible for creating a new router just to be able to use the reactive return types. Solution 2 would also mean that the ASM for MVC would be different then now?

Anyway the general idea is good I think, core should be as slim and flexible as possible, this is a step towards both.

[jknack]

Solution 2 would also mean that the ASM for MVC would be different then now?

No, none of them affect or change APT/MVC.

Will go with Solution 1.

[agentgt]

Dumb question but why not just support https://www.reactive-streams.org/ API in core (and then later Java 9 Flow).

The only reflection would be to check if you are in Java 9 and or above to access Flow: https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/Flow.html

Just the other day I tried to return a Reactive Streams Publisher and a Flow.Publisher and it did not work. Both of these were not RxJava or Reactor but they do implement the spec interfaces.

The only reason why you would want to support returning other types is for performance reasons of adding additional operations but since you are probably just consuming the stream I can't see why just supporting Reactive Streams isn't good enough unless you want to support RxJava 1.x.