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 core-libs-dev mailing list