| Re: [ecf-dev] Java8 support |
|
On 4/1/2014 10:40 AM, Wim Jongman
wrote:
Well, the main reason was expediency...and possibly a lack of imagination on my part :). WRT fragments...given that this is API we are talking about (i.e. the service API and the provider API), I could not figure out how to do it with fragments...without using the Equinox-specific manifest header: 'Eclipse-ExtensibleAPI: true'. I frankly wanted to avoid using this header, because it would be great if all of this can/could/would/will run on all OSGi frameworks (Equinox, Felix/Karaf, Concierge). WRT feature patches...I don't know how that would work...but maybe that's because of my lack of imagination. As an aside...I did put together a feature patch for Kepler (ECF core + filetransfer) so that Kepler users can use ECF 3.8.1/Luna without any problems conflicting with old versions of ECF core/filetransfer. So...I'm open to other alternatives than new/separate '.java8' providers...let's discuss here. To be clear...wrt the distribution provider support, there is now just one method in one class that has to be overridden to enable the completeablefuture/java8 support *all existing distribution providers*. That's this method: org.eclipse.ecf.remoteservice.AbstractRemoteService.callFuture(IRemoteCall, Class) For the generic java8 provider, here's the implementation [1]. If you look at the callFuture method, you will see that it *only* references java8's CF class and protected superclass (AbstractRemoteService) methods...which means it could be simply moved up to AbstractRemoteService itself...if org.eclipse.ecf.remoteservice could support java8. The good news is that it's only this callFuture method that has to be enhanced...nothing else. But moving this code into AbstractRemoteService is very tricky...because nearly everything having to do with OSGi remote services depends upon o.e.e.remoteservice...e.g. the OSGi remote services code as well as all providers...since it's an API bridging OSGi RS and ECF providers. It was my first inclination to implement AbstractRemoteService.callFuture as [1] does...but as per above...to do this would quickly mean that none of ECF's RS impl nor providers would run on < Java8. I would love to find a better way...to allow Java8 users to use *any* RS provider...at least any that extends AbstractRemoteService...with no changes...so please help figure this out. 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. 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
|