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