Instrumentation best practices question, and more

[Alan Bateman]

On 25/11/2015 22:56, Michael Rasmussen wrote:
> :
>
> 1) There have been some discussions on this mailing list already
> regarding escaping the encaptulation of the modules, but I haven't
> found anything regarding what the best/recommended practice is for
> something like profilers, trace advices, etc or anything else that
> instruments classes throughout the system, inserting calls to methods
> to perform various tasks.
> In JDK8, adding this using a javaagent, my classes were on the boot
> classpath, thus accessible to the entire system. But this is no longer
> the case in jigsaw -- so how am I supposed to do this in a module-aware
> system?
> Am I just supposed to hack into the module system, to add edges from
> every single module in the system to my agent? While that is doable,
> it doesn't sounds very nice, requiring poking a lot of holes using
> reflection to bypass the "in-same-module" checks etc.
> These kind of instrumentations are not that uncommon in the Java
> ecosystem, so I assume there must have been some considerations how
> this should be accompliced?
> Or is there no recommended way for doing this?
Not in the current EA builds but in time there will be support for 
"module aware" agents.

In the mean-time then agents developed for JDK 8 and older should mostly 
just work. If you do load time or dynamic instrumentation via JVM TI or 
java.lang.instrument then you get some "readability for free", 
specifically there will be read edges automatically added so that when 
you instrument code in named module M then M will read the unnamed 
modules of the both the boot and application class loader. So if you 
instrument code in a named module to call your into your supporting 
classes on the boot class path or class path then it should continue to 
work.

I don't think I understand your point about being on the boot class path 
and get access "to the entire system". Being on the boot class path will 
limit visibility but doesn't change accessibility. Perhaps you mean that 
you get all permissions when running with a security manager?

>
> 2) Why the backwards-incompatible change to getResourceAsStream
> family of methods? Sure, the methods are binary compatible, but
> behave very differently than previously!
> Object.class.getResourceAsStream("Object.class") now returns null,
> apparently just for the sake of it, as the InputStream can easily
> be obtained from the Module, without any in-same-module checks, via:
> Object.class.getModule().getResourceAsStream("java/lang/Object.class")
> But, accessing this through the Module requires the code to be
> compiled against JDK9, having to keep multiple different codepaths in
> the code depending on which JDK version I'm loading the resources on!
Mark has summarized the current state of affairs here:

http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000163.html

>
> 3) Why was the implementation of java.lang.Package changed, so it no
> longer returns the content of the Manifest file?
> Previously, doing MyClass.class.getPackage().getImplementationTitle()
> would return the "Implementation-Title" entry from the manifest file,
> but now it returns null instead.
> The documentation in JDK8 even mentions that this information is
> typically stored in the manifest, where as the JDK9 now states that
> these values are unspecified.
If MyClass is packaged as a JAR file with an Implementation-Title 
attribute then this should continue to work. I just checked and I don't 
see any issues but it's possible my test case doesn't match what you 
have. If you can create a short test case then that would be useful to 
help us see whether there is a bug here.

-Alan