On 13/11/2015 12:04, Rafael Winterhalter wrote:
Hello,
I recently started testing several byte code manipulation frameworks
against a recent build of Jigsaw and found a common problem of all of these
libraries. I am myself the developer of Byte Buddy (
https://github.com/raphw/byte-buddy) and I know most tools for code
manipulation fairly well. I hope that this mailing list can provide me some
me advice on patching my library and providing help to other maintainers.
Especially in the context of using the instrumentation API, it is often not
possible to do reflection on load classes. Rather, code manipulation tools
read Java class files and parse these files for exposing classes using a
similar API but without the possibility to invoke a method or to read a
field.
Typically these tools read Java class files by querying a class loader for
the class file, e.g.:
ClassLoader.getSystemClassLoader("java/lang/Object.class");
This does not longer work using Jigsaw and I wonder how one is now supposed
to locate a class file. Do I need to find all runtime images and query each
single one? How would the path be for such a class file?
Java agents that do byte code instrumentation with java.lang.instrument
should continue to work, this goes for both load-time and dynamic
instrumentation and also where the code is instrumented to calling into
supporting classes on the class path. There is still work to do for the
scenario where agents modify the classes with references to types in
other modules but that will come in time.
As regards ClassLoader.getResourceXXX (which I think is what you mean)
then it continues to search the class path as before. It doesn't however
locate resources in named modules because they are encapsulated. The
same named methods in java.lang.Class to get resources allow code to get
at resources in its own module but not other modules. As to how to get
at resources in named modules then there are a few ways but the simplest
for now is to look at java.lang.reflect.Module getResourceAsStream.
-Alan
