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 Thu, 05 May 2016 23:24:55 GMT
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
View raw message