[
https://issues.apache.org/jira/browse/CASSANDRA-14563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560937#comment-16560937
]
Sumanth Pasupuleti edited comment on CASSANDRA-14563 at 8/11/18 4:17 PM:
-------------------------------------------------------------------------
I agree with you that AnimalSniffer catches incompatibilities at compile-time;
so would the circleCI build job against jdk1.7 isn't it? For example, here is
the build failure with java8 specific change, breaking the java7 build workflow
(that has my circle CI java7 workflow changes) -
[https://circleci.com/gh/sumanth-pasupuleti/cassandra/56]. (I am done with the
circleCI workflow way of implementation - will polish it up for patch if we
agree with this approach)
I was hoping CircleCI way of doing it could be beneficial in the sense
* We could use similar workflow in config.yml in the future for trunk, when we
may need to support multiple versions of JAVA (java8, java9, etc)
* Since all of our releases get validated through CircleCI, thought java7
specific workflow would benefit, which would truly use jdk1.7 for compilation
* This would avoid having dependency on an external jar like AnimalSniffer
{quote}it's an expensive way for us to support jdk1.7 at runtime
{quote}
I am trying to understand how this is more expensive - are you referring to
have to run an additional workflow in CircleCI?
I am happy to work on AnimalSniffer approach as well, but just trying to
understand better, as to why CircleCI workflow for java7 would not work for us.
Here is the PR for CircleCI changes to add java7 build workflow
https://github.com/apache/cassandra/pull/248
was (Author: sumanth.pasupuleti):
I agree with you that AnimalSniffer catches incompatibilities at compile-time;
so would the circleCI build job against jdk1.7 isn't it? For example, here is
the build failure with java8 specific change, breaking the java7 build workflow
(that has my circle CI java7 workflow changes) -
[https://circleci.com/gh/sumanth-pasupuleti/cassandra/56]. (I am done with the
circleCI workflow way of implementation - will polish it up for patch if we
agree with this approach)
I was hoping CircleCI way of doing it could be beneficial in the sense
* We could use similar workflow in config.yml in the future for trunk, when we
may need to support multiple versions of JAVA (java8, java9, etc)
* Since all of our releases get validated through CircleCI, thought java7
specific workflow would benefit, which would truly use jdk1.7 for compilation
* This would avoid having dependency on an external jar like AnimalSniffer
{quote}it's an expensive way for us to support jdk1.7 at runtime
{quote}
I am trying to understand how this is more expensive - are you referring to
have to run an additional workflow in CircleCI?
I am happy to work on AnimalSniffer approach as well, but just trying to
understand better, as to why CircleCI workflow for java7 would not work for us.
Here is the PR for CircleCI changes to add java7 build workflow
https://github.com/apache/cassandra/pull/243
> Add animalsniffer to build to ensure runtime jdk compatbility
> -------------------------------------------------------------
>
> Key: CASSANDRA-14563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14563
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
> Reporter: mck
> Assignee: Sumanth Pasupuleti
> Priority: Minor
> Labels: lhf
>
> Cassandra-2.2 still supports running on JDK1.7
> No tests check this though, as all build and test with JDK1.8
> Adding the ant animalsniffer task can check that jdk1.8 classes or methods
> are not used accidentally.
> ref: http://www.mojohaus.org/animal-sniffer/animal-sniffer/index.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
