I'm not particularly attached to Java 8 either! I guess we've traditionally been pretty conservative, especially because Avro is widely used in big data environments -- back when on-premise clusters were the norm, it used to be trickier to bump Java versions across all nodes. That's really not a thing any more, is it?
We currently build and test all major java versions[1] but only upload Java 8 compiled artifacts. Any idea what other projects are doing? I'd say pick a widely used one (Apache Commons might be a good candidate) and track what they do, much like how we follow pip to determine which versions of python we support. I created https://issues.apache.org/jira/browse/AVRO-3627 to make sure this gets tracked one day for easy reference! All my best, Ryan [1]: https://github.com/apache/avro/blob/d6a0d0a790274de27b2cfde07d14151a4a327a96/.github/workflows/test-lang-java.yml#L43-L47 On Fri, Sep 9, 2022 at 3:50 PM Christophe Le Saëc <chles...@gmail.com> wrote: > > Hello here, > Is there any reason to stay in Java8 for Avro project ? > > On my laptop, i succeed to change to version 11 > > <maven.compiler.source>11</maven.compiler.source> > <maven.compiler.target>11</maven.compiler.target> > > just by adding a new FieldAccessor class using > java.lang.invoke.MethodHandles instead of sun.misc.Unsafe (And compile > FieldAccessUnsafe or the new class depends of JDK version with Maven trick). > Whole unit tests work fine. > I wonder if there are other good reasons to stay with Java 8 version. > > Best regards, > Christophe Le Saëc
