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
