On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman <alan.bate...@oracle.com> wrote:
>
> On 18/11/2019 15:01, Jaikiran Pai wrote:
> > :
> >
> > So this Class-Path entry is being ignored starting Java 13.
> >
> Yes, bad values are now ignored, bringing an end to an effort on the
> run-time over multiple releases to fix the problems this area.
> JDK-8224253[1] is the JDK 13 release note to announce this change and I
> see you've found the system property that you can use to track down bad
> values. In previous releases you will get the same behavior with
> -Djdk.net.URLClassPath.disableClassPathURLCheck=false as the changes to
> reject bad input have been in place for some time. Brent can summarize
> but I think the only outstanding work is to fix the javac handling.
OK, having read the updated specification (thanks Alan!) I'm now quite
curious why `/C:/helloworld.jar` is considered invalid. It is in fact
a valid relative URL (colons are allowed in path segments, and the
leading `/` unambiguously delineates the URL path), and thus it seems
that it should be considered valid.
Examining the code in URLClassPath:
static URL tryResolveFile(URL base, String input) throws MalformedURLException {
int index = input.indexOf(':'); // <-- A
boolean isFile;
if (index >= 0) {
String scheme = input.substring(0, index);
isFile = "file".equalsIgnoreCase(scheme);
} else {
isFile = true;
}
return (isFile) ? new URL(base, input) : null;
}
The line marked as `A` seems to incorrectly detect URL scheme. If a
`/` appears before the `:` then the `:` is legitimately part of the
path, not a scheme delimiter, however this code does not check to see
if the `:` appears after a `/`.
--
- DML
