Accessing module internals from bytecode rewriting agent

[Remi Forax]

Hi Kirk,
--patch-module both at compile time and at runtime is what your are looking for.

cheers,
Rémi

----- Mail original -----
> De: "Kirk Pepperdine" <kirk.pepperdine at gmail.com>
> À: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>, core-libs-dev at 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 modified classes to the bootstrap class path. I fear all this mucking
> about with modularization is going to leave the road to diagnostics littered
> with a ton of tools that will not longer work. As it is, 8 broke all the
> techniques and tooling used to diagnose class loader leaks… without fixing the
> fundamental problems that caused them to leak in the first place..and added a
> new sources for performance regressions for which there is little in the way of
> tooling and certainly much less of an understanding of the fundamental issues
> out in the general developer population. The availability of high quality
> tooling is a huge bonus in the Java eco structure…. Please, don’t send us back
> to the Stone Age.
> 
> Kind regards,
> Kirk Pepperdine
> 
>> On May 2, 2017, at 9:48 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> 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 options like Xbootclasspath, which have been dropped.  We can't
>>> migrate those tests to use the new command line flags before we migrate to Java
>>> 9, because if we do, they will stop working with Java 8.  Due to the size of
>>> our code base, it's pretty much impossible to migrate all of the users to a new
>>> set of command line flags at the same time as we migrate to Java 9.
>> So I'm curious about -Xbootclasspath as that completely overrides the runtime
>> classes. Is this static instrumentation or combining the VM/launcher from one
>> build with the classes from a different JDK build? In any case, and as you have
>> found, -Xbootclasspath  and -Xbootclasspath/p are meaningless now, a
>> consequence of moving all the core APIs to modules. The -Xbootclasspath/a
>> option works as before with the caveat that not all platform classes are
>> visible to the boot class loader now (a consequence of ongoing security work to
>> move non-core components away from the fully privileged boot loader).
>> 
>> It might be that you mean the `javac -bootclasspath,  this works as before when
>> you target 8 or older.
>> 
>> -Alan