On Sat, 26 Apr 2025 04:34:58 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
> Other Reviewers may have a different opinion, mine is that this change should > not be integrated. Thank you @jaikiran for taking on the unglamorous task of writing this note. > Almost every piece of code in any project has a potential to be micro > optimized for some arbitrary improvement, even the JDK project too. That > doesn't mean that those changes should be done. Faster != better. The Magic of Java is not that 1% of developers can write clever, lock-free, allocation free, low-level, hand-optimized code. What's magic is that you can put any random 80% developer on a boring e-commerce project, switch them out over years or even decades and still have a reasonably maintainable (and performant!) code base 15 years later. This is the Ethos of the Java platform to me, not that it helps you win the The One Billion Row Challenge. Put too many 1% developers on a Java project and they will soon get bored and start inventing clever problems for which they have even more clever solutions. But clever != maintainable. Maintainable code is straightforward, stupid and obvious. > I believe that this non-stop churn to the JDK code, code which has been > around long enough without any practical issues, is not an improvement but a > needless distraction. Changes should be justified and solve a real-world problem. Solving the problem should have clear benefits which outweigh the cost of the review process and the cost of any future increase in maintainability burden over decades. My first contribution to OpenJDK was performance related, so has many of my later contributions. I have also received reviewer pushback when my micro optimizations seemed inconsequential, affected long term maintainabiliy in negative ways or made changes too tricky or laborsome to review. So I tried to adapt, become more self-critical towards which problems I was solving and I even started looking into other kinds of problems, like fixing correctness bugs, improving test coverage. The review process is not for free. It's important to actually listen to what reviewers are saying. When they are not saying much, that's also a signal. When getting reviewer pushback for a change, I often find it more productive to just withdraw the change and find something else to work on, rather than arguing against the reviewers or changing the goal of the PR just to push it through. Faster != better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24864#issuecomment-2831897022
