accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlmar...@comcast.net
Subject Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)
Date Tue, 03 May 2016 20:48:42 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message