Thank you Josh, I definitely share the excitement but I also want to bring
a few more things.
" Having a new section in the build.xml for JDK17 runtime env w/more
--add-exports and --add-opens is consistent with how we got jdk11 support
working (and run it to this day looks like). It's worth consi
> if we go for Java 17 this means we bump to 5.0 instead of 4.1 at least
> because we will remove the already deprecated scripted UDFs and this is
> breaking change.
Ah. I assumed optionality on build (exclude on JDK17, include on 11). If that's
not possible then yeah, 5.0 would make more sense.
“ exclude on JDK17, include on 11”
At this point we do not support that setup, yes
On Thu, 24 Mar 2022 at 12:43, Josh McKenzie wrote:
> if we go for Java 17 this means we bump to 5.0 instead of 4.1 at least
> because we will remove the already deprecated scripted UDFs and this is
> breaking cha
I don't think it would be worth the effort or a good idea to do so either.
For the next blog, we're highlighting a recent user case that is going/gone
live in the 'Case Study' section of the website.
Here's the Google Doc for 72-hour review, please add any edits or
suggestions as comments, please:
https://docs.google.com/document/d/1xWXWgo-bB3Lx32tEhA77h14-40uN_8N2OnMFu7
Me too… support a feature only with certain jdk sounds also confusing to me
personally
On Thu, 24 Mar 2022 at 12:54, Brandon Williams wrote:
> I don't think it would be worth the effort or a good idea to do so either.
>
Fair enough. Was just a thought for a not often used deprecated feature if it
was a blocker.
On Thu, Mar 24, 2022, at 4:33 PM, Ekaterina Dimitrova wrote:
> Me too… support a feature only with certain jdk sounds also confusing to me
> personally
>
> On Thu, 24 Mar 2022 at 12:54, Brandon Williams
