I was thinking the same thing, and if we are going to do that, lets bump the versions of our major dependencies (Hadoop, ZK, etc). Josh is making good progress on the VFS front, much more than I was able to achieve. 1.8-SNAPSHOT has over 260 resolved issues. We could resolve the 5 open blockers, bump the JDK and dependency versions, and rename 1.8 to 2.0.
----- Original Message ----- From: "Sean Busbey" <[email protected]> To: "dev@accumulo apache. org" <[email protected]> Sent: Monday, May 2, 2016 1:54:53 AM Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache) If we drop jdk7 support, I would strongly prefer a major version bump. On Sun, May 1, 2016 at 1:43 PM, Josh Elser <[email protected]> wrote: > Folks -- > > Let's come up with a plan for Java 8 support. Do we bump minJdk for > accumulo-1.8.0 to 8? Should we fork a branch for 1.8 and make master > 2.0.0-SNAPSHOT (and do the bump there)? > > Other approaches? > > - Josh > > -------- Original Message -------- > Subject: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache > Date: Sat, 30 Apr 2016 01:06:12 +0000 (UTC) > From: Ben Manes (JIRA) <[email protected]> > Reply-To: [email protected] > To: [email protected] > > > [ > https://issues.apache.org/jira/browse/ACCUMULO-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15265032#comment-15265032 > > ] > > Ben Manes commented on ACCUMULO-4177: > ------------------------------------- > > I can put something together when Accumulo is ready to accept Java 8 > patches. Let me know. > >> TinyLFU-based BlockCache >> ------------------------ >> >> Key: ACCUMULO-4177 >> URL: https://issues.apache.org/jira/browse/ACCUMULO-4177 >> Project: Accumulo >> Issue Type: Improvement >> Reporter: Ben Manes >> >> >> [LruBlockCache|https://github.com/apache/accumulo/blob/master/core/src/main/java/org/apache/accumulo/core/file/blockfile/cache/LruBlockCache.java] >> >> appears to be based on HBase's. I currently have a patch being reviewed in >> [HBASE-15560|https://issues.apache.org/jira/browse/HBASE-15560] that >> replaces the pseudo Segmented LRU with the TinyLFU eviction policy. That >> should allow the cache to make [better >> predictions|https://github.com/ben-manes/caffeine/wiki/Efficiency] based on >> frequency and recency, such as improved scan resistance. The implementation >> uses [Caffeine|https://github.com/ben-manes/caffeine], the successor to >> Guava's cache, to provide concurrency and keep the patch small. >> Full details are in the JIRA ticket. I think it should be easy to port if >> there is interest. > > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) -- busbey
