On Thu, May 12, 2022 at 9:05 PM Jiayu Liu <ji...@hey.com.invalid> wrote: > 1. sub-project `libthrift`, which is the current Java library, to be > configured with --release flag [2] to target Java 8 (class file version, > APIs)
This is already what happens today, if the version detected is >= JDK 9. However, I saw your changes in https://github.com/apache/thrift/pull/2606 And, I think that is nicer, because it enforces JDK 11 for building. But it still produces Java 8 compatible binaries. > 2. sub-project `cross-test`, which is split out from the existing > project, to only contain cross test code, this way we can follow more > gradle convention, reduce customized configurations (e.g. using > `application` plugin instead of manually creating start scripts), and > have stronger encapsulation I thought the lib/kotlin directory basically served this purpose already. Are there other cross-tests? Or are you proposing some other move? It's not clear what you're proposing here. > 3. sub-project `libthrift-jdk11`, similar to what Kotlin does [3] with > their stdlib, to target JDK 11+. Both `libthrift` and this need to be > published, the added overhead for publishing should be minimal given > they share same config and process (signing, verification, etc.), and > for users who are not eager to use newer version, no changes are needed > on their side. I don't see any benefit to doing that at all. There's not really any benefit to producing Java 11 byte code from the same Java 8 source files as what is in libthrift. This would only matter if there were Java 11-specific improvements... and I don't see any interest here in maintaining two versions of libthrift, one with Java 8 compatibility and one with Java 11-specific changes. The libthrift built to be compatible with Java 8 works perfectly fine on Java 11, so there's no reason to have a separate artifact for Java 11 only. > > Regardless of making this change or not, I think we can start using Java > 11 to compile with --release 8 flag, to ensure better encapsulation and > version compatibility. +1 to that. Although it already works that way today, I'll follow your PR that is making improvements to how this is done. -- Christopher
