Hello,
A general comment on CSR filing, writing a CSR and getting it reviewed
and approved is not necessarily a large amount of work or high-latency.
Many small requests are approved the same day they are finalized.
I'm happy to answer questions about CSRs, including on whether or not
one needs to be filed.
Cheers,
-Joe
On 8/22/2018 9:46 AM, [email protected] wrote:
2018/8/21 7:25:58 -0700, [email protected]:
On Tue, Aug 21, 2018 at 12:14 PM, [email protected] wrote:
...
I can easily add a new make target to build hsdis.
Adding a new binary to the OpenJDK images will require a CSR.
Do we really need a CSR for hsdis? hsdis is a shared library/DLL and
not a "binary" which can be called by the user or executed
stand-alone. The functionality offered by hsdis is only accessible by
already existing command line parameters (like -XX:+PrintAssembly).
The CSR FAQ [1] only mentions (among others):
- Adding or removing a command in $JDK/bin
- Adding, removing, or changing a command line option
which both don't seem to be applicable to hsdis.
The mere addition or removal of a shared library within the JDK image
does not, of itself, require a CSR -- unless it’s a shared library that
external code is expected to link against, which isn’t the case here.
If we wind up building hsdis by default, however, and thus including it
in the JDK image, then we’d effectively modify the behavior of the
existing -XX:+PrintAssembly option. It’s a change to diagnostic
information, and so strictly speaking a CSR is not required, but it
would be both visible to and of potential interest to many developers,
so a CSR (and a release note) would be helpful.
If we wind up not building hsdis by default then it’s even more of a
borderline case. If we think that many implementors would enable it
in their builds then a CSR would be helpful; if not, then I wouldn’t
bother.
- Mark
