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

Brian Goetz brian.goetz at oracle.com
Mon Jul 27 19:37:34 UTC 2020


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

I think it's perfectly fine to start a discussion.  I wouldn't start 
with a JEP draft, though, as that will have many of the same problems 
that the RFR did.  You'll want to start with what you see as the 
problem, why it is a problem, why it needs to be solved in the JDK, etc, 
and then proceed to evaluating solutions, as I outlined in my mail, and 
build consensus at each step.

Given the discussions we've had already, it seems highly unlikely that a 
JEP that enshrined _this exact solution_ would gain consensus.  But, it 
is entirely possible that an open-minded discussion of the problem and 
the many possible solutions, might lead to a solution that you could 
build some consensus around.  (Or it might not; that's OK too.)

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

I will answer this one as it speaks to a common mis-assumption about 
OpenJDK.  You obviously had some variant of the problem+solutions 
discussion internally on your team, and came to a solution that worked 
in your situation.  That's all good!  But, you should be prepared to 
start back at the beginning if you want to change "everybody's Java"; 
the set of considerations for a feature in a given deployment or even 
distribution are not the same as for the upstream, so the discussion 
might go differently.  (In particular, the answer to "is this a problem 
that needs to be solved in <distribution>" may well vary with 
<distribution>.)




More information about the core-libs-dev mailing list