I would also vote for targeting 3.4 and have a long term version of Java
there.
On Tue, Mar 28, 2023 at 11:52 AM Igor Dvorzhak
wrote:
> +1 to re-focusing on 3.4 branch and upgrading it to Java 11/17, instead of
> making potentially breaking changes to 3.3.
>
> On Tue, Mar 28, 2023 at 11:17 AM
+1 to re-focusing on 3.4 branch and upgrading it to Java 11/17, instead of
making potentially breaking changes to 3.3.
On Tue, Mar 28, 2023 at 11:17 AM Chris Nauroth wrote:
> In theory, I like the idea of setting aside Java 8. Unfortunately, I don't
> know that upgrading within the 3.3 line
In theory, I like the idea of setting aside Java 8. Unfortunately, I don't
know that upgrading within the 3.3 line adheres to our binary compatibility
policy [1]. I don't see specific discussion of the Java version there, but
it states that you should be able to drop in minor upgrades and have
>
> it's already hard to migrate from JDK8 why not retarget JDK17.
>
+1, makes sense to me, sounds like a win-win situation to me, though there
would be some additional issues to chase now :)
-Ayush
On Tue, 28 Mar 2023 at 23:29, Wei-Chiu Chuang wrote:
> My random thoughts. Probably bad
My random thoughts. Probably bad takes:
There are projects experimenting with JDK17 now.
JDK11 active support will end in 6 months. If it's already hard to migrate
from JDK8 why not retarget JDK17.
On Tue, Mar 28, 2023 at 10:30 AM Ayush Saxena wrote:
> I know Jersey upgrade as a blocker. Some
I know Jersey upgrade as a blocker. Some folks were chasing that last year
during 3.3.4 time, I don’t know where it is now, didn’t see then what’s the
problem there but I remember there was some intitial PR which did it for HDFS
atleast, so I never looked beyond that…
I too had jdk-11 in my
well, how about we flip the switch and get on with it.
slf4j seems happy on java11,
side issue, anyone seen test failures on zulu1.8; somehow my test run is
failing and i'm trying to work out whether its a mismatch in command
line/ide jvm versions, or the 3.3.5 JARs have been built with an
