accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Tue, 03 May 2016 21:09:17 GMT
On Tue, May 3, 2016 at 4:54 PM, Christopher <ctubbsii@apache.org> wrote:

> I think I'd prefer leaving 1.8 as it stands, with the expectation to have a
> release line of 1.8 which only requires Java 7.
>

+1

I can not see any reason to switch to JDK8 before releasing 1.8... assuming
thats going to happen soonish


>
> We can create a 2.0 branch, which bumps the Java version, and can accept
> changes which require Java 8 or API-breaking changes (as per semver) for
> the next major release line after 1.8.
>
> That would put us on a solid roadmap for 2.0 without disrupting 1.8
> development, which is probably already nearing release readiness.
>
> On Tue, May 3, 2016 at 4:33 PM Josh Elser <josh.elser@gmail.com> wrote:
>
> > Gotcha. Thanks for clarifying, Mike -- I'm inclined to agree with you. I
> > can't think of a reason why we would upgrade to Java8 and not make use
> > of it in some way (publicly or privately).
> >
> > That being said, I don't think I see consensus. How about we regroup in
> > the form of a vote? (normal semver rules are an invariant -- no changes
> > to our public API compatibility rules are implied by the below)
> >
> > * Call the current 1.8.0-SNAPSHOT (master) "2.0.0-SNAPSHOT" and move to
> > jdk8
> > * Branch 1.8, make master 2.0.0-SNAPSHOT. 1.8 stays jdk7, 2.0 goes jdk8
> >
> > Please chime in if I missed another option or am calling discussion too
> > soon. It just seems like we might have veered off-track and I don't want
> > this to fall to the wayside (again) without decision.
> >
> > Mike Drob wrote:
> > > If our code ends up using java 8 bytecode in any classes required by a
> > > consumer, then I think they will get compilation (linking?) errors,
> > > regardless of java 8 types in our methods signatures.
> > >
> > > On Tue, May 3, 2016 at 3:09 PM, Josh Elser<josh.elser@gmail.com>
> wrote:
> > >
> > >> That's a new assertion ("we can't actually use Java 8 features util
> > >> Accumulo-2"), isn't it? We could use new Java 8 features internally
> > which
> > >> would require a minimum of Java 8 and not affect the public API. These
> > are
> > >> related, not mutally exclusive, IMO.
> > >>
> > >> To Shawn's point: introducing Java 8 types/APIs was exactly the point
> --
> > >> we got here from ACCUMULO-4177 which does exactly that.
> > >>
> > >>
> > >> Mike Drob wrote:
> > >>
> > >>> I agree with Shawn's implied statement -- why bother dropping Java
7
> in
> > >>> any
> > >>> Accumulo 1.x if we can't actually make use of Java 8 features.until
> > >>> Accumulo 2.0
> > >>>
> > >>> On Tue, May 3, 2016 at 1:29 PM, Christopher<ctubbsii@apache.org>
> >  wrote:
> > >>>
> > >>> Right, these are competing and mutually exclusive goals, so we need
> to
> > >>>> decide which is a priority and on what timeline we should transition
> > to
> > >>>> Java 8 to support those goals.
> > >>>>
> > >>>> On Tue, May 3, 2016 at 9:16 AM Shawn Walker<
> accumulo@shawn-walker.net
> > >
> > >>>> wrote:
> > >>>>
> > >>>> I'm not sure that guaranteeing build-ability under Java 7 would
> > address
> > >>>> the
> > >>>>
> > >>>>> issue that raised this discussion:  We (might) want to add
a
> > dependency
> > >>>>> which requires Java 8.  Or, following Keith's comment, we might
> wish
> > to
> > >>>>> introduce Java 8 types (e.g. CompletableFuture<T>) into
Accumulo's
> > >>>>>
> > >>>> "public"
> > >>>>
> > >>>>> API.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Mon, May 2, 2016 at 6:42 PM, Christopher<ctubbsii@apache.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>> I don't feel strongly about this, but I was kind of thinking
that
> > we'd
> > >>>>> bump
> > >>>>>
> > >>>>>> to Java 8 dependency (opportunistically) when we were ready
to
> > develop
> > >>>>>>
> > >>>>> a
> > >>>>> 2.0 version. But, I'm not opposed to doing it on the 1.8 branch.
> > >>>>>> On Mon, May 2, 2016 at 2:50 PM William Slacum<wslacum@gmail.com>
> > >>>>>>
> > >>>>> wrote:
> > >>>>> So my point about versioning WRT to the Java runtime is more
about
> > >>>>>> how
> > >>>>> there are incompatibilities within the granularity of Java
versions
> > >>>>>> we
> > >>>>> talk
> > >>>>>>> about (I'm specifically referencing a Kerberos incompatibility
> > within
> > >>>>>>> versions of Java 7), so I think that just blanket saying
"We
> > support
> > >>>>>>>
> > >>>>>> Java X
> > >>>>>>
> > >>>>>>> or Y" really isn't enough. I personally feel some kind
of version
> > >>>>>>>
> > >>>>>> bump
> > >>>>> is
> > >>>>>
> > >>>>>> nice to say that something has changed, but until the public
API
> > >>>>>> starts
> > >>>>> exposing Java 8 features, it's a total cop out to say, "Here's
all
> > >>>>>> these
> > >>>>>> bug fixes and some new features, oh by the way upgrade
your
> > >>>>>> infrastructure
> > >>>>>>
> > >>>>>>> because we decided to use a new Java version for an
optional
> > >>>>>>>
> > >>>>>> feature".
> > >>>>> The best parallel I can think of is in Scala, where there's
no
> binary
> > >>>>>>> compatibility between minor versions (ie, 2.10, 2.11,etc),
so
> > there's
> > >>>>>>> generally an extra qualifier on libraries marking the
scala
> > >>>>>>>
> > >>>>>> compability
> > >>>>> level. Would we ever want to have accumulo-server-1.7-j[7|8]
> styled
> > >>>>>>> artifacts to signal some general JRE compatibility?
It's a total
> > >>>>>>>
> > >>>>>> mess,
> > >>>>> but
> > >>>>>>> I haven't seen a better solution.
> > >>>>>>>
> > >>>>>>> Another idea is we could potentially have some guarantee
for Java
> > 7,
> > >>>>>>>
> > >>>>>> such
> > >>>>>> as making sure we can build a distribution using Java 7,
but only
> > >>>>>>> distribute Java 8 artifacts by default?
> > >>>>>>>
> > >>>>>>> On Mon, May 2, 2016 at 2:30 PM, Josh Elser<josh.elser@gmail.com>
> > >>>>>>>
> > >>>>>> wrote:
> > >>>>>> Sean Busbey wrote:
> > >>>>>>>> On Mon, May 2, 2016 at 8:55 AM, Josh Elser<josh.elser@gmail.com
> >
> > >>>>>>>> wrote:
> > >>>>>>>>    Thanks for the input, Sean.
> > >>>>>>>>>>>    Playing devil's advocate: we didn't
have a major version
> > bump
> > >>>>>>>>>>>
> > >>>>>>>>>> when
> > >>>>>> we
> > >>>>>>>>    dropped JDK6 support (in Accumulo-1.7.0). Oracle
has EOL'ed
> > >>>>>>>>>> java 7
> > >>>>>> back in
> > >>>>>>>>>>>    April  2015. Was the 6->7 upgrade
different than a 7->8
> > >>>>>>>>>>>
> > >>>>>>>>>> upgrade?
> > >>>>> On Mon, May 2, 2016 at 10:31 AM, Keith Turner<keith@deenlo.com>
> > >>>>>>>> wrote:
> > >>>>>>>    On Mon, May 2, 2016 at 1:54 AM, Sean Busbey<
> > >>>>>>>>>> busbey@cloudera.com
> > >>>>> wrote:
> > >>>>>>>>>>>    If we drop jdk7 support, I would
strongly prefer a major
> > >>>>>>>>>>>> version
> > >>>>>> bump.
> > >>>>>>>>>>>
> > >>>>>>>>>>>    Whats the rationale for binding
a bump to Accumulo 2.0
> with
> > a
> > >>>>>>>>>>>
> > >>>>>>>>>> bump
> > >>>>>> in
> > >>>>>>>> the
> > >>>>>>>>>>>    JDK version?
> > >>>>>>>>>>>
> > >>>>>>>>>>> The decision to drop JDK6 support happened
in latemarch  /
> > >>>>>>>> earlyApril
> > >>>>>> 2014[1], long before any of our discussions or decisions
on
> > >>>>>>>> semver.
> > >>>>> AFAICT it didn't get discussed again, presumably because by
the
> > >>>>>>>> time
> > >>>>> we got to 1.7.0 RCs it was too far in the past.
> > >>>>>>>>> Thanks for the correction, Sean. I hadn't dug
around closely
> > >>>>>>> enough.
> > >>>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message