| Re: [ecf-dev] Java8 support |
On 4/1/2014 11:23 AM, Scott Lewis wrote:
<stuff deleted>
I've been playing around with this and I think this is the way to go...rather than having new providers as I originally did. This way...as described above...any/all distribution providers will 'just work' for ECF's async proxies...with CF on java8.
Here's a thought I just had: AbstractRemoteService currently extends Object. What if we added (in 3.8.1 and/or Juno) a superclass for AbstractRemoteService...e.g. call it AbstractService...in a new bundle. The <= java7 version of this abstract superclass would implement *only* callFuture...with no references to Java8 CF. The java8 version, however, would implement callFuture with the CF code as [1] does. I think this could work...it would retain backward compatibility...because adding a superclass is one of the few binary compatible changes to API that can be made. And for the two versions of this new bundle (<= j8 and j8+)...only one of them would/could resolve at runtime...based upon which version of java is being used. This may be it.
I've created this bug [1] to track, and I will report progress as comments on the bug. Please join the bug to contribute/assist for Luna.
We will have to figure out some way to build and test...with java8 for the java8-specific code (containing the AbstractRemoteService superclass) and java7 for everything else.
Thanks,
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=431756
Let me know what you think.
No matter what we do though...we will need to figure out a way to compile, build and test everything...i.e. the j8 bits and everything else...in a way that will allow java7 consumers of RS to continue to install and run appropriately.
Thanks,
Scott
[1] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.remoteservice.java8/src/org/eclipse/ecf/provider/internal/remoteservice/java8/J8RemoteServiceContainerAdapterFactory.java
Cheers,
Wim
On Mon, Mar 31, 2014 at 8:32 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Folks,
As some of you probably know, I've been working on Java8 support in ECF's implementation of OSGi remote services (see description below and on blog post). As of now, all of this work has been generalized and pushed to ECF's git repo...i.e. see the git links below.
Over the next few weeks, I'm going to write a tutorial on the use of CompletableFuture via ECF's asynchronous proxies...and put it in the wiki.
But...if we are going to build and deploy the java8 generic (and other) providers...along with the timeservice consumer and host examples...we will need to figure out how to build and deploy these 3 new bundles...since they depend upon java8...just to compile. Could Wim and/or Markus please comment on what's needed on our Jenkins instance to support this? ...and any additions we need should make (e.g. new features?).
Thanks,
Scott
5) Use of Java8 for asynchronous remote services. As many of you know, java8 has some new features that are very interesting/useful from a remote services perspective...see [5] for example. I intend to get this work into Luna...as well as a new wiki-based tutorial demonstrating via our example async time service code described in the blog...which is now checked in, BTW [5a]). This is really exciting, IMHO, because it's right at the intersection between remote services...which have a strong need for asynchronous/non-blocking semantics...the java8 async/concurrency/functional programming features...and ECF's ability to easily and efficiently support async proxies...through our provider architecture, underlying event-driven structure, and existing support for async proxies [5b].
[5] http://eclipseecf.blogspot.com/2014/03/completablefuture-for-osgi-remote.html
[5a] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.remoteservice.java8
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice.consumer.ds.async
[5b] https://wiki.eclipse.org/ECF/Asynchronous_Remote_Services
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev