bq. we stop building against JDK6 in jenkins For QA run, JDK6 is used. >From https://builds.apache.org/job/PreCommit-HBASE-Build/9436/console :
/usr/bin/java java version "1.6.0_20" FYI On Wed, Apr 30, 2014 at 2:52 PM, Enis Söztutar <[email protected]> wrote: > On Wed, Apr 30, 2014 at 9:34 PM, Andrew Purtell <[email protected]> > wrote: > > > What does support for JDK 6 mean in the community context here? > > > > For me, dropping support explicitly means that we stop building against > JDK6 in jenkins, and won't try to fix issues if they are jdk6 only. Release > testing > and unit tests are done on jdk7. > > > > > > The Hadoop discussion (eventually) settled on when they might adopt APIs > > only available in JDK 7 or later. We have no such proposals on the table > > here, right? I see this mentioned in option #1 but is there any 7+ API we > > care about? Otherwise that discussion is premature. > > > > There are only a handful of new APIs, which we can live without. I think > the issue is about whether we will reject a patch > or not if it contains JDK7 APIs. G1 is there, but we probably do not want > to default to that for now. > > > > > > Unless we pick up new 7+ APIs then it's a question of what runtimes we > are > > running builds against or testing with. I plan to do this with 7 and 8 > just > > as a personal preference. Keeping the lights on for JDK 6 on Jenkins > seems > > perfectly fine to do if we have volunteers to fix the issues found there. > > That begs the question what happens when that build starts failing. > Simply > > filing JIRAs pointing out test failures is noise, those are junk issues > > without failure analysis and patches. I suspect someone will do > occasional > > searches for such issues and close as Invalid or Cannot Reproduce. Anyone > > here interested in committing to fix failing JDK 6 builds? > > > > We can decide to keep the JDK6 but deprecate. To me, that means that the > code should still compile > and jenkins will run unit tests against it, but usual testing for release > and precommit builds etc > are done with jdk7. JDK6 is supported on a volunteer basis as you suggest. > > > > > > > > On Wed, Apr 30, 2014 at 1:43 PM, Enis Söztutar <[email protected]> wrote: > > > > > Hi, > > > > > > Just wanted to kick off a discussion around whether or not we would > > > explicitly drop support for JDK6 in 1.0, and hence all 1.x releases. > > > > > > There has been some discussion on hadoop common-dev[1] about this with > no > > > conclusion so far. The general consensus was that hadoop might drop > jdk6 > > > support in 3.0, but keep it for 2.x releases (which makes sense for > > them). > > > > > > I would like us to come to a decision for 1.0, and document this in > > either > > > outcome so that all 1.x releases can be validated against that > decision. > > > > > > 1) Drop JDK6 support in 1.0 series: > > > - In this case, we will switch all jenkins builds of trunk (precommit > as > > > well) to jdk7. 0.98- builds might keep jdk6 and jdk7 builds. > > > - Trunk code can use JDK7 APIs. > > > > > > 2) NOT drop JDK6 support in 1.0 > > > - Keep a jenkins build running on jdk6 with trunk running unit tests. > > > - Decide whether we can drop support in 2.x. > > > > > > > > > In either case we document this in book (A JDK version x HBase version > > > release matrix) > > > > > > > > > [1] > > > > > > > > > https://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201404.mbox/%3ccabbyifm02nmvarparpqnsej8gb5x9wtty8c18tafr6z4tql...@mail.gmail.com%3E > > > > > > Enis > > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > >
