Re: Supporting multiple JDKs

> I also can't remember any reports on regressions in 2.2 bug fix releases specific to 1.7. So what's the actual problem we want to solve here? Discussion for 2.2 came up from the ticket CASSANDRA-14563 , which I think came up from an

Re: Supporting multiple JDKs

I really don't see any benefit at all in having any additional Java 1.7 specific build and testing changes for the 2.2 branch. The 2.2 version is reaching EOL and will only get critical patches until then anyways. I also can't remember any reports on regressions in 2.2 bug fix releases specific to

Re: Supporting multiple JDKs

> And I would suggest to go further and crash the build with JDK1.7 so we can take away the possibility for users to shoot their foot off this way. I like this suggestion. Either we should be on the side of NO support to JDK 1.7, or if we say we support JDK1.7, I believe we should be building

Re: Supporting multiple JDKs

> How would we be sure users will never encounter bugs unless we build > against that JDK? Apache Cassandra does not distribute JDK1.7 built releases. The only way a user could repeat such a bug is if they have built C* themselves. I don't think the project should be responsible for every

Re: Supporting multiple JDKs

C* 2.2 > I'm still left wondering why we want to use CI resources to find bugs that the users will never encounter. How would we be sure users will never encounter bugs unless we build against that JDK? This is the reason I propose having a CircleCI build against 1.7. > If you take out "and

Re: Supporting multiple JDKs

Hey Sumanth, could you clear a few things up for me… > C* 2.2 > > I'm still a bit confused as to what's the benefit in compiling with > > jdk1.7 and then testing with jdk1.7 or jdk1.8 > > I meant two separate workflows for each JDK i.e. > Workflow1: Build against jdk1.7, and optionally run

Re: Supporting multiple JDKs

+1 from me on both points below -- Jeff Jirsa > On Aug 28, 2018, at 1:40 PM, Sumanth Pasupuleti > wrote: > > Correct me if I am wrong, but I see the following consensus so far, on the > proposal. > > C* 2.2 > AnimalSniffer > Use AnimalSniffer for compile-time feedback on JDK 1.7

Re: Supporting multiple JDKs

Correct me if I am wrong, but I see the following consensus so far, on the proposal. C* 2.2 AnimalSniffer Use AnimalSniffer for compile-time feedback on JDK 1.7 compatibility - complete consensus so far Circle CI Builds In addition to existing JDK 1.8 support, build against JDK 1.7, and

Re: Supporting multiple JDKs

> I'm still a bit confused as to what's the benefit in compiling with jdk1.7 and then testing with jdk1.7 or jdk1.8 I meant two separate workflows for each JDK i.e. Workflow1: Build against jdk1.7, and optionally run UTs and Dtests against 1.7 Workflow2: Build against jdk1.8, and run UTs and

Re: Supporting multiple JDKs

> However, in addition to using such a > tool, I believe, when we make a release, we should build against the actual > JDKs we support (that way, we are not making a release just based on the > result of an external tool), and we should be able to optionally run UTs > and DTests against the JDK

Re: Supporting multiple JDKs

Some of our java8 code will not compile under java11 (see CASSANDRA-9608); the symbols have literally been removed (Unsafe.monitorEnter() / Unsafe.monitorExit() ). Setting -source to "8" will not help. Thus, we need two compilers for the foreseeable future. On Thu, Aug 23, 2018 at 3:44 PM,

Re: Supporting multiple JDKs

I am not against using a compile-time quick-feedback tool like Animal Sniffer either. It is great to have such a tool to know of any obvious bad changes right away during development. However, in addition to using such a tool, I believe, when we make a release, we should build against the actual

Re: Supporting multiple JDKs

> > There's a cost-optimisation here in reducing what we have to support. > > I agree and animal sniffer is a great way to ferret out obvious issues. > I am not against using animal sniffer. I'm concerned that there are > various incompatibilities[1] between JDK versions and I am not 100% >

Re: Supporting multiple JDKs

> On Aug 22, 2018, at 7:23 PM, Mick Semb Wever wrote: > > There's a cost-optimisation here in reducing what we have to support. I agree and animal sniffer is a great way to ferret out obvious issues. I am not against using animal sniffer. I'm concerned that there are various

Re: Supporting multiple JDKs

What do we mean "support multiple JDKs" ? Are we talking Run-time or Compile-time? > If we support multiple JDKs, at a minimum we should compile code against > those JDKs. Why? I really don't get that logic. There's a cost-optimisation here in reducing what we have to support. If we

Re: Supporting multiple JDKs

I think we should have the ability to build & run unit tests and dtests against a specified JDK. If we support multiple JDKs, at a minimum we should compile code against those JDKs. It would be ideal if we could run unit tests and dtests but given the availability of CircleCI resources that

Supporting multiple JDKs

Hi, The goal of this email is to arrive at a solution (probably resulting in a few follow-ups) to ensure support for multiple JDKs for different versions of Cassandra. This comes out of Jason's comment in https://issues.apache.org/jira/browse/CASSANDRA-14563. Below is the proposal. Please