I think there's confusion over 'support' and 'develop'. Going JDK8 should not imply dropping non-JDK6 versions:
Take Tomcat as an example. Tomcat 9 requires a newer JDK than Tomcat 8. That does not mean that Tomcat 8 isn't receiving 'support', or that it's stopped working - it's getting fixes, it's not EOL - it's probably what most people are actually building products on. Indeed Tomcat 6 still gets fixes. But 'new development' is happening elsewhere. In the context of 'LTS', I don't think it's acceptable to simply bump a heap of external requirements; if I were on a maintenance contract, I'd yell too! A Jenkins 1.xxx line should continue to receive fixes (e.g security, critical bugs, whatever else the community finds). A Jenkins 2.xxx line should take the opportunity to upgrade to JDK8 (and perhaps bump up some libraries like guava while it's at it). The argument I hear, and I think it's possibly a straw man, is a demographic of users who are 'stuck on <slow coach platform>' who go beyond demanding *support *(which I think they deserve), but also want *all the new features as well*. If they truly exist (perhaps they do, but it seems an odd combination of being unable to change anything about their environment *except* the version of Jenkins they run), then I find that position phenomenally presumptuous. What they are demanding is what I develop (for free! and give away to them!) must forever be tied to their lowest-common-denominator platform, representing an utterly tiny minority. Now that Java itself is also OSS (and virtualisation is a thing, and hardware is cheap, etc etc), this is never a "we can't change", it's simply a "we don't want to". Put simply, new features available on a new product version usually builds the business case for making an environmental change. But why bother doing that, when you can transfer the burden of doing that back to the unpaid, OSS developers giving me product for free? On the technical, Java8 brings some useful stuff, and is a more pleasant and modern place for a developer: - No more permgen space! - Default methods in interfaces (useful when you're trying to extend an API throughout the life of a product) - Lambda Expressions - Optional<T> - Method parameter names in metadata (I believe Jenkins needs a plugin to extract this. Certainly that's the approach I needed pre-JDK8, which often failed when my IDE decided to recompile - good riddance to that). In the context of recruiting (OSS) developers, I think Java moves slowly enough (especially cf. C#) to damage its mindshare without additionally making it all less fun by making everyone act like a corporate IT developer stuck on an obsolete platform. That just drives people to work on CI systems that don't have that constraint. On Tue, Mar 24, 2015 at 11:35 PM, nicolas de loof <[email protected]> wrote: > Proposal is not to maintain parallel branches, but to make next release to > require Java 8 and start using it for new development / step by step > enhance existing APIs to benefit Java 8 > > > >> What would change in 3/ 6 months ? >> Lot's of people will still run RHEL 5 and build legacy Java 1.3 >> applications. >> >> Ok, maybe 10 LTS's then. We need to have a plan for supporting the past >> and the future. If we do have so many people wanting the java6 branch, >> then they should be able to support it. It sounds like we have a large >> number of people interested in java8 and I don't think such a transition >> will be ready for quite some time. I imagine we will also have people using >> both and maintaining both. I still have RHEL5 and a SPARC and I will do >> what I have to with those as long as I need to. But I also have bleeding >> edge items and I'd like to see Jenkins continue to push that envelope. This >> is a community, I can't imagine that if the mainline moved on to Java8 we >> wouldn't still help those who are still using the current mainline. >> >> - >> Thomas >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/D13733B8.11501%25thomas.suckow%40pnnl.gov >> <https://groups.google.com/d/msgid/jenkinsci-dev/D13733B8.11501%25thomas.suckow%40pnnl.gov?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznBdm3DmnZ_GO0viCawUek0yXj3jnSiZR%3DoDpHObR%2BSvQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznBdm3DmnZ_GO0viCawUek0yXj3jnSiZR%3DoDpHObR%2BSvQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SEJxm%2BfSaJF192TjWWszB6Cjq2XS4ToXi0ztnyyoUvyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
