[External] : Re: Enhancements

Fri Nov 1 15:59:55 UTC 2024

Hi Tom,

What's your end goal here? Is it to become an active member of the OpenJDK community or do you have a specific enhancement that you want to deliver? If it's the former, working on bug fixes will be a faster path forward since those are more likely to be accepted and appreciated. If it's the later, then simply find the correct mailing list and start a thread about your enhancement to see what the rest of the community thinks about it.

There are many, many more things to consider when evaluating any change to the JDK than just its API. Too many to try to cover in an email thread, which is why it's all documented in the OpenJDK Developers' Guide (https://openjdk.org/guide/) which all developers should read before engaging in OpenJDK development. Please do so.

Thanks,
/Jesper

On 1 Nov 2024, at 15:39, Chen Liang <chen.l.liang at oracle.com> wrote:

Hi Tom,
Still, I recommend first sending to area mailing lists announcing that you have an enhancement proposal.  To your upset, but what determines the success of an enhancement is its API, especially its usages, such as its callers and overrides (user implementations); tests and implementations and comments can always be refurbished later.

The problem with challenging enhancements is usually not related to the implementations or tests, but more around the API designs, especially about reducing complexity.  Should we enhance this existing API or should we plan to nuke it and offer a new one because of the critical shortcomings?  Is this undocumented behavior relied on by a lot of users that we should promote it to official, or is it safe for us to simply change it silently?  Should we make this subroutine a new API like the main one, or should we keep it hidden in the implementation?  These are the more important questions than having robust testing or implementation.

Given these situations, I don't think it's a good idea to attempt "challenging enhancements" from "small enhancements" as they are of distinct nature from the bugs.

Chen
________________________________
From: Tom Mooney <Tom.Mooney at bjss.com<mailto:Tom.Mooney at bjss.com>>
Sent: Friday, November 1, 2024 9:29 AM
To: Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>>
Subject: [External] : Re: Enhancements

Thanks for your reply Chen, would having a clear definition of done (that i could email as an excel spreadsheet so every step I completed could be checked)  and QA evidence of the correctness etc of the enhancement be useful so that you can see every effort was taken to make the most well tested, correct and flexible implementation possible? I can understand that if an enhancement touches a lot of points in the JDK its high risk as its an immensely complex project but I was think about attempting small/minor enhancements when they pop up and when I get more experience contributing to slowly and safely taking on more challenging enhancements. Does that sound alright?

Ta
Tom

________________________________
From: Chen Liang <chen.l.liang at oracle.com>
Sent: 01 November 2024 14:23
To: Tom Mooney <Tom.Mooney at bjss.com>; jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: Re: Enhancements

Hello Tom,
Yes, the JDK project and the OpenJDK organization do accept enhancements.  However, they are usually less likely to be accepted compared to bug fixes, due to that they often need long-term maintenance and may become a "peak of complexity solution" (like finalization and security manager) in the future.  The addition of an enhancement is much easier than the removal of one, especially for core libraries.

In the core libraries, enhancements are mainly feasible due to their motivation, even though we would love to see these test coverage and nice implementation and specification.  A positive example is the recent addition of Reader::of(CharSequence) https://bugs.openjdk.org/browse/JDK-8341566 which is nicely motivated because a Reader is "for reading character streams" and there are immediate (no synchronization as in StringReader) and future (potential to immediately support future batch-copy methods on CharSequence) benefits to such an API.

Since the advantage and the long term implications of enhancements (especially new library APIs, as we won't be able to remove them easily) are not always clear, we strongly recommend sending to mailing lists before creating an issue on the JBS or bugs.java.com.  Meanwhile, we usually wish to settle down the API signature before moving on to review the implementation, so there's a suggestion for people to send the APIs implemented with throw UOE, so people can first focus on the basis (the API signatures) before moving on the implementation details to avoid waste of review efforts.

Regards.
Chen Liang
________________________________
From: jdk-dev <jdk-dev-retn at openjdk.org> on behalf of Tom Mooney <Tom.Mooney at bjss.com>
Sent: Friday, November 1, 2024 9:08 AM
To: jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: Enhancements

Hi

Does OpenJDK accept enhancements from contributors at all? It was suggested previously to prefer fixing bugs over enhancements but if the enhancements aren't too risky and on the smaller side of medium in size and not too risky are they likely to be accepted if you provide excellent test coverage, clean implementation and clear complete documentation that you'd done everything you need too. Is it good to define a general Definition of Done for this project so we can just work through a set of tasks to complete a ticket to maximise the chances our contributions will be accepted?

Ta
Tom

The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241101/978695f8/attachment-0001.htm>