I think we can actually fix most of these issues without geode-2.0. Most of these are in internal packages, which means we can change the package of these classes without breaking users. The only concerning one is org.apache.geode.cache.util, which is a public package. However, the AutoBalancer is actually still marked @Experimental, so we could technically move that as well. Or maybe deprecate the old one and it's associated jar, and create a new jar with a reasonable package. JDK11 users could just avoid the old jar.
I have been wondering for a while if we should just fold geode-cq and geode-wan back into geode-core. These are not really properly separated out, they are very tangled with core. The above package overlap kinda shows that as well. But maybe going through the effort of renaming the packages to make them java 11 modules would help improve the code anyway! -Dan On Mon, Nov 19, 2018 at 5:03 PM Owen Nichols <onich...@pivotal.io> wrote: > To package Geode as Java 11 Jigsaw module(s), a major hurdle is the > requirement that packages cannot be split across modules. > > If we simply map existing Geode jars to Modules, we have about 10 split > packages (see table below). Any restructuring would potentially have to > wait until Geode 2.0. > > A workaround would be to map existing packages into a small number of new > modules (e.g. geode-api and geode-internal). Existing jars would remain > as-is. Users making the transition to Java 11 /w Jigsaw already need to > switch from CLASSPATH to MODULEPATH so the inconvenience of a different > naming scheme for Geode-as-modules might be acceptable (however, once > module naming and organization is established, we may be stuck with it for > a long time). > > Thoughts? > > Is it even possible to rearrange all classes in each package below into a > single jar? Is doing so desirable enough to defer Java 11 support until a > yet-unplanned Geode 2.0, or perhaps to drive such a release? > > Or, is it satisfactory to fatten Geode releases to include one set of jars > for CLASSPATH use, plus a different set of jars for MODULEPATH use? > > > Package > Jar > org.apache.geode.cache.client.internal > geode-core-1.8.0.jar > geode-cq-1.8.0.jar > geode-wan-1.8.0.jar > org.apache.geode.cache.client.internal.locator.wan > geode-core-1.8.0.jar > geode-wan-1.8.0.jar > org.apache.geode.cache.query.internal.cq > geode-core-1.8.0.jar > geode-cq-1.8.0.jar > org.apache.geode.cache.util > geode-core-1.8.0.jar > geode-rebalancer-1.8.0.jar > org.apache.geode.internal > geode-connectors-1.8.0.jar > geode-core-1.8.0.jar > geode-cq-1.8.0.jar > geode-lucene-1.8.0.jar > geode-wan-1.8.0.jar > org.apache.geode.internal.cache.tier.sockets.command > geode-core-1.8.0.jar > geode-cq-1.8.0.jar > org.apache.geode.internal.cache.wan > geode-core-1.8.0.jar > geode-wan-1.8.0.jar > org.apache.geode.internal.cache.wan.parallel > geode-core-1.8.0.jar > geode-wan-1.8.0.jar > org.apache.geode.internal.cache.wan.serial > geode-core-1.8.0.jar > geode-wan-1.8.0.jar > org.apache.geode.internal.protocol.protobuf.v1 > geode-protobuf-1.8.0.jar > geode-protobuf-messages-1.8.0.jar
