#LayerPrimitives (was Re: Proposal: #NonHierarchicalLayers)

[Neil Bartlett (Paremus)]

> On 27 Feb 2017, at 10:47, mark.reinhold at oracle.com wrote:
> 
> 2017/2/21 9:05:22 -0800, david.lloyd at redhat.com:
>> Logically a non-goal is not an anti-goal, as I have observed many times
>> in the past as well.  Not setting out to do something is not the same
>> thing as forbidding it from being done
> 
> Of course not.  It was a non-goal to support bidirectional interoperation
> with OSGi.  It turned out that doing so required just a couple of small
> changes, however, so we went ahead and did it.
> 
>>                                      , especially if it is a minimal
>> change.
> 
> 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.
> 
>> 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.
> 
> You can choose to vote "no" anyway, of course, if you decide that it is
> more important to protect your own narrow interests than it is to support
> the broader interests of the entire Java ecosystem.

Mark, I have to call this out as inappropriate. Everything I have seen from David’s and Red Hat’s behaviour suggests that they are working for the broader interests of the Java ecosystem, and that you each disagree merely on how those interests are best served. Accusations of acting from bad motives will cause this forum to become less than civil.

From my perspective I am not clear why the changes under discussion are substantially more risky than those you have already made for OSGi interop. The stated justifications for rejecting #LayerPrimitives make little sense, and I’m concerned that this issue could block (or hinder to the point of impracticability) a fully backwards-compatible OSGi implementation.

Regards,
Neil



> 
> - Mark