Re: #ReflectiveAccessByInstrumentationAgents

On 05/05/2016 09:50 PM, 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 class

Re: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules

> On May 5, 2016, at 1:09 PM, Alexandre (Shura) Iline > wrote: > > http://cr.openjdk.java.net/~shurailine/8154182/webrev.01/ Pushed. I took the liberty to take out the extra-whitespace and rename the variable from x to p. Mandy

Re: Modules with packages duplication

> I'm not sure that I get the question. I think you might be asking about > classes loaded into modules that are in Layers but I don't know if the > context is java.lang.instrument or JVM TI. Sorry, I could have been more specific, and I might have misunderstood what you were saying. I was

Re: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules

Looks fine. Mandy > On May 5, 2016, at 1:09 PM, Alexandre (Shura) Iline > wrote: > > http://cr.openjdk.java.net/~shurailine/8154182/webrev.01/ > > I was storing the module list in a collection before to get the things more > “effective”. It did not make it more

Re: Modules with packages duplication

On 05/05/2016 18:44, Michael Rasmussen wrote: If the no split package rule is only applicable to boot layer, how will the instrumentation API provide the correct module for other layers, as currently that is implemented by mapping package to module ? I'm not sure that I get the question.

Re: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules

http://cr.openjdk.java.net/~shurailine/8154182/webrev.01/ I was storing the module list in a collection before to get the things more “effective”. It did not make it more effective, you are right about that. Thanks for the tip on “/modules”. Please take a look. Shura > On May 4, 2016, at

Re: #ReflectiveAccessByInstrumentationAgents

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 class called Rule) free reign when it calls this

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

There is potentially a separate discussion here, as to whether javac should "force" the provision of a jar-fs provider. Strictly speaking, javac does not inherently require it. You can use javac just fine, with files in the system image, and source and class files in the default file system.

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

> On May 5, 2016, at 11:42 AM, Alexandre (Shura) Iline > wrote: > Whether the java.tools API behavior is correct is a separate matter. I am > planning to create a standalone test case and take it with javac ppl. I take this ^^ back, as the error was there all

Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

Chris, could you please take another look: http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/ What I have discovered is that jdk.zipfs was used to access jars on the classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the class path through the environment removed

Re: Modules with packages duplication

If the no split package rule is only applicable to boot layer, how will the instrumentation API provide the correct module for other layers, as currently that is implemented by mapping package to module ? /Michael

Re: #ReflectiveAccessByInstrumentationAgents

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 was envisioned either :) /Michael

Re: #ReflectiveAccessByInstrumentationAgents

Hi Alan, I'm finally replying to your previous post and also reporting news of the solution I have currently investigated to retain existing Byteman agent capabilities (I have a working implementation and am interested to see how high it causes your eyebrows to rise :-). > If the instrumentation

Re: Modules with packages duplication

Hello Alan, Thank you for the answer. I have one more question connected with duplication of packages. Now we can compile two modules with the duplicated package without compile-time error if there is no module which can access both of them. But in case of these two modules are readable by

Re: NPE in InstrumentationImpl.transform()

On 05/05/16 16:06, Alan Bateman wrote: >> Loading classes from the unnamed boot module (for instance an agent) >> causes: >> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" >> with message transform method call failed at JPLISAgent.c line: 884 >> >> Due to trying to dereference

Re: NPE in InstrumentationImpl.transform()

On 05/05/2016 15:56, Michael Rasmussen wrote: Hi Loading classes from the unnamed boot module (for instance an agent) causes: *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at JPLISAgent.c line: 884 Due to trying to dereference the

NPE in InstrumentationImpl.transform()

Hi Loading classes from the unnamed boot module (for instance an agent) causes: *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at JPLISAgent.c line: 884 Due to trying to dereference the null-loader in

Re: none of our software actually functions

On 04/05/2016 21:15, David M. Lloyd wrote: Integration with Maven is the real problem in this case, I guess. Hervé Boutemy and Arnaud Hértier gave an update at Devoxx FR a few weeks ago: https://speakerdeck.com/aheritier/fr-apache-maven-java-9-et-le-projet-jigsaw-at-devoxx-france-2016