#LayerPrimitives (was Re: Proposal: #NonHierarchicalLayers)
David M. Lloyd
david.lloyd at redhat.com
Tue Feb 28 05:10:27 UTC 2017
On 2/27/17 4:47 AM, mark.reinhold at oracle.com wrote:
> The changes you have requested may appear minimal on the surface today.
> The impact of those changes over the long term is, however, likely far
> from minimal, as I have explained. Taking both the immediate and
> long-term consequences of every change into account is fundamental to
> responsible platform stewardship.
You did state that this was the case, but there was never an explanation
as to what the actual long term impact would be and why that impact is
unacceptable. Could you please elaborate on that?
>> We consider these issue inadequately addressed despite being rejected.
>> By JCP procedures, this obligates us to vote "no".
> There is no rule in the JCP that requires you to vote "no" on a JSR if
> the JSR fails to achieve a non-goal.
This is what I'm referring to:
"EC members should vote 'no' if they believe that the Spec Lead or
Maintenance Lead has not adequately addressed all Issues including those
that have been rejected or otherwise closed by the Expert Group."
"Non-goal" is your phrasing, but objectively speaking we're talking
about an issue (or rather, multiple issues) that you have rejected but
we consider inadequately resolved, which is why I think this language
(and the associated spirit) is applicable.
Obviously I'd prefer that we work to resolve the issues. My intention
was to point out that with all further paths for discussion or
compromise closed off, we are stuck without options save one, and that's
not really a position we want to be in.
On a personal note, I want to reiterate that I am very committed to
serving the best interests of the Java ecosystem. In fact I think that
each expert in the group brings a different valuable and valid
perspective. I may use our own projects as an example an laboratory
subject for experimentation, but that does not mean that I am seeking
only to serve our own interests; merely that I find it a convenient way
to explore the boundaries of the specification and find problem areas.
For me it's not too hard to extrapolate these issues to other libraries
and existing use cases, nor to see the potential value in the
corresponding capabilities for new use cases.
More information about the jpms-spec-experts