ClassPath.getTopLevelClasses() returns empty list.

[jcoeltjen]

Summary
ClassPath.getTopLevelClasses() returns empty list when the path of the classloader contains special characters.

How to reproduce this error

1. Create a packeage with three classes
2. Create the following unit test

    @Test
    public void testMain() throws Exception {
        ClassLoader loader = this.getClass().getClassLoader();
        ClassPath p = ClassPath.from(loader);
        ImmutableSet<ClassPath.ClassInfo> list = p.getTopLevelClasses("testpackage");
        Assert.assertEquals(3, list.size());
    }

1. Copy the whole project to a folder with special characters in its name (like % for example) and execute it.
2. The test will fail. If you copy the project to a folder without special characters in its path the test will pass.

[cpovirk]

@fluentfuture

[ColinChartier]

Looks to be caused by This line

It's caused because URLs automatically encode file names, while the File class expects raw unencoded input.

[cpovirk]

Previously: #1899

eamonnmcmanus suggested https://weblogs.java.net/blog/kohsuke/archive/2007/04/how_to_convert.html at that point. I'm not sure whether we had a reason for not doing it that way then.

[perceptron8]

I'm not sure whether incorrect URLs should be supported at all. I'd rather see an exception than no results. I believe that it is an URLClassLoader's responsibility to make sure it returns valid URLs. This is what should be supported in the first place. It's not anymore since 81b23cd as you already know.

Before:

guava/guava/src/com/google/common/reflect/ClassPath.java

Line 291 in 10e33c0

uri = entry.toURI();

entry.toURI() - yes, this could throw... in very rare circumstances.

After:

guava/guava/src/com/google/common/reflect/ClassPath.java

Line 289 in 81b23cd

File file = new File(entry.getFile());

entry.getFile() - if resource's path contains unsafe characters, you will most likely get them back... escaped.

Few days ago we switched from Guava 18 to 20. Our apps are mostly deployed into "C:\Program Files\Apache Software Foundation...". We have a lot of spaces in classpaths. Every time new File(entry.getFile()) gives something like "/C:/Apache%20Software%20Foundation/...", one .jar is ignored by the Scanner (!file.exists() is true).

It seems like 81b23cd fixed ClassPath behavior for some exotic case but ruined the rest. I understand that it's still @Beta, so no offence, shit happens.

I've created a small test for you. Guava 14 to 18 passes, Guava 19 and 20 fails.
https://github.com/perceptron8/guava-issue-2152-test
[Edit: unnecessary since 896c51a, deleted]

I'd be happy if you fix this bug just with the following. There is no backward compatibility already, so why not?

try {
    file = new File(entry.toURI());
} catch (URISyntaxException e) {
    throw new IllegalArgumentException(e);
}

This would be used only for processing URLs returned by UrlClassLoader. At the time #1899 was submitted, getClassPathEntries() was used for resolving Manifest's Class-Path entries too. Now it's not AFAIK. Nothing wrong should happen. Not only spaces, but also percent signs could be supported again.

Some exhaustive unit tests for ClassPath would be really handy.

[bjpe]

This bug just caused us to downgrade Guava from 19.0 to 18.0, so we would be delighted if this issue could be fixed.

[kluever]

/cc @cpovirk Any idea who the right owner should be?