Re: Proposal for back-porting JFR to OpenJDK8u

[guangyu.zhu]

Hi Gil,

Currently we put JFR API in a separate lib(jfr.jar), and use the same namespace and api as openjdk11, no omission.

Thanks,
Guangyu
------------------------------------------------------------------
Sender:Gil Tene <gil at azul.com>
Sent at:2018 Dec 6 (Thu) 22:55
To:Volker Simonis <volker.simonis at gmail.com>
Cc:jdk8u-dev <jdk8u-dev at openjdk.java.net>; Kingsum Chow <kingsum.chow at gmail.com>
Subject:Re: Proposal for back-porting JFR to OpenJDK8u



Sent from my iPad


On Dec 6, 2018, at 2:11 AM, Volker Simonis <volker.simonis at gmail.com> wrote:

> On Thu, Dec 6, 2018 at 10:38 AM Andrew Haley <aph at redhat.com> wrote:
>> 
>> Hi,
>> 
>> On 12/5/18 12:56 PM, Mario Torre wrote:
>>> On Wed, Dec 5, 2018 at 10:56 AM guangyu.zhu <guangyu.zhu at aliyun.com> wrote:
>>>> 
>>>> Java Flight Recorder (JFR) has been open-sourced in OpenJDK 11 for some time. The tool is very useful for trouble-shooting and performance tuning. However, a lot of Java applications are still running on JDK 8. Thus we back-ported JFR from 11 to 8 on x86-64 platform, which actually has been widely used at Alibaba. We believe it is stable enough to be contributed back to the community.  By contributing our patch, the community can help make it work on other platforms too. So, I’d like to file a JEP and propose contributing it to OpenJDK8project, then people can work together to make the patch be pushed finally. What do you think?
>>>> 
>>>> Thanks,
>>>> Guangyu (Greg) Zhu
>>> 
>>> 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?

> 
>> 
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671