On 29/12/2020 19:29, Gunnar Morling wrote:
:
That's interesting; what is missing from your PoV to make the API an
incubating one?
Getting consensus that it's the right thing to do, and then the
commitment to doing it. The latter requires re-examining the internal
plugin API, looking at the issues that have come up since JDK 9, going
over each of the API elements, iteration, and then setting it on a
course to incubate for a release or two, gathering feedback, then
eventually make it permanent and maintaining it. On one hard, it could
be interesting to have an eco system of useful link-time plugins.. On
the other hand, I think many of the plugins will be tied to core modules
so cannot be maintained outside of the jdk repo. Also many of the
plugins that we have experience with to date involve generating classes
or modifying existing class files at link time so there may be an
argument to wait until the JDK has a bytecode API.
:
I could see myself contributing to a plug-in around signature
validation, depending on how involved that task would be. I did a
quick PoC and discuss it here:
https://www.morling.dev/blog/jlinks-missing-link-api-signature-validation/
<https://urldefense.com/v3/__https://www.morling.dev/blog/jlinks-missing-link-api-signature-validation/__;!!GqivPVa7Brio!PtjEsu6vvtWl-ZEeGXaCz69AJ2svwDnzayzazAAtreJ_yLbBPOLj1s2o7XppEXf_Mw$>
This is using the existing Animal Sniffer tool for a basic signature
check. I'm not sure how much effort it'd be to fully implement this,
and also catch things like added non-virtual methods in a base
class/interface, changes to type parameters, and more. Could existing
code from the JDK be re-used for that task?
Nice blog and PoC! Yes, I think this is worth exploring more as static
analysis to detect mismatch with compile-time could be useful. A
possible starting point is something that scans a module path, it
doesn't have to start out as a jlink plugin. I could imagine `java
--validate-modules` making use of this to do deep analysis for example.
-Alan
