DateTimeException when including version 2020d.11 in a Spring application

[FDelporte]

Was doing some test with your library in an existing Spring application (Java 8) and suddenly the application didn't start anymore and threw this error:

Exception in thread "main" java.time.DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 0
        at java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
        at java.time.temporal.ChronoField.checkValidValue(ChronoField.java:703)
        at java.time.LocalDate.of(LocalDate.java:267)
        at java.time.LocalDateTime.of(LocalDateTime.java:336)
        at org.springframework.boot.loader.jar.CentralDirectoryFileHeader.decodeMsDosFormatDateTime(CentralDirectoryFileHeader.java:130)
        at org.springframework.boot.loader.jar.CentralDirectoryFileHeader.getTime(CentralDirectoryFileHeader.java:119)
        at org.springframework.boot.loader.jar.JarEntry.<init>(JarEntry.java:58)
        at org.springframework.boot.loader.jar.JarFileEntries.getEntry(JarFileEntries.java:327)
        at org.springframework.boot.loader.jar.JarFileEntries.access$400(JarFileEntries.java:48)
        at org.springframework.boot.loader.jar.JarFileEntries$EntryIterator.next(JarFileEntries.java:378)
        at org.springframework.boot.loader.jar.JarFileEntries$EntryIterator.next(JarFileEntries.java:362)
        at org.springframework.boot.loader.jar.JarFile$2.nextElement(JarFile.java:198)
        at org.springframework.boot.loader.jar.JarFile$2.nextElement(JarFile.java:189)
        at org.springframework.boot.loader.archive.JarFileArchive$EntryIterator.next(JarFileArchive.java:186)
        at org.springframework.boot.loader.archive.JarFileArchive$EntryIterator.next(JarFileArchive.java:171)
        at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:84)
        at org.springframework.boot.loader.ExecutableArchiveLauncher.getClassPathArchives(ExecutableArchiveLauncher.java:70)
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:49)
        at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)

I started commenting my code to check if the problem was caused by my implementation, but only after removing the dependency, the problem was fixed.

Turns out, having the dependency in the project, is enough to cause this startup error, even without any code using it.

When going back to version 2019b.9, the application starts OK.

[RomanIakovlev]

Hello, and thanks for reporting this. Here's some observations.

First, in the stack trace you've posted, there's no Timeshape frames present. Instead it fails in the java.time.*, triggered by Spring doing some of it's classpath magic.

Second, when I try to google this stack trace, this issue comes up: https://github.com/buildpacks/pack/issues/130. From reading about it, it seems others experience a similar issue with other builds and dependencies. It probably has something to do with the timestamps of the JAR entries (also the stack trace hints at this).

Third, when I check the timestamp of the entries in the JAR files from Timeshape 2019b.9 and 2020d.11, I see the entries 2019b.9 have some real timestamps, whereas the entries from 2020d.11 have zero timestamps. I also see this is the first Timeshape release with zero timestamps in JAR entries, because 2020a.10 has non-zero timestamps. The latest SNAPSHOT build of Timeshape also has zero timestamps.

Fourth, I noticed there was a change in OpenJDK version the Travis CI uses when building Timeshape. The 2020a.10 used 1.8.0_191, whereas the later builds use 1.8.0_252.

My guess would be that somewhere between 1.8.0_191 and 1.8.0_252 something has changed in OpenJDK, which caused JAR entries to be produced with zero timestamps, and this trips the Spring (or rather java.time.* classes).

I suggest the following: you could try the 2020a.10 and let me know if it works for you. I bet it should work just fine. If it does, you can stick with it for a while, since it has some fresher data than 2019b.9. I will investigate if using an alternative JDK (maybe the one from Oracle if the Travis CI still offers them) could bring any change to this behavior.

[RomanIakovlev]

Unfortunately, Travis CI has removed support for Oracle JDK version 8 (see the failed build in the #80). I'll try to come up with some alternative approach, but it will take some time. In the meanwhile, if you'll find a workaround for this problem, please post it here.

P.S. could you please let me know the exact Java version you're running?

[FDelporte]

Thanks for the quick reply and detailed investigation!! Was trying to run on openjdk version "1.8.0_275" Regarding Travis: time to switch to GitHub Actions? ;-)

[FDelporte]

BTW, confirmed 2020a.10 is OK!

[RomanIakovlev]

After some further investigations, I believe the problem is not in the JDK version, but somewhere in Timeshape build. I've reproduced the very same issue locally (zero timestamps on master branch). When I checked out the older version of repository, which corresponds to 2020a.10 release, my local build has actually produced non-zero timestamps for JAR entries. So it seems something along the way has caused this change.

[RomanIakovlev]

I think I managed to fix the problem, could you please try the latest SNAPSHOT?

<dependency>
  <groupId>net.iakovlev</groupId>
  <artifactId>timeshape</artifactId>
  <version>2020d.12-SNAPSHOT</version>
</dependency>

(and you should have the Sonatype snapshots repo configured, as in e.g. https://stackoverflow.com/a/56145228)

[basisbit]

Had the same problem as reported here in the issue, and it was fixed with the changes from PR 83. @RomanIakovlev any chance for getting a version release, so the Snapshot version is not needed as dependency with the addition of the snapshot repo? Thanks in advance!

[RomanIakovlev]

Hi @basisbit, thanks for confirming the problem is fixed in the snapshot. I'll make a release with it, hopefully soon.

[RomanIakovlev]

I have just made the release with the change discussed here, 2020d.12. Should be available on Maven Central in an hour or two.

[basisbit]

@RomanIakovlev could you please also set the git tag and create the git release info here on GitHub? Thanks!

[RomanIakovlev]

Going to close this now as it's quite old and the original issue is fixed. I'm currently not using GitHub releases with Timeshape, only publish it to Maven Central. If you find value in GitHub releases and tags, let's open a separate discussion.