Inconsistency with service loading by layer or by class loader

[Brian Goetz]

I'm sorry, David, but this response crosses a line, and this kind of 
interaction is not OK.   Ron is doing what any responsible architect 
would do -- trying to understand the problem that you think you are 
solving.  (If you think this is unnecessary, then you have a deep 
misunderstanding of how the JDK is evolved, and perhaps what you need to 
hear is more "philosophy", not less.)   But more importantly, suggesting 
Ron has no "standing" to speak for the integrity of the JDK is 
incorrect, and the words you've chosen are simply out of line.  He is 
asking the sensible "what problem are you really trying to solve here" 
questions that Mark, or I, or Paul, or Alan, or any of us would be 
asking (and if anything, asking them more patiently.)  Characterizing 
responsible stewardship as "bullying" is simply not OK.

You certainly have the right to take your ball and go home if you like 
-- but then you actually have to _go home_.  It's pretty clear, reading 
between the lines, that no one is compelled by the arguments you've made 
for these changes so far, despite how voluminously you've tried to make 
them.  I think it's time to move on.



> In any event, I'm not going to respond to this argument, and I'll tell you
> why. It's a bad-faith argument, repeating points I have already responded
> to, and I find your attitude to be dogmatic and offensive. I don't need to
> further justify our use case to you personally. I have explained myself
> more than adequately; if you actually cared to understand our use case, I
> believe that your line of questioning would be very different. Our products
> make good use of this effective and simple design and have done so since
> the days of Java 6. The platform's module system is in fact already 95%
> compatible with our design (not by accident), lacking literally two methods
> that would bring us the rest of the way towards allowing our design to use
> platform modules. You still seem uninterested in actually understanding our
> motivation for using modules, because you keep trying to tell me what our
> motivation is instead of listening to what I have been telling you. But
> regardless, none of this warrants a protracted philosophical argument.
> Nothing I propose requires a reimagining of the principles of the JPMS. You
> are certainly not anywhere near successfully bullying me into believing
> that I should abandon our well-proven implementation design. Your position
> within Oracle, and even your work on virtual threads, as significant as it
> may be, certainly does not suddenly make you the arbitrator of the valid
> use of this or any other part of the JDK. We have plenty of OpenJDK
> committers and authors here at Red Hat too, in fact, and we too have made
> contributions of worth.
>
> As I said before, philosophy and principles may inform a specification, but
> in the end, if the specification allows our use case then it is by
> definition valid, until/unless that specification is changed - for which
> there is a well defined process which I am now utilizing. If you find that
> personally repulsive, I am sorry to say that is not in any way my problem.
> If however you have a technical argument pertaining to the proposed change,
> you are more than welcome to present it reasonably and specifically, just
> as Alan (who actually wrote most of this code, by the way) has done.
> I'm sorry if you find this dissatisfying, but I have many responsibilities,
> and if my experience has taught me anything, it's that arguing in this
> manner is not a good use of my time (or anyone's time). As they say, "life
> is short".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241218/401f3fd1/attachment.htm>