#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 mailing list