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 Tue, 03 May 2016 20:56:16 GMT
Anything is possible! Even more if you figured out how to go faster than 
the speed of light ;)

dlmarion@comcast.net wrote:
> Branch 1.8, leave at JDK 7
> Move master to 2.0.0-SNAPSHOT and:
> ->  Move to JDK 8
> ->  Remove deprecated items
> ->  Bump versions for dependencies (*Htrace issue)
>
> Question: Could we release 1.8.0 and 2.0.0 around the same time such that 2.0.0 is equivalent
to 1.8.0 except for the changes mentioned above?
>
> ----- Original Message -----
>
> From: "Josh Elser"<josh.elser@gmail.com>
> To: dev@accumulo.apache.org
> Sent: Tuesday, May 3, 2016 4:33:39 PM
> Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based
BlockCache)
>
> 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