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

[Volker Simonis]

Hi Brian,

thanks a lot for your detailed answer. I've replied to some of your
comments inline but I don't expect another answer because it seems that all
arguments have been exchanged and we're happily agreeing to disagree :)

There's just a single remaining question for which I would appreciate an
answer. I perfectly understood that the OpenJDK maintainers don't want this
change but this list is obviously biased towards the developers of the
OpenJDK and not its users. So from your (and Alan's and Lance's) point of
view does it still make sense to create a JEP for this enhancement and have
a broader discussion about its usefulness on the "discuss" list? Or is your
rejection definitive, no matter what the outcome of such a discussion will
be?

Thank you and best regards,
Volker

On Fri, Jul 24, 2020 at 10:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> 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.
>

The proposed dispatching mechanism should obviously be tested and it should
work flawlessly. But every customer who will use or everybody who will ship
or bundle a combination of alternative libraries will just as obviously
have to test them. Or is Oracle testing all the available native Java
agents which a customer can use just because Java offers an interface which
allows native agents connecting to the VM?


>
> 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?
>

See my comment above. I just propose to give customers the possibility to
use alternative configurations and I think that's wise. Nobody will ever
run in an untested configuration until he is actively choosing to do so
because he expects that the benefits will outweigh the risks.


> 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.
>
>
 That's simply not true. I've developed this change to solve a real problem
and while doing so I went through all the points you've listed above. I'm
quite happy with it because we're using it productively with good results.
I've just proposed it here because I thought it might be useful for others
as well but if that's not the case it's perfectly fine for me.