search

sbt / ipcsocket

IPC: Unix Domain Socket and Windows Named Pipes for Java
Other
45 stars 16 forks source link

Add JNI implementations for graalvm native-image compatibility #8

Closed eatkins closed 4 years ago

eatkins commented 4 years ago

This PR reworks the project so that the client and server socket classes for posix and windows platforms have both jni and jna implementations. The reason for this is to support building a native sbt client using graalvm. JNA does not work well with the graalvm native-image tool.

eed3si9n commented 4 years ago

The title of this PR is "GraalVM support", but basically this PR is more like "Add JNA implementation"?

Also how does this affect the build / release process? Is there going to be a single universal JAR that can handle all platforms, or do we need to build one per platform?

eatkins commented 4 years ago

The title of this PR is "GraalVM support", but basically this PR is more like "Add JNA implementation"?

Title changed.

Also how does this affect the build / release process? Is there going to be a single universal JAR that can handle all platforms, or do we need to build one per platform?

This shouldn't require major changes to either building or releasing the library. New versions of the native libraries are built and uploaded to appveyor with each PR: https://ci.appveyor.com/project/sbt/ipcsocket/build/job/k0lpl67j8avs6gu9/artifacts https://ci.appveyor.com/project/sbt/ipcsocket/build/job/lcit981famoq1acy/artifacts These libraries are checking into src/main/resources so they are automatically packaged as part of jar building. The single jar contains all three implementation libraries so it is still a universal library though a bit bloated by the presence of platform specific files.

The safest way to make a release would be to download the binaries generated by the last commit and then check them in to a new commit from which the release is actually made. This step isn't strictly necessary though if no changes have been made to the *.c files since the last release. The artifacts contain some content that changes every time they are rebuilt so if we update the binaries when there have been no *.c source file changes, we will see a binary diff. This isn't harmful. Both binaries will work equivalently but it does increase the size of the git repository. Given how rarely we release ipcsocket, this is unlikely to ever matter so the most prudent thing is to just check in the latest binaries whenever we make a release.

eed3si9n commented 4 years ago

The safest way to make a release would be to download the binaries generated by the last commit and then check them in to a new commit from which the release is actually made. This step isn't strictly necessary though if no changes have been made to the *.c files since the last release.

ok. If that's a manual process, could we add an instruction in DEVELOPING.md?

eatkins commented 4 years ago

Instructions added: https://github.com/eatkins/ipcsocket/blob/jni-implementations/DEVELOPING.md.