hg: jigsaw/jake/langtools: tools/javac/classfiles/attributes/Module/ModuleTestBase.java failing

Changeset: be1e5fc53e60 Author:alanb Date: 2015-12-05 17:08 + URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/be1e5fc53e60 tools/javac/classfiles/attributes/Module/ModuleTestBase.java failing ! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java

Re: -Xpatch with jar, jimage, or other non-exploded format?

On 05/12/2015 10:14, Michael Rasmussen wrote: : In essence, yes -- since I know that our product is often used in a setup where multiple agents are present, thus we sometimes need to patch other agents as well, and they might not be in a module. And a lot of agents add themselves to the

hg: jigsaw/jake/jdk: 2 new changesets

Changeset: 7d1db02e8d8f Author:alanb Date: 2015-12-05 16:07 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d1db02e8d8f AccessControlTest.java failing since merge with JEP 274 ! test/java/lang/invoke/AccessControlTest.java Changeset: e4af8eb551c3 Author:redestad

Re: the acyclic module graph

On 05/12/2015 17:16, Jochen Theodorou wrote: Hi all, in the sadly few hours of my spare time these days I am trying to understand jigsaw better and I came across the condition that the module graph should be acyclic... which made me wonder... So Let us assume there is a module

Re: the acyclic module graph

You might have to be more precise in your example. The runtime could define interfaces and classes that app0 could implement / extend. The modularity isn't about execution exclusion, but rather about API visibility. Eric > On Dec 5, 2015, at 9:16 AM, Jochen Theodorou wrote:

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

Hi, On Sat, Dec 5, 2015 at 1:39 PM, Alan Bateman wrote: > > > On 05/12/2015 07:00, Ali Ebrahimi wrote: > >> : >> >> module FOO.aop{ >> implements FOO.api; >> } >> >> In other word, consumer module doesn't know any think about implementing >> module since here we

Re: -Xpatch with jar, jimage, or other non-exploded format?

On 04/12/2015 22:33, Michael Rasmussen wrote: : Using -Xbootclasspath/p I can patch any class on the null classloader, but how do I use -Xpatch to patch classes in the unnamed module? The boot class path is essentially gone. All the types in the platform and JDK modules are in named modules.

Re: Optional dependencies

On 04/12/2015 19:10, Peter Levart wrote: : You would have to invoke jodaBeansModule.addRead(guavaModule); from your org.joda.beans code before 1st use of any guava type. In Addition, you would have to ensure guava is part of runtime configuration - either implicitly by some module in your

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On 05/12/2015 07:00, Ali Ebrahimi wrote: : module FOO.aop{ implements FOO.api; } In other word, consumer module doesn't know any think about implementing module since here we have contract and that is API module. think of today's interface. In the distant past, this was known here as

Re: IllegalAccessError even when -XaddExports adds ALL-UNNAMED to the reported module/package

Thanks, that was it. I must say that the command line got big pretty fast, since I had to export several packages. How about having to possibility of adding an export to all packages in a module? -XaddExports:jdk.compiler/*=ALL-UNNAMED On Dec 4, 2015 2:48 AM, "Jonathan Gibbons"

Re: -Xpatch with jar, jimage, or other non-exploded format?

On 5 December 2015 at 11:43, Alan Bateman wrote: > The boot class path is essentially gone. All the types in the platform and > JDK modules are in named modules. The only way to have types in the unnamed > module of the boot loader is -Xbootclasspath/a or JVM TI >

Re: IllegalAccessError even when -XaddExports adds ALL-UNNAMED to the reported module/package

On 05/12/2015 09:03, Roel Spilker wrote: Thanks, that was it. I must say that the command line got big pretty fast, since I had to export several packages. How about having to possibility of adding an export to all packages in a module? -XaddExports:jdk.compiler/*=ALL-UNNAMED That makes it a

Re: ClassLoader::getResource

> However there is a change to the ClassLoader.getResourceXXX methods. Mark has > summarized the current state of affairs here: > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000163.html > >