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.pepperd...@gmail.com> > À: "Alan Bateman" <alan.bate...@oracle.com> > Cc: "jigsaw-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 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.bate...@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
