Re: [ecf-dev] Java8 support

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 4/2/2014 12:37 PM, Wim Jongman wrote:

I'm not exactly sure what you mean. Doesn't the distribution of this new base class give you the same problems?

No, it gives a different..but easier set of problems :).

There's now a new bundle:  org.eclipse.ecf.remoteservice.asyncproxy.   This bundle exposes three abstract classes as described in comment [1].  One of which is now used as a superclass for org.eclipse.ecf.remoteservice.AbstractRemoteService (the new superclass is called AbstractAsyncProxyRemoteService).   The important method implemented by AbstractAsyncProxyRemoteService is callFuture...which for JRE < 8 [2] needs to use only Future (because CF doesn't exist in JRE < 8), but on JRE >= 8 can/should use CF to implement callFuture [3].

I've created two projects/two versions of org.eclipse.ecf.remoteservice.asyncproxy...version 1.0.0 which is for EEs < J8 and version 2.0.0 in project org.eclipse.ecf.remoteservices.asyncproxy.j8 which is for EE >= J8.   The only difference between these two versions of this bundle is that for 2.0  the impl of callFuture uses CF (and therefore requires J8), while the 1.0 version uses only Future (and therefore will run < J8). 

I've tried to setup the osgi.ee capability (Require-Capability) so that version 1.0 will only be wired/used at runtime if the underlying runtime EE is < J8...and 2.0.0 will only be used if the EE is >= J8.   What I'm trying to get at is that if/when both of these versions are deployed in a framework, only the JRE appropriate one will be used...i.e. so when the AbstractAsyncProxyRemoteService class is loaded (via AbstractRemoteService)...the appropriate one will be used.   I've got all this checked in as per [1][2][3]. 

I'm now struggling with how to modify the build so that it builds *only* the org.eclipse.ecf.remoteservice.asyncproxy.j8 with J8 compiler...but uses < J8 to compile everything else...and then puts both versions of this asyncproxy bundle in one target repo (for the HEAD-sdk build anyway).

Scott

[1]  https://bugs.eclipse.org/bugs/show_bug.cgi?id=431756#c1
[2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/framework/bundles/org.eclipse.ecf.remoteservice.asyncproxy/src/org/eclipse/ecf/remoteservice/asyncproxy/AbstractAsyncProxyRemoteService.java
[3] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/framework/bundles/org.eclipse.ecf.remoteservice.asyncproxy.j8/src/org/eclipse/ecf/remoteservice/asyncproxy/AbstractAsyncProxyRemoteService.java

 

On Wed, Apr 2, 2014 at 12:41 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

On 4/1/2014 11:23 AM, Scott Lewis wrote:

<stuff deleted>

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 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.

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

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev