On Thu, 17 Dec 2020 22:07:36 GMT, Richard Fussenegger <github.com+1059453+fleshgrin...@openjdk.org> wrote:
>>> > There is very little value in adding the exception doing so might prevent >>> > existing applications from continuing to function. >>> >>> I disagree on the value and am with the author of the original issue. All >>> these existing applications are functioning but factually invalid, adding >>> the exception like we have it in all other methods of the class would >>> surface the issue in exactly those applications. >> >> While I can appreciate that the current behavior might be less than ideal, >> changing it to throw an UnsupportedOperationException could break existing >> applications. Have you had a chance to research the number of uses of >> version() in the java eco-system to determine that the risk to existing >> applications will minimal? >> >> If you feel that the change in functionality is important for users of >> UUID, then please propose a replacement method for version and propose to >> deprecate the existing method ? >> >> If you decide to move forward with proposing a replacement method for >> version, then please socialize the proposal on corelibs-dev prior to >> creating a new PR. >> >> Please note that a CSR will also be required to move forward. > > I cannot create CSRs, only members can. Deprecating and switching to another > function results in much more work for users overall because it affects all > those who use it correctly as well. In other words: 100% > > I'm in favor of rejection if that's the way forward. > > What's wrong with creating PRs for existing issues? I thought that more > contributions is actually the reason OpenJDK came to GitHub. 😉 Often an enhancement is created when there's an idea of an improvement but no resources to do the research and develop a justification. That work has to be done when someone has time. Usually ideas are discussed on one of the many OpenJDK email aliases to validate the idea and the approach before developing the code. See the list of OpenJDK Mail lists for details. https://mail.openjdk.java.net/mailman/listinfo As for moving to GitHub, it was in part to make it easier to collaborate on the development but also to move from Mercurial to Git. But GitHub does not replace the need for discussion on the Email Lists. ------------- PR: https://git.openjdk.java.net/jdk/pull/1467
