We can address package changes in the geode-old-client-support module.
That module is integrated with our serialization for this very purpose.
Most of our DataSerializable classes implement DataSerializableFixedID,
so they can be repackaged w/o any ramifications. Classes that don't fit
that category are mostly subclasses of Throwable or Function.
On 11/26/18 3:24 PM, Kirk Lund wrote:
One problem about moving around internal classes is that Geode uses
(proprietary and Java-based) serialization on the wire instead of defining
a wire-format that isn't dependent on class names/structures/packages.
I for one would love to move to a real wire-format with a well-defined
protocol but that's probably a separate project in its own right.
Are you really convinced that we could move internal classes around without
breaking rolling upgrades, client-server backwards compatibility and
diskstore contents?
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <dsm...@pivotal.io> wrote:
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
