Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

ECF-CompletableFuture with Java 8


As you may be knowing, Completable Future is one of the latest features in Java 8(java.util.concurrent.CompletableFuture), and in the upcoming Luna release of Eclipse, there is support for it. It allows any OSGi(Open Source Group international) service to be remoted without blocking, thus increasing the overall efficiency of Framework. The ECF’s asynchronous proxies capability could be extended to support the use of Completable as a return type rather than a Future. Its now possible for asynchronous service interfaces to return a CompletableFuture:

Package first.package;

Import java.util.concurrent.CompletableFuture;

Public interface IHelloAsync {

Public CompletableFuture<String>bye(String from);

This is extremely helpful and a big improvement as far as asynchronous remote services and their working are concerned, as it's not necessary for the consumer to call Future.get (and possibly block) directly, and instead non-blocking calls such as the following can be written:

IHelloAsync helloAsync=...get remote service via DS/injections, ServiceTracker or other CompletableFuture<String> cf=helloAsync(“slewis”); cf.thenAccept((response) -> System.out.println("response to slewis helloAsync + response));


Benefits of CompletableFuture:

1.It is very helpful in service design, as remote service designers, may declare and implement normal OSGi remote services (IHello) without having to concern themselves with the consumer's invocation style (synchronous or asynchronous).

2.The remote service designers, they may declare and implement normal OSGi remote services (IHello) without having to concern themselves with the consumer's invocation style (synchronous or asynchronous).

3.There is no blocking of code written by Remote Service Consumers.

4.There are no extra class dependencies in the synchronous or asynchronous service interfaces (e.g. IBye and IByeAsync).

5.There is no need for either the host implementation or the consumer to implement the asynchronous service interface, other than a declaration of the aync interface such as IbyeAsync

6.Failure handling becomes easier, via CompletableFuture.handle. This is obviously a big improvement, for remote services, since they are quite dependent on network and hence, are prone to failure because of the network.


References:

https://wiki.eclipse.org/ECF/Asynchronous_Remote_Services http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html https://bugs.eclipse.org/bugs/show_bug.cgi?id=431756

Back to the top