On 7/24/2020 7:48 AM, Volker Simonis wrote:
I think it's reasonable to ask if the JDK
really needs to support this complexity.
I can't see much complexity here.
Then I think we should start there. Until you can see the complexity
here that is obvious to Alan, Lance, myself, and others, then there is
no point discussing the specific technical issue.
Every configuration knob or flag creates complexity, because it creates
a transient environmental dependence -- yet another thing that can cause
behavior to change even when running the same JDK on the same underlying
platform.
I think you are looking at _your patch_ and saying "it's not that
complex", but that's not the kind of complexity we're talking about.
We're talking about the number of potential axes that can interact with
each other to cause surprising or hard-to-debug behavior. Can you
honestly not imagine something going wrong with having Inflater use one
zlib, Deflator another, and crc32 a third?
Until now I'm only hearing mostly high-level ,theoretical arguments
against the proposal rather than technical objections.
That's like when your mother tells you not to run with scissors,
complaining that her concern is only theoretical, because not only do we
not know anyone who has injured themselves running with scissors, but
even if we did, they were not running with THIS pair of scissors." But
of course, your mother was right, and Alan (and all the others that
reponded) are right too. One of the most important roles of JDK
stewards is pushing back on unnecessary complexity. This is what Alan
is doing.
The change itself is quite small
Small changes can still introduce complexity. (It's one line of code to
enforce that methods in Java only have an odd number of checked
exceptions on tuesdays, but that would surely be new complexity.)
and it doesn't change any default
behaviour at all so I didn't think a JEP will be required.
Which means either it will not be tested, or we have to double the
number of test modes.
I don't think we have to test all (or even various) zlib
which means customers using this will be running on an effectively
untested configuration. Does that seem wise?
Stepping back, we're in the classic trap where you've skipped over all
the important discussion, and as a result we've gotten the obvious
outcome, which is that we're talking about the wrong thing. Steps you
should have run before getting tied to your solution, at a minimum, include:
- Develop a clear and shared understanding about what the problem is
- Develop consensus that it is a problem
- Develop consensus that it is a problem that needs to be solved in
the JDK
- Brainstorm possible solutions, with tradeoffs, pros, and cons
- Identify the best solution, and build consensus around that
- Implement
- Test
- Review
- Iterate
But you skipped straight to "Implement", and are now surprised that
you're getting pushback against what should have been steps 1 or 2. You
are trying to drive the discussion to "what changes do I have to make to
have this patch accepted", but the conversation we should be having is
"should we solve this problem at all" and then "if so, is this the right
solution." And it seems you're not finding anyone who is very compelled
by either the problem or the solution.
I realize it sucks when you've done a lot of work and someone says "but
we don't want/need that"; this is why you socialize the idea first.
Alan said in his first mail "I don't think the JDK should be in the
business of ..." -- that's a clear "this is not a problem that needs to
be solved in the JDK." That's why we start at the top of the list.
