Fix support for Java modules

Context - reported in our forum:

java.lang.IllegalAccessError: Module 'java.base' no access to: package 'java.lang' because module 'java.base' can't read module 'unnamed module @61b4e073'
	at java.base/java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:1237)
	at java.base/java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
	at java.base/java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:1070)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:556)
	at co.elastic.apm.agent.profiler.SamplingProfiler.run(SamplingProfiler.java:342)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:836)

The SamplingProfiler is scheduled for execution by java.util.concurrent.ScheduledThreadPoolExecutor, which is loaded by the java.base module. For some reason, although it explicitly implements Runnable, an invokedynamic resolution is done, causing this failure.

The unnamed module should have all it’s packages exported automatically, however this doesn’t mean they can be accessed by named modules.

[raphw]

Yes, any unnamed module exports all of its packages and reads all packages that are exported to any module, what is implicit for any unnamed module (or open module). In this case, you have to adjust the module graph. If you can avoid it, I’d however make sure any class you provide is only ever loaded once within a hierarchy of class loaders. It will only cause trouble.

[eyalkoren]

Since it’s only about one agent class, it feels that the safest would be to use Unsafe (😁 ) to modify the module field of this class right after it has been loaded. If I do it conservatively enough (change the reference only if I find the right field and its type is exactly the same of the one I want to replace), we should at least not break other stuff in the JVM (🤞 )