RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr
Alan Bateman
Alan.Bateman at oracle.com
Thu Jun 21 07:52:03 UTC 2018
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
More information about the hotspot-jfr-dev
mailing list