+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 <cnaur...@gmail.com> wrote: > 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 > existing apps keep working. Users might find it surprising if they try to > upgrade a cluster that has JDK 8. > > There is also the question of impact on downstream projects [2]. We'd have > to check plans with our consumers. > > What about the idea of shooting for a 3.4 release on JDK 11 (or even 17)? > The downside is that we'd probably need to set boundaries on end of > life/limited support for 3.2 and 3.3 to keep the workload manageable. > > [1] > > https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Compatibility.html#Java_Binary_compatibility_for_end-user_applications_i.e._Apache_Hadoop_ABI > [2] https://github.com/apache/spark/blob/v3.3.2/pom.xml#L109 > > Chris Nauroth > > > On Tue, Mar 28, 2023 at 11:10 AM Ayush Saxena <ayush...@gmail.com> wrote: > > > > > > > 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 <weic...@apache.org> > wrote: > > > > > 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 <ayush...@gmail.com> > > wrote: > > > > > >> 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 mind, but only for trunk. 3.4.x can stay as > > >> java-11 only branch may be, but that is something later to decide, > once > > we > > >> get the code sorted… > > >> > > >> -Ayush > > >> > > >> > On 28-Mar-2023, at 9:16 PM, Steve Loughran > > <ste...@cloudera.com.invalid> > > >> wrote: > > >> > > > >> > 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 > > openjdk > > >> > version which requires IntBuffer implements an overridden method > > >> IntBuffer > > >> > rewind(). > > >> > > > >> > java.lang.NoSuchMethodError: > > >> java.nio.IntBuffer.rewind()Ljava/nio/IntBuffer; > > >> > > > >> > at > > >> > org.apache.hadoop.fs.FSInputChecker.verifySums(FSInputChecker.java:341) > > >> > at > > >> > > > >> > > > org.apache.hadoop.fs.FSInputChecker.readChecksumChunk(FSInputChecker.java:308) > > >> > at > org.apache.hadoop.fs.FSInputChecker.read1(FSInputChecker.java:257) > > >> > at org.apache.hadoop.fs.FSInputChecker.read(FSInputChecker.java:202) > > >> > at java.io.DataInputStream.read(DataInputStream.java:149) > > >> > > > >> >> On Tue, 28 Mar 2023 at 15:52, Viraj Jasani <vjas...@apache.org> > > wrote: > > >> >> IIRC some of the ongoing major dependency upgrades (log4j 1 to 2, > > >> jersey 1 > > >> >> to 2 and junit 4 to 5) are blockers for java 11 compile + test > > >> stability. > > >> >> On Tue, Mar 28, 2023 at 4:55 AM Steve Loughran > > >> <ste...@cloudera.com.invalid > > >> >> wrote: > > >> >>> Now that hadoop 3.3.5 is out, i want to propose something new > > >> >>> we switch branch-3.3 and trunk to being java11 only > > >> >>> 1. java 11 has been out for years > > >> >>> 2. oracle java 8 is no longer available under "premier support"; > you > > >> >>> can't really get upgrades > > >> >>> > > https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > >> >>> 3. openJDK 8 releases != oracle ones, and things you compile with > > them > > >> >>> don't always link to oracle java 8 (some classes in java.nio have > > >> >> added > > >> >>> more overrides) > > >> >>> 4. more and more libraries we want to upgrade to/bundle are java > 11 > > >> >> only > > >> >>> 5. moving to java 11 would cut our yetus build workload in half, > and > > >> >>> line up for adding java 17 builds instead. > > >> >>> I know there are some outstanding issues still in > > >> >>> https://issues.apache.org/jira/browse/HADOOP-16795 -but are they > > >> >> blockers? > > >> >>> Could we just move to java11 and enhance at our leisure, once > java8 > > >> is no > > >> >>> longer a concern. > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > > >> For additional commands, e-mail: common-dev-h...@hadoop.apache.org > > >> > > >> > > >
smime.p7s
Description: S/MIME Cryptographic Signature
