<div dir="ltr"><div class="gmail_quote">(resending from the proper address)</div><div class="gmail_quote"><br></div><div class="gmail_quote">> JNI is the same; we're not taking it away, but we're helping the user be aware of when a library is putting the integrity of the application at risk, so that they have the ability to make a judgement call on whether they are willing to trust that library.<br></div><div class="gmail_quote"><br>My concern is that this is going to be GDPR cookie banners all over again, or Proposition 65 warnings ("this Java application contains chemicals known to the state of California to cause cancer"). Justifications like "user awareness" and "conscious opt-in" strike me as weak when human factors like alarm fatigue [1] are considered. The JEP states that "the last few years have proven that the vast majority of code does not require breaking encapsulation," and I think that's factual but not truthful: almost all of the real-world JDK8 <i>applications</i> I've seen needed flags like `--add-opens` in order to upgrade to JDK11+, and to the best of my knowledge the use of JNI is also near-universal, at least at my company. Is integrity-by-default still worth doing if *every* real-world Java application requires these flags?<br><br>I suspect the answer is: yes, but not for reasons of informed user consent. Rather, the goal here is to incentivize the ecosystem to reduce its dependence on JNI and other integrity-breaking features, similar to what Windows Vista did by introducing UAC [2]. In fact, the JEP frankly discloses this intention:<br><br>> Because deep dependency trees are common, the chances are high that an application would unknowingly depend on an encapsulation-breaking library. Consequently, if applications had to opt <i>into</i> strong encapsulation, few would be able to do so. The platform must, therefore, exert pressure on the ecosystem to minimize the proliferation of libraries that bypass strong encapsulation by making strong encapsulation opt <i>out</i> rather than opt in.<br><br>I see the long-term wisdom of this, but I also find it a little grating considering that JNI has done a lot to pick up the slack in making many features available to Java developers: Unix domain sockets (pre-JDK16), fast AES-GCM (pre-JDK9), and Intel SHA Extensions (pre-JDK9) come to mind right away. If JNI is going to be <i>de facto</i> deprecated, it's reasonable for Java developers to wonder how their needs will be met without it.<br><br>[1] <a href="https://en.wikipedia.org/wiki/Alarm_fatigue" target="_blank">https://en.wikipedia.org/wiki/Alarm_fatigue</a><br>[2] <a href="https://web.archive.org/web/20080719165816/http://news.cnet.com/Microsoft-Vista-feature-designed-to-annoy-users/2100-1016_3-6237191.html" target="_blank">https://web.archive.org/web/20080719165816/http://news.cnet.com/Microsoft-Vista-feature-designed-to-annoy-users/2100-1016_3-6237191.html</a><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote><br>On Mon, Aug 28, 2023 at 9:39 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>I think you have a serious misunderstanding of what is being proposed<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>here.  Nobody is taking away JNI.  What is being taken away is the<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>ability to bury the use of JNI in a library where the user is unaware of<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>it.  By "user" here, I mean the person putting together a Java<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>application from a group of modules and JARs -- sometimes called the<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>"application assembler."  This user has a right to know what their<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>application is doing.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>When we started to enforce the accessibility model in Java 9, we didn't<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>take away the ability to do deep reflection, we took away the ability to<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>do so _without the user knowing_.  The reason that the various<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>`--add-opens` are specified on the command line is so that the user has<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>a chance to consent to relaxed integrity.  JNI is the same; we're not<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>taking it away, but we're helping the user be aware of when a library is<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>putting the integrity of the application at risk, so that they have the<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>ability to make a judgement call on whether they are willing to trust<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>that library.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>On 8/28/2023 11:37 AM, Constantin Christoph wrote:<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>><br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> JNI is a fundamental part of the java ecosystem, and it shouldn't be<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> restricted in a manner like this. It's a powerful, useful tool, and<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> should be treated like that. Developers should have that option freely<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>> available.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
</blockquote></div>
</blockquote></div></div>