Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Message-ID: <572BD647.4020701@gmail.com>
Date: Thu, 05 May 2016 19:24:55 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177)
 TinyLFU-based BlockCache)
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>
In-Reply-To: <CAL5zq9bscfGAvXRsO95eY0D5088A1hFSxir_X-tymxSJoH_kKA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Thu, 05 May 2016 23:25:07 -0000

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