(zipfs) Files.walkFileTree walk indefinitelly while processing JAR file with "/" as a directory inside.

A DESCRIPTION OF THE REQUEST :
ENV: MacOS + JDK9.0.4 + alipay-sdk-java20170117151523.jar

Desc: There is a "/" in the alipay jar file. FileTreeWalter walks the JAR file with a stack in depth-first style, it will first walk /com and its subdirectory, then go to /com 's sibling, which is "/". And this cause FileTreeWalker redo walking, the stack will never pop off, but keep increasing.

JUSTIFICATION :
Any JAR file with "/" as directory inside will cause JAVAC hang.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
FileTreeWalker should Ignore "/" in JAR file.
ACTUAL -
FileTreeWalker can not walk out the JAR file with "/" inside.

---------- BEGIN SOURCE ----------
Refer to JAR file to reproduce: https://openhome.alipay.com/doc/sdkDownload.resource?sdkType=JAVA
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Repackage JAR file without "/" inside.


This is related to JDK-8199776. The root cause of both 8197398 and 8199776 is same where Files.walkFileTree walk indefinitelly while processing JAR file with "/" as a directory inside. Since, "zipf.jar" is used for walking through jar the bug is in zipFile system code of "zipf.jar".

This issue 8199776 is reported by customer where the title and steps to reproduce it gives us impression that issue is caused when a jar is empty. However, on investigating it is found that the issue is cause when an entry (zipenty) inside jar has name "/" which is a reserved name for a root directory in zip file system.

Important Note:
The root cause of issue 8197398 (filed for jdk 12) and 8199776 (filed for jdk 8) is same but differ in code and its impact on their respective release.
1>. In case of jdk 8 the code for zipfileSystem is present in "zipf.jar" while in case of jdk due to modular structure we don't have zipf.jar. Instead we have similar set of classes in jdk 9 and above.
2>. In case of jkd 12 (Actually jdk 9 above) , Javac uses "java.nio.file.FileTreeWalker" api which internally "ZipFileSystem" api which contain above bug. Therefore, if add a jar have a zip entry name with "/" will end up with infinite loop. In case of jdk 8 since "zipf.jar" is not used by "Javac" util we don't see above issue.