> 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
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
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
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
> On Oct 11, 2018, at 12:49 PM, Patrick Rhomberg 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,
> 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
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:45 PM Udo Kohlmeyer 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
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
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
10 matches
Mail list logo
