geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: Running compatibility and upgrade tests using jdk9+
Date Thu, 11 Oct 2018 21:46:53 GMT
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 <prhomberg@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 <gosullivan@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 <jiliao@pivotal.io> wrote:
>> 
>>> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <udo@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
>>> 
>> 


Mime
View raw message