It is currently not possible to declare a Javaagent as modular, i.e. a module-info within an agent jar file is ignored and the Javaagent is loaded in the system class loader's unnamed module.

This can be a problem if the Javaagent requires classes from modules that are not resolved by a JVM if the executed application is itself modular and does not require the same dependent modules.

For example, a Javaagent might depend on java.sql which might not be required by the main application. Currently, the Java agent is unable to declare this dependency requirement in its own module-info. And while it is possible for a Javaagent to append its own dependencies to the class path, it cannot currently load JVM modules using the instrumentation API.

In my opinion, an application that uses a Java agent should be treated as a module-classpath hybrid such that all available modules should be resolved for the application, similarly to an application that is run on the class path. If Java agents contain a module-info on the other hand, I believe that it would be best to add a Java agent to the resolution graph while respecting its declared module dependencies.

In the current state, Java agents that work well on Java 8 JREs often fail on Java 9+ JREs once the application is run as modular what hinders migration. The only workaround is to find out all modules that an agent requires to run what is often non-trivial if the Java agent is not open source and maintained by a third-party.