On Mon, 24 May 2021 10:13:55 GMT, Сергей Цыпанов <github.com+10835776+stsypa...@openjdk.org> wrote:
>> But don't people access these internal code at their own risk, as jdk may >> change these code at any time without notice? > > True, I just wonder whether it's OK to change internals when we know for sure > that this breaks 3rd party code I think so. There are always unexpected ways the jdk may break and third-party libraries would need a different workaround for a new java version. For instance, in Apache log4j, its library has a special guard against the broken implementation of Reflection getCallerClass during java 7. The libraries can just handle these in their version-specific components. Especially given the fact that the code linked above already has version-specific handling (8 vs 9), so it won't hurt much for them to add another piece of logic to handle jdk 17+ in case this optimization is merged. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744
