accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Fri, 06 May 2016 03:39:20 GMT
Thanks boss. I figured you'd have my back :)
On May 5, 2016 9:43 PM, "Christopher" <ctubbsii@apache.org> wrote:

> Already pushed. Initially forgot about modernizer, but I'm working through
> it now.
>
> On Thu, May 5, 2016 at 7:25 PM Josh Elser <josh.elser@gmail.com> wrote:
>
> > Sounds good!
> >
> > I had tried to switch master to jdk8 as well, but ran into modernizer
> > plugin issues. I've since been on a call, so I haven't been able to push
> > that update. I'll get to it when I can, but perhaps someone has beaten
> > me to it already.
> >
> > Christopher wrote:
> > > 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