All, We started iterating on a solution for supporting Java modules based applications linking to Geode as a module dependency. Now before you go, "but why didn’t you do X?”, let’s set some ground rules here. The initial goal was to get *a* solution, not the best solution, for linking and using basic client features, like get, put, query, cq, function execution, and serialization. To that end PR-2911 (https://github.com/apache/geode/pull/2911 <https://github.com/apache/geode/pull/2911>) provides a solution. It produces a fat jar containing a set of classes that make up the features stated in our goal. It presents itself as a module using automatic naming in the manifest as ‘org.apache.geode'. The corresponding POM includes all the the same dependencies that geode-core had so that an application can just depend on this new module artifact and get all the dependent modules as well. You can see how this plays out in a simple “Hello World” application at https://github.com/pivotal-jbarrett/geode-example-java-11 <https://github.com/pivotal-jbarrett/geode-example-java-11>.
Why the fat jar? If you make the application require ‘geode.core’ (automatic name for geode-core.jar) then you immediately fail to compile with split package errors on ‘org.apache.shiro’ dependencies. Shiro lacks a Java modules update (see scary Shiro comments below). Ignoring the Shiro issues, by commenting it out, we then hit the split package issues discussed in earlier discussions. A fat jar, which includes ‘geode-core’, ‘geode-cq’, and ‘shiro-core', solves this issue. The downside, besides another jar, is that Shiro is implicitly exported from our fat jar and this can cause issues if the application is also using Shiro (not likely given all the Shiro issues below). What’s wrong with Shiro? It is effectively a dead project. The last several board reports are copy and paste. The reports all indicate stalled interest on mailing lists. The last release was May of 2017 and since then has only had a handful of commits and activity. The last release, 1.4.0, actually worsened the split package issues and all PRs posted to fix it have gone unmerged. Shiro is required to be on the client class path so that we can load one of our classes that ultimately doesn’t even use Shiro. We could do a better job here so that we don’t have to leak Shiro onto the client class path. So what’s next? We are going to experiment with other solutions: - Fat module with module-info.java to hide Shiro and other internals - Requires that we find a way to compile classes for Java 8 and modules-info with Java 9+. - Existing jars as automatic modules - Need to get Shiro out of the client class path and only into the server runtime class path. - Correct split packages in geode-core and geode-cq - Existing jars as modules with module-info - All the requirements of "Existing jars as automatic modules”. - Requires that we find a way to compile classes for Java 8 and modules-info with Java 9+. We would love any input on the current state of this iteration as well as any hints at other things we should try. In the mean time a review and acceptance of this PR helps move us forward in the modules direction. Thanks, Jake
