You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Owen Nichols <on...@pivotal.io> on 2018/11/20 00:54:31 UTC
[DISCUSS] Geode packages mustn't span Jigsaw modules
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
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Udo Kohlmeyer <ud...@apache.org>.
Geode-core provides suitable public alternatives, I'm sure Spring Data
Geode would be able to adapt and use the certified public API's.
--Udo
On 11/26/18 15:48, Dan Smith wrote:
> Our wire format and disk format generally does *not* depend on class names
> or packages. Internal classes implement DataSerializableFixedID and are
> sent using a fixed integer ID. So we should be able to move these classes
> around without affecting the on the wire format.
>
> I don't think we should shy away from changing *internal* packages. Worst
> case is that we break someone's code and encourage them to ask for a public
> API, which is a conversation we should be having anyway.
>
> But to allay some concerns I took a look at what internal classes spring
> data geode is using (on the master branch). I think all of these are in
> geode-core. So if we leave the packages in geode-core alone, SDG will be
> fine.
>
> import org.apache.geode.cache.query.internal.ResultsBag;
> import org.apache.geode.distributed.internal.DistributionConfig;
> import org.apache.geode.distributed.internal.InternalDistributedSystem;
> import org.apache.geode.distributed.internal.InternalLocator;
> import org.apache.geode.internal.DistributionLocator;
> import org.apache.geode.internal.GemFireVersion;
> import org.apache.geode.internal.InternalDataSerializer;
> import org.apache.geode.internal.cache.GemFireCacheImpl;
> import org.apache.geode.internal.cache.LocalRegion;
> import org.apache.geode.internal.cache.PartitionedRegion;
> import org.apache.geode.internal.cache.PoolManagerImpl;
> import org.apache.geode.internal.cache.UserSpecifiedRegionAttributes;
> import org.apache.geode.internal.concurrent.ConcurrentHashSet;
> import org.apache.geode.internal.datasource.ConfigProperty;
> import org.apache.geode.internal.datasource.GemFireBasicDataSource;
> import org.apache.geode.internal.jndi.JNDIInvoker;
> import org.apache.geode.internal.security.shiro.GeodePermissionResolver;
> import org.apache.geode.management.internal.cli.domain.RegionInformation;
> import
> org.apache.geode.management.internal.cli.functions.GetRegionsFunction;
> import org.apache.geode.management.internal.security.ResourcePermissions;
> import org.apache.geode.pdx.internal.PdxInstanceEnum;
> import org.apache.geode.pdx.internal.PdxInstanceFactoryImpl;
>
>
> On Mon, Nov 26, 2018 at 3:24 PM Kirk Lund <kl...@pivotal.io> 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 <ds...@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 <on...@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
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Dan Smith <ds...@pivotal.io>.
Our wire format and disk format generally does *not* depend on class names
or packages. Internal classes implement DataSerializableFixedID and are
sent using a fixed integer ID. So we should be able to move these classes
around without affecting the on the wire format.
I don't think we should shy away from changing *internal* packages. Worst
case is that we break someone's code and encourage them to ask for a public
API, which is a conversation we should be having anyway.
But to allay some concerns I took a look at what internal classes spring
data geode is using (on the master branch). I think all of these are in
geode-core. So if we leave the packages in geode-core alone, SDG will be
fine.
import org.apache.geode.cache.query.internal.ResultsBag;
import org.apache.geode.distributed.internal.DistributionConfig;
import org.apache.geode.distributed.internal.InternalDistributedSystem;
import org.apache.geode.distributed.internal.InternalLocator;
import org.apache.geode.internal.DistributionLocator;
import org.apache.geode.internal.GemFireVersion;
import org.apache.geode.internal.InternalDataSerializer;
import org.apache.geode.internal.cache.GemFireCacheImpl;
import org.apache.geode.internal.cache.LocalRegion;
import org.apache.geode.internal.cache.PartitionedRegion;
import org.apache.geode.internal.cache.PoolManagerImpl;
import org.apache.geode.internal.cache.UserSpecifiedRegionAttributes;
import org.apache.geode.internal.concurrent.ConcurrentHashSet;
import org.apache.geode.internal.datasource.ConfigProperty;
import org.apache.geode.internal.datasource.GemFireBasicDataSource;
import org.apache.geode.internal.jndi.JNDIInvoker;
import org.apache.geode.internal.security.shiro.GeodePermissionResolver;
import org.apache.geode.management.internal.cli.domain.RegionInformation;
import
org.apache.geode.management.internal.cli.functions.GetRegionsFunction;
import org.apache.geode.management.internal.security.ResourcePermissions;
import org.apache.geode.pdx.internal.PdxInstanceEnum;
import org.apache.geode.pdx.internal.PdxInstanceFactoryImpl;
On Mon, Nov 26, 2018 at 3:24 PM Kirk Lund <kl...@pivotal.io> 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 <ds...@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 <on...@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
> >
>
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <ds...@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 <on...@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
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Kirk Lund <kl...@pivotal.io>.
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 <ds...@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 <on...@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
>
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by John Blum <jb...@pivotal.io>.
@Galen - If a method is added to a Java interface (e.g. CacheListener),
then classes implementing the interface must define the method, or a
compile error will occur. This is true in the case where 1) the class
implements CacheListener directly rather than extending CacheListenerAdapter
and 2) where the added method on CacheListener is not a default method.
A few things/thoughts:
1) First, CLASSPATH does not go away, AFAIK. [1]
2) I am not intimately knowledgeable on (all things) JPMS yet, but a good
interim solution might be to opt for filename-based, "automatic modules" in
Geode. This perhaps does not solve the split package problem. But, as I
previously mentioned, I think having "internal" APIs is a problem that
needs to be solved before modularizing.
3) What percentage of users truly really care about JPMS yet? Java 9/10/11
deployments still pale in comparison to the number of Java 8 deployments
and will for the foreseeable future, especially with Oracle's new release
cadence and LTS policies, which many devs don't like.
Food for thought,
-j
[1] https://blog.joda.org/2018/09/from-java-8-to-java-11.html
On Mon, Nov 26, 2018 at 1:14 PM Jacob Barrett <jb...@pivotal.io> wrote:
> Before we get to far off the intention of this discussion, let's refocus.
> The purpose of the this discussion isn’t to find the “best” modules
> solution but rather to find one that is “good enough” to allow Geode 1.x to
> work in a Java 11 world with a reasonable user experience. While we can run
> the server effectively in Java 11 we cannot consume modules nor be consumed
> as modules by a modularized Java 11 application. Whatever steps we take in
> Geode 1.x will likely be thrown away for a solid solution for 2.x.
>
> So the question is:
> 1) Is refactoring internal to avoid the split packaging issue have a
> significant negative impact on downstream projects that currently use
> internal classes due to deficiencies in our public APIs? If so, what are
> the impacts and can we minimize them in other ways?
>
> 2) Would an uber module be a safer and less negatively impactful solution
> than option 1?
>
> 3) Is there some other interim solution nobody has thrown out yet?
>
> -Jake
>
>
--
-John
john.blum10101 (skype)
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Jacob Barrett <jb...@pivotal.io>.
Before we get to far off the intention of this discussion, let's refocus. The purpose of the this discussion isn’t to find the “best” modules solution but rather to find one that is “good enough” to allow Geode 1.x to work in a Java 11 world with a reasonable user experience. While we can run the server effectively in Java 11 we cannot consume modules nor be consumed as modules by a modularized Java 11 application. Whatever steps we take in Geode 1.x will likely be thrown away for a solid solution for 2.x.
So the question is:
1) Is refactoring internal to avoid the split packaging issue have a significant negative impact on downstream projects that currently use internal classes due to deficiencies in our public APIs? If so, what are the impacts and can we minimize them in other ways?
2) Would an uber module be a safer and less negatively impactful solution than option 1?
3) Is there some other interim solution nobody has thrown out yet?
-Jake
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Galen O'Sullivan <go...@pivotal.io>.
>
> If you want to
> maintain an API as internal, then you should properly protect that API with
> the appropriate *Java* access modifiers (private, package-private and
> protected).
>
Hopefully modules will allow us to do this better, by restricting which
*classes* are visible outside the module. However, Java doesn't have a
concept of submodules, which means there's no way to make
org.apache.geode.cache.tier.sockets visible to org.apache.cache or
org.apache.cache.tier without also being visible to everything. We can't
make InternalCache (for example) only visible to our own code without
declaring it package-private and putting (effectively) all of Geode in the
same package.
Adding a method to
> an interface, is an API breaking change.
>
I don't agree with this. If a new method is added, old API works just fine,
and unless I'm mistaken (and I may be), any code that used the old
interface should be able to use the new interface without issues.
Galen
On Mon, Nov 26, 2018 at 12:13 PM John Blum <jb...@pivotal.io> wrote:
> *> Most of these are in internal packages, which means we can change the
> package of these classes without breaking users.*
>
> I don't agree with this.
>
> Some functionality in Geode required by an application, or framework, is
> only available in an "internal" package, unfortunately. This has to do
> with the fact that many interfaces in Geode were not well designed.
>
> In general, and as a general rule of thumb, anytime you change a method
> name or method signature, it is an API breaking change. Adding a method to
> an interface, is an API breaking change. Removing methods from an
> interface is (potentially) an API breaking change. Changing a type is an
> API breaking change. There are several other examples. Any class/method
> (dare I say field of a class) that is not "properly protected" is part of
> your API, regardless if we deem it be "internal" only or not, and
> (possibly) will affect users.
>
> I think any level of modularity (and maturing) is pointless without 1)
> first, having well defined contracts/interfaces between functional areas
> (based on concerns) and 2) using appropriate access modifiers and cleanly
> delineating APIs/SPIs from implementations/providers.
>
> -j
>
>
>
> On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <ds...@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 <on...@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
> >
>
>
> --
> -John
> john.blum10101 (skype)
>
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by John Blum <jb...@pivotal.io>.
*> Most of these are in internal packages, which means we can change the
package of these classes without breaking users.*
I don't agree with this.
Some functionality in Geode required by an application, or framework, is
only available in an "internal" package, unfortunately. This has to do
with the fact that many interfaces in Geode were not well designed.
In general, and as a general rule of thumb, anytime you change a method
name or method signature, it is an API breaking change. Adding a method to
an interface, is an API breaking change. Removing methods from an
interface is (potentially) an API breaking change. Changing a type is an
API breaking change. There are several other examples. Any class/method
(dare I say field of a class) that is not "properly protected" is part of
your API, regardless if we deem it be "internal" only or not, and
(possibly) will affect users.
I think any level of modularity (and maturing) is pointless without 1)
first, having well defined contracts/interfaces between functional areas
(based on concerns) and 2) using appropriate access modifiers and cleanly
delineating APIs/SPIs from implementations/providers.
-j
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <ds...@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 <on...@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
>
--
-John
john.blum10101 (skype)
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Jacob Barrett <jb...@pivotal.io>.
If Dan's assertions are correct, and we can in fact refactor all these
packages without API changes, then I am all for giving it a shot. Worst
case we have done a little of the work we will have to do for a 2.0 api
change anyway and have to revert to the idea of an uber jar.
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <ds...@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 <on...@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
>
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by John Blum <jb...@pivotal.io>.
I need more time to think about this clearly (currently juggling multiple
things), but I would say this...
I don't think there should be "internal" APIs, as in o.a.g.*.internal.
There are only APIs/SPIs and implementations, period. If you want to
maintain an API as internal, then you should properly protect that API with
the appropriate *Java* access modifiers (private, package-private and
protected).
-j
On Mon, Nov 26, 2018 at 11:29 AM Jacob Barrett <jb...@pivotal.io> wrote:
> On Mon, Nov 26, 2018 at 11:23 AM Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
>
> > Imo, no module should export "internal". Maybe a stretch goal, but
> > something we should keep in mind.
> >
>
> Yes, agreed, but outside the scope of this current discussion.
>
--
-John
john.blum10101 (skype)
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Jacob Barrett <jb...@pivotal.io>.
On Mon, Nov 26, 2018 at 11:23 AM Udo Kohlmeyer <uk...@pivotal.io>
wrote:
> Imo, no module should export "internal". Maybe a stretch goal, but
> something we should keep in mind.
>
Yes, agreed, but outside the scope of this current discussion.
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
Imo, no module should export "internal". Maybe a stretch goal, but
something we should keep in mind.
On 11/26/18 10:50, Jacob Barrett wrote:
> One lingering question I have around jigsaw is the split package issue
> recursive? In that I mean if a module exports "org.apache.geode.internal"
> and another module exports "org.apache.geode.internal.foo" is this legal?
>
> On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <ds...@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 <on...@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
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Jacob Barrett <jb...@pivotal.io>.
One lingering question I have around jigsaw is the split package issue
recursive? In that I mean if a module exports "org.apache.geode.internal"
and another module exports "org.apache.geode.internal.foo" is this legal?
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <ds...@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 <on...@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
>
Re: [DISCUSS] Geode packages mustn't span Jigsaw modules
Posted by Dan Smith <ds...@pivotal.io>.
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 <on...@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