JEP411: Missing use-case: Monitoring / restricting libraries

Lim lim.chainz11+mailing at
Wed Apr 28 10:18:06 UTC 2021

Hi Markus, thank you for giving me the guidance for performing the JFR
I am able to test if my use case is suitable. Where do I provide my
feedback/issue of using the streamed JFR?

On Wed, Apr 21, 2021 at 10:32 PM Markus Gronlund
<markus.gronlund at> wrote:
> If the existing event probes in the JDK does not give you the information you need, like the name of URL's, it can be a reached by building your own "custom events" via the Events API [3]. It can be harder to add events to unknown code dynamically, but it can be done and you can use java.lang.Instrument to build an agent to inject the custom event.

I understand that new events can be added in code that I have control of
using the Events API but in this case, which is the name of URLs is not

Firstly, using a Java agent to instrument bytecode cannot be scaled because
there are a lot of HTTP libraries, including the built in Java APIs and 3rd
parties such as Apache HTTP, OkHttp. They can also roll their own "HTTP
wrapper" if the author doesn't want dependency. In addition, these 3rd party
libraries can be shaded and relocated, making it harder to target via

Obfuscation can also have an impact on reliability of instrumentation,
since obfuscation can be changed in every version and what if the
obfuscation has "anti-tamper/anti-debug" features? This is not
scalable if we need to monitor for each library that might call URLs.

> If there is a general problem area and provides a good scaling factor, and the URL information might just be such a case, it can make sense to investigate if this information can be provided directly by the JDK, by extending existing or new JFR events.

I believe that the majority of the HTTP libraries, and code that roll
their own are using the built in Java APIs, thus monitoring the built
in API that is used for making URLs calls make sense. Then, it can be
scaled to most of the libraries compared to instrumenting each one
which has its own problem stated above.

More information about the security-dev mailing list