Proposal for back-porting JFR to OpenJDK8u

[Roman Kennke]

>>>> This is awesome, I've been toying with this idea myself lately, so I'm
>>>> very happy you would like to contribute this code, I would support
>>>> this proposal completely, and I'm very curious to see the actual
>>>> patch.
>>>>
>>>> I think you are right in filing a JEP, it's the right approach for such changes.
>>>
>>> I'm not convinced that JEPs are appropriate for backports to jdk8u. We
>>> should instead evaluate this as a feature backport.
>>>
>>> We cannot change any APIs in the core Java namespaces. This is a legal
>>> requirement.
>>
>> But this is only true for Java SE libraries and JFR has never been part of SE.
> 
> [By my reading] To remain compatible/compliant with a Java Specification
> (Java SE 8 in this case), you cannot “modify, subset, superset, or otherwise
> extend the java.*, java.*, com.sun.*, and com.oracle.* namespaces.
> 
> The jdk.* namespace is fair game from a spec compatibility perspective,
> regardless of whether or not the classes end up in rt.jar. (I too like the
> idea of a separate jar).
> 
> However, even tho there is no spec requirements here, carefully dealing
> with the jdk namespace in a backport is important in order to avoid
> compatibility conflict with other OpenJDK versions. Keeping an identical
> API should be fine, and omissions might be ok, but additions (in backports)
> should probably be done with great care and forethought.
> 
> The stuff described so far sounds like it doesn’t add any new (compared
> to OpenJDK 11) things to the existing  jdk.jfr.* and jdk.msnagement.jfr.*
> namespaces, right?. Does it have any omissions?

I guess it might be interesting/important to check if there are
differences/incompatibilites to the closed-source/commercial JFR for
JDK8 ;-) Not sure if it matters much. Maybe just put everything in its
own namespace e.g. openjdk.jfr or such, to begin with? Or would that
make it worse?

Roman