On Fri, Jun 20, 2014 at 5:01 PM, Andrew Wang <andrew.w...@cloudera.com> wrote:
> Thanks everyone for the discussion so far. I talked with some of our other > teams and thought about the issue some more. > > Regarding branch-2, we can't do much because of compatibility. Dropping > support for a JDK is supposed to happen in a major release. I think we all > understand this though, so it's not really under discussion. > +1 > > Regarding trunk, I think that leapfrogging to JDK8 is the right move. JDK7 > is EOL April next year, so it'd be better to avoid going through this pain > twice so soon. Developer momentum also seems very strong behind JDK8 > because of all the shiny new features, so I think we'll see quick adoption. > We also need some time to clean up APIs and I'm sure people have big, > incompatible project ideas floating around they'd like to get in. > +1, doesn't seem to be much point in targeting another JDK version that will be EOL so soon. > > With the JDK7 EOL in mind, we need a JDK8-based 3.0 release by mid next > year. Since I have a strong interest in all these things, I'd like to > volunteer as release manager for this beast. This means, yep, I'll wrangle > the builds, worry about compat, bump lib versions, and all those other fun > tasks. There's clearly a lot to discuss logistically (let's take that to a > different thread), but this feels like the right way forward to me. > +1, thanks a lot for volunteering to take this on. > > Best, > Andrew > > On Fri, Jun 20, 2014 at 11:10 AM, Bryan Beaudreault < > bbeaudrea...@hubspot.com> wrote: > > > As one of the customers you guys have referenced a few times, I 100% > agree > > with Colin. :) > > > > We had to wait a few years for java7 to be supported for hadoop, or > > certified at least. It would be great to not have to wait a few years > > again for the newly released java8. People are already clamoring to use > it > > at our company, but we have to tell them "no" if their code in any way is > > pulled in by a hadoop job. > > > > It seems an easier and more wide-reaching priority to first ensure > > compatibility with newer JVMs, then hammer out deprecation of older and > use > > of new APIs internally. Those are of lesser concern to many of the > > customers I'd think. > > > > > > On Fri, Jun 20, 2014 at 2:02 PM, Colin McCabe <cmcc...@alumni.cmu.edu> > > wrote: > > > > > Er, that should read "order in which it ran unit tests." > > > > > > C. > > > > > > On Fri, Jun 20, 2014 at 11:02 AM, Colin McCabe <cmcc...@alumni.cmu.edu > > > > > wrote: > > > > I think the important thing to do right now is to ensure our code > > > > works with jdk8. This is similar to the work we did last year to fix > > > > issues that cropped up with jdk7. There were just a few minor things > > > > like the error in which it ran unit tests that caused issues. > > > > > > > > I don't think it's out of the question to bump minVersion directly > > > > from 1.6 to 1.8. Java 7 is EOL in less than a year, after all... at > > > > least according to the current roadmap here: > > > > http://www.oracle.com/technetwork/java/eol-135779.html > > > > > > > > We should try to do things in a way that causes the least disruption > > > > for users upgrading clusters, if possible... > > > > > > > > cheers, > > > > Colin > > > > > > > > On Thu, Jun 19, 2014 at 3:31 PM, Andrew Purtell <apurt...@apache.org > > > > > wrote: > > > >> There are a number of security (algorithm, not vulnerability) and > > > >> performance improvements that landed in 8, not 7. As a runtime for > the > > > >> performance conscious, it might be recommendable. I've come across > GC > > > >> issues in 6 or 7 where, talking with some Java platform folks, the > > first > > > >> suggested course of action is try again with 8. Would be be more of > > the > > > >> current moment if this discussion was about setting guidelines that > > > >> prescribe when and when not to use 8+ language features, or > > concurrency > > > >> library improvements that rely on intrinsics only available in the 8 > > > >> runtime? Has the Java 6 ship sailed? Just set the minimum supported > > JDK > > > and > > > >> runtime at 7 at next release? Use of the <> operator or multicatch > > > wouldn't > > > >> and shouldn't need be debated, they are quite minor. On the other > > hand, > > > I > > > >> would imagine discussion and debate on what 8+ language features > might > > > be > > > >> useful to use at some future time could be a lively one. > > > >> > > > >> > > > >> > > > >> On Wed, Jun 18, 2014 at 3:03 PM, Colin McCabe < > cmcc...@alumni.cmu.edu > > > > > > >> wrote: > > > >> > > > >>> In CDH5, Cloudera encourages people to use JDK7. JDK6 has been EOL > > > >>> for a while now and is not something we recommend. > > > >>> > > > >>> As we discussed before, everyone is in favor of upgrading to JDK7. > > > >>> Every cluster operator of a reasonably modern Hadoop should do > it.... > > > >>> whatever distro or release you run. As developers, we run JDK7 as > > > >>> well. > > > >>> > > > >>> I'd just like to see a plan for when branch-2 (or some other > branch) > > > >>> will create a stable release that drops support for JDK1.6. If we > > > >>> don't have such a plan, I feel like it's too early to talk about > this > > > >>> stuff. > > > >>> > > > >>> If we drop support for 1.6 in trunk but not in branch-2, we are > > > >>> fragmenting the project. People will start writing unreleaseable > > code > > > >>> (because it doesn't work on branch-2) and we'll be back to the bad > > old > > > >>> days of Hadoop version fragmentation that branch-2 was intended to > > > >>> solve. Backports will become harder. The biggest problem is that > > > >>> trunk will start to depend on libraries or Maven plugins that > > branch-2 > > > >>> can't even use, because they're JDK7+-only. > > > >>> > > > >>> Steve wrote: "if someone actually did file a bug on something on > > > >>> branch-2 which didn't work on Java 6 but went away on Java7+, we'd > > > >>> probably close it as a WORKSFORME". > > > >>> > > > >>> Steve, if this is true, we should just bump the minimum supported > > > >>> version for branch-2 to 1.7 today and resolve this. If we truly > > > >>> believe that there are no issues here, then let's just decide to > drop > > > >>> 1.6 in a specific future release of Hadoop 2. If there are issues > > > >>> with releasing JDK1.7+ only code, then let's figure out what they > are > > > >>> before proceeding. > > > >>> > > > >>> best, > > > >>> Colin > > > >>> > > > >>> > > > >>> On Wed, Jun 18, 2014 at 1:41 PM, Sandy Ryza < > sandy.r...@cloudera.com > > > > > > >>> wrote: > > > >>> > We do release warnings when we are aware of vulnerabilities in > our > > > >>> > dependencies. > > > >>> > > > > >>> > However, unless I'm grossly misunderstanding, the vulnerability > > that > > > you > > > >>> > point out is not a vulnerability within the context of our > > software. > > > >>> > Hadoop doesn't try to sandbox within JVMs. In a secure setup, > any > > > JVM > > > >>> > running non-trusted user code is running as that user, so > "breaking > > > out" > > > >>> > doesn't offer the ability to do anything malicious. > > > >>> > > > > >>> > -Sandy > > > >>> > > > > >>> > On Wed, Jun 18, 2014 at 1:30 PM, Ottenheimer, Davi < > > > >>> davi.ottenhei...@emc.com > > > >>> >> wrote: > > > >>> > > > > >>> >> Andrew, > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> “I don't see any point to switching” is an interesting > > perspective, > > > >>> given > > > >>> >> the well-known risks of running unsafe software. Clearly > customer > > > best > > > >>> >> interest is stability. JDK6 is in a known unsafe state. The > longer > > > >>> anyone > > > >>> >> delays the necessary transition to safety the longer the door is > > > left > > > >>> open > > > >>> >> to predictable disaster. > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> You also said "we still test and support JDK6". I searched but > > have > > > not > > > >>> >> been able to find Cloudera critical security fixes for JDK6. > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> Can you clarify, for example, Java 6 Update 51 for > CVE-2013-2465? > > In > > > >>> other > > > >>> >> words, did you release to your customers any kind of public > alert > > or > > > >>> >> warning of this CVSS 10.0 event as part of your JDK6 support? > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> http://www.cvedetails.com/cve/CVE-2013-2465/ > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> If you are not releasing your own security fixes for JDK6 > post-EOL > > > would > > > >>> >> it perhaps be safer to say Cloudera is hands-off; neither > > supports, > > > nor > > > >>> >> opposes the known insecure and deprecated/unpatched JDK? > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> I mentioned before in this thread the Oracle support timeline: > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> - official public EOL (end of life) was more than a year ago > > > >>> >> > > > >>> >> - premier support ended more than six months ago > > > >>> >> > > > >>> >> - extended support may get critical security fixes until the end > > of > > > 2016 > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> Given this timeline, does Cloudera officially take > responsibility > > > for > > > >>> >> Hadoop customer safety? Are you going to be releasing critical > > > security > > > >>> >> fixes to a known unsafe JDK? > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> Davi > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > -----Original Message----- > > > >>> >> > > > >>> >> > From: Andrew Wang [mailto:andrew.w...@cloudera.com] > > > >>> >> > > > >>> >> > Sent: Wednesday, June 18, 2014 12:33 PM > > > >>> >> > > > >>> >> > To: common-dev@hadoop.apache.org > > > >>> >> > > > >>> >> > Subject: Re: Plans of moving towards JDK7 in trunk > > > >>> >> > > > >>> >> > > > > >>> >> > > > >>> >> > Actually, a lot of our customers are still on JDK6, so if > > > anything, > > > >>> its > > > >>> >> popularity > > > >>> >> > > > >>> >> > hasn't significantly decreased. We still test and support JDK6 > > for > > > >>> CDH4 > > > >>> >> and > > > >>> >> > > > >>> >> > CDH5. The claim that branch-2 is effectively JDK7 because no > one > > > >>> supports > > > >>> >> > > > >>> >> > JDK6 is untrue. > > > >>> >> > > > >>> >> > > > > >>> >> > > > >>> >> > One issue with your proposal is that java 7+ libraries can > have > > > >>> >> incompatible > > > >>> >> > > > >>> >> > APIs compared to their java 6 versions. Guava moves very > quickly > > > with > > > >>> >> regard > > > >>> >> > > > >>> >> > to the deprecate+remove cycle. This means branch-2 and trunk > > > >>> divergence, > > > >>> >> > > > >>> >> > as we're stuck using different Guava APIs to do the same > thing. > > > >>> >> > > > >>> >> > > > > >>> >> > > > >>> >> > No one's arguing against moving to Java 7+ in trunk > eventually, > > > but > > > >>> >> there isn't > > > >>> >> > > > >>> >> > a clear plan for a trunk-based release. I don't see any point > to > > > >>> >> switching trunk > > > >>> >> > > > >>> >> > over until that's true, for the aforementioned reasons. > > > >>> >> > > > >>> >> > > > > >>> >> > > > >>> >> > Best, > > > >>> >> > > > >>> >> > Andrew > > > >>> >> > > > >>> >> > > > > >>> >> > > > >>> >> > > > > >>> >> > > > >>> >> > On Wed, Jun 18, 2014 at 12:08 PM, Steve Loughran > > > >>> >> > > > >>> >> > <ste...@hortonworks.com<mailto:ste...@hortonworks.com>> > > > >>> >> > > > >>> >> > wrote: > > > >>> >> > > > >>> >> > > > > >>> >> > > > >>> >> > > I also think we need to recognise that its been three months > > > since > > > >>> >> > > > >>> >> > > that last discussion, and Java 6 has not suddenly burst back > > > into > > > >>> >> > > > >>> >> > > popularity > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > - nobody providing commercial support for Hadoop is > > offering > > > >>> >> branch-2 > > > >>> >> > > > >>> >> > > support on Java 6 AFAIK > > > >>> >> > > > >>> >> > > - therefore, nobody is testing it at scale except > > privately, > > > and > > > >>> >> they > > > >>> >> > > > >>> >> > > aren't reporting bugs if they are > > > >>> >> > > > >>> >> > > - if someone actually did file a bug on something on > > branch-2 > > > >>> which > > > >>> >> > > > >>> >> > > didn't work on Java 6 but went away on Java7+, we'd > > probably > > > >>> close > > > >>> >> > > > >>> >> > > it as a > > > >>> >> > > > >>> >> > > WORKSFORME > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > whether we acknowledge it or not, Hadoop 2.x is now really > > Java > > > 7+. > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > We do all agree that hadoop 3 will not be java 6, so the > only > > > issue > > > >>> is > > > >>> >> > > > >>> >> > > "when and how to make that transition". > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > That patch of mine just makes it possible to do today. > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > I have actually jumped to Java7 in the slider project, and > > > actually > > > >>> >> > > > >>> >> > > being using Java 8 and twill; the new language features > there > > > are > > > >>> >> > > > >>> >> > > significant and would be great to use in Hadoop *at some > point > > > in > > > >>> the > > > >>> >> > > > >>> >> > > future* > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > For Java 7 though, based on that experience, the language > > > changes > > > >>> are > > > >>> >> > > > >>> >> > > convenient but not essential > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > - try-with-resources simply swallows close failures > without > > > the > > > >>> log > > > >>> >> > > > >>> >> > > integration we have with IOUtils.closeStream(), so > shoudn't > > > be > > > >>> used > > > >>> >> in > > > >>> >> > > > >>> >> > > hadoop core anyway. > > > >>> >> > > > >>> >> > > - string based switching: convenient, but not critical > > > >>> >> > > > >>> >> > > - type inference on template constructors. Modern IDEs > > > handle the > > > >>> >> pain > > > >>> >> > > > >>> >> > > anyway > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > The only feature I like is multi-catch and typed rethrow > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > catch(IOException | ExitException e) { > log.warn(e.toString(); > > > >>> throw > > > >>> >> > > > >>> >> > > e; } > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > this would make "e" look like Exception, but when rethrown > go > > > back > > > >>> to > > > >>> >> > > > >>> >> > > its original type. > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > This reduces duplicate work, and is the bit l actually > value. > > > Is it > > > >>> >> > > > >>> >> > > enough to justify making code incompatible across branches? > > No. > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > So i'm going to propose this, and would like to start a vote > > on > > > it > > > >>> >> > > > >>> >> > > soon > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > 1. we parameterize java versions in the POMs on all > > branches, > > > >>> with > > > >>> >> > > > >>> >> > > separate JDK versions and Java language > > > >>> >> > > > >>> >> > > 2. branch-2: java-6-language and JDK-6 minimum JDK > > > >>> >> > > > >>> >> > > 3. trunk: java-6-language and JDK-7 minimum JDK > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > This would guarantee that none of the java 7 language > features > > > went > > > >>> >> > > > >>> >> > > in, but we could move trunk up to java 7+ only libraries > > > (jersey, > > > >>> >> > > > >>> >> > > guava). Adopting > > > >>> >> > > > >>> >> > > JDK7 features then becomes no more different from adopting > > > java7+ > > > >>> >> > > > >>> >> > > libraries: those bits of code that have moved can't be > > > backported. > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > -Steve > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > On 17 June 2014 22:08, Andrew Wang < > andrew.w...@cloudera.com > > > >>> <mailto: > > > >>> >> andrew.w...@cloudera.com>> > > > >>> >> > > > >>> >> > wrote: > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > > Reviving this thread, I noticed there's been a patch and > +1 > > on > > > >>> >> > > > >>> >> > > > HADOOP-10530, and I don't think we actually reached a > > > conclusion. > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > I (and others) have expressed concerns about moving to > JDK7 > > > for > > > >>> >> trunk. > > > >>> >> > > > >>> >> > > > Summarizing a few points: > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > - We can't move to JDK7 in branch-2 because of > compatibility > > > >>> >> > > > >>> >> > > > - branch-2 is currently the only Hadoop release vehicle, > > > there are > > > >>> >> > > > >>> >> > > > no > > > >>> >> > > > >>> >> > > plans > > > >>> >> > > > >>> >> > > > for a trunk-based Hadoop 3 > > > >>> >> > > > >>> >> > > > - Introducing JDK7-only APIs in trunk will increase > > divergence > > > >>> with > > > >>> >> > > > >>> >> > > > branch-2 and make backports harder > > > >>> >> > > > >>> >> > > > - Almost all developers care only about branch-2, since it > > is > > > the > > > >>> >> > > > >>> >> > > > only release vehicle > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > With this in mind, I struggle to see any upsides to > > > introducing > > > >>> >> > > > >>> >> > > > JDK7-only APIs to trunk. Please let's not do anything on > > > >>> >> > > > >>> >> > > > HADOOP-10530 or related until we agree on this. > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > Thanks, > > > >>> >> > > > >>> >> > > > Andrew > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > On Mon, Apr 14, 2014 at 3:31 PM, Steve Loughran > > > >>> >> > > > >>> >> > > > <ste...@hortonworks.com<mailto:ste...@hortonworks.com>> > > > >>> >> > > > >>> >> > > > wrote: > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > > On 14 April 2014 17:46, Andrew Purtell < > > apurt...@apache.org > > > >>> >> <mailto:apurt...@apache.org>> wrote: > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > > How well is trunk tested? Does anyone deploy it with > > real > > > >>> >> > > > >>> >> > > applications > > > >>> >> > > > >>> >> > > > > > running on top? When will the trunk codebase next be > the > > > basis > > > >>> >> > > > >>> >> > > > > > for a production release? An impromptu diff of > > > hadoop-common > > > >>> >> > > > >>> >> > > > > > trunk against > > > >>> >> > > > >>> >> > > > > > branch-2 as of today is 38,625 lines. Can they be said > > to > > > be > > > >>> the > > > >>> >> > > > >>> >> > > > > > same animal? I ask because any disincentive toward > > putting > > > >>> code > > > >>> >> > > > >>> >> > > > > > in trunk > > > >>> >> > > > >>> >> > > is > > > >>> >> > > > >>> >> > > > > > beside the point, if the only target worth pursuing > > today > > > is > > > >>> >> > > > >>> >> > > > > > branch-2 unless one doesn't care if the code is > released > > > for > > > >>> >> > > > >>> >> > production use. > > > >>> >> > > > >>> >> > > > > > Questions on whither JDK6 or JDK7+ (or JRE6 versus > > JRE7+) > > > only > > > >>> >> > > > >>> >> > > > > > matter > > > >>> >> > > > >>> >> > > > for > > > >>> >> > > > >>> >> > > > > > the vast majority of Hadoopers if talking about > > branch-2. > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > I think its partly a timescale issue; its also because > the > > > 1-2 > > > >>> >> > > > >>> >> > > transition > > > >>> >> > > > >>> >> > > > > was so significant, especially at the YARN layer, that > > it's > > > >>> still > > > >>> >> > > > >>> >> > > taking > > > >>> >> > > > >>> >> > > > > time to trickle through. > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > If you do want code to ship this year, branch-2 is where > > > you are > > > >>> >> > > > >>> >> > > > > going > > > >>> >> > > > >>> >> > > to > > > >>> >> > > > >>> >> > > > > try and get it in -and like you say, that's where things > > get > > > >>> tried > > > >>> >> > > > >>> >> > > > > in > > > >>> >> > > > >>> >> > > the > > > >>> >> > > > >>> >> > > > > field. At the same time, the constraints of stability > are > > > >>> holding > > > >>> >> > > > >>> >> > > > > us > > > >>> >> > > > >>> >> > > back > > > >>> >> > > > >>> >> > > > > -already-. > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > I don't see why we should have such another major 1-2 > > > transition > > > >>> >> > > > >>> >> > > > > in > > > >>> >> > > > >>> >> > > > future; > > > >>> >> > > > >>> >> > > > > the rate that Arun is pushing out 2.x releases its > almost > > > back > > > >>> to > > > >>> >> > > > >>> >> > > > > the > > > >>> >> > > > >>> >> > > > 0.1x > > > >>> >> > > > >>> >> > > > > timescale -though at that point most people were fending > > for > > > >>> >> > > > >>> >> > > > > themselves > > > >>> >> > > > >>> >> > > > and > > > >>> >> > > > >>> >> > > > > expectations of stability were less. We do want smaller > > > version > > > >>> >> > > > >>> >> > > > increments > > > >>> >> > > > >>> >> > > > > in future, which branch-2 is -mostly- delivering. > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > While Java 7 doesn't have some must-have features, Java > 8 > > > is a > > > >>> >> > > > >>> >> > > > significant > > > >>> >> > > > >>> >> > > > > improvement in the language, and we should be looking > > ahead > > > to > > > >>> >> > > > >>> >> > > > > that, > > > >>> >> > > > >>> >> > > > maybe > > > >>> >> > > > >>> >> > > > > even doing some leading-edge work on the side, so the > same > > > >>> >> > > > >>> >> > > > > discussion doesn't come up in two years time when java 7 > > > goes > > > >>> EOL. > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > -steve > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > (personal opinions only, etc, ) > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > On Mon, Apr 14, 2014 at 9:22 AM, Colin McCabe < > > > >>> >> > > > >>> >> > > cmcc...@alumni.cmu.edu<mailto:cmcc...@alumni.cmu.edu> > > > >>> >> > > > >>> >> > > > > > >wrote: > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > > I think the bottom line here is that as long as our > > > stable > > > >>> >> > > > >>> >> > > > > > > release uses JDK6, there is going to be a very, very > > > strong > > > >>> >> > > > >>> >> > > > > > > disincentive to put any code which can't run on JDK6 > > > into > > > >>> >> trunk. > > > >>> >> > > > >>> >> > > > > > > > > > >>> >> > > > >>> >> > > > > > > Like I said earlier, the traditional reason for > > putting > > > >>> >> > > > >>> >> > > > > > > something > > > >>> >> > > > >>> >> > > in > > > >>> >> > > > >>> >> > > > > > > trunk but not the stable release is that it needs > more > > > >>> testing. > > > >>> >> > > > >>> >> > > If a > > > >>> >> > > > >>> >> > > > > > > stable release that drops support for JDK6 is more > > than > > > a > > > >>> year > > > >>> >> > > > >>> >> > > away, > > > >>> >> > > > >>> >> > > > > > > does it make sense to put anything in trunk like > that? > > > What > > > >>> >> > > > >>> >> > > > > > > might need more than a year of testing? Certainly > not > > > >>> changes > > > >>> >> > > > >>> >> > > > > > > to LocalFileSystem to use the new APIs. I also > don't > > > think > > > >>> an > > > >>> >> > > > >>> >> > > > > > > upgrade > > > >>> >> > > > >>> >> > > > to > > > >>> >> > > > >>> >> > > > > > > various libraries qualifies. > > > >>> >> > > > >>> >> > > > > > > > > > >>> >> > > > >>> >> > > > > > > It might be best to shelve this for now, like we've > > > done in > > > >>> >> > > > >>> >> > > > > > > the > > > >>> >> > > > >>> >> > > past, > > > >>> >> > > > >>> >> > > > > > > until we're ready to talk about a stable release > that > > > >>> requires > > > >>> >> > > > >>> >> > > JDK7+. > > > >>> >> > > > >>> >> > > > > > > At least that's my feeling. > > > >>> >> > > > >>> >> > > > > > > > > > >>> >> > > > >>> >> > > > > > > If we're really desperate for the new file APIs JDK7 > > > >>> provides, > > > >>> >> > > > >>> >> > > > > > > we could consider using loadable modules for it in > > > branch-2. > > > >>> >> > > > >>> >> > > > > > > This is similar to how we provide JNI versions of > > > certain > > > >>> >> > > > >>> >> > > > > > > things on certain platforms, without dropping > support > > > for > > > >>> the > > > >>> >> other > > > >>> >> > > > >>> >> > platforms. > > > >>> >> > > > >>> >> > > > > > > > > > >>> >> > > > >>> >> > > > > > > best, > > > >>> >> > > > >>> >> > > > > > > Colin > > > >>> >> > > > >>> >> > > > > > > > > > >>> >> > > > >>> >> > > > > > > On Sun, Apr 13, 2014 at 10:39 AM, Raymie Stata < > > > >>> >> > > > >>> >> > > rst...@altiscale.com<mailto:rst...@altiscale.com> > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > > > wrote: > > > >>> >> > > > >>> >> > > > > > > > There's an outstanding question addressed to me: > > "Are > > > >>> there > > > >>> >> > > > >>> >> > > > > particular > > > >>> >> > > > >>> >> > > > > > > > features or new dependencies that you would like > to > > > >>> >> > > > >>> >> > > > > > > > contribute > > > >>> >> > > > >>> >> > > (or > > > >>> >> > > > >>> >> > > > > see > > > >>> >> > > > >>> >> > > > > > > > contributed) that require using the Java 1.7 > APIs?" > > > The > > > >>> >> > > > >>> >> > > > > > > > question misses the point: We'd figure out how to > > > write > > > >>> >> > > > >>> >> > > > > > > > something we > > > >>> >> > > > >>> >> > > wanted > > > >>> >> > > > >>> >> > > > to > > > >>> >> > > > >>> >> > > > > > > > contribute to Hadoop against the APIs of Java4 if > > > that's > > > >>> >> > > > >>> >> > > > > > > > what it > > > >>> >> > > > >>> >> > > > took > > > >>> >> > > > >>> >> > > > > > > > to get them into a stable release. And at current > > > course > > > >>> >> > > > >>> >> > > > > > > > and > > > >>> >> > > > >>> >> > > > speed, > > > >>> >> > > > >>> >> > > > > > > > that's how ridiculous things could get. > > > >>> >> > > > >>> >> > > > > > > > > > > >>> >> > > > >>> >> > > > > > > > To summarize, it seems like there's a vague > > consensus > > > that > > > >>> >> > > > >>> >> > > > > > > > it > > > >>> >> > > > >>> >> > > might > > > >>> >> > > > >>> >> > > > > be > > > >>> >> > > > >>> >> > > > > > > > okay to eventually allow the use of Java7 in > trunk, > > > but > > > >>> >> > > > >>> >> > > > > > > > there's > > > >>> >> > > > >>> >> > > no > > > >>> >> > > > >>> >> > > > > > > > decision. And there's been no answer to the > concern > > > that > > > >>> >> > > > >>> >> > > > > > > > even if > > > >>> >> > > > >>> >> > > > > such > > > >>> >> > > > >>> >> > > > > > > > dependencies were allowed in Java7, the only > people > > > using > > > >>> >> > > > >>> >> > > > > > > > them > > > >>> >> > > > >>> >> > > > would > > > >>> >> > > > >>> >> > > > > > > > be people who uninterested in getting their > patches > > > into a > > > >>> >> > > > >>> >> > > > > > > > stable release of Hadoop on any knowable > timeframe, > > > which > > > >>> >> > > > >>> >> > > > > > > > doesn't bode > > > >>> >> > > > >>> >> > > > well > > > >>> >> > > > >>> >> > > > > > > > for the ability to stabilize that Java7 code when > it > > > comes > > > >>> >> > > > >>> >> > > > > > > > time > > > >>> >> > > > >>> >> > > to > > > >>> >> > > > >>> >> > > > > > > > attempt to. > > > >>> >> > > > >>> >> > > > > > > > > > > >>> >> > > > >>> >> > > > > > > > I don't have more to add, so I'll go back to > > lurking. > > > >>> It'll > > > >>> >> > > > >>> >> > > > > > > > be interesting to see where we'll be standing a > year > > > from > > > >>> >> now. > > > >>> >> > > > >>> >> > > > > > > > > > > >>> >> > > > >>> >> > > > > > > > On Sun, Apr 13, 2014 at 2:09 AM, Tsuyoshi OZAWA > > > >>> >> > > > >>> >> > > > > > > > <ozawa.tsuyo...@gmail.com<mailto: > > > ozawa.tsuyo...@gmail.com > > > >>> >> > > > >>> >> wrote: > > > >>> >> > > > >>> >> > > > > > > >> Hi, > > > >>> >> > > > >>> >> > > > > > > >> > > > >>> >> > > > >>> >> > > > > > > >> +1 for Karthik's idea(non-binding). > > > >>> >> > > > >>> >> > > > > > > >> > > > >>> >> > > > >>> >> > > > > > > >> IMO, we should keep the compatibility between > JDK 6 > > > and > > > >>> JDK > > > >>> >> > > > >>> >> > > > > > > >> 7 on > > > >>> >> > > > >>> >> > > > > both > > > >>> >> > > > >>> >> > > > > > > branch-1 > > > >>> >> > > > >>> >> > > > > > > >> and branch-2, because users can be using them. > For > > > future > > > >>> >> > > > >>> >> > > releases > > > >>> >> > > > >>> >> > > > > > that > > > >>> >> > > > >>> >> > > > > > > we can > > > >>> >> > > > >>> >> > > > > > > >> declare breaking compatibility(e.g. 3.0.0 > release), > > > we > > > >>> can > > > >>> >> > > > >>> >> > > > > > > >> use > > > >>> >> > > > >>> >> > > > JDK 7 > > > >>> >> > > > >>> >> > > > > > > >> features if we > > > >>> >> > > > >>> >> > > > > > > >> can get benefits. However, it can increase > > > maintenance > > > >>> >> > > > >>> >> > > > > > > >> costs and > > > >>> >> > > > >>> >> > > > > > > distributes the > > > >>> >> > > > >>> >> > > > > > > >> efforts of contributions to maintain branches. > > Then, > > > I > > > >>> >> > > > >>> >> > > > > > > >> think it > > > >>> >> > > > >>> >> > > is > > > >>> >> > > > >>> >> > > > > > > >> reasonable approach > > > >>> >> > > > >>> >> > > > > > > >> that we use limited and minimum JDK-7 APIs when > we > > > have > > > >>> >> > > > >>> >> > > > > > > >> reasons > > > >>> >> > > > >>> >> > > we > > > >>> >> > > > >>> >> > > > > > need > > > >>> >> > > > >>> >> > > > > > > to use > > > >>> >> > > > >>> >> > > > > > > >> the features. > > > >>> >> > > > >>> >> > > > > > > >> By the way, if we start to use JDK 7 APIs, we > > should > > > >>> >> > > > >>> >> > > > > > > >> declare the > > > >>> >> > > > >>> >> > > > > basis > > > >>> >> > > > >>> >> > > > > > > >> when to use > > > >>> >> > > > >>> >> > > > > > > >> JDK 7 APIs on Wiki not to confuse contributors. > > > >>> >> > > > >>> >> > > > > > > >> > > > >>> >> > > > >>> >> > > > > > > >> Thanks, > > > >>> >> > > > >>> >> > > > > > > >> - Tsuyoshi > > > >>> >> > > > >>> >> > > > > > > >> > > > >>> >> > > > >>> >> > > > > > > >> On Wed, Apr 9, 2014 at 11:44 AM, Raymie Stata < > > > >>> >> > > > >>> >> > > > rst...@altiscale.com<mailto:rst...@altiscale.com> > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > > wrote: > > > >>> >> > > > >>> >> > > > > > > >>>> It might make sense to try to enumerate the > > > benefits of > > > >>> >> > > > >>> >> > > > switching > > > >>> >> > > > >>> >> > > > > to > > > >>> >> > > > >>> >> > > > > > > >>>> Java7 APIs and dependencies. > > > >>> >> > > > >>> >> > > > > > > >>> > > > >>> >> > > > >>> >> > > > > > > >>> - Java7 introduced a huge number of language, > > > >>> byte-code, > > > >>> >> > > > >>> >> > > > > > > >>> API, > > > >>> >> > > > >>> >> > > > and > > > >>> >> > > > >>> >> > > > > > > >>> tooling enhancements! Just to name a few: > > > >>> >> > > > >>> >> > > > > > > >>> try-with-resources, > > > >>> >> > > > >>> >> > > > > newer > > > >>> >> > > > >>> >> > > > > > > >>> and stronger encyrption methods, more scalable > > > >>> concurrency > > > >>> >> > > > >>> >> > > > > > primitives. > > > >>> >> > > > >>> >> > > > > > > >>> See > > > >>> >> > > > >>> >> > > > > > > >>> > > > >>> http://www.slideshare.net/boulderjug/55-things-in-java-7 > > > >>> >> > > > >>> >> > > > > > > >>> > > > >>> >> > > > >>> >> > > > > > > >>> - We can't update current dependencies, and we > > > can't > > > >>> add > > > >>> >> > > > >>> >> > > > > > > >>> cool > > > >>> >> > > > >>> >> > > > new > > > >>> >> > > > >>> >> > > > > > > ones. > > > >>> >> > > > >>> >> > > > > > > >>> > > > >>> >> > > > >>> >> > > > > > > >>> - Putting language/APIs aside, don't forget > > that a > > > >>> huge > > > >>> >> > > > >>> >> > > amount > > > >>> >> > > > >>> >> > > > of > > > >>> >> > > > >>> >> > > > > > > effort > > > >>> >> > > > >>> >> > > > > > > >>> goes into qualifying for Java6 (at least, I hope > > the > > > >>> folks > > > >>> >> > > > >>> >> > > > claiming > > > >>> >> > > > >>> >> > > > > > to > > > >>> >> > > > >>> >> > > > > > > >>> support Java6 are putting in such an effort :-). > > > >>> Wouldn't > > > >>> >> > > > >>> >> > > Hadoop > > > >>> >> > > > >>> >> > > > > > > >>> users/customers be better served if > qualification > > > effort > > > >>> >> > > > >>> >> > > > > > > >>> went > > > >>> >> > > > >>> >> > > > into > > > >>> >> > > > >>> >> > > > > > > >>> Java7/8 versus Java6/7? > > > >>> >> > > > >>> >> > > > > > > >>> > > > >>> >> > > > >>> >> > > > > > > >>> Getting to Java7 as a development env (and Java8 > > as > > > a > > > >>> >> > > > >>> >> > > > > > > >>> runtime > > > >>> >> > > > >>> >> > > > env) > > > >>> >> > > > >>> >> > > > > > > >>> seems like a no-brainer. Question is: How? > > > >>> >> > > > >>> >> > > > > > > >>> > > > >>> >> > > > >>> >> > > > > > > >>> On Tue, Apr 8, 2014 at 10:21 AM, Sandy Ryza < > > > >>> >> > > > >>> >> > > > > sandy.r...@cloudera.com<mailto:sandy.r...@cloudera.com> > > > >>> >> > > > >>> >> > > > > > > > > > >>> >> > > > >>> >> > > > > > > wrote: > > > >>> >> > > > >>> >> > > > > > > >>>> It might make sense to try to enumerate the > > > benefits of > > > >>> >> > > > >>> >> > > > switching > > > >>> >> > > > >>> >> > > > > to > > > >>> >> > > > >>> >> > > > > > > Java7 > > > >>> >> > > > >>> >> > > > > > > >>>> APIs and dependencies. IMO, the ones listed so > > > far on > > > >>> >> > > > >>> >> > > > > > > >>>> this > > > >>> >> > > > >>> >> > > > thread > > > >>> >> > > > >>> >> > > > > > > don't > > > >>> >> > > > >>> >> > > > > > > >>>> make a compelling enough case to drop Java6 in > > > branch-2 > > > >>> >> > > > >>> >> > > > > > > >>>> on any > > > >>> >> > > > >>> >> > > > > time > > > >>> >> > > > >>> >> > > > > > > frame, > > > >>> >> > > > >>> >> > > > > > > >>>> even if this means supporting Java6 through > 2015. > > > For > > > >>> >> > > > >>> >> > > example, > > > >>> >> > > > >>> >> > > > > the > > > >>> >> > > > >>> >> > > > > > > change > > > >>> >> > > > >>> >> > > > > > > >>>> in RawLocalFileSystem semantics might be an > > > >>> incompatible > > > >>> >> > > > >>> >> > > change > > > >>> >> > > > >>> >> > > > > for > > > >>> >> > > > >>> >> > > > > > > >>>> branch-2 any way. > > > >>> >> > > > >>> >> > > > > > > >>>> > > > >>> >> > > > >>> >> > > > > > > >>>> > > > >>> >> > > > >>> >> > > > > > > >>>> On Tue, Apr 8, 2014 at 10:05 AM, Karthik > > Kambatla < > > > >>> >> > > > >>> >> > > > > > ka...@cloudera.com<mailto:ka...@cloudera.com> > > > >>> >> > > > >>> >> > > > > > > >wrote: > > > >>> >> > > > >>> >> > > > > > > >>>> > > > >>> >> > > > >>> >> > > > > > > >>>>> +1 to NOT breaking compatibility in branch-2. > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > >>> >> > > > >>> >> > > > > > > >>>>> I think it is reasonable to require JDK7 for > > > trunk, if > > > >>> >> > > > >>> >> > > > > > > >>>>> we > > > >>> >> > > > >>> >> > > limit > > > >>> >> > > > >>> >> > > > > use > > > >>> >> > > > >>> >> > > > > > > of > > > >>> >> > > > >>> >> > > > > > > >>>>> JDK7-only API to security fixes etc. If we > make > > > other > > > >>> >> > > > >>> >> > > > > optimizations > > > >>> >> > > > >>> >> > > > > > > (like > > > >>> >> > > > >>> >> > > > > > > >>>>> IO), it would be a pain to backport things to > > > >>> branch-2. > > > >>> >> > > > >>> >> > > > > > > >>>>> I > > > >>> >> > > > >>> >> > > guess > > > >>> >> > > > >>> >> > > > > > this > > > >>> >> > > > >>> >> > > > > > > all > > > >>> >> > > > >>> >> > > > > > > >>>>> depends on when we see ourselves shipping > > > Hadoop-3. > > > >>> Any > > > >>> >> > > > >>> >> > > > > > > >>>>> ideas > > > >>> >> > > > >>> >> > > > on > > > >>> >> > > > >>> >> > > > > > > that? > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > >>> >> > > > >>> >> > > > > > > >>>>> On Tue, Apr 8, 2014 at 9:19 AM, Eli Collins < > > > >>> >> > > > >>> >> > > e...@cloudera.com<mailto:e...@cloudera.com>> > > > >>> >> > > > >>> >> > > > > > > wrote: > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > >>> >> > > > >>> >> > > > > > > >>>>> > On Tue, Apr 8, 2014 at 2:00 AM, Ottenheimer, > > > Davi > > > >>> >> > > > >>> >> > > > > > > >>>>> > <davi.ottenhei...@emc.com<mailto: > > > >>> >> davi.ottenhei...@emc.com>> wrote: > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> From: Eli Collins [mailto: > e...@cloudera.com > > ] > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> Sent: Monday, April 07, 2014 11:54 AM > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> IMO we should not drop support for Java 6 > > in > > > a > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> minor > > > >>> >> > > > >>> >> > > > update > > > >>> >> > > > >>> >> > > > > > of a > > > >>> >> > > > >>> >> > > > > > > >>>>> stable > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> release (v2). I don't think the larger > > > Hadoop > > > >>> user > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> base > > > >>> >> > > > >>> >> > > > > would > > > >>> >> > > > >>> >> > > > > > > find it > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> acceptable that upgrading to a minor > update > > > >>> caused > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> their > > > >>> >> > > > >>> >> > > > > > > systems to > > > >>> >> > > > >>> >> > > > > > > >>>>> stop > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> working because they didn't upgrade Java. > > > There > > > >>> are > > > >>> >> > > > >>> >> > > people > > > >>> >> > > > >>> >> > > > > > still > > > >>> >> > > > >>> >> > > > > > > >>>>> getting > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> support for Java 6. ... > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> Thanks, > > > >>> >> > > > >>> >> > > > > > > >>>>> > >> Eli > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > Hi Eli, > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > Technically you are correct those with > > > extended > > > >>> >> > > > >>> >> > > > > > > >>>>> > > support > > > >>> >> > > > >>> >> > > get > > > >>> >> > > > >>> >> > > > > > > critical > > > >>> >> > > > >>> >> > > > > > > >>>>> > security fixes for 6 until the end of 2016. > I > > am > > > >>> >> > > > >>> >> > > > > > > >>>>> > curious > > > >>> >> > > > >>> >> > > > > whether > > > >>> >> > > > >>> >> > > > > > > many of > > > >>> >> > > > >>> >> > > > > > > >>>>> > those are in the Hadoop user base. Do you > > know? > > > My > > > >>> >> > > > >>> >> > > > > > > >>>>> > guess is > > > >>> >> > > > >>> >> > > > the > > > >>> >> > > > >>> >> > > > > > > vast > > > >>> >> > > > >>> >> > > > > > > >>>>> > majority are within Oracle's official public > > > end of > > > >>> >> > > > >>> >> > > > > > > >>>>> > life, > > > >>> >> > > > >>> >> > > > which > > > >>> >> > > > >>> >> > > > > > > was over > > > >>> >> > > > >>> >> > > > > > > >>>>> 12 > > > >>> >> > > > >>> >> > > > > > > >>>>> > months ago. Even Premier support ended Dec > > 2013: > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > http://www.oracle.com/technetwork/java/eol- > > < > > > >>> >> http://www.oracle.com/technetwork/java/eol-135779.ht> > > > >>> >> > > > >>> >> > 135779.ht< > http://www.oracle.com/technetwork/java/eol-135779.ht> > > > >>> >> > > > >>> >> > > > > > > >>>>> > > ml > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > The end of Java 6 support carries much > risk. > > > It > > > >>> has > > > >>> >> > > > >>> >> > > > > > > >>>>> > > to be > > > >>> >> > > > >>> >> > > > > > > considered in > > > >>> >> > > > >>> >> > > > > > > >>>>> > terms of serious security vulnerabilities > such > > > as > > > >>> >> > > > >>> >> > > > CVE-2013-2465 > > > >>> >> > > > >>> >> > > > > > > with CVSS > > > >>> >> > > > >>> >> > > > > > > >>>>> > score 10.0. > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > http://www.cvedetails.com/cve/CVE-2013-2465/ > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > Since you mentioned "caused systems to > stop" > > > as an > > > >>> >> > > > >>> >> > > example > > > >>> >> > > > >>> >> > > > of > > > >>> >> > > > >>> >> > > > > > > what > > > >>> >> > > > >>> >> > > > > > > >>>>> would > > > >>> >> > > > >>> >> > > > > > > >>>>> > be a concern to Hadoop users, please note > the > > > >>> >> > > > >>> >> > > > > > > >>>>> > CVE-2013-2465 > > > >>> >> > > > >>> >> > > > > > > availability > > > >>> >> > > > >>> >> > > > > > > >>>>> > impact: > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > "Complete (There is a total shutdown of > the > > > >>> affected > > > >>> >> > > > >>> >> > > > > resource. > > > >>> >> > > > >>> >> > > > > > > The > > > >>> >> > > > >>> >> > > > > > > >>>>> > attacker can render the resource completely > > > >>> >> unavailable.)" > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > This vulnerability was patched in Java 6 > > > Update > > > >>> 51, > > > >>> >> > > > >>> >> > > > > > > >>>>> > > but > > > >>> >> > > > >>> >> > > > post > > > >>> >> > > > >>> >> > > > > > end > > > >>> >> > > > >>> >> > > > > > > of > > > >>> >> > > > >>> >> > > > > > > >>>>> > life. Apple pushed out the update > specifically > > > >>> because > > > >>> >> > > > >>> >> > > > > > > >>>>> > of > > > >>> >> > > > >>> >> > > > this > > > >>> >> > > > >>> >> > > > > > > >>>>> > vulnerability ( > > > http://support.apple.com/kb/HT5717) > > > >>> as > > > >>> >> > > > >>> >> > > > > > > >>>>> > did > > > >>> >> > > > >>> >> > > > some > > > >>> >> > > > >>> >> > > > > > > other > > > >>> >> > > > >>> >> > > > > > > >>>>> > vendors privately, but for the majority of > > > people > > > >>> >> > > > >>> >> > > > > > > >>>>> > using > > > >>> >> > > > >>> >> > > Java > > > >>> >> > > > >>> >> > > > 6 > > > >>> >> > > > >>> >> > > > > > > means they > > > >>> >> > > > >>> >> > > > > > > >>>>> > have a ticking time bomb. > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > Allowing it to stay should be considered > in > > > terms > > > >>> of > > > >>> >> > > > >>> >> > > > > accepting > > > >>> >> > > > >>> >> > > > > > > the > > > >>> >> > > > >>> >> > > > > > > >>>>> whole > > > >>> >> > > > >>> >> > > > > > > >>>>> > risk posture. > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > >>> >> > > > >>> >> > > > > > > >>>>> > There are some who get extended support, > but I > > > >>> suspect > > > >>> >> > > > >>> >> > > > > > > >>>>> > many > > > >>> >> > > > >>> >> > > > > just > > > >>> >> > > > >>> >> > > > > > > have > > > >>> >> > > > >>> >> > > > > > > >>>>> > a if-it's-not-broke mentality when it comes > to > > > >>> >> > > > >>> >> > > > > > > >>>>> > production > > > >>> >> > > > >>> >> > > > > > > deployments. > > > >>> >> > > > >>> >> > > > > > > >>>>> > The current code supports both java6 and > java7 > > > and > > > >>> so > > > >>> >> > > > >>> >> > > allows > > > >>> >> > > > >>> >> > > > > > these > > > >>> >> > > > >>> >> > > > > > > >>>>> > people to remain compatible, while enabling > > > others > > > >>> to > > > >>> >> > > > >>> >> > > upgrade > > > >>> >> > > > >>> >> > > > > to > > > >>> >> > > > >>> >> > > > > > > the > > > >>> >> > > > >>> >> > > > > > > >>>>> > java7 runtime. This seems like the right > > > compromise > > > >>> >> > > > >>> >> > > > > > > >>>>> > for a > > > >>> >> > > > >>> >> > > > > stable > > > >>> >> > > > >>> >> > > > > > > >>>>> > release series. Again, absolutely makes > sense > > > for > > > >>> >> > > > >>> >> > > > > > > >>>>> > trunk (ie > > > >>> >> > > > >>> >> > > > v3) > > > >>> >> > > > >>> >> > > > > > to > > > >>> >> > > > >>> >> > > > > > > >>>>> > require java7 or greater. > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > > >>> >> > > > >>> >> > > > > > > >>>>> > > > >>> >> > > > >>> >> > > > > > > >> > > > >>> >> > > > >>> >> > > > > > > >> > > > >>> >> > > > >>> >> > > > > > > >> > > > >>> >> > > > >>> >> > > > > > > >> -- > > > >>> >> > > > >>> >> > > > > > > >> - Tsuyoshi > > > >>> >> > > > >>> >> > > > > > > > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > -- > > > >>> >> > > > >>> >> > > > > > Best regards, > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > - Andy > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > Problems worthy of attack prove their worth by hitting > > > back. - > > > >>> >> > > > >>> >> > > > > > Piet > > > >>> >> > > > >>> >> > > > Hein > > > >>> >> > > > >>> >> > > > > > (via Tom White) > > > >>> >> > > > >>> >> > > > > > > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > -- > > > >>> >> > > > >>> >> > > > > CONFIDENTIALITY NOTICE > > > >>> >> > > > >>> >> > > > > NOTICE: This message is intended for the use of the > > > individual > > > >>> or > > > >>> >> > > > >>> >> > > entity > > > >>> >> > > > >>> >> > > > to > > > >>> >> > > > >>> >> > > > > which it is addressed and may contain information that > is > > > >>> >> > > > >>> >> > > > > confidential, privileged and exempt from disclosure > under > > > >>> >> > > > >>> >> > > > > applicable law. If the > > > >>> >> > > > >>> >> > > reader > > > >>> >> > > > >>> >> > > > > of this message is not the intended recipient, you are > > > hereby > > > >>> >> > > > >>> >> > > > > notified > > > >>> >> > > > >>> >> > > > that > > > >>> >> > > > >>> >> > > > > any printing, copying, dissemination, distribution, > > > disclosure > > > >>> or > > > >>> >> > > > >>> >> > > > > forwarding of this communication is strictly prohibited. > > If > > > you > > > >>> >> > > > >>> >> > > > > have received this communication in error, please > contact > > > the > > > >>> >> > > > >>> >> > > > > sender > > > >>> >> > > > >>> >> > > > immediately > > > >>> >> > > > >>> >> > > > > and delete it from your system. Thank You. > > > >>> >> > > > >>> >> > > > > > > > >>> >> > > > >>> >> > > > > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> >> > > -- > > > >>> >> > > > >>> >> > > CONFIDENTIALITY NOTICE > > > >>> >> > > > >>> >> > > NOTICE: This message is intended for the use of the > individual > > > or > > > >>> >> > > > >>> >> > > entity to which it is addressed and may contain information > > > that is > > > >>> >> > > > >>> >> > > confidential, privileged and exempt from disclosure under > > > applicable > > > >>> >> > > > >>> >> > > law. If the reader of this message is not the intended > > > recipient, > > > >>> you > > > >>> >> > > > >>> >> > > are hereby notified that any printing, copying, > dissemination, > > > >>> >> > > > >>> >> > > distribution, disclosure or forwarding of this communication > > is > > > >>> >> > > > >>> >> > > strictly prohibited. If you have received this communication > > in > > > >>> error, > > > >>> >> > > > >>> >> > > please contact the sender immediately and delete it from > your > > > >>> system. > > > >>> >> > > > >>> >> > Thank You. > > > >>> >> > > > >>> >> > > > > > >>> >> > > > >>> > > > >> > > > >> > > > >> > > > >> -- > > > >> Best regards, > > > >> > > > >> - Andy > > > >> > > > >> Problems worthy of attack prove their worth by hitting back. - Piet > > Hein > > > >> (via Tom White) > > > > > >
