adding rsockets support into JDK

[Alan Bateman]

On 12/09/2018 22:49, Brian Burkhalter wrote:
> :
>
> This change would move all of the existing Rdma* classes out of the 
> share tree into the linux tree. The implementation classes are also 
> decoupled from the jdk.net.Sockets API via reflection. I verified that 
> with this change the only Java files which are built on macOS are 
> RdmaProviderFactory and RdmaSocketOptions. I also verified that the 
> code builds and all the tests pass on Linux (Ubuntu 18.04 with 
> the librdmacm-dev package installed). Note that none of this addresses 
> the dlopen/dlsym issue which Alan raised.
>
> I added two packages here, jdk.net.internal and jdk.net.internal.rdma. 
> I don’t know that these are the best package names to use. Assuming 
> however that they are OK, then maybe you would want to move all the 
> Java code currently in the rdma.ch <http://rdma.ch> package into 
> jdk.net.internal.rdma in the linux-only tree.
>
> I am also wondering whether, assuming my changes in [1] or something 
> similar were in place, some of the other reflection currently in use 
> might be able to be removed and some of the classes consolidated. It 
> seems that if checks are done up front in something like 
> RdmaProviderFactory then they should not need to be redone elsewhere 
> given that the reflection in this factory isolates the RDMA-specific 
> code from the API points. (Note that in the RdmaProviderFactory static 
> initializer there still needs to be added a reflective check of 
> whether RDMA is available on the system.)
>
Lucy's mail reminded me to comment on this.

No objection to introducing 
jdk.net.internal.rdma.{SocketFactory,RdmaSocketFactoryRdmaProviderFactory} 
but it still means some ugly reflection in rdmaSocketProvider() to 
decide whether to return a provider or throw UOE. If you want something 
simpler just create a RdmaSocketImpl in shared code where the 
constructor throws UOE. The build will compile in this version on 
non-Linux platforms. We have a couple of other examples where platform 
specific classes shadow same named classes in share/classes.

jdk.internal.net.rdma seem okay to me for the package name (the webrev 
had jdk.net.internal.rmda which I assume wasn't intended).

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180915/071ecead/attachment.html>