Re: Accessing module internals from bytecode rewriting agent

On 16/06/2017 10:26, Michael Rasmussen wrote: : If going that route, then there are 3 capabilities added with JVMTI 9 that you should look into, in order to be able to intercept the loading of the very early classes as well (Object, String, Class etc): can_generate_early_vmstart

Re: Accessing module internals from bytecode rewriting agent

On 15 June 2017 at 21:31, Jeremy Manson wrote: > My initial thought in this general direction was to write a JVMTI agent > that takes a list of JAR files as arguments. It then does two things: > > - Intercepts all loads of classes using the ClassFileLoadHook, checks to >

Re: Accessing module internals from bytecode rewriting agent

On 15/06/2017 01:00, Jeremy Manson wrote: : The upshot is that, in the same way as we would have turned on the big kill switch by default to ease the transition, we are also likely to implement -Xbootclasspath/p to ease the transition. You might find it easier to add --patch-module to your

Re: Accessing module internals from bytecode rewriting agent

On 14/06/2017 00:57, Jeremy Manson wrote: Hey folks, As a followup to this, given everything else that has happened in the mean time: I wonder if the same logic Mark put in his proposal to allow illegal access to internal APIs (

Re: Accessing module internals from bytecode rewriting agent

On 09/05/2017 01:45, Martin Buchholz wrote: On Tue, May 2, 2017 at 2:40 AM, Andrew Dinn wrote: Just wanted to post a heads-up that this fall-back behaviour has now been implemented in Byteman release 4.0.0-BETA5. Thanks - I can confirm 4.0.0-BETA5 works for me. Also Mandy

Re: Accessing module internals from bytecode rewriting agent

On 02/05/2017 19:00, Remi Forax wrote: Hi Kirk, --patch-module both at compile time and at runtime is what your are looking for. Right, and more details in the "Patching module content" section of JEP 261 [1]. -Alan [1] http://openjdk.java.net/jeps/261#Patching-module-content

Re: Accessing module internals from bytecode rewriting agent

-dev" <jigsaw-dev@openjdk.java.net>, core-libs-...@openjdk.java.net > Envoyé: Mardi 2 Mai 2017 19:50:50 > Objet: Re: Accessing module internals from bytecode rewriting agent > Hi Alan, > > One of the techniques that I’ve used in the past for troubleshooting is to > prepend mo

Re: Accessing module internals from bytecode rewriting agent

On Tue, May 2, 2017 at 2:15 PM, Paul Sandoz wrote: > At one point we were mulling back porting the Java 9 runtime changes to > Java 8 and therefore we could go back to Java 7, but we decided not to > proceed with that, which is what i suspect you may be thinking about. >

Re: Accessing module internals from bytecode rewriting agent

> On 2 May 2017, at 09:45, Michael Nascimento wrote: > > On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote: > >> 8 can deal with multi-release JARs. >> > > I missed that. Starting with what update? Is there any link I could use to > share this

Re: Accessing module internals from bytecode rewriting agent

On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote: > 8 can deal with multi-release JARs. > I missed that. Starting with what update? Is there any link I could use to share this info? Regards, Michael

Re: Accessing module internals from bytecode rewriting agent

On 02/05/2017 07:50, Jeremy Manson wrote: : If we follow this path, before we migrate to Java 9, we would need to make sure all of our code builds and the tests pass with Java 9 and Java 8. We can't make all of the code build and the tests pass with Java 9 as-is, because many of them use

Re: Accessing module internals from bytecode rewriting agent

Or use multi-release JARs. On 4/25/2017 3:14 AM, Jeremy Manson wrote: I guess I can call it reflectively.

Re: Accessing module internals from bytecode rewriting agent

Thanks, all. I should have remembered the special casing of java.util.concurrent in checkUnprivilegedlookupClass. It's surprising to see different behavior crossing the java.util.concurrent boundary, as I observed trying to access PriorityQueue.queue (fails!) vs. PriorityBlockingQueue.queue

Re: Accessing module internals from bytecode rewriting agent

[...] > > Meanwhile, Mandy Chung has kindly offered to look into the security > considerations that are at play and come up with a less restrictive > policy which enforces the security needs more accurately. At that point > I will probably remove the fallback -- in part because I hope that by >

Re: Accessing module internals from bytecode rewriting agent

On 25/04/17 07:22, Alan Bateman wrote: > On 25/04/2017 04:26, Martin Buchholz wrote: > >> : >> >> java.lang.IllegalArgumentException: illegal lookupClass: class >> java.util.PriorityQueue >> >> Bytecode rewriting agents have the power to inject code into classes; >> they >> should somehow also be

Re: Accessing module internals from bytecode rewriting agent

On 25/04/2017 07:29, Jeremy Manson wrote: Ah, then it sounds as if I just don't know what I'm doing. Any pointers? This should help:

Re: Accessing module internals from bytecode rewriting agent

On 25/04/2017 07:22, Jeremy Manson wrote: : The instrument API specifically supports a Boot-Class-Path attribute in the MANIFEST, as well as Instrumentation.appendToBootStrapClassLoaderSearch. I had been using that as a way to make it possible to rewrite JDK internals (add allocation

Re: Accessing module internals from bytecode rewriting agent

On 25/04/2017 04:26, Martin Buchholz wrote: : java.lang.IllegalArgumentException: illegal lookupClass: class java.util.PriorityQueue Bytecode rewriting agents have the power to inject code into classes; they should somehow also be able to reflectively inspect those same classes! But how? We

Accessing module internals from bytecode rewriting agent

We've been playing with byteman. If I have a simple rule that accesses a private field, RULE trace java.util.PriorityQueue_add CLASS java.util.PriorityQueue METHOD add AT EXIT IF true DO traceln(java.util.Arrays.toString($0.queue)) ENDRULE Then with jdk8 I get output like: [1, 2, 3] but in