jetlang/core

core's Issues

PoolFiber backed by same thread never fulfills tasks after call to `start`

Hi,

The following code will never terminate:

Fiber fiber = new PoolFiberFactory(Runnable::run).create();
fiber.start();

CompletableFuture<Integer> future = supplyAsync(() -> 1, fiber)
    .thenCompose(x -> supplyAsync(() -> x + 2, fiber));

System.out.println(future.join());

Although the backing executor on its own works as expected:

Executor sameThread = Runnable::run;

CompletableFuture<Integer> future = supplyAsync(() -> 1, sameThread)
    .thenCompose(x -> supplyAsync(() -> x + 2, sameThread));

System.out.println(future.join());

At least one use case for this is to avoid instantiating a bunch of unnecessary threads in test code.

The above behavior feels like a bug -- is there any reason it would be expected or desired behavior?

ThreadFiber executes pending commands after dispose, PoolFiber does not

We've been using jetlang 0.2.5 for few years and decided to update all of the third party libraries used by our framework. After updating to version 0.2.12, some of our unit tests failed and I investigated the reasons.

The cause is a change from 2012 in PoolFiber. Since then, pending commands will not be executed anymore after calling dispose() on the fiber. This is in contrast to the ThreadFiber, that still executes pending commands. Is this an intentional difference in behaviour or just an unwanted side effect caused by a fix? Which kind of behavior should be expected from a fiber? Should all fibers behave the same way?

In our case, we have a callback that is called when the fiber is stopped. During and after this callback, no other commands should be executed. Until now, I cancelled all subscriptions and added the callback to the execution queue of the fiber, then disposed it. This still works with ThreadFiber, but not with PoolFiber (probably prevented by isRunning in https://github.com/jetlang/core/blob/master/src/main/java/org/jetlang/fibers/PoolFiber.java#L61). I fixed this by disposing the fiber only after the callback was invoked (using a CountDownLatch and blocking the calling thread), so for us, it is no big deal. I just wonder whether all fibers should behave the same way.

@FunctionalInterface on functional interfaces

Jetlang contains a few widely-used interfaces which contain a single abstract method with no method-level type parameters. These are therefore "functional interfaces", and can be implemented with lambda expressions and method references. The primary example would be Publisher, but Filter, Callback, and Converter are others. In my code, all of these are often implemented by lambdas and method references, probably even a majority of the time.

Java has an annotation, @FunctionalInterface, to mark functional interfaces. It's purely a marker annotation, and has no functional consequences, so these interfaces are just as usable without it as with it.

With one substantial exception: IntelliJ will only consider an interface as the target of an Extract Functional Parameter or Extract Functional Variable refactoring if it is annotated with @FunctionalInterface! I lean very heavily on IntelliJ's refactorings, including that one, and when i'm doing Jetlang plumbing, it's a definite drag not to be able to quickly extract something into a Publisher or whatever.

So, could we add @FunctionalInterface to functional interfaces where possible?

I'm happy to submit a PR to that if so.