That's what I meant; bug fixes will be included in normal releases. It's actually fairly similar to how the Jenkins LTS process works in that LTS releases are basically just points chosen in time to maintain as branches for backporting security fixes (slight difference being that in Jenkins, we "upmerge" security fixes instead of backporting for maximum compatibility) while everything else continues to be released early and often (though Jenkins does weekly releases instead of every 26 weeks like Java, and our LTS releases are more in line with Java's regular release schedule).
As to what to do about broken code from upstream? We can make a shim utility class for detecting if the bug is present and selecting the appropriate behavior at runtime, or perhaps the production code should be updated to use the NIO2 APIs which work properly unlike the old File API. On Sat, 8 Aug 2020 at 10:50, Gary Gregory <garydgreg...@gmail.com> wrote: > > FWIW, there recently was a bug found by Commons Lang in Java 15 and 16. > Java 16 has now fixed the bug but it will not be fixed in Java 15, at > least not before GA. > > > Gary > > On Sat, Aug 8, 2020, 11:45 Matt Sicker <boa...@gmail.com> wrote: > > > Even if it’s fixed upstream, it’ll never get backported most likely. Even > > compiler bugs aren’t backported (see for example a bug related to > > reflection on intersection types that was fixed in Java 9; I can’t find an > > exact reference, but multiple bugs related to this were all address in 9). > > > > On Fri, Aug 7, 2020 at 12:03 sebb <seb...@gmail.com> wrote: > > > > > If so, then it is not sufficient to run tests on Windows, it looks > > > like we need to run tests on Windows with the appropriate version of > > > Java. > > > > > > Presumably that is why Jenkins did not show the error. > > > > > > However, fixing the test won't fix the code - there may be instances > > > of lastModified elsewhere. > > > > > > The Java bug needs to be fixed. > > > > > > > > > On Fri, 7 Aug 2020 at 17:12, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > > > On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <boa...@gmail.com> wrote: > > > > > > > > > That sounds like a file modification time granularity issue. Does > > > Windows > > > > > not support milliseconds or finer for file modification times? It > > > could be > > > > > that the test executed too fast! > > > > > > > > > > > > > This might be a classic bug I've run into at work: > > > > https://bugs.openjdk.java.net/browse/JDK-8177809 > > > > > > > > Basically, never use File.lastModified(), use > > > Files.getLastModifiedTime(). > > > > > > > > Gary > > > > > > > > > > > > > > > > > > On Fri, Aug 7, 2020 at 09:01 Gary Gregory <garydgreg...@gmail.com> > > > wrote: > > > > > > > > > > > As of recently, I am seing: > > > > > > > > > > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase > > > > > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time > > > elapsed: > > > > > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase > > > > > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: > > > 0.038 s > > > > > > <<< FAILURE! > > > > > > org.opentest4j.AssertionFailedError: Check last modified date not > > > same as > > > > > > input ==> expected: not equal but was: <1596807101505> > > > > > > at > > > > > > org.apache.commons.io > > > > > > > > > > > > > > > > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229) > > > > > > > > > > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< > > > > > FAILURE! > > > > > > org.opentest4j.AssertionFailedError: expected: <true> but was: > > > <false> > > > > > > at > > > > > > org.apache.commons.io > > > > > > > > > > > > > > > > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403) > > > > > > > > > > > > I am wondering if GitHub/Travis can also be set up to run at least > > > one > > > > > > build on Windows so we can catch issues like these? > > > > > > > > > > > > Gary > > > > > > > > > > > -- > > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
