You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2018/10/08 21:11:32 UTC
Running compatibility and upgrade tests using jdk9+
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
Re: Running compatibility and upgrade tests using jdk9+
Posted by Patrick Rhomberg <pr...@pivotal.io>.
> If we throw away support for rolling JDK versions (which we’ve always
supported)
Looking at the documentation and our history of testing, I thought we've
only supported Java8, since Geode 1.0. At Geode 1.5, the required JDK
became Java 1.8.121, but this is significantly different than rolling a
patch version. I can't find anywhere that suggests "we've always supported
rolling JDK versions" is anything more than vacuously true. Which isn't to
say we shouldn't -- I'm mostly just trying to be a voice of caution here.
@Dan, Owen, thank you for the correction. My mistake.
On Thu, Oct 11, 2018 at 1:39 PM, Owen Nichols <on...@pivotal.io> wrote:
> Here’s the potential test matrix:
>
> Geode 1.7 on Java 8 <—> Geode 1.7 on Java 8: already extensively tested
> Geode 1.8 on Java 8 <—> Geode 1.7 on Java 8: already in
> backward-compatibility test plan
> Geode 1.7 on Java 11 <—> Geode 1.7 on Java 8: UNSUPPORTED1
> Geode 1.8 on Java 11 <—> Geode 1.7 on Java 8: UNSUPPORTED2
> Geode 1.8 on Java 8 <—> Geode 1.8 on Java 8: already extensively tested
> Geode 1.7 on Java 11 <—> Geode 1.8 on Java 8: UNSUPPORTED1
> Geode 1.8 on Java 11 <—> Geode 1.8 on Java 8: need to add additional
> tests for this
> Geode 1.7 on Java 11 <—> Geode 1.7 on Java 11: UNSUPPORTED1
> Geode 1.8 on Java 11 <—> Geode 1.7 on Java 11: UNSUPPORTED1
> Geode 1.8 on Java 11 <—> Geode 1.8 on Java 11: already extensively tested
>
> 1=Versions of Geode prior to 1.8 can’t run on Java 11.
> 2=ALL members of existing geode clusters MUST be rolled to Geode 1.8
> before ANY members are rolled to Java 11.
>
> We will need to do whatever it takes to make Geode 1.8 able to talk to
> other Geode 1.8 members even when one is running Java 8 and one is running
> Java 11. If we are unable to achieve that, then we cannot bring Java 11
> support until Geode 2.0.
>
> -Owen
>
> > On Oct 11, 2018, at 10:26 AM, Galen O'Sullivan <go...@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 <ji...@pivotal.io> wrote:
> >
> >> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <ud...@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
> >>
>
>
Re: Running compatibility and upgrade tests using jdk9+
Posted by Owen Nichols <on...@pivotal.io>.
Here’s the potential test matrix:
Geode 1.7 on Java 8 <—> Geode 1.7 on Java 8: already extensively tested
Geode 1.8 on Java 8 <—> Geode 1.7 on Java 8: already in backward-compatibility test plan
Geode 1.7 on Java 11 <—> Geode 1.7 on Java 8: UNSUPPORTED1
Geode 1.8 on Java 11 <—> Geode 1.7 on Java 8: UNSUPPORTED2
Geode 1.8 on Java 8 <—> Geode 1.8 on Java 8: already extensively tested
Geode 1.7 on Java 11 <—> Geode 1.8 on Java 8: UNSUPPORTED1
Geode 1.8 on Java 11 <—> Geode 1.8 on Java 8: need to add additional tests for this
Geode 1.7 on Java 11 <—> Geode 1.7 on Java 11: UNSUPPORTED1
Geode 1.8 on Java 11 <—> Geode 1.7 on Java 11: UNSUPPORTED1
Geode 1.8 on Java 11 <—> Geode 1.8 on Java 11: already extensively tested
1=Versions of Geode prior to 1.8 can’t run on Java 11.
2=ALL members of existing geode clusters MUST be rolled to Geode 1.8 before ANY members are rolled to Java 11.
We will need to do whatever it takes to make Geode 1.8 able to talk to other Geode 1.8 members even when one is running Java 8 and one is running Java 11. If we are unable to achieve that, then we cannot bring Java 11 support until Geode 2.0.
-Owen
> On Oct 11, 2018, at 10:26 AM, Galen O'Sullivan <go...@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 <ji...@pivotal.io> wrote:
>
>> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <ud...@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
>>
Re: Running compatibility and upgrade tests using jdk9+
Posted by Owen Nichols <on...@pivotal.io>.
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 <pr...@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 <go...@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 <ji...@pivotal.io> wrote:
>>
>>> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <ud...@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
>>>
>>
Re: Running compatibility and upgrade tests using jdk9+
Posted by Dan Smith <ds...@pivotal.io>.
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 <pr...@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 <go...@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 <ji...@pivotal.io> wrote:
> >
> > > On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <ud...@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
> > >
> >
>
Re: Running compatibility and upgrade tests using jdk9+
Posted by Anthony Baker <ab...@pivotal.io>.
> On Oct 11, 2018, at 12:49 PM, Patrick Rhomberg <pr...@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.
There is a long list of capabilities built into Geode that work together to provide 24x7x365 operation with zero downtime *ever*. This is why we carefully test backwards compatibility across various dimensions and ensure that users can do rolling upgrades from version to version.
If we throw away support for rolling JDK versions (which we’ve always supported) then we leave our users with a difficult decision: schedule an outage, fail-over to a secondary cluster, or stay on jdk 8 forever.
Is there a technical reason preventing us from supporting rolling JDK upgrades? If so, can we find a way to work around this?
Anthony
Re: Running compatibility and upgrade tests using jdk9+
Posted by Patrick Rhomberg <pr...@pivotal.io>.
> 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 <go...@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 <ji...@pivotal.io> wrote:
>
> > On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <ud...@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
> >
>
Re: Running compatibility and upgrade tests using jdk9+
Posted by Galen O'Sullivan <go...@pivotal.io>.
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 <ji...@pivotal.io> wrote:
> On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <ud...@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
>
Re: Running compatibility and upgrade tests using jdk9+
Posted by Jinmei Liao <ji...@pivotal.io>.
On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer <ud...@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
Re: Running compatibility and upgrade tests using jdk9+
Posted by Udo Kohlmeyer <ud...@apache.org>.
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?
Also does this effort cover some of the main additions to the JDK since
9, which is the whole modularity theme?
--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?
>