Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

[Alan Bateman]

On 01/04/2018 22:02, Rafael Winterhalter wrote:
> :
>
> 1. Java agents cannot define auxiliary classes.
>
> :
> The reason for
> using Unsafe is that many instrumentations need to define auxiliary classes
> to aid an instrumentation similar to javac which sometimes needs to define
> anonymous classes or even synthetic classes. For example, if a Java agent
> wants to register an event listener to some framework, such listeners often
> declare multiple methods what makes it impossible to fullfil the listener
> contract using a lambda expression. Instead, one typically injects an
> additional class into the same package as the instrumented class.
This seems a reasonable requirement. As you know, JSR-163 created this 
API (and JVM TI) for tools to instrument code in mostly benign ways 
where any additional agent provided helper classes are made visibility 
via the appendToXXXClassLoaderSearch methods. I don't think the use-case 
of dynamically generated helper classes came up, I don't recall it 
coming up on serviceability-dev in the intervening years either. In any 
case, I think there should be a way to support this scenario, it amounts 
to a ClassFileTransformer providing the class bytes of additional 
classes to be defined in the same runtime package as the class being 
loaded or transformed. There are a number of API choices and it's 
probably best if we bring proposals to serviceability-dev as that is 
where this API is maintained.


> :
>
> 2. Java proxies cannot invoke default methods of proxied interfaces
>
> The Java proxy API does not currently allow the invocation of an overridden
> default method since
> the InvocationHandler API only supplies an instance of
> java.lang.reflection.Method.
The issue of Proxies and default methods has come up on core-libs-dev a 
few times. In the mean-time, JEP 274 added support for MethodHandles 
that bind to non-abstract methods in interfaces. I just double checked 
and I can create a proxy where the invocation handler creates a method 
handle to the default method, binds it to proxy, and invokes it. I also 
checked the case where the interface is public in an exported package of 
a named module. Can you say a bit more, or provide an example, where you 
run into issues? I'm wondering if you are running into an accessibility 
issue or something else.

-Alan