JAR searched on the classpath instead of the module path in Build #156

[Paul Bakker]

Following up on my earlier message, I think I found a bug in
jdk.internal.loader.BuiltinClassLoader.
When a resource is loaded from a package that does not contain classes in
an automatic module, the loading works fine. When the resource is loaded
from a package that does contain classes, the loading fails.

In jdk.internal.loader.BuiltinClassLoader on line 261 the following happens:

  public URL findResource(String name) {
        String pn = Resources.toPackageName(name);
        LoadedModule module = packageToModule.get(pn);
        if (module != null) {

1) When no classes exist in the package (but other resources do), the
module is null
2) When classes do exist in the package, the module has a value.

The second code path isn't able to load the resource in the end.

I have a very simple test case set up here:
https://github.com/paulbakker/java9-resource-bug
The test case contains one automatic module; this jar has the following
structure:

src
├── example1
│   └── somefile.txt
├── example2
│   ├── SomeClass.java
│   └── someotherfile.txt
└── tester
    └── ResourceLoader.java

The ResourceLoader class has one method, which is invoked from the tester
in the test project:

 public void loadResource() throws IOException {
        new SomeClass();

        URL resource =
ResourceLoader.class.getClassLoader().getResource("example1/somefile.txt");
        System.out.println(resource);

        URL resource2 =
ResourceLoader.class.getClassLoader().getResource("example2/someotherfile.txt");
        System.out.println(resource2);
    }


The first resource is found, the second is not.

Best,

Paul Bakker

On Fri, Mar 17, 2017 at 5:06 PM, Paul Bakker <paul.bakker.nl at gmail.com>
wrote:

> Hi Alan,
>
> I'm upgrading my "Migrating to Java 9 Modules" talk to the latest build
> and run into the same problem with build 9-ea+160-jigsaw-nightly-h6207-
> 20170316.
>
> Hibernate-core is an automatic-module. This JAR contains the xsd file that
> can't be loaded. The Hibernate code does the following:
>
> public static URL resolveLocalSchemaUrl(String schemaResourceName) {
> URL url = LocalSchemaLocator.class.getClassLoader().getResource(
> schemaResourceName );
> if ( url == null ) {
> throw new XmlInfrastructureException( "Unable to locate schema [" +
> schemaResourceName + "] via classpath" );
> }
> return url;
> }
>
> The classpath version of the same application does work (all code on the
> classpath) still works with this build, so I suspect it's related to the
> module system.
>
> Best,
>
> Paul
>
>
> On Mon, Feb 13, 2017 at 4:52 AM, Sanne Grinovero <sanne at redhat.com> wrote:
>
>> Hi Alexandru,
>>
>> please be aware that Hibernate to support Jigsaw is a work in
>> progress. We had some successful builds (including test runs) some
>> months ago, but we have yet to catch up on recent changes in OpenJDK.
>>
>> Progress for each Hibernate project can be monitored here:
>>  - http://ci.hibernate.org/view/JDK9/
>>
>> (although we didn't upgrade to build 156 yet, investigating still some
>> surprising changes)
>>
>> The issue you've found should probably be recorded on the Hibernate
>> JIRA for project HHH:
>>  - https://hibernate.atlassian.net/projects/HHH/summary
>>
>> Thanks,
>> Sanne
>>
>>
>> On Sun, Feb 12, 2017 at 3:33 PM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>> > On 12/02/2017 13:29, Alexandru Jecan wrote:
>> >
>> >> :
>> >>
>> >>
>> >> I compile my application, create the modular JAR and then at runtime I
>> get
>> >> the error:
>> >>
>> >> Caused by:
>> >> org.hibernate.boot.jaxb.internal.stax.XmlInfrastructureException:
>> Unable to
>> >> locate schema [org/hibernate/jpa/orm_2_0.xsd] via classpath
>> >>
>> >>
>> >> Could you please tell me, why does it search for the JAR on the
>> classpath
>> >> since I moved the JAR to automatic modules ?
>> >>
>> >> I have run using the –classpath and the –module-path options at the
>> same
>> >> time.
>> >>
>> >>
>> >> After that I took an older Jigsaw build (#141 and also #142).
>> >>
>> >> I performed exactly the same steps and it works perfectly. The error
>> from
>> >> above is not displayed any more.
>> >
>> > There are >1500 changes in builds 143-156. Is there any way that you can
>> > bisect this and track down the first build where you see a problem? The
>> > exception hints of something involving JAXB and a XML schema file. You
>> don't
>> > say if you are using the java.xml.bind module or the standalone JAXB on
>> the
>> > class path. In this area, I note that there was a big refresh of JAXB
>> from
>> > the upstream Metro project in jdk-9+146. In addition, there was a
>> change to
>> > the Xalan serializer in jdk-9+150 that have brought several regressions
>> and
>> > bug reports, the fixes for all issues aren't in JDK 9 yet. So anything
>> to
>> > narrow this down would be good.
>> >
>> > -Alan
>>
>
>