RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr

Alan Bateman Alan.Bateman at oracle.com
Sun Jun 24 17:00:34 UTC 2018


On 24/06/2018 12:42, Erik Gahlin wrote:
> I have updated jdk.internal.event.Event class with comments.
>
> http://cr.openjdk.java.net/~egahlin/8203629.2/
>
> It is basically a copy the comments in jdk.jfr.Event, but without 
> reference to classes in the JFR module.
>
> The rationale for using a class instead of an interface has to do with 
> the implementation of JFR. Markus brought up some reasons in his e-mail.
>
> I thought about mentioning JFR in the javadoc, and that the purpose of 
> the class is to allow use of JFR without a compile time dependency on 
> the JFR module, but decided not to, since I think the class could have 
> a value on its own for JVMs that do not support JFR, but that want to 
> do to something similar for the JDK. They could, for instance, add an 
> implementation in the empty method bodies.
I read the mail from Markus and looked at the updated webrev. It's good 
to have some javadoc, just a bit strange to have an abstract class 
without any abstract methods. There isn't enough in the discussion here 
to understand the original rational for why jdk.jfr.Event is abstract, 
esp. as the constructor is protected so it can't be directed 
instantiated outside of the jdk.jfr package. Also an abstract class can 
extend a non-abstract class so abstract jdk.jfr.Event could extend a 
non-abstract jdk.internal.event.Event if you want to clean this up a 
bit. I don't want to get in the way of the current effort but at some 
point I think another set of eyes on the APIs here might help.

BTW: My previous comment about the modifiers was mostly about jdk.jfr.Event.

-Alan


More information about the core-libs-dev mailing list