<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Volker,<br>
note that the warning is generated once per module.</p>
<p>I think what you want is some kind of "log" mode which, while
slower, might be more helpful to identify all the places which are
performing JNI calls.</p>
<p>That said, even the "log" mode might not detect everything (as it
basically depends on the control flow in your application). So, a
classfile analyzer might be more complete.</p>
<p>If we want to enable different policies for
--enable-native-access (similarly to what's done fo<span style="color: rgb(29, 28, 29); font-family: Slack-Lato,
Slack-Fractions, appleLogo, sans-serif; font-size: 15px;
font-style: normal; font-variant-ligatures: common-ligatures;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: left; text-indent: 0px;
text-transform: none; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; white-space: normal;
background-color: rgb(255, 255, 255); text-decoration-thickness:
initial; text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">r
-illegal-access=permit|deny|warn|debug), we need to split the
current --enable-native-access flag in two:</span></p>
<p><span style="color: rgb(29, 28, 29); font-family: Slack-Lato,
Slack-Fractions, appleLogo, sans-serif; font-size: 15px;
font-style: normal; font-variant-ligatures: common-ligatures;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: left; text-indent: 0px;
text-transform: none; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; white-space: normal;
background-color: rgb(255, 255, 255); text-decoration-thickness:
initial; text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">* a flag to
select the list of modules that are allowed to perform native
access<br>
* a flag to select what should happen when a native access from
a non-allowed module is detected</span></p>
<p><span style="color: rgb(29, 28, 29); font-family: Slack-Lato,
Slack-Fractions, appleLogo, sans-serif; font-size: 15px;
font-style: normal; font-variant-ligatures: common-ligatures;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 2; text-align: left; text-indent: 0px;
text-transform: none; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; white-space: normal;
background-color: rgb(255, 255, 255); text-decoration-thickness:
initial; text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">Cheers<br>
Maurizio<br>
</span></p>
<div class="moz-cite-prefix">On 22/08/2023 14:39, Volker Simonis
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+3eh13meOsRT+hGt1i1LVYCzrb-hhqbteeq5mzpsW3vSGGoFg@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi,
Could the warning be changed to include a stack trace (at least
optional)? I think that can be helpful for bigger applications in
order to identify the reason for why a JNI library was loaded.
Thank you and best regards,
Volker
On Mon, Aug 21, 2023 at 5:42 AM Ron Pressler <a class="moz-txt-link-rfc2396E" href="mailto:ron.pressler@oracle.com"><ron.pressler@oracle.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Hi.
JNI has been part of the Java Platform since JDK 1.1, but it is inherently
unsafe, so we are proposing to restrict the use of JNI in line with the use of
restricted methods in the Foreign Function & Memory (FFM) API [1].
The FFM API, expected to become permanent in JDK 22, has methods for interacting
with native code that are inherently unsafe. To protect the integrity of the
Java Platform [2], use of these methods is restricted. This means that calling
them causes warnings, unless the user enables unsafe native access on the
command line. In a future release, calling them will cause exceptions instead
of warnings.
We propose to align JNI and FFM as follows. Starting in JDK 22, the Java runtime
will give warnings about the use of JNI, unless the user (as for FFM) enables
unsafe native access on the command line. In a future release, using JNI will
cause exceptions instead of warnings.
In other words, our proposal is: In the future, code that uses JNI will run only
if unsafe native access is enabled, and to prepare for that future, JDK 22
should spotlight the use of JNI with warnings. We've published a draft JEP that
explains why using JNI is unsafe and describes the warnings [3].
We recognize that many applications use JNI and will be impacted by this
proposal. It is bound to spark discussion that continues even after the
preparatory warnings in JDK 22. Comments are welcome.
— Ron
[1]: <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/442">https://openjdk.org/jeps/442</a>
[2]: <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8305968">https://openjdk.org/jeps/8305968</a>
[3]: <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8307341">https://openjdk.org/jeps/8307341</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>