Proposal for back-porting JFR to OpenJDK8u

[Hohensee, Paul]

Oracle's JDK8 includes JFR APIs, but I don't know that those are considered part of the Java SE specification. If they're not, then they're at least nominally malleable. I'd recommend that a backport be just that and not change the JDK11 JFR APIs, even if those aren’t exactly the same as the JDK8 JFR APIs, not least because the JDK8 JFR source is private. Or, a compatibility mode might be the way to go, but testing would be an issue.

Paul

On 12/6/18, 7:32 AM, "jdk8u-dev on behalf of Mario Torre" <jdk8u-dev-bounces at openjdk.java.net on behalf of neugens at redhat.com> wrote:

    On Thu, Dec 6, 2018 at 4:12 PM Roman Kennke <rkennke at redhat.com> 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 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?
    
    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 jdk.management.flightrecorder from
    com.oracle.jrockit, 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.
    
    Cheers,
    Mario
    -- 
    Mario Torre
    Associate Manager, Software Engineering
    Red Hat GmbH <https://www.redhat.com>
    9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898