<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I think I've calmed down now. Now let me calmly sort out the issues in our dispute:</div><div dir="ltr"><br></div><div dir="ltr">1. You classify the ability to break integrity as a "superpower", and use the problems that some superpowers </div><div dir="ltr">bring to prove that all superpowers should be limited. I don't agree with this.</div><div dir="ltr">I think that although JNI (and I/O) are also superpowers and can indeed be used to cause trouble in theory, </div><div dir="ltr">they are essentially different from the superpowers that actually cause trouble:</div><div dir="ltr"><br></div><div dir="ltr"> 1. Users have historically preferred pure Java implementations, using JNI almost only when necessary and no replacement.</div><div dir="ltr"> Therefore, even if JNI is marked as "unsafe", it is difficult for users to return to the safe field, so in essence, </div><div dir="ltr"> this will not make more people to enjoy integrity.</div><div dir="ltr"> 2. JNI has been widely used, but it has not actually hindered JDK development by being abused to break integrity.</div><div dir="ltr"><br></div><div dir="ltr">I can understand the point of JPMS, but for the reasons above, the benefits of restricting JNI are far less than the benefits of JPMS.<br></div><div dir="ltr">So I don't think "we have tasted the benefits of restricting some superpowers in the past" is a sufficient reason to continue to restrict other superpowers,<br></div><div dir="ltr">we need more practical reasons.<br></div><div dir="ltr"><br></div><div dir="ltr">2. You're emphasizing that there is an "end user" independent of the developer, not even the author of the main module, which confuses me.</div><div dir="ltr">In my experience, the developer of the main module and the "end user" of the packaged program are often the same person/group of people.</div><div dir="ltr">I don't understand why it is necessary to distinguish between the two identities.<br></div><div dir="ltr">If you think it is necessary to distinguish between the two identities, then I think that no matter which identity I am, I find your proposal unappealing and causing trouble:</div><div dir="ltr"><br></div><div dir="ltr"> * When I'm a developer, I consider it my obligation to provide a program with integrity that won't crash.</div><div dir="ltr"> I take it for granted, since I'm the one fixing the bugs. Whether it's a JVM crash or a code logic error, it's all my responsibility.</div><div dir="ltr"> I don't know what good this proposal would do for me.<br></div><div dir="ltr"> * When I am the "end user". Ummm, I don't even know what my role is on the team. Leader? Reviewer? Build script writer? O&M Personnel?</div><div dir="ltr"> Well, whatever I am, I'm not happy with the proposal. Why do I get this list of modules from a developer and then ask me to write it again?</div><div dir="ltr"> Obviously, I don't have permission to modify this list. If I modify it, the program will crash at random moments.</div><div dir="ltr"> If I want to review it, then it’s fine if the developer writes it and I am responsible for reviewing it. Why should I write it again?</div><div dir="ltr"> I think this will just lead to more crashes due to incorrect configuration.</div><div dir="ltr"><br></div><div dir="ltr">3. Why should end users care about low-level libraries?</div><div dir="ltr">You said this:<br></div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And if you think that’s the worst of it, well, get a load of this. Some serialization libraries, say, those that can deserialise JSON, need to set private (perhaps even final) fields and instantiate objects without calling a constructor. This, of course, requires breaking access control, the invariant that supports all others. So they use a low-level library with superpowers that break access control. So far, everyone has the best intentions. However, the JSON library deals with input that arrives to the application from the outside world, and that input determines which fields it sets and which objects it instantiates without a constructor. A vulnerability in that innocent library can direct its action toward critical JDK classes, and because the operation is done by using a super-powered low-level library, there are no longer any access checks in its way. So, everyone here is well meaning — the application and both libraries; the vulnerability is not in the super-powered library. But now a vulnerability in one library can have a catastrophic effect because there is some transitive dependency with superpowers.<br></blockquote><div><br></div><div>You are right, the error may occur due to misuse of low-level libraries by high-level libraries. So shouldn't we care more about high-level libraries?</div><div>Low-level libraries may not have any bugs, and focusing on it may be a waste of time. So why should end users care about these low-level libraries?<br></div><div><br></div><div>4. I'm surprised and puzzled by your negative attitude towards feedback.</div><div dir="ltr"> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Now I’d like to say something general about feedback. Java users demand things that are contradictory; it is simply impossible to satisfy them all. Our job is to take into account those contradictory demands and find a path that provides the most value for the least cost when integrated over the ecosystem as a whole. Obviously, no matter what we do or don’t do, some portion of users will be negatively affected and they’ll have a negative opinion of some change or lack thereof. Such opinions are inescapable, but also unhelpful. Obviously some people weren’t happy when applications broke when migrating from 8 to 9 because Java didn’t have integrity by default, while others aren’t happy that integrity by default requires them to add a flag when they want to selectively give up on integrity. Similarly, I hope it goes without saying that the time and money that went into designing and developing the features that allow us to achieve integrity by default in the hopefully no-so-distant-future, by people with cumulative centuries of work on OpenJDK behind them, represents a significant amount of thinking.<br></blockquote><div dir="ltr"><br></div><div dir="ltr">Yes, there are always supporters and opponents of a proposal, so the objections don’t matter? <br></div><div dir="ltr">Objection implies an opinion: The status quo is better than your proposal. Therefore, they don't necessarily have to provide their own solutions.</div><div dir="ltr"><br></div><div dir="ltr">I did a survey, and while it wasn't extensive, it had a fairly high percentage of negative feedback. This shows that there are indeed many people who are dissatisfied with this,<br></div><div dir="ltr">so I hope you have a stronger case for this proposal. But up to now, I think the reasons you gave are very insufficient. As I mentioned earlier:<br></div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So I don't think "we have tasted the benefits of restricting some superpowers in the past" is a sufficient reason to continue to restrict other superpowers, we need more practical reasons.<br></blockquote><div> </div><div dir="ltr">Also, I've given my proposal many times before (based on module-info), but you are just emphasizing that even the "main module author" is not the "end user".<br></div><div dir="ltr">I don't think this is a reliable reason.<br></div><div dir="ltr"><br></div><div dir="ltr">Glavo</div><div dir="ltr"><br></div><div dir="ltr"><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 2, 2023 at 5:49 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 2 Sep 2023, at 08:06, Simon Nash <<a href="mailto:simon@cjnash.com" target="_blank">simon@cjnash.com</a>> wrote:<br>
> <br>
> As I pointed out in my earlier message, although the end user of the application does not need to specify the flag, they do see the scary warning written to stderr when the flag is not present. This will happen when an a older version of an application that uses JNI is run on a newer version of the JDK.<br>
<br>
They do not need to see the flag even if the flag is there. We’re talking about flags passed to the JVM, not to the application launcher. Also, all JVM flags can, as always, be put in configuration @files; there’s no need to actually type them on the command line.<br>
<br>
> <br>
> This will scare these end users and is likely to reinforce the incorrect perception that Java is unsafe and Java-based applications should be avoided.<br>
<br>
Java has been issuing warnings like this multiple times over the past five years. Another one was just added in JDK 21. This is the standard practice in Java to prepare for future changes.<br>
<br>
— Ron<br>
<br>
</blockquote></div></div>