git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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, Sumanth Pasupuleti <
sumanth.pasupuleti.is@xxxxxxxxx> 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 <mck@xxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >
> >
>