RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory
brian.goetz at oracle.com
Mon Jan 21 17:16:41 UTC 2019
> Hi Alan/Brian,
My apologies for having missed this the first time around; messages to lists get swept into folders, and staying on top of many lists is not an exact science.
> I believe I have addressed all outstanding comments on the JEP per se,
> including those made by Alan. Is it now possible for one of you to
> endorse the JEP so it can be submitted?
You don’t actually need my endorsement to Submit a JEP to be a Candidate; all you need is evidence that it’s been socialized on the right list (check) and a reviewer (check). So you’re not blocked on submitting at all.
That said, Candidate is actually supposed to be an early stage in the lifecycle; making something a candidate is essentially a statement that the feature is worth considering. It is not any sort of commitment that the feature meets the high bar for inclusion, or is done — just that it is something that is worth continuing to work on in OpenJDK.
Clearly, you’ve done a lot more than the minimum to meet the Candidate bar. Where I see this JEP at is you’ve iterated on the implementation and the design for a few rounds — and where we’re at now is we’re facing the stewardship questions of exactly what the right way to position this feature in the JDK is. Based on the list discussion so far, it seems like we’ve not yet reached consensus on this, so these discussions can continue, whether the JEP is a Candidate or not.
I concur with Alan and Stuart’s assessment that this is very much a “stop gap” measure. (That’s not a value judgment, either the design of MBB, or your work.) It is clear that MBBs are reaching the end of their design lifetime, and the set of mismatches to the problems people want to solve are growing, and the amount of investment needed to bring MBBs up to the task would be significant. It seems likely a much better long-term solution is Panama, but I agree that Panama is not yet ready to replace MBB, and so some stop-gap is needed to prolong the usefulness of MBBs for long enough for a better solution to emerge. However, Alan’s concern — which I share — is that by expanding the MBB API now, we open ourselves up to increased maintenance costs in the too-near future. Before we settle on an API, we’re going to need to come to consensus on the right tradeoffs here, and I’m not convinced we’ve found this yet. So we’ll keep talking.
> Is there any other impediment to submitting the JEP and proceeding to
> code review?
There do not seem to be impediments to submitting the JEP, but I would call out the assumption that the next stop is code review, and then integration. That seems to want to skip over the far more important “should we / how should we” discussions, which are still in progress.
More information about the core-libs-dev