Just in case others end up in the same situation: --patch-module (alone) doesn't do the trick as it can't be used to override the module-info.class of the jdk.jlink module. So I'm just using it to inject my plug-in and then use a Java Agent to register that one as a service provider (via Instrumentation#redefineModule()).
If I find the time I'll try and blog about it; needless to say, that a public, supported API would be much appreciated :) Thanks Alan and Remi for your help! 2017-11-21 11:46 GMT+01:00 Alan Bateman <alan.bate...@oracle.com>: > On 21/11/2017 09:29, Remi Forax wrote: > >> Hi Alan, >> I use jlink plugins for 2 things, >> - code generation, i.e. find patterns in the bytecode and optimize them >> because at link time you are in a closed world, so something that was >> dynamic is not anymore. >> - just bytecode crawling to find specific annotations to improve startup. >> >> I believe implementation like Weld or Spring should have access to an >> open API to be able to do thing kind of optimizations, imagine, you could >> create all proxies upfront or better use invokedynamic to even avoid proxy >> creation at all. >> >> The plugin API doesn't have to be complex, it's a read/replace/append of >> bytecode files. >> >> Good work was done in JDK 9 to get the plugin API to its current state. > We had hoped to expose it in an incubating module but it didn't happen as > it would have required splitting the jdk.jlink module in an awkward way. > Yes, it should be revisited. > > > -Alan >
