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 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.
What does support for JDK 6 mean in the community context here?
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.
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? On Wed, Apr 30, 2014 at 1:43 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote: Best regards,
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
On Wed, Apr 30, 2014 at 9:34 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote: 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.
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.
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.