Re: RFR: 8177845: Need a mechanism to load Graal

> On Apr 27, 2017, at 2:30 PM, Doug Simon wrote: > > >> On 27 Apr 2017, at 23:24, Mandy Chung wrote: >> >> >>> On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: >>> >>> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 >>

Re: Auto-modules vs. the unnamed module

2017/4/27 8:16:50 -0700, Andrew Dinn : > On 27/04/17 15:58, Ceki Gulcu wrote: >> Please forgive my possibly silly question but can someone kindly explain >> the advantages of placing a non-modular artifact on the module path >> instead of the class path? In other words, why

Re: RFR: 8177845: Need a mechanism to load Graal

> On Apr 27, 2017, at 7:47 AM, Doug Simon wrote: > > [1] http://cr.openjdk.java.net/~dnsimon/8177845.02 I reviewed the top repo and jdk repo change. For hotspot change, I reviewed jdk.vm.ci.services/* and jdk.internal.vm.ci module-info.java.

Re: Java Platform Module System

On 25.04.2017 19:02, Alex Buckley wrote: On 4/25/2017 1:20 AM, Stephan Herrmann wrote: On 25.04.2017 03:50, Alex Buckley wrote: Dependency resolution in JPMS is accomplished by the static 'resolve' method of java.lang.module.Configuration. Interesting. Are you saying the semantics of JPMS

Re: RFR: 8177845: Need a mechanism to load Graal

> On 27 Apr 2017, at 21:15, Vladimir Kozlov wrote: > > make/CompileJavaModules.gmk Please, adjust comment for jdk.aot: > > ># Don't use Indy strings concatenation to have good JVMCI startup > >performance. > --- > <# Don't use Indy strings concatenation to have

Re: RFR: 8177845: Need a mechanism to load Graal

> On Apr 27, 2017, at 11:51 AM, Doug Simon wrote: > >> >> On 27 Apr 2017, at 18:44, Christian Thalinger wrote: >> >> Thanks for doing this. I have a hard time following what’s happening :-) >> >> src/jdk.internal.vm.compiler/.mx.graal/suite.py

Re: RFR: 8177845: Need a mechanism to load Graal

> On 27 Apr 2017, at 18:44, Christian Thalinger wrote: > > Thanks for doing this. I have a hard time following what’s happening :-) > > src/jdk.internal.vm.compiler/.mx.graal/suite.py > > + "jdklibraries" : { > +"JVMCI_SERVICES" : { > + "path" :

Re: Can automatic modules be made to work?

The returning question is: how can I as a *library builder* participate in adopting Jigsaw? The first thing you need to ensure is that there are no split package issues. The next steps can be conflicting: - I want to name my module, so my customers can refer to it - I do not want to refer

hg: jigsaw/jake/jdk: 49 new changesets

Changeset: 91b0fe2e552a Author:smarks Date: 2017-04-17 15:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91b0fe2e552a 8177789: fix collections framework links to point to java.util package doc Reviewed-by: bchristi, martin !

hg: jigsaw/jake/jaxp: 8 new changesets

Changeset: 2fdbfbde3bc0 Author:joehw Date: 2017-04-17 16:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/2fdbfbde3bc0 8162572: Update License Header for all JAXP sources Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Constants.java

hg: jigsaw/jake: 13 new changesets

Changeset: d3c1b028c499 Author:shurailine Date: 2017-04-17 19:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d3c1b028c499 8173801: Modify makefiles to not build demos and samples bundles. Reviewed-by: ihse, prr, erikj ! common/autoconf/spec.gmk.in !

hg: jigsaw/jake/nashorn: 7 new changesets

Changeset: 03e5f1316a2d Author:sundar Date: 2017-04-19 14:05 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/03e5f1316a2d 8178954: jjs uses wrong javadoc base URL Reviewed-by: hannesw ! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Main.java

hg: jigsaw/jake/hotspot: 8 new changesets

Changeset: a92a6f4a454e Author:jlahoda Date: 2017-04-19 13:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a92a6f4a454e 8178012: Finish removal of -Xmodule: Summary: Setting jtreg to use --patch-module instead of -Xmodule:. Reviewed-by: alanb ! test/TEST.ROOT

hg: jigsaw/jake/langtools: 19 new changesets

Changeset: 5aa6f825b4ec Author:jjg Date: 2017-04-17 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5aa6f825b4ec 8162917: langtools/test/tools/javadoc/CompletionError.java is not runnable Reviewed-by: ksrini ! test/tools/javadoc/CompletionError.java

hg: jigsaw/jake/jaxws: 3 new changesets

Changeset: 1c610f1b4097 Author:aefimov Date: 2017-04-24 18:21 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/1c610f1b4097 8176168: Performance drop due to SAXParser SymbolTable reset Reviewed-by: joehw, lancea !

hg: jigsaw/jake/corba: 2 new changesets

Changeset: 03a2cc9c8a1e Author:lana Date: 2017-04-27 16:07 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/03a2cc9c8a1e Added tag jdk-9+167 for changeset 43de67f51801 ! .hgtags Changeset: 480115f56220 Author:alanb Date: 2017-04-27 17:17 +0100 URL:

Re: RFR: 8177845: Need a mechanism to load Graal

Thanks for doing this. I have a hard time following what’s happening :-) src/jdk.internal.vm.compiler/.mx.graal/suite.py + "jdklibraries" : { +"JVMCI_SERVICES" : { + "path" : "lib/jvmci-services.jar", + "sourcePath" : "lib/jvmci-services.src.zip", + "optional" : False, +

Re: Auto-modules vs. the unnamed module

On 27-Apr-17 5:22 PM, Alan Bateman wrote: The advantage of automatic modules is that it allows you to treat a library as a module when compiling or running. It essentially allows you to make progress on modularization without waiting for everything that you transitively depend on to migrate

Re: RFR: 8177845: Need a mechanism to load Graal

> On 27 Apr 2017, at 17:40, Alan Bateman wrote: > > On 27/04/2017 15:47, Doug Simon wrote: > >> : >> >> - The jaotc launcher now needs to explicitly export JVMCI and >> jdk.internal.vm.compiler to jdk.aot[4]. >> Unfortunately there needs to be one --add-exports

Re: RFR: 8177845: Need a mechanism to load Graal

On 27/04/2017 15:47, Doug Simon wrote: : - The jaotc launcher now needs to explicitly export JVMCI and jdk.internal.vm.compiler to jdk.aot[4]. Unfortunately there needs to be one --add-exports option per qualified export target as combining them with a comma (e.g.,

Re: Auto-modules vs. the unnamed module

On 27/04/2017 15:58, Ceki Gulcu wrote: Hello all, Please forgive my possibly silly question but can someone kindly explain the advantages of placing a non-modular artifact on the module path instead of the class path? In other words, why should the user prefer a non-modular artifact to

Re: Auto-modules vs. the unnamed module

On 27/04/17 15:58, Ceki Gulcu wrote: > > Please forgive my possibly silly question but can someone kindly explain > the advantages of placing a non-modular artifact on the module path > instead of the class path? In other words, why should the user prefer a > non-modular artifact to act as an

Re: Huge implications of multiple class loaders for application modules

> On Apr 25, 2017, at 8:44 AM, David M. Lloyd wrote: > On 04/25/2017 08:31 AM, Alan Bateman wrote: >> On 25/04/2017 14:16, Michael Nascimento wrote: >> >>> : >>> and also the fact >>> packages must be defined by a single module even if they are not >>> exported, >>>

Auto-modules vs. the unnamed module

Hello all, Please forgive my possibly silly question but can someone kindly explain the advantages of placing a non-modular artifact on the module path instead of the class path? In other words, why should the user prefer a non-modular artifact to act as an auto-module instead of its

Re: RFR: 8177845: Need a mechanism to load Graal

> On 21 Apr 2017, at 13:46, Doug Simon wrote: > > There has been some discussion about whether we want to update Graal in the > JDK at this late stage. The main (only?) risk is a regression in the AOT tool. > > If we don't update Graal from upstream, then the qualified

hg: jigsaw/jake/jdk: 5 new changesets

Changeset: be341882bfba Author:alanb Date: 2017-04-27 11:20 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be341882bfba Add more test cases to ExecJarWithAgent ! test/java/lang/instrument/executableJAR/ExecJarWithAgent.java Changeset: c01aff0ff6bf Author:alanb

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

Alan, Remi, Andrew - thanks to you all for the examples/links, I will look into it when I got a spare moment. Also to answer Alan's previous question: > If you can find the defining loader of > org.jboss.weld.proxies.util.Map$Proxy then I think it would be useful to > this discussion. If the

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

On 26/04/2017 15:04, Matej Novotny wrote: You can spin one module per package, by creating one ModuleLayer per package, not unlike j.l.r.Proxy does. Don't know a bit about it, but it sounds like a way worth exploring. Would you have a pointer towards some code showing how to deal with