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


Reply via email to