Re: Ant JunitTask update to support JDK9 modules

2016-05-06 Thread Tomas Zezula
Hi Alan, > On 28 Apr 2016, at 13:22, Alan Bateman wrote: > > On 27/04/2016 17:17, Tomas Zezula wrote: >> As seen in the modulepath and classpath mixture thread there are many >> possibilities how to execute unit tests. >> I've sumarised them on the ant-dev mailing list in the context of Apache A

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Paul Benedict
I prefer the originally-proposed addExports() but allowing the layer to authorize it -- with a security check or other custom constraint the implementer chooses to code. Cheers, Paul On Fri, May 6, 2016 at 9:34 AM, Peter Levart wrote: > Hi, > > > On 05/06/2016 10:07 AM, Andrew Dinn wrote: > >>

Re: Ant JunitTask update to support JDK9 modules

2016-05-06 Thread Tomas Zezula
> On 27 Apr 2016, at 23:26, Alex Buckley wrote: > > On 4/27/2016 1:41 PM, Jan Lahoda wrote: >> On 27.4.2016 21:30, Alex Buckley wrote: >>> Your changes skyrocket in complexity because your Ant setup involves >>> both ant-junit.jar and ant-junit4.jar. The JUnit task documentation >>> (https://ant

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Peter Levart
Hi, On 05/06/2016 10:07 AM, Andrew Dinn wrote: >Have you looked at injecting code in the victim module that invokes >Module addExports to export the packages to the Byteman modules (modules >plural because it sounds like the code is split between the unnamed >module of the app class loader and

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Alan Bateman
On 06/05/2016 09:47, Andrew Dinn wrote: What I don't want to do is export the API provided by a concealed class/package that exposes a module check -free setAccessible to anything other than the Byteman class which uses it. If I follow your suggestion then I would potentially expose setAccessible

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Andrew Dinn
On 06/05/16 09:37, Alan Bateman wrote: > On 06/05/2016 09:16, Andrew Dinn wrote: >> : >> Yes, that's probably the best way to restrict access if you assume the >> agent is itself in a Jigsaw module. > Your agent may not be in a named module but it will be in an unnamed > module. Once you catch up o

hg: jigsaw/jake/jdk: 67 new changesets

2016-05-06 Thread alan . bateman
Changeset: 41f95dde9770 Author:mrkam Date: 2016-04-25 16:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/41f95dde9770 8154594: JFrame.setDefaultCloseOperation is prohibited in jtreg: Missing part of the fix Reviewed-by: alexsch, prr ! test/sanity/client/lib/SwingSet3

hg: jigsaw/jake/jaxws: 2 new changesets

2016-05-06 Thread alan . bateman
Changeset: 2d52e0610b05 Author:lana Date: 2016-05-05 17:35 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2d52e0610b05 Added tag jdk-9+117 for changeset 58265b39fc74 ! .hgtags Changeset: 1d96ce2eaed2 Author:alanb Date: 2016-05-06 08:08 +0100 URL: http:/

hg: jigsaw/jake: 13 new changesets

2016-05-06 Thread alan . bateman
Changeset: c3efe6acb2ae Author:erikj Date: 2016-04-27 14:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c3efe6acb2ae 8154841: Let different Jib profiles have different default make targets Reviewed-by: dholmes, tbell ! common/conf/jib-profiles.js ! make/Init.gmk ! make/Jp

hg: jigsaw/jake/jaxp: 5 new changesets

2016-05-06 Thread alan . bateman
Changeset: af1875980cbf Author:joehw Date: 2016-04-28 09:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/af1875980cbf 8154220: Semi-colon delimited list of catalog files in System property is throwing IllegalArgumentException Reviewed-by: lancea ! src/java.xml/share/

hg: jigsaw/jake/nashorn: 5 new changesets

2016-05-06 Thread alan . bateman
Changeset: bafd733be429 Author:hannesw Date: 2016-04-27 15:50 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bafd733be429 8134503: support ES6 parsing in Nashorn Reviewed-by: jlaskey, sundar, mhaupt Contributed-by: andreas.wo...@oracle.com ! src/jdk.scripting.nashor

hg: jigsaw/jake/langtools: 18 new changesets

2016-05-06 Thread alan . bateman
Changeset: 2aa0433e0add Author:jlahoda Date: 2016-04-15 11:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2aa0433e0add 8154283: Check for clash between package and class not working when package in a different module Summary: Looking for any visible package when

hg: jigsaw/jake/hotspot: 2 new changesets

2016-05-06 Thread alan . bateman
Changeset: 4443f69bba5a Author:lana Date: 2016-05-05 17:35 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4443f69bba5a Added tag jdk-9+117 for changeset 88170d364290 ! .hgtags Changeset: 07536fe9b503 Author:alanb Date: 2016-05-06 09:38 +0100 URL: http

hg: jigsaw/jake/corba: 2 new changesets

2016-05-06 Thread alan . bateman
Changeset: 18695748cc41 Author:lana Date: 2016-05-05 17:35 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/18695748cc41 Added tag jdk-9+117 for changeset 7a1b36bf2fe5 ! .hgtags Changeset: 285b3e979423 Author:alanb Date: 2016-05-06 08:08 +0100 URL: http:/

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Alan Bateman
On 06/05/2016 09:16, Andrew Dinn wrote: : Yes, that's probably the best way to restrict access if you assume the agent is itself in a Jigsaw module. Your agent may not be in a named module but it will be in an unnamed module. Once you catch up on the concepts then I think it should be much cl

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Michael Rasmussen
> Thanks very much for offering me this code but before I can look at it I > actually need explicit confirmation that I am able to release it under > LGPL (sorry to be fussy but I don't want any legal issues to cause my > employer a problem). If you could acknowledge that permission then I'll > be

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Andrew Dinn
On 06/05/16 09:18, Michael Rasmussen wrote: >> Is your code open source? More importantly, is its license compatible >> with the LGPL license used by Byteman? If so then can I take a peek? >> (and maybe steal it :-) > > Nothing fancy about it, just a simple class generated via ASM and then > defin

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Michael Rasmussen
> Is your code open source? More importantly, is its license compatible > with the LGPL license used by Byteman? If so then can I take a peek? > (and maybe steal it :-) Nothing fancy about it, just a simple class generated via ASM and then defined using unsafe Here's a simple main class with it (

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Andrew Dinn
On 06/05/16 08:59, Alan Bateman wrote: > On 06/05/2016 08:32, Peter Levart wrote: >> I think that not giving the agent such API just makes life for agent >> writers harder but does not prevent them to break encapsulation in >> arbitrary ways anyway. > > We've been over this a few times, it's on t

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Andrew Dinn
On 06/05/16 07:29, Alan Bateman wrote: > On 05/05/2016 23:26, Peter Levart wrote: >> What about adding an all-powers addModuleExports(module, pn, other) >> method to java.lang.instrument.Instrumentation (like it was done with >> addModuleReads) to simplify the agent's task? An agent could be >> con

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Andrew Dinn
On 05/05/16 20:50, Alan Bateman wrote: > > On 05/05/2016 17:31, Andrew Dinn wrote: >> : >> >> I looked at several ways of making this work and decided the best thing >> was to have the agent redefine AccessibleObject.checkCanSetAccessible so >> that it grants Byteman code (specifically one Byteman

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Alan Bateman
On 06/05/2016 08:32, Peter Levart wrote: : The easiest thing for agent to do then is to observe class loading and when 1st class of a particular module located in an exported package is about to be loaded, instruments it and adds a static method to it - a trampoline that invokes Module.addExp

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Andrew Dinn
On 05/05/16 23:26, Peter Levart wrote: > What about adding an all-powers addModuleExports(module, pn, other) > method to java.lang.instrument.Instrumentation (like it was done with > addModuleReads) to simplify the agent's task? An agent could be > considered trusted code, couldn't it? Well, that

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Andrew Dinn
On 05/05/16 18:38, Michael Rasmussen wrote: > While waiting for some proper way of doing this, in my current prototype > for supporting jigsaw I'm simply injecting a class into the > java.lang.reflect package that can call setAccessible0, in order to > circumvent these checks. > Probably not what w

Re: #ReflectiveAccessByInstrumentationAgents

2016-05-06 Thread Peter Levart
On 05/06/2016 08:29 AM, Alan Bateman wrote: On 05/05/2016 23:26, Peter Levart wrote: What about adding an all-powers addModuleExports(module, pn, other) method to java.lang.instrument.Instrumentation (like it was done with addModuleReads) to simplify the agent's task? An agent could be con