geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@pivotal.io>
Subject Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Date Mon, 26 Nov 2018 23:24:30 GMT
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 <dsmith@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 <onichols@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
>

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