RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

[Brian Goetz]

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.