Proposal for back-porting JFR to OpenJDK8u

Mario Torre neugens at
Thu Dec 6 15:29:15 UTC 2018

On Thu, Dec 6, 2018 at 4:12 PM Roman Kennke <rkennke at> wrote:
> >>>> 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?

I don't think this is much of a concern, as far as I understood from
public documentation, the jdk.jfr.* API has been introduced in 9 for
Oracle JDK, and that was the base of the current 11 specification. The
JMX API was moved to from, but I think this isn't so relevant either, since
it's mostly used by Mission Control, perhaps by jcmd, and anyway,
tools that use it wouldn't work on OpenJDK anyway at this stage.

Nevertheless, I hope someone from Oracle may comment here with some
insight, we definitely don't want to make compatibility harder across
existing deployments.

Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

More information about the jdk8u-dev mailing list