git.net

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

Re: Supporting multiple JDKs


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