At the current moment I don't think it makes sense to run old versions with anything but JDK 8, since they didn't support JDK 9+ or anything like that.
Going forward though it seems like we should start running the backwards compatibility tests between versions that do support JDK 9+, once we have more than one of those. Could we just skip testing versions *less* than whenever we start supporting JDK 9+? For the first release, that would mean no compatibility testing but after that we would start doing it. The test suite Galen is talking about seems nice, although I'm not sure if we need to be testing the JDK's serialization guarantees. Changing the JDK should not break compatibility of Java serialization. Patrick - the case you mentioned is not serialization. That's an incompatibility in compiled code, not in serialized data. -Dan On Thu, Oct 11, 2018 at 12:49 PM Patrick Rhomberg <prhomb...@pivotal.io> wrote: > > 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 > > > > > >
