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