Serialization between two JVMs running different versions of Java is definitely possible. Serialization sends field values, not any bytecode.
GEODE-5850 seems to be a different issue (attempting to use Java11-compiled bytecode in Java8, which will not work for reasons that have nothing to do with serialization). > On 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 >>> >>
