Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

[David Lloyd]

On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman <Alan.Bateman at 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