The internal implementation of java.util.zip.ZipFile maintains a cache of the ZIP structure of each ZIP file that's currently open. This cache helps prevent repeat parsing of the ZIP structure of the same underlying ZIP file every time a ZipFile instance is created for the same ZIP file. The cache uses an internal key to map a ZIP file to the corresponding ZIP structure that's cached.

A java.util.zip.ZipFile can be constructed by passing a Charset which will be used to decode the entry names (and comment) in a ZIP file.

In Java 15, through https://bugs.openjdk.org/browse/JDK-8243254, we introduced a change in this part of the code. One part of that change updated the cache key components to even include a boolean which stated whether the Charset used to construct the ZipFile is UTF-8 or not.

A side effect of this change is that for non UTF-8 Charsets, when the cache is already populated for a particular ZIP file, the implementation of ZipFile might end up using a cached ZIP structure which was decoded using a different Charset than the one with which a current instance of ZipFile is being constructed. In other words, the internal cache considers a cached ZIP structure for a particular ZIP file, to be usable by a ZipFile instance, even when it isn't. This can then contribute to issues where the entry name(s) may not be found through the ZipFile instance.
 
The attached Test.java reproduces this issue on Java 15 and above:

javac Test.java
java Test.java

results in:

Exception in thread "main" java.lang.AssertionError: euro sign entry missing in java.util.zip.ZipFile@3830f1c0
    at Test.testCachedZipFileSource(Test.java:89)
    at Test.main(Test.java:42)