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 15:07:04 GMT
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