just using Java 8 (i.e. use some new API that do a better job) could help, but doesn't need a debate, we already do this for a while. Requiring Java 8 would allow some major change in jenkins design, especially on the way we extend base classes, and define API (as inner classes) vs lambdas
2014-09-25 2:47 GMT+02:00 Mark Waite <[email protected]>: > I agree with Russ. If we require Java 8, rather than just allowing it, > we'll cause many users to stop upgrading their Jenkins installations, and > will tend to lose their involvement in the project. > > I appreciate developer benefits very much, but with 80 000+ installations, > I think preserving compatibility is more valuable than the developer > benefits of requiring Java 8. > > I admit that I was just hit by exactly this condition as a developer. I > added a new test to the git client plugin which depended on a Java 7 NIO > feature. It failed to compile in my test configuration with Java 6. Even > so, I still think that the most we should require is Java 7. > > Is there a way to count the summarize the distribution of virtual machines > used with Jenkins today, similar to the summary posted earlier about > platforms used with Jenkins? > > Are there ways we could allow more of the benefits of Java 8 development, > while still retaining compatibility? > > Mark Waite > > On Wed, Sep 24, 2014 at 4:48 PM, Russ Tremain <[email protected]> > wrote: > >> +1 >> >> I think it is fine to "allow java 8" but not require it. >> >> Requiring the latest version of java to run Jenkins just means that many >> shops will stop upgrading Jenkins. >> >> Compared to whatever new esoteric language features JDK8 has, stability >> of the Jenkins production platform concerns far outweigh convenience or >> curiosity concerns for Jenkins developers. >> >> To put it graphically: >> >> Production platform stability: whale >> Jenkins developer convenience: anchovy >> >> So that's my vote. ;) >> >> At 12:23 PM -0700 9/24/14, Kohsuke Kawaguchi wrote: >> >> I think we need to ask this to the users list and what people say. I'm >> happy to pose this question in JUC Bay Area to get the feel, too. >> >> >> As much as I love the idea as a developer, this does have a significant >> negative impact on the users. >> >> >> For one, we aren't just talking about optionally taking advantages of >> Java8 library features, like we do today for Java7. Here you are proposing >> to compile version 52 class files that only Java8 understands. >> >> >> It is also not just so called esoteric OSes that do not have Java8. Take >> Ubuntu for example. The current latest release 14.04 still doesn't have >> Java8 as a native package >> <http://packages.ubuntu.com/search?suite=trusty-updates&searchon=names&keywords=openjdk>. >> IIUC you currently have to rely on installing it from somebody's private >> repository (and I have no way of trusting these guys.) This means our DEB >> package will not be installable on its own. >> >> >> Here's another one. IBM still hasn't released JDK8. If you are an IBM >> shop and need to use IBM JDK for support contracts, you'll be left behind. >> >> >> I'd be happy to be proven wrong, but I don't think JDK8 dependency will >> be happening any time soon. >> >> >> 2014-09-24 11:50 GMT-07:00 Daniel Beck <[email protected]>: >> >> >> On 24.09.2014, at 19:53, oliver gondÏa <[email protected]> wrote: >> >> > Do we have stats for connected slaves? I expect there is significantly >> more instances that are using exotic platforms to power some of their >> slaves but not master. >> >> Since only relatively few Jenkins installs actually seem to use slaves, >> that's not the case. >> >> Out of ~27300 slaves, only ~200 are known to run any of the platforms >> mentioned above. Unfortunately, we don't know the OS of ~6500 slaves and I >> don't see why this should be the case. >> >> (Of course, one could argue that the more likely an organization is to >> have lots of nodes and use obscure commercial Unixes, the less likely it is >> they participate in anonymous usage statistics -- but that makes it their >> problem IMO.) >> >> >> -- >> 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]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Kohsuke Kawaguchi >> >> -- >> 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]. >> 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]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Thanks! > Mark Waite > > -- > 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]. > 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]. For more options, visit https://groups.google.com/d/optout.
