Re: [DISSCUSS] Cassandra and Java 17

[Ekaterina Dimitrova]

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 considering if we
want to move away from this paradigm eventually but if it comes down to
"super experimental JDK17 support in 4.1 vs. tackling this now", I'd
*personally* advocate for the former."
My biggest worry is that the temporary decisions are the most permanent
ones. We shouldn't let it slip in time. It might be a bigger problem in the
long term.

About the dependencies - my understanding from our latest mail threads is
there is a plan directly to go for beta version in about a month; there is
no concrete plan I've heard of for performance testing for example. Even if
we carefully revise the changelogs I bet there will be things not written
there. Now on the other hand 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.

Also, our review cycles of bigger sensitive works tend to be long for a
good reason. I am not even sure who will want to do the reviews.

Instead of rushing it into this release, do we want instead a feature
branch for now if we want it out there super experimental so people can
have easy access for testing and visibility/awareness?


On Wed, Mar 23, 2022 at 3:02 PM Josh McKenzie  wrote:

> My .02 (Ekaterina and I have been chatting on slack about this a bit):
>
> 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 considering if we
> want to move away from this paradigm eventually but if it comes down to
> "super experimental JDK17 support in 4.1 vs. tackling this now", I'd
> *personally* advocate for the former.
>
> For updating our dependencies, it's going to be a balance between needing
> to support newer JDK's (and older JDK's going out of support) and
> introducing risk to our runtime env by updating dependencies for JDK's that
> aren't yet formally supported. I think we're always going to have tension
> where the newest supported JDK is going to introduce dependency upgrade
> requirements that will "force" updates to things that the oldest JDK
> doesn't strictly need, and in this case it happens to be for a JDK we won't
> officially support yet.
>
> I'd be in favor of the exercise of updating our dependencies as required
> to have bleeding edge experimental support for JDK 17 in 4.1 (i.e. "tests
> run with it and don't necessarily pass, we don't recommend you use it in
> production") with the motion Scott mentioned about changelog validation.
>
> Having a little more rigor around how and when we do this as a project
> (i.e. start validating new JDK at point N in lifecycle of oldest supported
> falling out of support, upgrade dependencies to make new JDK M work,
> validate those new dependency additions by doing behavior O) would probably
> be pretty wise. This is something we've done multiple times in the past and
> will need to keep doing into the future.
>
> Thanks for all the hard work on this Ekaterina!
>
> ~Josh
>
>
> On Wed, Mar 23, 2022, at 11:31 AM, Ekaterina Dimitrova wrote:
>
> Thank you for your quick response Scott.
>
> I agree on all points you made. Also, with our current setup the
> dependencies updates would affect the stable Java 11. We cannot afford to
> not consider potential changes in behavior, performance, etc
> But also we should work on potential blockers and not leave the dependency
> to atrophy.
>
> On Wed, 23 Mar 2022 at 11:07, C. Scott Andreas 
> wrote:
>
> Ekaterina, thank you very much for sharing this!
>
> I admit, it’s much more involved than I expected to be.
>
> The —add-opens and —add-exports flags seem suitable for development and
> perhaps experimental support, but we’ll probably want to make changes to
> remove as many as we can before considering JDK17 suitable for general use.
>
> Updating dependencies will be good for general hygiene, but it would also
> be important for us to scan changelogs for the intervening versions of each
> we’re upgrading to flag any unexpected behavior changes that may impact
> Cassandra or which the community might want to know about.
>
> Thank you for working to get Cassandra launching on JDK17. Excited for
> what’s ahead.
>
> — Scott
>
> On Mar 23, 2022, at 7:58 AM, Ekaterina Dimitrova 
> wrote:
>
> 
>
> Hi everyone,
>
> Looking into our way to Java 17, I wanted to share with the community
> findings/thoughts and align on course of action.
>
> We already deprecated scripted UDFs so we can remove them when the time to
> switch from Java8&11 to Java 11&17 comes. I removed the ant script tasks
> and created custom ant tasks to workaround the need of Nashorn. Ant is al

Re: [DISSCUSS] Cassandra and Java 17

[Josh McKenzie]

> 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.

On Thu, Mar 24, 2022, at 12:39 PM, Ekaterina Dimitrova wrote:
> 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 considering if we 
> want to move away from this paradigm eventually but if it comes down to 
> "super experimental JDK17 support in 4.1 vs. tackling this now", I'd 
> *personally* advocate for the former."
> My biggest worry is that the temporary decisions are the most permanent ones. 
> We shouldn't let it slip in time. It might be a bigger problem in the long 
> term.
> 
> About the dependencies - my understanding from our latest mail threads is 
> there is a plan directly to go for beta version in about a month; there is no 
> concrete plan I've heard of for performance testing for example. Even if we 
> carefully revise the changelogs I bet there will be things not written there. 
> Now on the other hand 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.
> 
> Also, our review cycles of bigger sensitive works tend to be long for a good 
> reason. I am not even sure who will want to do the reviews. 
> 
> Instead of rushing it into this release, do we want instead a feature branch 
> for now if we want it out there super experimental so people can have easy 
> access for testing and visibility/awareness?
> 
> 
> On Wed, Mar 23, 2022 at 3:02 PM Josh McKenzie  wrote:
>> __
>> My .02 (Ekaterina and I have been chatting on slack about this a bit):
>> 
>> 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 considering if we 
>> want to move away from this paradigm eventually but if it comes down to 
>> "super experimental JDK17 support in 4.1 vs. tackling this now", I'd 
>> *personally* advocate for the former.
>> 
>> For updating our dependencies, it's going to be a balance between needing to 
>> support newer JDK's (and older JDK's going out of support) and introducing 
>> risk to our runtime env by updating dependencies for JDK's that aren't yet 
>> formally supported. I think we're always going to have tension where the 
>> newest supported JDK is going to introduce dependency upgrade requirements 
>> that will "force" updates to things that the oldest JDK doesn't strictly 
>> need, and in this case it happens to be for a JDK we won't officially 
>> support yet.
>> 
>> I'd be in favor of the exercise of updating our dependencies as required to 
>> have bleeding edge experimental support for JDK 17 in 4.1 (i.e. "tests run 
>> with it and don't necessarily pass, we don't recommend you use it in 
>> production") with the motion Scott mentioned about changelog validation.
>> 
>> Having a little more rigor around how and when we do this as a project (i.e. 
>> start validating new JDK at point N in lifecycle of oldest supported falling 
>> out of support, upgrade dependencies to make new JDK M work, validate those 
>> new dependency additions by doing behavior O) would probably be pretty wise. 
>> This is something we've done multiple times in the past and will need to 
>> keep doing into the future.
>> 
>> Thanks for all the hard work on this Ekaterina!
>> 
>> ~Josh
>>  
>> 
>> On Wed, Mar 23, 2022, at 11:31 AM, Ekaterina Dimitrova wrote:
>>> Thank you for your quick response Scott. 
>>> 
>>> I agree on all points you made. Also, with our current setup the 
>>> dependencies updates would affect the stable Java 11. We cannot afford to 
>>> not consider potential changes in behavior, performance, etc 
>>> But also we should work on potential blockers and not leave the dependency 
>>> to atrophy. 
>>> 
>>> On Wed, 23 Mar 2022 at 11:07, C. Scott Andreas  wrote:
 Ekaterina, thank you very much for sharing this!
 
 I admit, it’s much more involved than I expected to be.
 
 The —add-opens and —add-exports flags seem suitable for development and 
 perhaps experimental support, but we’ll probably want to make changes to 
 remove as many as we can before considering JDK17 suitable for general use.
 
 Updating dependencies will be good for general hygiene, but it would also 
 be important for us to scan changelogs for the intervening versions of 
 each we’re upgrading to flag any unexpected behavior changes that may 
 impact Cassandra or which the comm

Re: [DISSCUSS] Cassandra and Java 17

[Ekaterina Dimitrova]

“ 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 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.
>
> On Thu, Mar 24, 2022, at 12:39 PM, Ekaterina Dimitrova wrote:
>
> 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 considering if we
> want to move away from this paradigm eventually but if it comes down to
> "super experimental JDK17 support in 4.1 vs. tackling this now", I'd
> *personally* advocate for the former."
> My biggest worry is that the temporary decisions are the most permanent
> ones. We shouldn't let it slip in time. It might be a bigger problem in the
> long term.
>
> About the dependencies - my understanding from our latest mail threads is
> there is a plan directly to go for beta version in about a month; there is
> no concrete plan I've heard of for performance testing for example. Even if
> we carefully revise the changelogs I bet there will be things not written
> there. Now on the other hand 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.
>
> Also, our review cycles of bigger sensitive works tend to be long for a
> good reason. I am not even sure who will want to do the reviews.
>
> Instead of rushing it into this release, do we want instead a feature
> branch for now if we want it out there super experimental so people can
> have easy access for testing and visibility/awareness?
>
>
> On Wed, Mar 23, 2022 at 3:02 PM Josh McKenzie 
> wrote:
>
>
> My .02 (Ekaterina and I have been chatting on slack about this a bit):
>
> 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 considering if we
> want to move away from this paradigm eventually but if it comes down to
> "super experimental JDK17 support in 4.1 vs. tackling this now", I'd
> *personally* advocate for the former.
>
> For updating our dependencies, it's going to be a balance between needing
> to support newer JDK's (and older JDK's going out of support) and
> introducing risk to our runtime env by updating dependencies for JDK's that
> aren't yet formally supported. I think we're always going to have tension
> where the newest supported JDK is going to introduce dependency upgrade
> requirements that will "force" updates to things that the oldest JDK
> doesn't strictly need, and in this case it happens to be for a JDK we won't
> officially support yet.
>
> I'd be in favor of the exercise of updating our dependencies as required
> to have bleeding edge experimental support for JDK 17 in 4.1 (i.e. "tests
> run with it and don't necessarily pass, we don't recommend you use it in
> production") with the motion Scott mentioned about changelog validation.
>
> Having a little more rigor around how and when we do this as a project
> (i.e. start validating new JDK at point N in lifecycle of oldest supported
> falling out of support, upgrade dependencies to make new JDK M work,
> validate those new dependency additions by doing behavior O) would probably
> be pretty wise. This is something we've done multiple times in the past and
> will need to keep doing into the future.
>
> Thanks for all the hard work on this Ekaterina!
>
> ~Josh
>
>
> On Wed, Mar 23, 2022, at 11:31 AM, Ekaterina Dimitrova wrote:
>
> Thank you for your quick response Scott.
>
> I agree on all points you made. Also, with our current setup the
> dependencies updates would affect the stable Java 11. We cannot afford to
> not consider potential changes in behavior, performance, etc
> But also we should work on potential blockers and not leave the dependency
> to atrophy.
>
> On Wed, 23 Mar 2022 at 11:07, C. Scott Andreas 
> wrote:
>
> Ekaterina, thank you very much for sharing this!
>
> I admit, it’s much more involved than I expected to be.
>
> The —add-opens and —add-exports flags seem suitable for development and
> perhaps experimental support, but we’ll probably want to make changes to
> remove as many as we can before considering JDK17 suitable for general use.
>
> Updating dependencies will be good for general hygiene, but it would also
> be important for us to scan changelogs for the intervening versions of each
> we’re upgrading to flag any unexpected behavior changes that may impact
> Cassandra or which the community m

Re: [DISSCUSS] Cassandra and Java 17

[Brandon Williams]

I don't think it would be worth the effort or a good idea to do so either.

FOR REVIEW: blog post - Kinetic Data case study

[Chris Thornett]

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_8N2OnMFu7m-8gg/edit?usp=sharing

On case studies generally, if you're aware of companies/organizations that
haven't provided one for the project or we need to do a refresh, please let
me know.

Thanks,

-- 

Chris Thornett
senior content strategist, Constantia.io
ch...@constantia.io
LinkedIn  | Twitter

Re: [DISSCUSS] Cassandra and Java 17

[Ekaterina Dimitrova]

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.
>

Re: [DISSCUSS] Cassandra and Java 17

[Josh McKenzie]

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  wrote:
>> I don't think it would be worth the effort or a good idea to do so either.