> We need testing of Geode (both old and current versions) on older JVMs talking to Geode on newer JVMs.
It would be nice to support this, but I'm not sure we should. We support rolling upgrades between versions of Geode, but I'm not convinced we should support JDK mismatch within a live cluster. > what if Java built-in serialization changes in a way that breaks our code somehow? I just submitted a PR addressing the fact that this definitely happens. `java.io.Serialization` will just flat-out refuse to deserialize a class when running in Version X if it was compiled in Version >X. See GEODE-5850 / "exception java.lang.UnsupportedClassVersionError: <classname> has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0." On Thu, Oct 11, 2018 at 10:26 AM, Galen O'Sullivan <gosulli...@pivotal.io> wrote: > I think we should run some sort of backwards-compatibility tests between > Java 8 and Java 9/11+. We need testing of Geode (both old and current > versions) on older JVMs talking to Geode on newer JVMs. (for example, what > if Java built-in serialization changes in a way that breaks our code > somehow?) > > On Mon, Oct 8, 2018 at 2:50 PM Jinmei Liao <jil...@pivotal.io> wrote: > > > On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <u...@apache.org> wrote: > > > > > Should this not rather be a statement of.. "Running on JDK 11+" and not > > > 9+? Given that 9 + 10 are not in support anymore. > > > Also, when this is released, we will running on 11 rather than 9, or > > > what is the thought (end goal) with this effort? > > > > > Yes, let's for the sake of discussion, assuming jdk9+ here means jdk11+. > > > > > > > > > > Also does this effort cover some of the main additions to the JDK since > > > 9, which is the whole modularity theme? > > > > > Not yet. We are just trying to get a green pipeline to start with. > > > > > > > > > > --Udo > > > > > > On 10/8/18 14:11, Jinmei Liao wrote: > > > > In the effort of making GEODE java 9+ compatible, we already > determined > > > > that older released versions of GEODE can NOT be run using jdk9+. > With > > > this > > > > in mind, should we still run those compatibility/upgrade DUnit tests > in > > > > java9+ pipeline? The current state of things are: > > > > > > > > 1) A subset of compatibility/upgrade DUnit tests are successful in > > java9+ > > > > are passing because the dunit test environment happen to have the > > missing > > > > jars in the classpath. With the exclusion of Geode 1.4 in those > test, > > we > > > > can make all of them pass. (Just FYI, only Geode1.4 is failing in > jdk9+ > > > is > > > > because we introduced SerializationFilter in 1.4, but the support for > > in > > > > jdk9 was added only in 1.5). > > > > 2. We will have parallel pipelines testing with both jdk8 and jdk9+. > So > > > > even if we don't run these tests in jdk9+ pipeline, we are still > > running > > > > them in jdk8. > > > > > > > > The question to ask is: does running compatibility/upgrade tests in > > jdk9 > > > in > > > > addition to jdk8 offer additional value? > > > > > > > > > > > > > > -- > > Cheers > > > > Jinmei > > >
