Supportive of this as well. I see testability of trunk against JDK17 as more important than continuous preservation of support for scripted UDFs *during* that development.
Will be tempted to cherry-pick this and begin kicking the tires as soon as it’s ready. 👍 - Scott > On Feb 5, 2023, at 6:14 PM, Mick Semb Wever <m...@apache.org> wrote: > > > >> To my understanding this wasn't the original desire and consensus with >> JDK17, folk requested that it be introduced complete, though I cannot >> actually find the reference to that. I was about to raise a thread asking >> for us to instead take an incremental approach, to help us move faster and >> safer, but am doing it here, thanks for raising the thread Josh. As others >> point out, we can't paint ourselves into the wrong corner with JDK17, though >> we can't drop JDK8 support until we're out of the (right) corner. > > > I forgot to mention something. > > Taking an incremental approach here also includes dropping support for > scripted UDFs first, and later on adding hooks for UDFs so users can re-add > the functionality. (This could have been (but idk,) the "complete" desire > expressed.) > > Implementing the hooks for UDFs is a current blocker and slowing down the > introduction of jdk17. We would like to remove the blocker by first dropping > the already deprecated UDFs first. I am for this approach because everyone > having to develop and test against jdk8, when they know 5.0 won't, is more > the headache here. > >
