I wasn’t trying to convince you, let alone bully you, to change anything in your design. Since you are trying to convince us to change something in ours, I told you what kind of information we’d need that would clearly demonstrate the problem(s) with the feature as it currently is and when used as recommended, such as performance numbers. I really was trying to help you help us help you actually get something done.
— Ron > On 18 Dec 2024, at 16:48, David Lloyd <david.ll...@redhat.com> wrote: > > On Wed, Dec 18, 2024 at 9:47 AM Ron Pressler <ron.press...@oracle.com> wrote: > Here’s why we find your suggestions/descriptions so difficult to wrap our > heads around: > > Who is "we"? Are you speaking for others, and if so, whom? > > 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". > > -- > - DML • he/him
