accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Thu, 05 May 2016 17:53:00 GMT
Okay, so if we're okay treating the master branch as a 2.0 development
branch, then I'm going to go ahead and start focusing on some 2.0 tickets
that may involve refactoring which have breaking changes that I've been
reluctant to do before without an explicit 2.0 development branch. Of
course, none of this says we have to stop development on 1.x stuffs, or
says anything about when we'll release a 2.0, but it'd be nice to have a
place to start putting in stuff for an eventual 2.0.

On Thu, May 5, 2016 at 11:07 AM Josh Elser <josh.elser@gmail.com> wrote:

> Ok, looks to me that we are in agreement now and don't need a vote.
>
> I will create a 1.8 branch today (updating Jenkins appropriately) so we
> can get master in a state that would be ready for the changes in 4177.
>
> Keith Turner wrote:
> > 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