> 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 <onich...@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 <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 > >> > >
