Regarding point 2 - the lib/kotlin has its own cross tests which tests kotlin generator code, the lib/java has all along had its own cross tests, which currently live in lib/java/src/crossTests. These two are not related.
Note in lib/java we had to modify sourceset via gradle config, and use shadow jar plugin to package the cross test shadow jar, and also configure start script to generate the cross test runner, most of which can be removed if we switch to a multi project setup and it was what i was proposing. Regarding point 3 - the added module does not contain libthrift code but only the parts that are JDK11 specific for example the new JDK http client. I did not mean to compile the same code using two different targets but rather split out JDK11 Api dependent code so the libthrift continues to run on Java 8 On May 13, 2022, Christopher <ctubb...@apache.org> wrote: > 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
