On 05.09.2016 17:00, Alan Bateman wrote:
On 05/09/2016 15:50, Jochen Theodorou wrote:
getResource did not get caller sensitive, right?
The Class getResource/getResourceAsStream methods are but this is only
relevant if you are invoke them on classes in named modules. This is why
I was asking w
On 05/09/2016 15:50, Jochen Theodorou wrote:
getResource did not get caller sensitive, right?
The Class getResource/getResourceAsStream methods are but this is only
relevant if you are invoke them on classes in named modules. This is why
I was asking what "this.class" was in the previous mail
On 05.09.2016 15:15, Jochen Theodorou wrote:
On 04.09.2016 22:05, Alan Bateman wrote:
On 04/09/2016 14:35, Jochen Theodorou wrote:
Hi all,
I am using build 9-ea+132
I have a test, that does in the setup this.class.getResource("/jars"),
to get a URL to the jars directory. The parent directo
On 04.09.2016 22:05, Alan Bateman wrote:
On 04/09/2016 14:35, Jochen Theodorou wrote:
Hi all,
I am using build 9-ea+132
I have a test, that does in the setup this.class.getResource("/jars"),
to get a URL to the jars directory. The parent directory is on the
classpath, but the call returns n
On 04/09/2016 22:33, Jochen Theodorou wrote:
hmmm... makes a sad sense to me. Though it seems to extend to
ClassLoader#getResources(). That can´t be because of multi-release JAR
files, can it?
I can't think how the MR JARs could be an issue here. Do you think you
could distill this down t
hmmm... makes a sad sense to me. Though it seems to extend to
ClassLoader#getResources(). That can´t be because of multi-release JAR
files, can it?
bye Jochen
On 04.09.2016 17:32, Uwe Schindler wrote:
Hi,
I think this is related to multi-release JAR files because directories are no longe
On 04/09/2016 14:35, Jochen Theodorou wrote:
Hi all,
I am using build 9-ea+132
I have a test, that does in the setup this.class.getResource("/jars"),
to get a URL to the jars directory. The parent directory is on the
classpath, but the call returns null... This code is not run in a
named m
This kind of "package-list" by getResources seems to be used quite
frequently in the wild... Check out this issue I filed for Log4j2.
https://issues.apache.org/jira/browse/LOG4J2-1484
I agree it's a side-effect that isn't defined in the spec (and
shouldn't be working).
Dawid
On Sun, Sep 4, 2016
Hi,
I think this is related to multi-release JAR files because directories are no
longer "unique" for the same resource. I am not 100% sure, but according to
specs, Resources are only files, never directories, so I'd always say the above
code is wrong and it is just caused by an implementation
