Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

let getAsync and putAsync return ICompletableFuture #5315

Closed
valdo404 opened this issue May 15, 2015 · 6 comments

Comments

Projects
None yet
7 participants
@valdo404
Copy link

commented May 15, 2015

As for now it is very complicated to listen a getAsync or putAsync result and to integrate it with completable futures or listenable futures.

Would it be possible to return an ICompletableFuture since it is an interface which seems to extends jdk futures and is returned by an IMap ?

@valdo404 valdo404 closed this May 15, 2015

@valdo404 valdo404 reopened this May 15, 2015

@gurbuzali gurbuzali added this to the 3.6 milestone May 15, 2015

@gurbuzali

This comment has been minimized.

Copy link
Member

commented May 15, 2015

you can cast to ICompletableFuture as a workaround

@jerrinot

This comment has been minimized.

Copy link
Contributor

commented May 15, 2015

Hi @valdo404,
I understand the need, however it's quite tricky - returning a different type breaks binary compatibility. It doesn't matter the new type extents the original type - they are treated as different types when it comes to a method dispatch.

As @gurbuzali wrote you can cast return values of most async methods to ICompletableFuture - just be aware that doing so may slightly increase a risk of a migration to a newer version - as it relies on implementation details.

@valdo404

This comment has been minimized.

Copy link
Author

commented May 18, 2015

Well, considering futures and asynchronous requests, do you have a plan for the whole thing ? Sometimes when the data is loaded or written to/from a map loader, synchronous requests are bad.

@Tembrel

This comment has been minimized.

Copy link

commented May 18, 2015

Casting with a fallback should be safe enough:

    public static <T> ICompletableFuture<T> toCompletableFuture(
            Future<T> f, ExecutorService e) {

        if (f instanceof ICompletableFuture) {
            return (ICompletableFuture<T>) f;
        } else {
            return new CompletableFutureTask<>(() -> f.get(), e);
        }
    }

    public static <T> ICompletableFuture<T> toCompletableFuture(Future<T> f) {
        return toCompletableFuture(f, ForkJoinPool.commonPool());
    }

Note that I'm using lambda syntax from Java 8 for compactness, but this approach really only makes sense for Java 6/7 uses. (And the common pool is only available in Java 8, so you'd have to find your own default here.)

ICompletableFuture is an awkward but unfortunately necessary wart in migrating towards full use of Java 8 while retaining Java 6/7 compatibility. If you're using Java 8 and Hazelcast (as I am), you'll want to avoid it and move to java.util.concurrent.CompletableFuture wherever possible, hiding the details behind adapter functions analogous to the one above but using true Java 8 abstractions.

@enesakar enesakar modified the milestones: 3.6, 3.7 Nov 27, 2015

@LoneRifle

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2016

This issue is a duplicate of - and superseded by - #6999, and will be implemented by #7967.

@vbekiaris

This comment has been minimized.

Copy link
Contributor

commented Apr 21, 2016

Fixed by #7967

@vbekiaris vbekiaris closed this Apr 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.