@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 <jbarr...@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)
