Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

> 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 incident where a JDK1.7 incompatible commit was made into 2.2
branch. But I see the consensus on 2.2 that, there is no ROI on spending
time on 2.2 given that its reaching EOL, which can mean (CASSANDRA-14563
 (in discussion
state) and CASSANDRA-14625
 (in patch available
state) may be resolved as won't fix)

As for 4.0/4.x, I think there are a couple of takeaways from this thread,
and I am happy to pursue them.
1. Make CI jobs use "_build_multi_java" and adding optional workflow to run
tests against JAVA 11 - CASSANDRA-14609

2. Add CI job to validate "ant artifacts" - CASSANDRA-14718

3. Auto-update of documentation from CI builds - CASSANDRA-14719


Thanks,
Sumanth

On Sat, Sep 8, 2018 at 4:59 AM Stefan Podkowinski  wrote:

> 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 1.7. So what's the actual problem we want to solve here?
>
> As for 4.0, we're going to ship multi-release jars, which are targeted
> against Java 8, but also contain Java 11 classes that will only be used
> when executed under Java 11 (also currently just a single class). I can
> see two issues that need our attention with that:
>  * We should make sure to use the "_build_multi_java" target for our CI
> jobs, so we're really testing the same build that we would ship. It's
> probably not going to make a real difference, but who knows..
>  * It would also be nice to have the option to run tests on CI under
> Java 11, although we only provide "experimental" support for that Java
> version. Nice to have at this point, as there will be plenty of bugs in
> 4.0 to fix, until we should spend time looking more closely for more
> subtle Java 11 issues. But if someone wants to contribute any work to
> make this happen, I'd be glad to have that option running tests on Java
> 11, so don't get me wrong.
>
>
> On 07.09.18 04:10, Sumanth Pasupuleti wrote:
> >> 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
> > against JDK1.7 to make sure we are compliant.
> > I have a quick clarifying question here - I believe origin of
> > CASSANDRA-14563 is from the introduction of an API in 2.2 that is
> > incompatible with 1.7, that has then been manually detected and fixed.
> Are
> > you suggesting, going further, we would not support 1.7?
> >
> >> Currently I'm unclear on how we would make a stable release using only
> > JDK8, maybe their are plans on the table i don't know about?
> >
> > From the current state of build.xml and from the past discussions, I do
> > believe as well, that we need both JDKs to make a 4.0 release using
> > ‘_build_multi_java’. Bonus would be that, the release would also be able
> to
> > run against Java11, but that would be an experimental release.
> >
> >> I'm not familiar with optional jobs or workflows in CircleCi, do you
> have
> > an example of what you mean at hand?
> >
> > By optional, I was referring to having workflow definitions in place, but
> > calls to those workflows commented out. Basically similar to what we have
> > today.
> > workflows:
> > version: 2
> > build_and_run_tests: *default_jobs
> > #build_and_run_tests: *with_dtest_jobs_only
> > #build_and_run_tests_java11: *with_dtest_jobs_java11
> > Jason created CASSANDRA-14609 for this purpose I believe.
> >
> >> Off-topic, but what are your thoughts on this? Can we add `ant
> > artifacts`, and the building of the docs, as a separate jobs into the
> > existing default CircleCI workflow? I think we should also be looking
> into
> > getting https://cassandra.apache.org/doc/latest/ automatically updated
> > after each successful trunk build, and have
> > https://cassandra.apache.org/doc/X.Y versions on the docs in place
> (which
> > are only updated after each patch release).
> >
> > I like all these ideas! I believe we should be able to add a workflow to
> > test out artifact generation. Will create a JIRA for this. Your
> suggestions
> > around auto-update of docs provides a way to keep 

Re: Supporting multiple JDKs

[Stefan Podkowinski]

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 1.7. So what's the actual problem we want to solve here?

As for 4.0, we're going to ship multi-release jars, which are targeted
against Java 8, but also contain Java 11 classes that will only be used
when executed under Java 11 (also currently just a single class). I can
see two issues that need our attention with that:
 * We should make sure to use the "_build_multi_java" target for our CI
jobs, so we're really testing the same build that we would ship. It's
probably not going to make a real difference, but who knows..
 * It would also be nice to have the option to run tests on CI under
Java 11, although we only provide "experimental" support for that Java
version. Nice to have at this point, as there will be plenty of bugs in
4.0 to fix, until we should spend time looking more closely for more
subtle Java 11 issues. But if someone wants to contribute any work to
make this happen, I'd be glad to have that option running tests on Java
11, so don't get me wrong.


On 07.09.18 04:10, Sumanth Pasupuleti wrote:
>> 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
> against JDK1.7 to make sure we are compliant.
> I have a quick clarifying question here - I believe origin of
> CASSANDRA-14563 is from the introduction of an API in 2.2 that is
> incompatible with 1.7, that has then been manually detected and fixed. Are
> you suggesting, going further, we would not support 1.7?
>
>> Currently I'm unclear on how we would make a stable release using only
> JDK8, maybe their are plans on the table i don't know about?
>
> From the current state of build.xml and from the past discussions, I do
> believe as well, that we need both JDKs to make a 4.0 release using
> ‘_build_multi_java’. Bonus would be that, the release would also be able to
> run against Java11, but that would be an experimental release.
>
>> I'm not familiar with optional jobs or workflows in CircleCi, do you have
> an example of what you mean at hand?
>
> By optional, I was referring to having workflow definitions in place, but
> calls to those workflows commented out. Basically similar to what we have
> today.
> workflows:
> version: 2
> build_and_run_tests: *default_jobs
> #build_and_run_tests: *with_dtest_jobs_only
> #build_and_run_tests_java11: *with_dtest_jobs_java11
> Jason created CASSANDRA-14609 for this purpose I believe.
>
>> Off-topic, but what are your thoughts on this? Can we add `ant
> artifacts`, and the building of the docs, as a separate jobs into the
> existing default CircleCI workflow? I think we should also be looking into
> getting https://cassandra.apache.org/doc/latest/ automatically updated
> after each successful trunk build, and have
> https://cassandra.apache.org/doc/X.Y versions on the docs in place (which
> are only updated after each patch release).
>
> I like all these ideas! I believe we should be able to add a workflow to
> test out artifact generation. Will create a JIRA for this. Your suggestions
> around auto-update of docs provides a way to keep our website docs
> up-to-date. Not sure what it takes to do it though. Will be happy to
> explore (as part of separate JIRAs).
>
> Thanks,
> Sumanth
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

> 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
against JDK1.7 to make sure we are compliant.
I have a quick clarifying question here - I believe origin of
CASSANDRA-14563 is from the introduction of an API in 2.2 that is
incompatible with 1.7, that has then been manually detected and fixed. Are
you suggesting, going further, we would not support 1.7?

> Currently I'm unclear on how we would make a stable release using only
JDK8, maybe their are plans on the table i don't know about?

>From the current state of build.xml and from the past discussions, I do
believe as well, that we need both JDKs to make a 4.0 release using
‘_build_multi_java’. Bonus would be that, the release would also be able to
run against Java11, but that would be an experimental release.

> I'm not familiar with optional jobs or workflows in CircleCi, do you have
an example of what you mean at hand?

By optional, I was referring to having workflow definitions in place, but
calls to those workflows commented out. Basically similar to what we have
today.
workflows:
version: 2
build_and_run_tests: *default_jobs
#build_and_run_tests: *with_dtest_jobs_only
#build_and_run_tests_java11: *with_dtest_jobs_java11
Jason created CASSANDRA-14609 for this purpose I believe.

> Off-topic, but what are your thoughts on this? Can we add `ant
artifacts`, and the building of the docs, as a separate jobs into the
existing default CircleCI workflow? I think we should also be looking into
getting https://cassandra.apache.org/doc/latest/ automatically updated
after each successful trunk build, and have
https://cassandra.apache.org/doc/X.Y versions on the docs in place (which
are only updated after each patch release).

I like all these ideas! I believe we should be able to add a workflow to
test out artifact generation. Will create a JIRA for this. Your suggestions
around auto-update of docs provides a way to keep our website docs
up-to-date. Not sure what it takes to do it though. Will be happy to
explore (as part of separate JIRAs).

Thanks,
Sumanth

On Wed, Sep 5, 2018 at 9:30 PM Mick Semb Wever  wrote:

>
>
> > 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 possible build
> combination tom, dick and harry can do.
> That's my 2cents anyway.
>
> 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.
>
>
> > > The time it takes for tests to run is a headache, so to have to run
> > dtests four times over makes me grimace.
> > It takes only about 25min with default 4x parallelism to run unit tests
> in
> > CircleCI.
>
> I referred to dtests, how would you do this on CircleCI?
> Today dtests take 5-9 hours on builds.apache.org, not including re-runs
> for offheap, large, novnode.
>
>
> > We definitely can build against JDK 8 alone, however from the thread you
> > linked and from 9608, we wanted to do a stable release that uses JDK8,
> and
> > an experimental release, which uses JDK8 to build most files, and JDK11
> to
> > build the Java 11 specific AtomicBTreePartitionBase file.
>
> Currently I'm unclear on how we would make a stable release using only
> JDK8, maybe their are plans on the table i don't know about?
>
> The current build.xml requires both JDKs to run `ant artifacts`.
> That is any release will have compiled in ant all but one class with
> `_build_multi_java` instead of `_build_java8_only`.
>
>
> > My proposal is not to necessarily run UTs and DTests against JDK11 always
> > with every commit but to have workflows in place that can be used
> whenever
> > we deem necessary.
>
>
> I'm not familiar with optional jobs or workflows in CircleCi, do you have
> an example of what you mean at hand?
> I like the idea of having a collection of CircleCi workflows, even if I'd
> rather see less JDKs supported at compile-time.
>
>
> > I think building the artefacts should be part of the CI build step
> because patches are not always about java code.
>
> Off-topic, but what are your thoughts on this? Can we add `ant artifacts`,
> and the building of the docs, as a separate jobs into the existing default
> CircleCI workflow? I think we should also be looking into getting
> https://cassandra.apache.org/doc/latest/ automatically updated after each
> successful trunk build, and have https://cassandra.apache.org/doc/X.Y
> versions on the docs in place (which are only updated after each patch
> release).
>
> regards,
> Mick
>
> 

Re: Supporting multiple JDKs

[Mick Semb Wever]

> 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 possible build 
combination tom, dick and harry can do.
That's my 2cents anyway. 

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.


> > The time it takes for tests to run is a headache, so to have to run
> dtests four times over makes me grimace.
> It takes only about 25min with default 4x parallelism to run unit tests in
> CircleCI.

I referred to dtests, how would you do this on CircleCI?
Today dtests take 5-9 hours on builds.apache.org, not including re-runs for 
offheap, large, novnode.


> We definitely can build against JDK 8 alone, however from the thread you
> linked and from 9608, we wanted to do a stable release that uses JDK8, and
> an experimental release, which uses JDK8 to build most files, and JDK11 to
> build the Java 11 specific AtomicBTreePartitionBase file.

Currently I'm unclear on how we would make a stable release using only JDK8, 
maybe their are plans on the table i don't know about?
 
The current build.xml requires both JDKs to run `ant artifacts`.
That is any release will have compiled in ant all but one class with 
`_build_multi_java` instead of `_build_java8_only`.


> My proposal is not to necessarily run UTs and DTests against JDK11 always
> with every commit but to have workflows in place that can be used whenever
> we deem necessary.


I'm not familiar with optional jobs or workflows in CircleCi, do you have an 
example of what you mean at hand?
I like the idea of having a collection of CircleCi workflows, even if I'd 
rather see less JDKs supported at compile-time.


> I think building the artefacts should be part of the CI build step because 
> patches are not always about java code. 

Off-topic, but what are your thoughts on this? Can we add `ant artifacts`, and 
the building of the docs, as a separate jobs into the existing default CircleCI 
workflow? I think we should also be looking into getting 
https://cassandra.apache.org/doc/latest/ automatically updated after each 
successful trunk build, and have https://cassandra.apache.org/doc/X.Y versions 
on the docs in place (which are only updated after each patch release).

regards,
Mick

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

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 optionally run UTs and Dtests against 1.7" from
workflow1 then I'm fine with it.
I don't think it hurts to have workflows that "can" do UTs and DTests
against 1.7. We can run them only when we make a release.
> The time it takes for tests to run is a headache, so to have to run
dtests four times over makes me grimace.
It takes only about 25min with default 4x parallelism to run unit tests in
CircleCI.


4.0
> Currently afaik we can't build the artifacts against only either JDK8 or
JDK11, hence the hybrid JDK setup.
We definitely can build against JDK 8 alone, however from the thread you
linked and from 9608, we wanted to do a stable release that uses JDK8, and
an experimental release, which uses JDK8 to build most files, and JDK11 to
build the Java 11 specific AtomicBTreePartitionBase file.

> In that thread it was mentioned the concerns about the cost of running
tests twice, and whether we should avoid running tests with JDK11 until
we're closer to formally supporting JDK11 at run-time.
My proposal is not to necessarily run UTs and DTests against JDK11 always
with every commit but to have workflows in place that can be used whenever
we deem necessary.

Thanks,
Sumanth

On Thu, Aug 30, 2018 at 12:34 AM Mick Semb Wever  wrote:

>
> 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 UTs and Dtests
> against
> > 1.7
>
> I'm still left wondering why we want to use CI resources to find bugs that
> the users will never encounter.
> If you take out "and optionally run UTs and Dtests against 1.7" from
> workflow1 then I'm fine with it.
>
> The time it takes for tests to run is a headache, so to have to run dtests
> four times over makes me grimace.
>
>
> > C* 4.0
>
> I'm not quite clear on what the change you intend here is.
>
> Currently afaik we can't build the artefacts against only either JDK8 or
> JDK11, hence the hybrid jdk setup.
> I think building the artefacts should be part of the CI build step because
> patches are not always about java code.
>
> And that unit and dtests are run only against these 'release' built
> artefacts. Presuming the plan remains that the hybrid approach would be the
> 'release' process so long as jdk11 was GA before Cassandra-4.0.
>
>
> https://lists.apache.org/thread.html/45b3f12885f881d211f79368bdd5046e504e0149757cf19c8747bcb2@%3Cdev.cassandra.apache.org%3E
>
> In that thread it was mentioned the concerns about the cost of running
> tests twice, and whether we should avoid running tests with JDK11 until
> we're closer to formally supporting JDK11 at run-time.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Supporting multiple JDKs

[Mick Semb Wever]

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 UTs and Dtests against
> 1.7

I'm still left wondering why we want to use CI resources to find bugs that the 
users will never encounter.
If you take out "and optionally run UTs and Dtests against 1.7" from workflow1 
then I'm fine with it.

The time it takes for tests to run is a headache, so to have to run dtests four 
times over makes me grimace.


> C* 4.0

I'm not quite clear on what the change you intend here is.

Currently afaik we can't build the artefacts against only either JDK8 or JDK11, 
hence the hybrid jdk setup.
I think building the artefacts should be part of the CI build step because 
patches are not always about java code. 

And that unit and dtests are run only against these 'release' built artefacts. 
Presuming the plan remains that the hybrid approach would be the 'release' 
process so long as jdk11 was GA before Cassandra-4.0.

https://lists.apache.org/thread.html/45b3f12885f881d211f79368bdd5046e504e0149757cf19c8747bcb2@%3Cdev.cassandra.apache.org%3E

In that thread it was mentioned the concerns about the cost of running tests 
twice, and whether we should avoid running tests with JDK11 until we're closer 
to formally supporting JDK11 at run-time. 

regards,
Mick

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[Jeff Jirsa]

+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 compatibility -
> complete consensus so far
> Circle CI Builds
> In addition to existing JDK 1.8 support, build against JDK 1.7, and
> [optionally] run unit tests and DTests against JDK 1.7 - Dinesh and
> Sumanth +1 so far. Mick - I am not sure if you are +0 or -1 on this.
> 
> C* 4.0
> Circle CI Builds
> In addition to existing JDK 1.8 support, build against JDK 11 and
> [optionally] run unit tests and DTests against JDK 11. - complete consensus
> so far
> 
> If anyone has any further feedback, please comment.
> 
> Thanks,
> Sumanth
> 
> On Fri, Aug 24, 2018 at 7:27 AM Sumanth Pasupuleti
>  wrote:
> 
>>> 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 DTests against 1.8.
>> 
>>> If you find breakages here that otherwise don't exist when it's compiled
>> with jdk1.8 then that's just false-positives. As well as generally wasting
>> CI resources.
>> If we find breakages in workflow1, and not in workflow 2, how would they be
>> false positives? we will need to then look into whats causing breakages
>> with 1.7, isn't it?
>> 
>> Thanks,
>> Sumanth
>> 
>> On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever  wrote:
>> 
 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  (i.e. Java7 and Java8 for 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
>>> 
>>> If you find breakages here that otherwise don't exist when it's compiled
>>> with jdk1.8 then that's just false-positives. As well as generally
>> wasting
>>> CI resources.
>>> 
>>> Either way, there's not much point discussing this as Cassandra-2.1 is
>>> about EOL, and Cassandra-4.0 is stuck with a very specific compile.
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

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
[optionally] run unit tests and DTests against JDK 1.7 - Dinesh and
Sumanth +1 so far. Mick - I am not sure if you are +0 or -1 on this.

C* 4.0
Circle CI Builds
In addition to existing JDK 1.8 support, build against JDK 11 and
[optionally] run unit tests and DTests against JDK 11. - complete consensus
so far

If anyone has any further feedback, please comment.

Thanks,
Sumanth

On Fri, Aug 24, 2018 at 7:27 AM Sumanth Pasupuleti
 wrote:

> > 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 DTests against 1.8.
>
> > If you find breakages here that otherwise don't exist when it's compiled
> with jdk1.8 then that's just false-positives. As well as generally wasting
> CI resources.
> If we find breakages in workflow1, and not in workflow 2, how would they be
> false positives? we will need to then look into whats causing breakages
> with 1.7, isn't it?
>
> Thanks,
> Sumanth
>
> On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever  wrote:
>
> > > 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  (i.e. Java7 and Java8 for 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
> >
> > If you find breakages here that otherwise don't exist when it's compiled
> > with jdk1.8 then that's just false-positives. As well as generally
> wasting
> > CI resources.
> >
> > Either way, there's not much point discussing this as Cassandra-2.1 is
> > about EOL, and Cassandra-4.0 is stuck with a very specific compile.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

> 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 DTests against 1.8.

> If you find breakages here that otherwise don't exist when it's compiled
with jdk1.8 then that's just false-positives. As well as generally wasting
CI resources.
If we find breakages in workflow1, and not in workflow 2, how would they be
false positives? we will need to then look into whats causing breakages
with 1.7, isn't it?

Thanks,
Sumanth

On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever  wrote:

> > 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  (i.e. Java7 and Java8 for 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
>
> If you find breakages here that otherwise don't exist when it's compiled
> with jdk1.8 then that's just false-positives. As well as generally wasting
> CI resources.
>
> Either way, there's not much point discussing this as Cassandra-2.1 is
> about EOL, and Cassandra-4.0 is stuck with a very specific compile.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Supporting multiple JDKs

[Mick Semb Wever]

> 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  (i.e. Java7 and Java8 for 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

If you find breakages here that otherwise don't exist when it's compiled with 
jdk1.8 then that's just false-positives. As well as generally wasting CI 
resources.

Either way, there's not much point discussing this as Cassandra-2.1 is about 
EOL, and Cassandra-4.0 is stuck with a very specific compile.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[Jason Brown]

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, Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> 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
> 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  (i.e. Java7 and Java8 for C* 2.2).
>
> > What do we mean "support multiple JDKs" ?
> > Are we talking Run-time or Compile-time?
> I am talking both - compile-time can for Build, run-time for UTs and
> DTests.
>
> > I think that dtests are always going to be the important defence here,
> and that we simplify it by running dtests on a standardised JDK compile.
> I agree, but its good to have an optional workflow in CircleCI to be able
> to run DTest against the non-standardized JDK as well, which we support
> (Java7 for example, for C*2.2, and Java11 for C* 4.0)
>
> Thanks,
> Sumanth
>
> On Thu, Aug 23, 2018 at 12:06 AM 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 incompatibilities[1] between JDK versions and I am not 100%
> > > certain that animal sniffer will catch all of them.
> >
> >
> > Yeah, but is compiling (and unit tests) really any more effective against
> > behavioural incompatibilities (which also occur from one patch JDK
> version
> > to the next)?
> >
> > I think that dtests are always going to be the important defence here,
> and
> > that we simplify it by running dtests on a standardised JDK compile.
> >
> > regards,
> > Mick
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

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
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  (i.e. Java7 and Java8 for C* 2.2).

> What do we mean "support multiple JDKs" ?
> Are we talking Run-time or Compile-time?
I am talking both - compile-time can for Build, run-time for UTs and DTests.

> I think that dtests are always going to be the important defence here,
and that we simplify it by running dtests on a standardised JDK compile.
I agree, but its good to have an optional workflow in CircleCI to be able
to run DTest against the non-standardized JDK as well, which we support
(Java7 for example, for C*2.2, and Java11 for C* 4.0)

Thanks,
Sumanth

On Thu, Aug 23, 2018 at 12:06 AM 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 incompatibilities[1] between JDK versions and I am not 100%
> > certain that animal sniffer will catch all of them.
>
>
> Yeah, but is compiling (and unit tests) really any more effective against
> behavioural incompatibilities (which also occur from one patch JDK version
> to the next)?
>
> I think that dtests are always going to be the important defence here, and
> that we simplify it by running dtests on a standardised JDK compile.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Supporting multiple JDKs

[Mick Semb Wever]

> > 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% 
> certain that animal sniffer will catch all of them.


Yeah, but is compiling (and unit tests) really any more effective against 
behavioural incompatibilities (which also occur from one patch JDK version to 
the next)?

I think that dtests are always going to be the important defence here, and that 
we simplify it by running dtests on a standardised JDK compile.

regards,
Mick

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[Dinesh Joshi]

> 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 
incompatibilities[1] between JDK versions and I am not 100% certain that animal 
sniffer will catch all of them.

Dinesh

[1] 
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
 

Re: Supporting multiple JDKs

[Mick Semb Wever]

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 support compiling with multiple JDKs and running with multiple JDKs, then 
we've a matrix of things to test. And it's kinda odd i think, when we don't 
need to compile against multiple JDKs and don't distribute releases built on 
different JDKs.

The suggestion to use the AnimalSniffer ant task was a way to simply this.

That is, so we can 
 - only build with one JDK (the same we build releases with),
 - run unit tests only against that JDK,
 - run dtests against multiple JDKs.

Ensuring at compile-time that earlier JDKs are supported at run-time then is 
done using the AnimalSniffer ant task. It doesn't just simply the testing 
matrix, but provides a quick feedback loop to the developer when they 
accidentally code against a java api that's not available in the older JDK.

There's also two contexts here: Cassandra-2.2 (jdks 1.7 and 1.8) and 
Cassandra-4.0 (jdks 1.8 and 11).
I don't know if it's possible, but it would be awesome once jdk11 is released 
that it's the only jdk we use to compile Cassandra-4.0+ with.

regards,
Mick

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[dinesh.jo...@yahoo.com.INVALID]

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 could be time 
consuming.
Dinesh 

On Wednesday, August 22, 2018, 10:12:35 AM PDT, Sumanth Pasupuleti 
 wrote:  
 
 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 provide your thoughts.

C* 2.2
Goal:
Need to support Java7 and Java8.
Current State:
CircleCI workflow to build, run UTs and DTests against Java8 (run by
default)
Proposed State:
* Add CircleCI workflow to build against Java7 (
https://issues.apache.org/jira/browse/CASSANDRA-14625), and optionally run
UTs and DTests against Java7
* Add a tool like AnimalSniffer into build process (proposed by Mick in
https://issues.apache.org/jira/browse/CASSANDRA-14563), so that build would
fail as part of the development process in case of JDK incompatibility.


C* 3.0 and 3.11
Goal:
Support Java8.
Current state:
CircleCI workflow to build, run UTs and DTests against Java8 (run by
default)
Proposed State:
* No change. Same as current.


C* 4.0
Goal:
Support Java8 and Java11.
Current state:
CircleCI workflow to build, run UTs and DTests against Java8 (run by
default)
Proposed State:
* Add CircleCI workflow to build against Java11, and optionally run UTs and
DTests against Java11

Looking forward to any feedback.

Thanks,
Sumanth