-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
9.0.1
-
x86_64
-
windows
FULL PRODUCT VERSION :
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.10586]
A DESCRIPTION OF THE PROBLEM :
We use the 'jar' command to update files in an existing Android apk file.
For example if we want to update the AndroidManifest file in the APK archive we use the following command: jar -uf app.apk -C . AndroidManifest.xml
This used to work well in previous Java versions.
However, with version 9 we encounter an Exception that says:
Invalid value for MonthOfYear (valid values 1 - 12): 0
One possible cause might be that files within the Android apk archive dont seem to have a timestamp attached.
Our company heavily uses this feature and this issue breaks our compatability with JDK 9.
REGRESSION. Last worked in version 8u141
ADDITIONAL REGRESSION INFORMATION:
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) Client VM (build 25.60-b23, mixed mode)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Get the most basic Android APK. We used Android Studio and exported the default project.
Now we got an app-debug.apk which is an archive that contains some files.
If we want to update for example the AndroidManifest.xml we use the following command:
jar -uf app.apk -C . AndroidManifest.xml
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
we expect to successfully perform the update
ACTUAL -
java.time.DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 0
at java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
at java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.java:714)
at java.base/java.time.LocalDate.of(LocalDate.java:269)
at java.base/java.time.LocalDateTime.of(LocalDateTime.java:336)
at java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:82)
at java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:101)
at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
at jdk.jartool/sun.tools.jar.Main.update(Main.java:959)
at jdk.jartool/sun.tools.jar.Main.run(Main.java:360)
at jdk.jartool/sun.tools.jar.Main.main(Main.java:1670)
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
if we extract the apk file and zip it again (without modifying its content) we get an archive file again that can be updated.
(probably because now the files seem to have a timestamp)
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.10586]
A DESCRIPTION OF THE PROBLEM :
We use the 'jar' command to update files in an existing Android apk file.
For example if we want to update the AndroidManifest file in the APK archive we use the following command: jar -uf app.apk -C . AndroidManifest.xml
This used to work well in previous Java versions.
However, with version 9 we encounter an Exception that says:
Invalid value for MonthOfYear (valid values 1 - 12): 0
One possible cause might be that files within the Android apk archive dont seem to have a timestamp attached.
Our company heavily uses this feature and this issue breaks our compatability with JDK 9.
REGRESSION. Last worked in version 8u141
ADDITIONAL REGRESSION INFORMATION:
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) Client VM (build 25.60-b23, mixed mode)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Get the most basic Android APK. We used Android Studio and exported the default project.
Now we got an app-debug.apk which is an archive that contains some files.
If we want to update for example the AndroidManifest.xml we use the following command:
jar -uf app.apk -C . AndroidManifest.xml
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
we expect to successfully perform the update
ACTUAL -
java.time.DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 0
at java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
at java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.java:714)
at java.base/java.time.LocalDate.of(LocalDate.java:269)
at java.base/java.time.LocalDateTime.of(LocalDateTime.java:336)
at java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:82)
at java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:101)
at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
at jdk.jartool/sun.tools.jar.Main.update(Main.java:959)
at jdk.jartool/sun.tools.jar.Main.run(Main.java:360)
at jdk.jartool/sun.tools.jar.Main.main(Main.java:1670)
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
if we extract the apk file and zip it again (without modifying its content) we get an archive file again that can be updated.
(probably because now the files seem to have a timestamp)
- duplicates
-
JDK-8184940 JDK 9 rejects zip files where the modified day or month is 0
-
- Closed
-