[9] RFR: 8140649: imageFile should use delete[] with new[]

[Artem Smotrakov]

Hello,

Please review this small fix for jdk9/dev repo.

It updates imageFile.cpp to use delete[] operator together with new[]. 
It also adds a check to ImageLocation::set_data(u1*) method to prevent a 
possible null-dereference.


Bug: https://bugs.openjdk.java.net/browse/JDK-8140649
Webrev: 
http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/


Artem

Re: [9] RFR: 8140649: imageFile should use delete[] with new[]

[Jim Laskey (Oracle)]

+1

> On Nov 2, 2015, at 9:30 AM, Artem Smotrakov  
> wrote:
> 
> Hello,
> 
> Please review this small fix for jdk9/dev repo.
> 
> It updates imageFile.cpp to use delete[] operator together with new[]. It 
> also adds a check to ImageLocation::set_data(u1*) method to prevent a 
> possible null-dereference.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8140649
> Webrev: http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/
> 
> Artem

Question on Implied readability

[Ali Ebrahimi]

Hi,
please clear situation for me:

I have two version of com.bar module
one com.baz that depends on com.bar
one com.foo that depends on both com.bar and com.baz

Two layer:
layer 1: com.baz and com.bar@1
---

module com.bar {//version1
exports com.bar;
}

--

//Bar.java

package com.bar;
public class Bar {
public String bar(){ return "bar1";}
}

module com.baz {
requires com.bar;
exports com.baz;
}

-

//Baz.java

package com.baz;

import com.bar.Bar;
public class Baz {
public String baz(){ return new Bar().bar();}
public Bar bar(){
return new Bar();
}
}

layer 2: com.foo and com.bar@2

 module com.bar {//version2

exports com.bar;
}

-

//Bar.java

package com.bar;

public class Bar {
public String bar(){ return "bar2";}
}

-

module com.foo {
requires com.bar;
requires com.baz;
}

-

Foo.java

package com.foo;

import com.bar.Bar;
import com.baz.Baz;

public class Main {
public static void main(String[] args) {
System.out.println(new Baz().baz());
System.out.println(new Bar().bar());
}
}

Result:

bar1
bar2

Good. So we can have different versions of same module.

But, my question arise from section "Implied readability" of

"The State of the Module System" document:
"The public modifiers mean that any module that depends upon the
java.sql module
will read not only the java.sql module but also the java.logging and
java.xml modules. "

Based on this paragraph we can edit module descriptors for modules com.foo
and com.baz as:


module com.baz {
requires public com.bar;
exports com.baz;
}

--

module com.foo {
requires com.baz;
}

But result is:

bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0/Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0
/NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:531)
at jakeplus.minicontainer.Bootstrapper.main(java.base@9.0
/Bootstrapper.java:67)
Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module:
com.foo)
 cannot access class com.bar.Bar (in module: com.bar), com.foo cannot read
com.bar
at com.foo.Main.main(com.foo/Main.java:12)
... 5 more

The exception message says: com.foo cannot read com.bar. Why?
Is not two situation equivalent? (before Implied readability and after)
This is bug?

Best Regards,
Ali Ebrahimi

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Jochen Theodorou]

On 02.11.2015 11:24, Alan Bateman wrote:
[...]

Uwe Schindler has created a bug on this topic here:

   https://issues.apache.org/jira/browse/GROOVY-7587

It makes me wonder if Groovy has ever been used with a security manager
as it seems to wrap or need access to all JDK-internal types.


This impression is wrong, Groovy does not need access to all 
JDK-internal types. But this is a dynamic language at heart. If you do 
not have a static type, then the runtime type is what counts, and that 
is the exact type, which is sometime an internal JDK type. It means 
Groovy has to do the same thing it has to do when a security manager 
doesn't like access to this class, which is to not use the specific 
class/method, but the super class information... or the information of 
that super class.. in worst case this will be Object, which means only 
method from Object can be called using Groovy in that case.


The current state is, that this issue is now fixed. The example scripts 
in the issue are working. That does not mean we can now run the build on 
jigsaw of course.


bye Jochen

Re: Question on Implied readability

[Alan Bateman]

On 02/11/2015 13:20, Ali Ebrahimi wrote:

:

bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0/Native
Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0
/NativeMethodAccessorImpl.java:62)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0
/DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:531)
 at jakeplus.minicontainer.Bootstrapper.main(java.base@9.0
/Bootstrapper.java:67)
Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module:
com.foo)
  cannot access class com.bar.Bar (in module: com.bar), com.foo cannot read
com.bar
 at com.foo.Main.main(com.foo/Main.java:12)
 ... 5 more

The exception message says: com.foo cannot read com.bar. Why?
Is not two situation equivalent? (before Implied readability and after)
This is bug?


I used the source from your mail to create a test case but I didn't 
duplicate what you were seeing. In my test then I created two layers L1 
and L2. In L1 then com.bar@1 and com.baz are mapped to the same loader 
CL1. In L2 then com.bar@2 and com.foo are mapped to the same loader CL2. 
The parent of L2 is L1. The parent of CL2 is CL1 with CL2 doing 
local-first rather than parent delegation so that it loads the local 
version of module com.bar's types.


The readability is setup as expected:

Module foo = layer2.findModule("com.foo").get();
Module bar2 = layer2.findModule("com.bar").get();
assertTrue(foo.canRead(bar2));

Module bar1 = layer1.findModule("com.bar").get();
assertFalse(foo.canRead(bar1))

I can't rule out a bug of course but I would need to see an outline of 
what jakeplus.minicontainer.Bootstrapper is doing so that I can see how 
the layers and class loaders are arranged.


-Alan.

Re: Question on Implied readability

[Ali Ebrahimi]

Hi Alan,

I don't khow how you testing this.
But this is simple possible test case:

public class Test {
public static void main(String[] args) throws Exception {
ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1"));
Configuration cfg1 = Configuration.resolve(finder1,
Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz");

ModuleClassLoader cl1 = new ModuleClassLoader(cfg1);
Layer layer1 = Layer.create(cfg1, m -> cl1);

ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2"));
Configuration cfg2 = Configuration.resolve(finder2,
layer1,ModuleFinder.empty(),"com.bar","com.foo");

ModuleClassLoader cl2 = new ModuleClassLoader(cl1,cfg2);
Layer layer2 = Layer.create(cfg2, m -> cl2);

System.out.println("layer2.modules()\n"+layer2.modules());
System.out.println("layer1.modules()\n"+layer1.modules());

Module foo = layer2.findModule("com.foo").get();
Module bar2 = layer2.findModule("com.bar").get();
System.out.println("foo.canRead(bar2) -> "+foo.canRead(bar2));

Module bar1 = layer1.findModule("com.bar").get();
System.out.println("foo.canRead(bar1) -> "+foo.canRead(bar1));

ClassLoader fooModuleLoader = layer2.findLoader("com.foo");
Class mainClass = fooModuleLoader.loadClass("com.foo.Main");

Test.class.getModule().addReads(mainClass.getModule());
Method mainMethod = mainClass.getMethod("main", String[].class);

mainMethod.invoke(null, (Object)new String[0]);
}

And Result:

layer2.modules()
[module com.foo, module com.bar]
layer1.modules()
[module com.baz, module com.bar]
foo.canRead(bar2) -> false
foo.canRead(bar1) -> false
bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0/Native
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0/NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:531)
at com.test.Test.main(com.test/Test.java:48)
Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module: com.foo)
 cannot access class com.bar.Bar (in module: com.bar), com.foo cannot
read com.bar
at com.foo.Main.main(com.foo/Main.java:12)
... 5 more


Note that I get above result if Implied readability used.


On Mon, Nov 2, 2015 at 10:18 PM, Alan Bateman 
wrote:

> On 02/11/2015 13:20, Ali Ebrahimi wrote:
>
>> :
>>
>>
> I can't rule out a bug of course but I would need to see an outline of
> what jakeplus.minicontainer.Bootstrapper is doing so that I can see how the
> layers and class loaders are arranged.


This is simple extension to jake that build layers based on config from
command line.
 Sample Input:











>
> -Alan.
>



-- 

Best Regards,
Ali Ebrahimi

Re: Question on Implied readability

[Paul Benedict]

Alan, please correct me if wrong, but there is no enforced correlation
between the module name and the jar name it's packaged in, right? The name
is officially taken from the module-info.class? If so, I'd like to make a
suggestion. One thing that's been extremely useful to me with JBoss is the
ability to link back to the JAR path in the stack trace. Is there any
chance you would consider expanding the stack trace to something like this:

bar1
Exception in thread "main" java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0
[c:\jdk\1.9\jre\modules\java.base.jar]/NativeMethod)

Paul


Cheers,
Paul

On Mon, Nov 2, 2015 at 12:48 PM, Alan Bateman 
wrote:

> On 02/11/2015 13:20, Ali Ebrahimi wrote:
>
>> :
>>
>> bar1
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0
>> /Native
>> Method)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0
>> /NativeMethodAccessorImpl.java:62)
>>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0
>> /DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(java.base@9.0
>> /Method.java:531)
>>  at jakeplus.minicontainer.Bootstrapper.main(java.base@9.0
>> /Bootstrapper.java:67)
>> Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module:
>> com.foo)
>>   cannot access class com.bar.Bar (in module: com.bar), com.foo cannot
>> read
>> com.bar
>>  at com.foo.Main.main(com.foo/Main.java:12)
>>  ... 5 more
>>
>> The exception message says: com.foo cannot read com.bar. Why?
>> Is not two situation equivalent? (before Implied readability and after)
>> This is bug?
>>
>
> I used the source from your mail to create a test case but I didn't
> duplicate what you were seeing. In my test then I created two layers L1 and
> L2. In L1 then com.bar@1 and com.baz are mapped to the same loader CL1.
> In L2 then com.bar@2 and com.foo are mapped to the same loader CL2. The
> parent of L2 is L1. The parent of CL2 is CL1 with CL2 doing local-first
> rather than parent delegation so that it loads the local version of module
> com.bar's types.
>
> The readability is setup as expected:
>
> Module foo = layer2.findModule("com.foo").get();
> Module bar2 = layer2.findModule("com.bar").get();
> assertTrue(foo.canRead(bar2));
>
> Module bar1 = layer1.findModule("com.bar").get();
> assertFalse(foo.canRead(bar1))
>
> I can't rule out a bug of course but I would need to see an outline of
> what jakeplus.minicontainer.Bootstrapper is doing so that I can see how the
> layers and class loaders are arranged.
>
> -Alan.
>

Re: Is Caching JrtFileSystem acceptable?

[Sundararajan Athijegannathan]

As Alan said, other thing async. closing of the file system, nothing 
really comes to mind. There is checkResource call in code to check that 
the resource exists before opening channel on it.. Is it possible to 
reproduce this on a smaller app?


-Sundar

On 11/2/2015 4:05 PM, Alan Bateman wrote:

On 02/11/2015 09:48, Jayaprakash Arthanareeswaran wrote:


Hello,

We recently changed our code in Eclipse to support JRE 8 when loading
classes from a Java 9 images (discussion at [1]). The change was to 
use a

JrtFileSystem with a class loader. The file system is then cached and
re-used for every request to get something from the JRE 9 images. The 
code

is something like this:

URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL();
URLClassLoader loader = new URLClassLoader(new URL[] { url });
FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader);

After this change, we have started getting an NPE in the file system (We
are randomly hitting this and at this point no idea what is causing it):

Daemon Thread [Java indexing] (Suspended (exception 
NullPointerException))

ByteArrayInputStream.(byte[]) line: 106
JrtFileSystem.newByteChannel(byte[], Set,
FileAttribute...) line: 600
JrtPath.newByteChannel(Set, FileAttribute...) line:
732
JrtFileSystemProvider.newByteChannel(Path, Set,
FileAttribute...) line: 218
Files.newByteChannel(Path, Set, FileAttribute...)
line: 361
Files.newByteChannel(Path, OpenOption...) line: 407
Files.readAllBytes(Path) line: 3152

I have confirmed that the JrtFileSystem that is used in the above 
stack and
what we cached are the same objects. And the path that is being 
passed in
the beginning is a valid JrtPath. I would like to know if this is a 
bug in

the file system implementation or something to do with our code.

Of course, I don't have the source for JrtFileSystem, so unable to debug
this further. Thanks for any pointers in trouble-shooting this further.

I'm not aware of any issues here and there shouldn't be an issue 
retaining the reference to the jrt FileSystem.


As the jrt FileSystem is in the stack trace then it means that 
Files.readAllBytes has been called with Path associated with the jrt 
file system. It's not obvious how a NPE could arise after that. The 
only thing that comes to mind is the file system being closed 
asynchronously, I can't recall how the jrt file system handles that 
(Sundar will know).


However, just to establish the environment - is this IBM JDK 8 or an 
Oracle/OpenJDK build of JDK 8? Also is the target image a regular JDK 
9 build or a Jigsaw build? There are changes to the jrt file system 
code in the Jigsaw forest but this is mostly to support exploded builds.


-Alan

Re: Question on Implied readability

[Alan Bateman]

On 02/11/2015 20:02, Ali Ebrahimi wrote:

:
layer2.modules() [module com.foo, module com.bar] layer1.modules() 
[module com.baz, module com.bar] foo.canRead(bar2) -> false 
foo.canRead(bar1) -> false
Thanks, I see the issue. The reason it didn't duplicate for me is 
because I hadn't dropped the requires com.bar.


So the bug is implied readability across layers when the same named 
module exists in multiple layers. In this case com.foo should read 
com.bar@1. The com.bar (@2) is the same configuration as com.foo is 
confusing the code. We'll need to fix this.


-Alan

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Mani Sarkar]

Hi Rory,

TestNG has an alternative build system which we will try to use to build it
using the Jigsaw binary.

How do you report such bugs to Gradle / Groovy ? Is it simpler if you
reported to them on their mailing list ? Let me know what works best, this
is fairly important as other Gradle users might have similar issues.

Cheers,
Mani

On Mon, Nov 2, 2015 at 8:51 AM, Rory O'Donnell 
wrote:

> I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log
> an issue there ?
>
> Rgds,Rory
>
>
> On 31/10/2015 13:56, Alan Bateman wrote:
>
>> On 31/10/2015 12:50, Mani Sarkar wrote:
>>
>>> Hi Rory,
>>>
>>> Do you know of a version of Gradle or a EA version which is JDK 9 Jigsaw
>>> compatible, we get these failures when building:
>>>
>>>
>>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console
>>>
>>> Caused by: java.lang.IllegalAccessException: class
>> org.gradle.internal.reflect.DirectInstantiator cannot access class
>> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module
>> jdk.compiler does not export package com.sun.tools.javac.api to > module @b7f23d9>
>> at
>> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49)
>> ... 86 more
>>
>> We should at least check if there is a bug in the Gradle JIRA for this.
>> It can be worked around by configuring the compileJava options to fork
>> javac but you might not want to do that.
>>
>> The other issue with Gradle that we know about is the ClassCastException
>> when attempting to run tests, this is tracked here:
>> https://issues.gradle.org/browse/GRADLE-3287
>>
>> -Alan.
>>
>>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>


-- 
@theNeomatrix369 *  |  **Blog
**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  |  **Bitbucket
* * |  **Github
* * |  **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

Re: Avoiding same-package conflicts

[Alex Buckley]

On 10/30/2015 1:38 PM, Jochen Theodorou wrote:

I can second that by an example using Groovy. We have not yet taken
steps to make jigsaw modules, but we quite some time ago we have split
the code base in what would become eventually become modules in the
future. Because of history this did mean to split packages. So we have a
couple of jars (that want to be modules), with overlapping package names.

Examples of package conflicts with the "base module":

* The groovy-console has a conflict in groovy.ui
* groovy-ant has a conflict in groovy.util
* groovy-docgenerator in org.codehaus.groovy.tools
* groovy-nio in org.codehaus.groovy.runtime
* groovy-sql in org.codehaus.groovy.runtime
* groovy-swing in org.codehaus.groovy.runtime
* groovy-test in goovy.lang and groovy.util
* groovy-xml in org.codehaus.groovy.runtime and goovy.util

That's 7 "modules" with conflicts out of 19. One should remember here,
that the codebase is like 10+ years old, and something that is now a
"module" used to be fixed part of the language in the past. So some poor
naming decision have been made. The org.codehaus.groovy.runtime
conflicts could probably be solved, but the groovy.util ones are
difficult, since this is a package imported by default (like java.lang
in java), so moving classes to differing packages will break Groovy
scripts... very elementary here for example GroovyTestCase in
groovy-util, which is in the groovy-test "module"..


The initial modularization of JavaFX had a similar pattern: more split 
packages than you would think, due to a "horizontal" module wanting to 
share packages with numerous "vertical" domain modules. There, the 
"horizontal" module was a 'builder' module which hoped to add 
$COMPONENTBuilder classes to the packages of various 'component' 
modules; eventually the $COMPONENTBuilder classes were deemed 
unnecessary and the 'builder' module deleted. For Groovy, I suggest that 
your "base module" has the greatest claim to the 
org.codehaus.groovy.runtime package, and that the 
groovy-{nio,sql,swing,xml} modules should export 
org.codehaus.groovy.runtime.* subpackages to the base module only.


It doesn't seem great that the groovy-ant and groovy-test modules try to 
augment the important groovy.util package owned by your base module. 
Speaking generally, it makes no sense to allow a module to protect its 
internals if at the same time its API can be augmented by unrelated 
modules -- it can't be the "same" API because it doesn't have access to 
the same internals.



also... there is a automated meta class lookup system, that is based on
the package name with a prefix. So someone could provide a meta class
for java.util.ArrayList, while another does this for LinkedList. If they
are using modules, they cannot be loaded at the same time. Granted, I
don't like this mechanism, and I am looking for ways to deprecate it in
the near future, but it is another example of same-package conflicts.


Does this mean a Groovy meta class can currently be defined as a class 
in the java.* run-time package of the bootstrap loader?


Alex

Is Caching JrtFileSystem acceptable?

[Jayaprakash Arthanareeswaran]

Hello,

We recently changed our code in Eclipse to support JRE 8 when loading
classes from a Java 9 images (discussion at [1]). The change was to use a
JrtFileSystem with a class loader. The file system is then cached and
re-used for every request to get something from the JRE 9 images. The code
is something like this:

URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL();
URLClassLoader loader = new URLClassLoader(new URL[] { url });
FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader);

After this change, we have started getting an NPE in the file system (We
are randomly hitting this and at this point no idea what is causing it):

Daemon Thread [Java indexing] (Suspended (exception NullPointerException))
ByteArrayInputStream.(byte[]) line: 106
JrtFileSystem.newByteChannel(byte[], Set,
FileAttribute...) line: 600
JrtPath.newByteChannel(Set, FileAttribute...) line:
732
JrtFileSystemProvider.newByteChannel(Path, Set,
FileAttribute...) line: 218
Files.newByteChannel(Path, Set, FileAttribute...)
line: 361
Files.newByteChannel(Path, OpenOption...) line: 407
Files.readAllBytes(Path) line: 3152

I have confirmed that the JrtFileSystem that is used in the above stack and
what we cached are the same objects. And the path that is being passed in
the beginning is a valid JrtPath. I would like to know if this is a bug in
the file system implementation or something to do with our code.

Of course, I don't have the source for JrtFileSystem, so unable to debug
this further. Thanks for any pointers in trouble-shooting this further.

Regards,
Jay

[1]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-October/004857.html

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Alan Bateman]

On 02/11/2015 08:56, Cédric Champeau wrote:
BTW, Groovy itself is not compatible with Jigsaw, so my guess would be 
that even if Gradle fixed this, you would have different errors 
because Gradle uses Groovy. What is possible today is to run Gradle on 
Java 9 non jigsaw, and compile using Java 9 Jigsaw.


Jochen sent an email on jigsaw-dev a few weeks ago ("Groovy with 
Jigsaw") but as far as I understand, there's no clear understanding of 
the problem/solutions so far.
There was one specific issue in that thread, it was a VerifyError that 
stemmed from Guava overriding 
java.lang.reflect.AccessibleObject.setAccessible. That issue was 
resolved at the time and I don't think there were any other specific 
issues on that thread. There was of course the general issue that Groovy 
seems to access or wrap types in non-exported packages but we don't have 
a solution to that except via the command-line -XaddExports.


-Alan.

Re: TestNG build failing with JDK9 Jigsaw due to Gradle

[Cédric Champeau]

>
>  That issue was resolved at the time and I don't think there were any
> other specific issues on that thread. There was of course the general issue
> that Groovy seems to access or wrap types in non-exported packages but we
> don't have a solution to that except via the command-line -XaddExports.
>
> -Alan.
>

I think this is the particular issue Jochen is very worried about. We
should think about the consequences of it. What does it mean to be forced
to use -XaddExports. It is at least unclear to me. What would be
catastrophic is releasing Jigsaw and realizing that we killed Groovy
because it cannot use modules without, for example, disabling all kind of
security.

Re: Is Caching JrtFileSystem acceptable?

[Alan Bateman]

On 02/11/2015 09:48, Jayaprakash Arthanareeswaran wrote:


Hello,

We recently changed our code in Eclipse to support JRE 8 when loading
classes from a Java 9 images (discussion at [1]). The change was to use a
JrtFileSystem with a class loader. The file system is then cached and
re-used for every request to get something from the JRE 9 images. The code
is something like this:

URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL();
URLClassLoader loader = new URLClassLoader(new URL[] { url });
FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader);

After this change, we have started getting an NPE in the file system (We
are randomly hitting this and at this point no idea what is causing it):

Daemon Thread [Java indexing] (Suspended (exception NullPointerException))
ByteArrayInputStream.(byte[]) line: 106
JrtFileSystem.newByteChannel(byte[], Set,
FileAttribute...) line: 600
JrtPath.newByteChannel(Set, FileAttribute...) line:
732
JrtFileSystemProvider.newByteChannel(Path, Set,
FileAttribute...) line: 218
Files.newByteChannel(Path, Set, FileAttribute...)
line: 361
Files.newByteChannel(Path, OpenOption...) line: 407
Files.readAllBytes(Path) line: 3152

I have confirmed that the JrtFileSystem that is used in the above stack and
what we cached are the same objects. And the path that is being passed in
the beginning is a valid JrtPath. I would like to know if this is a bug in
the file system implementation or something to do with our code.

Of course, I don't have the source for JrtFileSystem, so unable to debug
this further. Thanks for any pointers in trouble-shooting this further.

I'm not aware of any issues here and there shouldn't be an issue 
retaining the reference to the jrt FileSystem.


As the jrt FileSystem is in the stack trace then it means that 
Files.readAllBytes has been called with Path associated with the jrt 
file system. It's not obvious how a NPE could arise after that. The only 
thing that comes to mind is the file system being closed asynchronously, 
I can't recall how the jrt file system handles that (Sundar will know).


However, just to establish the environment - is this IBM JDK 8 or an 
Oracle/OpenJDK build of JDK 8? Also is the target image a regular JDK 9 
build or a Jigsaw build? There are changes to the jrt file system code 
in the Jigsaw forest but this is mostly to support exploded builds.


-Alan

Re: Question on Implied readability

[Ali Ebrahimi]

Hi,


On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman 
wrote:

> On 02/11/2015 20:02, Ali Ebrahimi wrote:
> Thanks, I see the issue. The reason it didn't duplicate for me is because
> I hadn't dropped the requires com.bar.
>
> So the bug is implied readability across layers when the same named module
> exists in multiple layers. In this case com.foo should read com.bar@1.
> The com.bar (@2) is the same configuration as com.foo is confusing the
> code. We'll need to fix this.
>
> So, you say com.foo can not read com.bar(@2) and why?
Based on implied readability module com.foo implicitly reads com.bar, in
other word have requires com.bar;
and because com.bar(@2) is co-layer with com.foo, so
module com.foo should reads com.bar(@2).
com.bar(@2) override com.bar(@1) for com.foo.
How this specified in spec?

> -Alan
>

-- 

Best Regards,
Ali Ebrahimi

RE: Question on Implied readability

[Frank Yuan]

> -Original Message-
> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf Of 
> Alex Buckley
> Sent: Tuesday, November 03, 2015 10:27 AM
> To: jigsaw-dev 
> Subject: Re: Question on Implied readability
> 
> On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:
> > On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman 
> > wrote:
> >
> >> On 02/11/2015 20:02, Ali Ebrahimi wrote:
> >> Thanks, I see the issue. The reason it didn't duplicate for me is
> >> because I hadn't dropped the requires com.bar.
> >>
> >> So the bug is implied readability across layers when the same named
> >> module exists in multiple layers. In this case com.foo should read 
> >> com.bar@1.
> >> The com.bar (@2) is the same configuration as com.foo is confusing
> >> the code. We'll need to fix this.
> >>
> >> So, you say com.foo can not read com.bar(@2) and why?
> > Based on implied readability module com.foo implicitly reads com.bar,
> > in other word have requires com.bar; and because com.bar(@2) is
> > co-layer with com.foo, so module com.foo should reads com.bar(@2).
> > com.bar(@2) override com.bar(@1) for com.foo.
> > How this specified in spec?
> 
> It's currently underspecified in Configuration::resolve as "A readability 
> graph is then constructed to take account of implicitly declared
> dependences (requires public)."
> 
> We'll have to think about the implication of com.baz in layer1 sometimes 
> offering a 'requires public' on com.bar in layer1, and
> sometimes offering a 'requires public' on com.bar in layer2, depending on who 
> is reading com.baz in layer1.

Hi Alex

I don't think so. com.baz declares "requires public com.bar", so com.baz decide 
which com.bar is readable, in this case, decide which com.bar is used by com.foo
Consider the following scenario, which is the common usage of implied 
readability
com.baz provides the following service:
public Object1 getObject();
Object1 is a class defined in com.bar, please not com.bar@2 is not visible to 
com.baz(indeed to avoid conflict, only one com.bar can be visible/readable to 
com.baz), so com.baz construct an Object1 of com.bar@1 during getObject() is 
invoked, and then com.foo get this Object1 instance, now com.foo can only use 
type Object1 of com.bar@1 to interpret it, who guarantee what Object1 of 
com.bar@2 is?! So here the type must be definite, M2 requires public M1,  M3 
requires M2, then which M1 is read by M2, which M1 must be readable to M3. It's 
not related to Layer actually.

Frank


> 
> Alex

Re: Question on Implied readability

[Alex Buckley]

On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:

On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman 
wrote:


On 02/11/2015 20:02, Ali Ebrahimi wrote:
Thanks, I see the issue. The reason it didn't duplicate for me is because
I hadn't dropped the requires com.bar.

So the bug is implied readability across layers when the same named module
exists in multiple layers. In this case com.foo should read com.bar@1.
The com.bar (@2) is the same configuration as com.foo is confusing the
code. We'll need to fix this.

So, you say com.foo can not read com.bar(@2) and why?

Based on implied readability module com.foo implicitly reads com.bar, in
other word have requires com.bar;
and because com.bar(@2) is co-layer with com.foo, so
module com.foo should reads com.bar(@2).
com.bar(@2) override com.bar(@1) for com.foo.
How this specified in spec?


It's currently underspecified in Configuration::resolve as "A 
readability graph is then constructed to take account of implicitly 
declared dependences (requires public)."


We'll have to think about the implication of com.baz in layer1 sometimes 
offering a 'requires public' on com.bar in layer1, and sometimes 
offering a 'requires public' on com.bar in layer2, depending on who is 
reading com.baz in layer1.


Alex