Proposal for back-porting JFR to OpenJDK8u

Roman Kennke rkennke at
Thu Dec 6 15:11:01 UTC 2018

>>>> 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* 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?


More information about the jdk8u-dev mailing list