On 2018-06-21 09:52, Alan Bateman wrote:
On 20/06/2018 18:59, Erik Gahlin wrote:
:
Also all the methods are empty which makes me wonder if they should
be abstract (as the class is abstract) or whether it should be an
interface.
Abstract is needed to prevent user from instantiating the class.
The methods need to have a body, otherwise event classes in java.base
would need to implement the methods, which would be cumbersome. We
like to use a class as it simplifies the implementation if we know
all event classes have a common ancestor with java.lang.Object as a
parent.
so we can be guaranteed that the class
I'm not sure that I understand the issues here but just to say that
jdk.internal.event is not exported so code outside of the JDK cannot
directly instantiate instances of classes in that package. Also
interfaces can have default methods which may go to your concern about
needing to implement each of the 6 methods. Once Event is cleaned up
with some javadoc then it will be easier to argue this one way or the
other.
-Alan
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 also removed an import statement in JDKEvents.java that referenced a
test class that should not have been there.
Erik
