FSInfo#getJarClassPath throws an exception not declared in its throws clause

[Jaikiran Pai]

In recent versions of JDK (I think after JDK 8), the
com.sun.tools.javac.file.FSInfo#getJarClassPath(...) is throwing a
java.nio.file.InvalidPathException in certain cases when the classpath
entry it is parsing isn't a valid one. This is because of its usage of
the java.nio.file.Path APIs, specifically
https://github.com/openjdk/jdk/blob/4ad3d82c76936a8927ed8a505689a3683144ad98/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java#L112.

The throws clause of this FSInfo#getJarClassPath API lists IOException,
so this method is now throwing an exception which isn't listed in its
throws clause. As a result, callers, like the
com.sun.tools.javac.file.Locations.SearchPath#addJarClassPath(...)
https://github.com/openjdk/jdk/blob/4ad3d82c76936a8927ed8a505689a3683144ad98/src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java#L425
are no longer able to catch this exception and log it and move on.
Instead it gets propagated all the way back to the top level callers,
thus breaking applications which are trying to compile java files
programmatically.

Would this be considered a bug? If so, I can create a JBS issue and
provide a patch (and will try a jtreg test case too) for review.

Although these classes are internal and not public API, the calling code
is actually using public APIs (which internally end up calling these
APIs). Like here
https://github.com/quarkusio/quarkus/blob/master/core/devmode/src/main/java/io/quarkus/dev/JavaCompilationProvider.java#L48.

For a lengthy discussion/context - please read the comments in this
issue https://github.com/quarkusio/quarkus/issues/3592

-Jaikiran