update OutputUtils to support stacktrace links leading to JDK files.

[mbien]

fixes #4516

• add active JDK to class path
• fix the packageName parsing of the line action when modules are involved
• open class file if no source found -> allows user to download/attach sources

second commit is for cleanup, first has the changes.

test snippet

    public static void main(String[] args) throws Exception {
        // for a JDK/application trace
        new FileReader("nonexistent");

        // for a trace in 3rd party deps (guava)
        ImmutableSet.of("a").iterator().remove();
    }

devbuild link (expires in 7 days):
https://github.com/apache/netbeans/suites/10002051531/artifacts/485721202

[mbien]

rebased to latest master

[matthiasblaesing]

Looks sane to me and a quick test on JDK 8 and 11 showed, that it works both with and without modules.

One thing I'm not really sure about is the order of classpaths:

       return createProxyClassPath(
                    Stream.concat(
                        Stream.of(prov.getProjectClassPaths(ClassPath.BOOT)),
                        Stream.of(prov.getProjectClassPaths(ClassPath.EXECUTE)))
                );

consider nbjavac. When it is declared as a dependency it overrides the built-in javac although normal classloading behavior would be to prefer the boot classpath. So my assumption would be, that people having dependencies clashing with JDK classes would ensure that the classloaders are setup to prefer these. But that is a niche use-case, so feel free to disagree and merge as is.

[mbien]

consider nbjavac. When it is declared as a dependency it overrides the built-in javac although normal classloading behavior would be to prefer the boot classpath. So my assumption would be, that people having dependencies clashing with JDK classes would ensure that the classloaders are setup to prefer these. But that is a niche use-case, so feel free to disagree and merge as is.

@matthiasblaesing That is a good point. I thought about this before and wasn't sure either. But I think having project-cp before boot cp might be indeed the better default for stack trace linking since it covers more cases than the other way around (i think). Swapped it now and rebased to latest master for a fresh build.

[mbien]

all green. merging.