Okay, thanks for the responses. It's pretty clear that bumping to JRE 7 as a minimum is unacceptable for 1.6.x, and that's understandable.
At this point, I think it would be best to back off to Jetty 8 for 1.6.x, and created a ticket (ACCUMULO-2934) to do that. Feel free to continue the discussion if there's any new thoughts. I'll not be able to work on ACCUMULO-2934 over the weekend anyway, and I'll check back here before I do. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Jun 20, 2014 at 5:59 PM, Bill Havanki <[email protected]> wrote: > +1 for option 2, -1 for option 1 ... in other words, keep Accumulo 1.6.x at > Java 6. As a cluster admin I'd be unpleasantly surprised to find that I > need to update Java versions for a minor/bugfix (whatever we call it) > release. > > I am happy with the idea of moving to Jetty 8 for 1.6.x as part of > ACCUMULO-2786. Originally the ticket didn't call for upgrading Jetty, but > just getting its libraries included in packaging, but at this point, it's > sensible and more responsible to upgrade too. > > > On Fri, Jun 20, 2014 at 5:39 PM, Christopher <[email protected]> wrote: > > > More data points to consider: > > > > mortbay Jetty has known security vulnerabilities (albeit relatively low > > ones) > > > > > http://www.cvedetails.com/vulnerability-list/vendor_id-9694/product_id-17330/Mortbay-Jetty.html > > > > Jetty 6 was announced as deprecated in January 2012 (for some performance > > and security issues) > > http://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00026.html > > > > Another option is to bump down to Jetty 8 for 1.6.x, which might be a > > smaller change that would keep us on JRE 6, and still satisfy > > ACCUMULO-2786. > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Fri, Jun 20, 2014 at 5:27 PM, Sean Busbey <[email protected]> > wrote: > > > > > strong -1 on option 1; 1.6.0 went out with Java 6 as a minimum and we > > > should not change that in the major release. > > > > > > +1 on option 2. > > > > > > > > > On Fri, Jun 20, 2014 at 5:22 PM, Mike Drob <[email protected]> > wrote: > > > > > > > +1 for option 2. > > > > > > > > We promised users that they can use Java 6 for 1.6.0 and it would be > > very > > > > jarring to suddenly require 1.7.0. > > > > > > > > April 2015 is a long time away, and I'm not sure that the world will > > > > migrate quickly, given how long it took for Java 7 adoption. > > > > > > > > > > > > On Fri, Jun 20, 2014 at 4:19 PM, Christopher <[email protected]> > > > wrote: > > > > > > > > > As pointed out by Dave on ACCUMULO-2808, it looks like > ACCUMULO-2808 > > / > > > > > ACCUMULO-2786 causes the monitor to require Java 7. > > > > > > > > > > Personally, I'm okay with this, but obviously this was not expected > > or > > > > > intended. > > > > > > > > > > Since we're still targeting Java 6 in our Accumulo build, the other > > > > > Accumulo services will still run in JRE6, and our code is still > JRE6 > > > > > compatible (even if we build with JDK7). If building with JDK7 > fixed > > > the > > > > > issue and produced a monitor service that ran fine in JRE6, I'd say > > no > > > > > problem: we build with JDK7, while targeting JRE6. However, I don't > > > think > > > > > that will work. I think the monitor will just fail at runtime > rather > > > than > > > > > compile time (if somebody has time to check, I'd appreciate > > > > confirmation). > > > > > > > > > > So, our choices seem to be: > > > > > > > > > > 1. Make note of this requirement in the release notes for 1.6.1 and > > > > target > > > > > JRE7 in future 1.6 builds, or > > > > > 2. Back out the changes for ACCUMULO-2808 from 1.6.1, and redo > > > > > ACCUMULO-2786 with some other implementation. > > > > > > > > > > (It should be noted that Java 7 is expected to be EOL in April > 2015; > > > the > > > > > announcement was already made, so people should be migrating to 8 > > > > already, > > > > > if possible) > > > > > > > > > > -- > > > > > Christopher L Tubbs II > > > > > http://gravatar.com/ctubbsii > > > > > > > > > > > > > > > > > > > > > -- > > > Sean > > > > > > > > > -- > // Bill Havanki > // Solutions Architect, Cloudera Govt Solutions > // 443.686.9283 >
