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 <m...@apache.org> 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 > >
