Revert "Switch maven compiler version to 17 (#18751)"#18759
Revert "Switch maven compiler version to 17 (#18751)"#18759cryptoe merged 1 commit intoapache:masterfrom
Conversation
This reverts commit cf8f995.
|
Odd. All UT/IT tests passed. Is there a way we can somehow conditionally enable this so people who don't use hadoop ingests get the benefit of a newer compiler? Doesn't seem ideal to be stuck on JDK 11 compiler for a feature that has been deprecated. This could be done potentially with the hadoop maven profiles. |
If i understand things correctly, I think the issue is that it would allow using language level 17 features in Druid code which is what would actually break hadoop ingestion. We don't officially support java 11 anymore, but hadoop ingestion still works because none of the parts that run there need java 17 only stuff yet. |
Is there a way to just detect to use JDK 11 compiler when a Hadoop profile is being used? This way the project doesn't stagnate and isn't pinned down by deprecated features (for example, enabling virtual thread or other JDK 17+ features). Virtual thread is 21 but same point applies I guess. |
I think we are just doing this artificial language level restriction until Druid 37 which iirc is the current target for removing hadoop support from the dev list threads. There is such a thing as multi-release jars which allow using new language features but still supporting older versions, but this are kind of tedious and only very very recently even supported by intellij (and I haven't had a chance to play around much with that support so unsure how usable it is yet.. also not sure about other ide support), so should be reserved for specific features where the benefits outweigh the cost in complexity I think. |
This reverts commit cf8f995.
as this breaks hadoop ingest.