Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <CAL5zq9bRQmw+KWqoDDeR7ww2WiphQgQVo0qN7QOd=_Tzr7T+TA@mail.gmail.com>
References: <57264E4B.1070901@gmail.com>
	<CAGHyZ6JTO3qUuXQL6NEgMoaAZBh=avJpDu4hsYx__d7FhCsreQ@mail.gmail.com>
	<CAGUtCHrQHnD-D1JJ0JBkxQZW-LaR7P--iWFBc3M=N4ipHYt0gw@mail.gmail.com>
	<CAGHyZ6JKHPD2F5DrEc6vVWj53eVjTHcfc9PUConDjedzFfv1xw@mail.gmail.com>
	<57279CAA.8030200@gmail.com>
	<CALs3O6jhiXXczES3KsL2SxX5HQH=jONyPE9DspXNnMtp-=Ti+g@mail.gmail.com>
	<CAL5zq9bWmt5p=5YO=bJknos+tf1ePRTd0a0gej-5oRZiMn-ODg@mail.gmail.com>
	<CAD=3M0z4xtn3NqJQX1FqAAB_evixNQ9JjGhgAOONM9yJufFKbQ@mail.gmail.com>
	<CAL5zq9YkSY0xiOCVjGp2jH2-C2TSQR0pHBxJR_r-PEnUt8VOMg@mail.gmail.com>
	<CAJRvFdqOemg7LNp1LgLWdQNgN1FB=t9Fv1ApEv8Y+5CK3+Rm9Q@mail.gmail.com>
	<57290589.8020609@gmail.com>
	<CAJRvFdqhLEZZPGtoyLc8U14SKT03N+4+gEttf9rHSntyYfA4WA@mail.gmail.com>
	<57290B23.6060600@gmail.com>
	<CAL5zq9aps+O0pTXabsTo1h0PfwM-L2z_hKtn835xhWy-wCFwog@mail.gmail.com>
	<CAGUtCHpWKZA52ubRVUcYa21GrFtwmqxGAqw_W-_vcRJJiL+CLQ@mail.gmail.com>
	<572B6198.70204@gmail.com>
	<CAL5zq9bscfGAvXRsO95eY0D5088A1hFSxir_X-tymxSJoH_kKA@mail.gmail.com>
	<572BD647.4020701@gmail.com>
	<CAL5zq9YSHNyjNoFuV2cdorQ-LYYquzHTT+U+DEyKa2L8zyK+9Q@mail.gmail.com>
	<CAOyNEs5QmphKePvp4boJAgiEdnovi0X_ZGa-gG=ZosqrM3Aymw@mail.gmail.com>
	<CAL5zq9bRQmw+KWqoDDeR7ww2WiphQgQVo0qN7QOd=_Tzr7T+TA@mail.gmail.com>
Date: Fri, 6 May 2016 10:25:44 -0400
Message-ID: <CAOyNEs65L9x2YAMAAdSgjwqvjeM3qLMM5ndtbsjCJ_ZgDESuqw@mail.gmail.com>
Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented]
 (ACCUMULO-4177) TinyLFU-based BlockCache)
From: Josh Elser <josh.elser@gmail.com>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=001a1142cdd4f4609305322d3bbb
archived-at: Fri, 06 May 2016 14:25:50 -0000

--001a1142cdd4f4609305322d3bbb
Content-Type: text/plain; charset=UTF-8

We can't disable modernizer just for mock? Or really, any code which we
intentionally don't want to modernize?
On May 5, 2016 11:43 PM, "Christopher" <ctubbsii@apache.org> wrote:

> Another interesting point... didn't realize until actually doing it:
> bumping to JDK8 *requires* a bump in the major version, because modernizer
> will block on some incompatible API changes in Mock, which is already
> deprecated. (Unless we're okay with disabling modernizer... which I guess
> is an acceptable solution... but it makes me unhappy :) )
>
> On Thu, May 5, 2016 at 11:39 PM Josh Elser <josh.elser@gmail.com> wrote:
>
> > 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.
> > > > >
> > > >
> > >
> >
>

--001a1142cdd4f4609305322d3bbb--