[wildfly-dev] common cdi-tck problem on wildfly with java 9

Scott Stark sstark at redhat.com
Mon Jul 11 13:48:37 EDT 2016


Ok, I'll look at those, but I am using the b126 build. Maybe the fix slipped.

[tmp 512]$ java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+126)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+126, mixed mode)

----- Original Message -----
From: "Tomaž Cerar" <tomaz.cerar at gmail.com>
To: "Scott Stark" <sstark at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Monday, July 11, 2016 6:44:36 AM
Subject: Re: [wildfly-dev] common cdi-tck problem on wildfly with java 9

This is one of known issues, see for details:
http://openjdk.java.net/projects/jigsaw/spec/issues/#module-graphs
http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources
http://openjdk.java.net/projects/jigsaw/spec/issues/#PlatformClassLoader

Some of this is being addressed as part upcoming jigsaw b126

--
tomaz


On Mon, Jul 11, 2016 at 10:36 AM, Scott Stark <sstark at redhat.com> wrote:

> So the problem is a change in behavior of a URLClassLoader that has a null
> parent class loader. This seems like it is a big compatibility problem as
> classes defined by such a class loader only have visibility into the
> java.base module rather than the entire platform.
>
> The simple fix is to pass in the new ClassLoader.getPlatformClassLoader()
> as the URLClassLoader parent rather than null. However, this seems like
> what the ClassLoader should be doing itself as I would expect a lot of code
> will break. I'll create a bug report for the simple test case I have that
> shows the problem.
>



More information about the wildfly-dev mailing list