The problem sometimes not are the developers and their desire of upgrading. The problem are the clients that don't desire to upgrade the JVM that have installed in their servers. I had a case where a client was running a Sun Java 5 JVM with a bug on String class that sometimes calculated bad string lengths and was making to our product to fail. The solution was to updated to a more modern JVM, but they don't like to do it.
________________________________ De: Xeno Amess <xenoam...@gmail.com> Enviado: jueves, 10 de octubre de 2019 8:16 Para: Commons Developers List <dev@commons.apache.org> Asunto: Re: [exec] Update from Java 5 to 6 +1 for java 8 I just assume developers who still using java 6 do not care about upgrading their commons too... But what is the meaning of jigsaw....I mean, everybody use maven and maven is good, right? sebb <seb...@gmail.com> 于2019年10月10日周四 上午6:55写道： > > On Wed, 9 Oct 2019 at 22:38, John Patrick <nhoj.patr...@gmail.com> wrote: > > > > Regarding the question, it was by Simon Ritter (Azul Systems > > previously Oracle previously Sun). "Put your hand up if your running > > applications in production using Java X", started with Java 8, then > > asked about 11, then 12 and 13, then asked 7 and then 6. Not sure if > > he said Java 5 but I don't think he did. > > OK, thanks. > > > It's great java is backwards compatible, but Java 5 was EOL 2009, Java > > 6 was EOL 2013, Java 7 was EOL 2015, java 8 EOL 2019 personal usage > > 2020 and AdoptOpenJDK 2023). > > > > People jokes and complained about Java was dead or slow and releases > > took 2-5 years... JPMS has now been released for 2 years and how many > > frameworks/applications have actually release a version where you can > > take advantage of modules and create real lightweight images. > > Most of Commons components are quite small, so is this really a concern? > > > I've been using Java since 1.1, I was annoyed major releases took > > ages, but I'm more annoyed about the whole java ecosystem not stepping > > up as they have got use to the previously slow release cycles. I > > realise OpenSource project is done in peoples spare time and they are > > choosing to participate, but I've tried with multiple projects to > > raise pull requests to help taking the next steps. > > > > My personal view is all commons projects should aim from Jan 2020 to > > bump to creating multi release jars of Java 8 and Java 11, so people > > using Java 8 are still supported and people using Java 11+ can uses > > modules. > > And anyone using Java 7 or earlier is excluded. > > Unless I am mistaken, if we don't create these multi-release jars, > people will still be able to use existing releases. > > > > > On Wed, 9 Oct 2019 at 18:21, Alex Herbert <alex.d.herb...@gmail.com> wrote: > > > > > > On 09/10/2019 14:12, Gary Gregory wrote: > > > > Hi All, > > > > > > > > I'd like to update Commons Exec from Java 5 to 6 to get it to build on > > > > Java > > > > 11. > > > > > > > > Gary > > > > > > Gary changed git master to update to 1.6 but travis was not able to > > > build for older JDKs. > > > > > > I have tried following the recommended instructions for their trusty > > > distribution to use JDK 6 [1]. This did not work [2]. It would appear > > > that travis cannot support openjdk6 any more. > > > > > > Using 'dist: trusty' allows a clean build on JDK 7, 8, 11. > > > > > > I recommend dropping openjdk6 from the build matrix. > > > > > > Other items from the .travis.yml are the broken configuration for the > > > coveralls report. This can be fixed separately as the pom needs some > > > updating. > > > > > > Alex > > > > > > [1] > > > https://docs.travis-ci.com/user/reference/trusty/#jvm-clojure-groovy-java-scala-images > > > > > > [2] https://travis-ci.org/apache/commons-exec/builds/595713743 > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
