Future is now based on Executor instead of ExecutorService about vavr-gwt HOT 6 CLOSED

Would it be worth to automatically extract these from source jars as part of the build process? Then it would be always actual.

I think it s too complicated... In addition to copying, there is still a lot to be changed

from vavr-gwt.

On my machine a mvn clean test runs ok (it depends on 1.0.0-SNAPSHOT):

@ruslansennov the vavr-gwt/src/main/resources/**/* stuff seems fragile to me. I would suggest to exclude the whole io.vavr.concurrent package from vavr-gwt. Does Multithreading make sense in the GWT part of a Javascript application?

The super.io.vavr.concurrent.FutureImpl seems to be outdated. Do we have to copy/paste the source all the time when we make changes to Vavr's FutureImpl? How do we know which dependencies need to be included as part of the super package for GWT? And how do we know if we can remove dependencies again, when they are not needed anymore?

This all seems a bit fragile to me 🤔

from vavr-gwt.

super.io.vavr.concurrent.FutureImpl must have the same signatures as io.vavr.concurrent.FutureImpl. I'll try to fix it soon.

from vavr-gwt.

Great, thx!
Would it be worth to automatically extract these from source jars as part of the build process? Then it would be always actual.

from vavr-gwt.

Does Multithreading make sense in the GWT part of a Javascript application?

I'm not familiar with js, but I can image an exotic situation when Future is very useful. It could be the implementation of Executor on workers (is it possible?). Future will be still single threaded, but asynchronous.

from vavr-gwt.

Yes, Javascript has a notion for async processing. It is Promise in ES6, similar to our Future. In ES7 there is also an async keyword.

from vavr-gwt.