geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Barrett <>
Subject First Iteration on Java Module Support
Date Wed, 28 Nov 2018 22:53:19 GMT

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

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message