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