Re: Accessible Flight-Tracker?
FlightView Elite. Alan Lemly Sent from my iPhoneOn May 19, 2024, at 3:09 PM, Mohammad Fazil wrote: Hi, Group. I am looking for an accessible flight-tracker for iPhone, any recommendations? Thanks! -- The following information is important for all members of the V iPhone list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your V iPhone list moderator is Mark Taylor. Mark can be reached at: mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/viphone@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "VIPhone" group. To unsubscribe from this group and stop receiving emails from it, send an email to viphone+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/viphone/DS7PR20MB41598A3F1D5F14E3F2805C55C9E82%40DS7PR20MB4159.namprd20.prod.outlook.com. -- The following information is important for all members of the V iPhone list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your V iPhone list moderator is Mark Taylor. Mark can be reached at: mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/viphone@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "VIPhone" group. To unsubscribe from this group and stop receiving emails from it, send an email to viphone+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/viphone/06C08AF8-A47C-472A-92F4-4F123FC072E7%40gmail.com.
Re: [PATCH 1/6] drm/bridge: analogix: remove unused struct 'bridge_init'
* Dmitry Baryshkov (dmitry.barysh...@linaro.org) wrote:
> On Sat, May 18, 2024 at 12:24:27AM +0100, li...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > 'bridge_init' is unused, I think following:
> > commit 6a1688ae8794 ("drm/bridge: ptn3460: Convert to I2C driver model")
> > (which is where a git --follow finds it)
> > Remove it.
>
> Please rephrase the commit message following guidelines in
> Documentation/process. Use Fixes tags if suitable.
I specifically don't want to use Fixes in these set because
there's no need for someone to backport this to older
kernels that use the original, and many backporters
use 'Fixes' as an automated means to find stuff they should
backport.
Other than that, is there something specific you think I've
missed?
(I'm also purposely being less certain here, because --follow
is showing it in a ptn3460 and I don't quite follow
why that changes it here).
Dave
>
> >
> > Build tested.
> >
> > Signed-off-by: Dr. David Alan Gilbert
> > ---
> > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > index df9370e0ff23..1e03f3525a92 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -36,11 +36,6 @@
> >
> > static const bool verify_fast_training;
> >
> > -struct bridge_init {
> > - struct i2c_client *client;
> > - struct device_node *node;
> > -};
> > -
> > static int analogix_dp_init_dp(struct analogix_dp_device *dp)
> > {
> > int ret;
> > --
> > 2.45.1
> >
>
> --
> With best wishes
> Dmitry
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
git: 4f77144279f2 - main - arm64 pmap: eliminate a redundant variable
The branch main has been updated by alc:
URL:
https://cgit.FreeBSD.org/src/commit/?id=4f77144279f210ce65d77c13470c6363c3ce3c57
commit 4f77144279f210ce65d77c13470c6363c3ce3c57
Author: Alan Cox
AuthorDate: 2024-05-19 19:22:53 +
Commit: Alan Cox
CommitDate: 2024-05-19 19:33:19 +
arm64 pmap: eliminate a redundant variable
Moreover, if we attempt an L2 promotion on the kernel pmap from
pmap_enter_quick_locked(), this change eliminates the recomputation of
the L2 entry's address.
MFC after: 1 week
---
sys/arm64/arm64/pmap.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
index a6056a5edfc2..269513589d78 100644
--- a/sys/arm64/arm64/pmap.c
+++ b/sys/arm64/arm64/pmap.c
@@ -5848,7 +5848,6 @@ static vm_page_t
pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va, vm_page_t m,
vm_prot_t prot, vm_page_t mpte, struct rwlock **lockp)
{
- pd_entry_t *pde;
pt_entry_t *l1, *l2, *l3, l3_val;
vm_paddr_t pa;
int lvl;
@@ -5913,13 +5912,13 @@ pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va,
vm_page_t m,
l3 = [pmap_l3_index(va)];
} else {
mpte = NULL;
- pde = pmap_pde(kernel_pmap, va, );
- KASSERT(pde != NULL,
+ l2 = pmap_pde(kernel_pmap, va, );
+ KASSERT(l2 != NULL,
("pmap_enter_quick_locked: Invalid page entry, va: 0x%lx",
va));
KASSERT(lvl == 2,
("pmap_enter_quick_locked: Invalid level %d", lvl));
- l3 = pmap_l2_to_l3(pde, va);
+ l3 = pmap_l2_to_l3(l2, va);
}
/*
git: 4f77144279f2 - main - arm64 pmap: eliminate a redundant variable
The branch main has been updated by alc:
URL:
https://cgit.FreeBSD.org/src/commit/?id=4f77144279f210ce65d77c13470c6363c3ce3c57
commit 4f77144279f210ce65d77c13470c6363c3ce3c57
Author: Alan Cox
AuthorDate: 2024-05-19 19:22:53 +
Commit: Alan Cox
CommitDate: 2024-05-19 19:33:19 +
arm64 pmap: eliminate a redundant variable
Moreover, if we attempt an L2 promotion on the kernel pmap from
pmap_enter_quick_locked(), this change eliminates the recomputation of
the L2 entry's address.
MFC after: 1 week
---
sys/arm64/arm64/pmap.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
index a6056a5edfc2..269513589d78 100644
--- a/sys/arm64/arm64/pmap.c
+++ b/sys/arm64/arm64/pmap.c
@@ -5848,7 +5848,6 @@ static vm_page_t
pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va, vm_page_t m,
vm_prot_t prot, vm_page_t mpte, struct rwlock **lockp)
{
- pd_entry_t *pde;
pt_entry_t *l1, *l2, *l3, l3_val;
vm_paddr_t pa;
int lvl;
@@ -5913,13 +5912,13 @@ pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va,
vm_page_t m,
l3 = [pmap_l3_index(va)];
} else {
mpte = NULL;
- pde = pmap_pde(kernel_pmap, va, );
- KASSERT(pde != NULL,
+ l2 = pmap_pde(kernel_pmap, va, );
+ KASSERT(l2 != NULL,
("pmap_enter_quick_locked: Invalid page entry, va: 0x%lx",
va));
KASSERT(lvl == 2,
("pmap_enter_quick_locked: Invalid level %d", lvl));
- l3 = pmap_l2_to_l3(pde, va);
+ l3 = pmap_l2_to_l3(l2, va);
}
/*
[MOPO] Tcm
Last night in double feature discussion with Spielberg they were supposed to show 40 guns with Stanwyck but mistakenly showed jewel thief ..wonder technically how that happens ..these are all pre recorded I would imagine? Visit the MoPo Mailing List Web Site at www.filmfan.com ___ How to UNSUBSCRIBE from the MoPo Mailing List Send a message addressed to: lists...@listserv.american.edu In the BODY of your message type: SIGNOFF MOPO-L The author of this message is solely responsible for its content.
Re: RFR: 8332071: Convert package.html files in `java.management.rmi` to package-info.java
On Thu, 16 May 2024 10:39:43 GMT, Nizar Benalla wrote: > Please review this change. I converted the `package.html` file to > `package-info.java`, because `javac` cannot recognize `package.html`. > I already brought this up [in the mailing > list](https://mail.openjdk.org/pipermail/serviceability-dev/2024-May/055650.html). > The conversion was done in-place, only renaming it in git. > > I also added a couple of `@since` tags, with only 2 changes I don't want to > split these two fixes into separate PRs. > `CREDENTIALS_FILTER_PATTERN` and `SERIAL_FILTER_PATTERN` were first added in > https://bugs.openjdk.org/browse/JDK-8187556 src/java.management.rmi/share/classes/javax/management/remote/rmi/package-info.java line 26: > 24: */ > 25: > 26: /** I assume you'll need to prepend each line with `*` too, which has the side effect of making it appear that every line is changed but I think we just need to get over that. - PR Review Comment: https://git.openjdk.org/jdk/pull/19263#discussion_r1606084149
git: 3cc1b35bc1bd - main - vfs_getopt(9): fix typo
The branch main has been updated by asomers: URL: https://cgit.FreeBSD.org/src/commit/?id=3cc1b35bc1bdcdee279b3ee7d0e0946b684df898 commit 3cc1b35bc1bdcdee279b3ee7d0e0946b684df898 Author: Alan Somers AuthorDate: 2024-05-19 15:49:03 + Commit: Alan Somers CommitDate: 2024-05-19 15:49:03 + vfs_getopt(9): fix typo [skip ci] Reported by:Claudiu MFC after: 2 weeks --- share/man/man9/vfs_getopt.9 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/share/man/man9/vfs_getopt.9 b/share/man/man9/vfs_getopt.9 index 0e68655f540f..ff0f027314c7 100644 --- a/share/man/man9/vfs_getopt.9 +++ b/share/man/man9/vfs_getopt.9 @@ -24,7 +24,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH .\" DAMAGE. .\" -.Dd July 31, 2011 +.Dd May 19, 2024 .Dt VFS_GETOPT 9 .Os .Sh NAME @@ -46,7 +46,7 @@ .Fa "struct vfsoptlist *opts" "const char *name" "void **buf" "int *len" .Fc .Ft "char *" -.Fn vfs_getops "struct vfsoptlist *opts" "const char *name" "int *error" +.Fn vfs_getopts "struct vfsoptlist *opts" "const char *name" "int *error" .Ft int .Fo vfs_flagopt .Fa "struct vfsoptlist *opts" "const char *name" "uint64_t *flags" "uint64_t flag" @@ -177,7 +177,7 @@ function returns 0 if the option was found; otherwise, is returned. .Pp The -.Fn vfs_getops +.Fn vfs_getopts function returns the specified option if it is found, and is .Dv NUL terminated.
git: 3cc1b35bc1bd - main - vfs_getopt(9): fix typo
The branch main has been updated by asomers: URL: https://cgit.FreeBSD.org/src/commit/?id=3cc1b35bc1bdcdee279b3ee7d0e0946b684df898 commit 3cc1b35bc1bdcdee279b3ee7d0e0946b684df898 Author: Alan Somers AuthorDate: 2024-05-19 15:49:03 + Commit: Alan Somers CommitDate: 2024-05-19 15:49:03 + vfs_getopt(9): fix typo [skip ci] Reported by:Claudiu MFC after: 2 weeks --- share/man/man9/vfs_getopt.9 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/share/man/man9/vfs_getopt.9 b/share/man/man9/vfs_getopt.9 index 0e68655f540f..ff0f027314c7 100644 --- a/share/man/man9/vfs_getopt.9 +++ b/share/man/man9/vfs_getopt.9 @@ -24,7 +24,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH .\" DAMAGE. .\" -.Dd July 31, 2011 +.Dd May 19, 2024 .Dt VFS_GETOPT 9 .Os .Sh NAME @@ -46,7 +46,7 @@ .Fa "struct vfsoptlist *opts" "const char *name" "void **buf" "int *len" .Fc .Ft "char *" -.Fn vfs_getops "struct vfsoptlist *opts" "const char *name" "int *error" +.Fn vfs_getopts "struct vfsoptlist *opts" "const char *name" "int *error" .Ft int .Fo vfs_flagopt .Fa "struct vfsoptlist *opts" "const char *name" "uint64_t *flags" "uint64_t flag" @@ -177,7 +177,7 @@ function returns 0 if the option was found; otherwise, is returned. .Pp The -.Fn vfs_getops +.Fn vfs_getopts function returns the specified option if it is found, and is .Dv NUL terminated.
Re: [Article] NuttX on Sophgo SG2000 RISC-V SoC (Milk-V Duo S SBC)
Kudos Lup! Fantastic work! And nice board to run NuttX On Sat, May 18, 2024 at 7:50 PM Lee, Lup Yuen wrote: > Soon we’ll see many new 64-bit RISC-V SBCs based on the Sophgo SG2000 > RISC-V SoC. Will they boot NuttX? Let’s find out… > > (1) We boot Linux on Milk-V Duo S (with SG2000) > > (2) Peek inside SG2000 Linux and observe how it boots > > (3) Then we take NuttX for RISC-V (Ox64 BL808) > > (4) Tweak NuttX Kernel to boot on SG2000 > > (5) Fix the (undocumented) Interrupt Controller > > (6) And Milk-V Duo S boots to a fully-functional NuttX Shell > > (7) Something strangely satisfying about NuttX on RISC-V… We finished the > port in Only 10 Days > > Here's how: https://lupyuen.codeberg.page/articles/sg2000.html > > Lup >
Re: RFR: 8332181: Deprecate for removal the java.net.MulticastSocket.setTTL/getTTL and the 2-arg send methods [v2]
On Fri, 17 May 2024 11:50:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in that issue these methods have been deprecated since Java 1.2 and
>> 1.4 days. They currently have replacement methods (noted in their javadoc)
>> which have been in use for several releases. This commit updates these
>> deprecated methods to deprecated for removal, to allow for their removal in
>> a future release.
>>
>> No new tests have been added and existing tests in tier1, tier2 and tier3
>> continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the last revision:
>
> also add forRemoval in internal classes
I think DatagramSocketImpl.getTTL/setTTL will need to be deprecated for removal
at the same time.
Also I assume @Deprecated can be dropped from DatagramSocketAdaptor and
NetMulticastSocket, they just override or call the deprecated methods so should
only need `@SuppressWarnings("removal")`.
-
PR Comment: https://git.openjdk.org/jdk/pull/19242#issuecomment-2119261576
Re: RFR: 8315767: InetAddress: constructing objects from BSD literal addresses [v9]
On Fri, 17 May 2024 10:42:44 GMT, Alan Bateman wrote: >> Sergey Chernyshev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update src/java.base/share/classes/java/net/Inet4Address.java >> >> Co-authored-by: Daniel Fuchs <67001856+df...@users.noreply.github.com> > > I read through the API docs in the latest revision (664fccb1) and it looks > very good. The new method is not easily discovered, which is okay as it's > very much a method for experts, I see wonder if we should put a `@see` in > InetAddress.ofLiteral. > Thanks @AlanBateman for your note. There's a link to `ofPosixLiteral` from > the class level doc. I didn't want to touch `ofLiteral` as it already has the > link to the #format subtitle in the class doc I think you may have mis-read my comment. I think we need to add `@see InetAddress4#ofPosixLiteral(String)` to InetAddress.ofLiteral, not Inet4Address.ofLiteral. The reason is that methods defined by Inet4Address are not very discoverable and there is no reference to ofPosixLiteral in InetAddress's class description or anywhere else. - PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2119257287
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 18/05/2024 19:12, Piergiorgio Sartor via Python-list wrote: >> So venvs make managing all that pretty convenient. Dunno why everybody's >> so down on venvs... Not so much down on them, they are just one extra step that's mostly not needed(in my use case) > Only people which are *not* using python... :-) > > In my experience, venvs is the only possible > way to use python properly. Well, I've been using Python since 1998 on Linux, Windows and MacOS and have yet to find a use for a venv. I've played with them when they first came out but haven't actually found a scenario where I've thought "I need a venv for that!" But then I'm a sole user, I have 3 or 4 projects going but only me working on them. I only have 2 Python versions at any time and the OS handles that just fine without any venvs. > The dependency nightmare created by python, pip > and all the rest cannot be resolved otherwise. I've honestly never experienced this "nightmare". I install stuff and it just works. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
git: 3bb5428ad643 - main - rc.conf.5: remove obsolete advice about kld_list
The branch main has been updated by asomers: URL: https://cgit.FreeBSD.org/src/commit/?id=3bb5428ad643e38dd755c8d66c8ac2ae8f7575b5 commit 3bb5428ad643e38dd755c8d66c8ac2ae8f7575b5 Author: Alan Somers AuthorDate: 2024-05-18 14:25:10 + Commit: Alan Somers CommitDate: 2024-05-18 15:51:15 + rc.conf.5: remove obsolete advice about kld_list Loading modules via kld_list is no longer substantially faster than via loader.conf. [skip ci] MFC after: 2 weeks Reviewed by:imp Differential Revision: https://reviews.freebsd.org/D45242 --- share/man/man5/rc.conf.5 | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/share/man/man5/rc.conf.5 b/share/man/man5/rc.conf.5 index 68d8dade2c6d..51a48341be60 100644 --- a/share/man/man5/rc.conf.5 +++ b/share/man/man5/rc.conf.5 @@ -22,7 +22,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.Dd May 4, 2024 +.Dd May 18, 2024 .Dt RC.CONF 5 .Os .Sh NAME @@ -334,10 +334,6 @@ A whitespace-separated list of kernel modules to load right after the local disks are mounted, without any .Pa .ko extension or path. -Loading modules at this point in the boot process is -much faster than doing it via -.Pa /boot/loader.conf -for those modules not necessary for mounting local disks. .It Va kldxref_enable .Pq Vt bool Set to
git: 3bb5428ad643 - main - rc.conf.5: remove obsolete advice about kld_list
The branch main has been updated by asomers: URL: https://cgit.FreeBSD.org/src/commit/?id=3bb5428ad643e38dd755c8d66c8ac2ae8f7575b5 commit 3bb5428ad643e38dd755c8d66c8ac2ae8f7575b5 Author: Alan Somers AuthorDate: 2024-05-18 14:25:10 + Commit: Alan Somers CommitDate: 2024-05-18 15:51:15 + rc.conf.5: remove obsolete advice about kld_list Loading modules via kld_list is no longer substantially faster than via loader.conf. [skip ci] MFC after: 2 weeks Reviewed by:imp Differential Revision: https://reviews.freebsd.org/D45242 --- share/man/man5/rc.conf.5 | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/share/man/man5/rc.conf.5 b/share/man/man5/rc.conf.5 index 68d8dade2c6d..51a48341be60 100644 --- a/share/man/man5/rc.conf.5 +++ b/share/man/man5/rc.conf.5 @@ -22,7 +22,7 @@ .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.Dd May 4, 2024 +.Dd May 18, 2024 .Dt RC.CONF 5 .Os .Sh NAME @@ -334,10 +334,6 @@ A whitespace-separated list of kernel modules to load right after the local disks are mounted, without any .Pa .ko extension or path. -Loading modules at this point in the boot process is -much faster than doing it via -.Pa /boot/loader.conf -for those modules not necessary for mounting local disks. .It Va kldxref_enable .Pq Vt bool Set to
Re: Build fail in mariadb on fedora 40
* Julien Nabet (serval2...@yahoo.fr) wrote:
> On 17/05/2024 15:47, Dr. David Alan Gilbert wrote:
> > Hi,
> >I'm getting:
> >
> > workdir/UnpackedTarball/mariadb-connector-c/libmariadb/ma_client_plugin.c:87:207:
> > error: initialization of ‘struct st_mysql_client_plugin *’ from
> > incompatible pointer type ‘struct st_mysql_client_plugin_AUTHENTICATION *’
> > [-Wincompatible-pointer-types]
> > 87 |(struct st_mysql_client_plugin *)_socket_client_plugin,
> > (struct st_mysql_client_plugin *)_sha2_password_client_plugin,
> > (struct st_mysql_client_plugin *)_native_password_client_plugin,
> > (struct st_mysql_client_plugin_AUTHENTICATION
> > *)_gssapi_client_client_plugin,
> >|
> >
> >^
> > /discs/fast/core/workdir/UnpackedTarball/mariadb-connector-c/libmariadb/ma_client_plugin.c:87:207:
> > note: (near initialization for ‘mysql_client_builtins[3]’)
> > make[1]: *** [/discs/fast/core/solenv/gbuild/LinkTarget.mk:366:
> > /discs/fast/core/workdir/GenCObject/UnpackedTarball/mariadb-connector-c/libmariadb/ma_client_plugin.o]
> > Error 1
> > make[1]: *** Waiting for unfinished jobs
> > make: *** [Makefile:294: build] Error 2
> >
> > Host: Fedora 40, x86-64
> > configured with:
> > ./configure --srcdir=/discs/fast/core --enable-option-checking=fatal
> > --enable-debug
> >
> > using --with-system-mariadb fixed it.
>
> Hello David,
Hi Julien,
Thanks for the reply.
> Sorry, I don't know why you encounter this :-(
It looks like others started hitting it; see:
https://gerrit.libreoffice.org/c/core/+/167806
(I believe as a windows user)
> If it can help, here's the content of my autogen.input:
>
> CC=clang
> CXX=clang++
Hmm I'm using gcc instead, but I don't see how the cast
would be valid:
UnpackedTarball/mariadb-connector-c/include/mysql/client_plugin.h has:
#include
struct st_mysql_client_plugin_AUTHENTICATION
{
MYSQL_CLIENT_PLUGIN_HEADER
int (*authenticate_user)(MYSQL_PLUGIN_VIO *vio, struct st_mysql *mysql);
};
although, hmm, that header also defines:
#define mysql_declare_client_plugin(X) \
struct st_mysql_client_plugin_ ## X\
_mysql_client_plugin_declaration_ = { \
MYSQL_CLIENT_ ## X ## _PLUGIN,\
MYSQL_CLIENT_ ## X ## _PLUGIN_INTERFACE_VERSION,
#define mysql_end_client_plugin }
which is curiously different from the system
/usr/include/mysql/server/mysql/client_plugin.h
#define mysql_declare_client_plugin(X) \
C_MODE_START MYSQL_PLUGIN_EXPORT_C \
struct st_mysql_client_plugin_ ## X\
_mysql_client_plugin_declaration_ = { \
MYSQL_CLIENT_ ## X ## _PLUGIN,\
MYSQL_CLIENT_ ## X ## _PLUGIN_INTERFACE_VERSION,
#define mysql_end_client_plugin }; C_MODE_END
so those C_MODE_START/END make me think someone is doing something
funky with the compiler anyway.
Dave
> --enable-ld=lld
> --enable-online-update
> --enable-dbgutil
> --enable-evolution2
> --enable-gtk4
> --enable-qt5
> --enable-kf5
> --enable-gtk3-kde5
> --enable-skia=debug
> --enable-ext-nlpsolver
> --enable-ext-numbertext
> --enable-ext-wiki-publisher
> --enable-dbus
> --enable-werror
> --enable-dependency-tracking
> --enable-python=fully-internal
> --without-system-mariadb
> --enable-bundle-mariadb
> --enable-symbols
> --enable-avahi
> --enable-eot
> --enable-odk
> --with-lang=en-US de es fr hu it ja nl pt pt-BR ru nb nn
> --with-myspell-dicts
>
> Julien
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [Emc-developers] The Wiki Certificate might have expired
Andy, It works here on my Mac. Alan > Date: Fri, 17 May 2024 23:25:41 +0100 > From: andy pugh > To: EMC developers > Subject: [Emc-developers] The Wiki Certificate might have expired > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > My Mac is really unwilling to visit wiki.linuxcnc.org > > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is designed > for the especial use of mechanical geniuses, daredevils and lunatics." > ? George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: Help with adjustment transaction
On 2024-05-17 23:40, "Robin H. Johnson" writes: > TL;DR: you insert balance assertions when you know the balance based on > some source of truth. Thank you, this is very useful to know. Alan -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ledger-cli/m2r0dzv0t4.fsf%40petitepomme.net. signature.asc Description: PGP signature
[RESULT][VOTE] FLIP-452: Allow Skipping Invocation of Function Calls While Constant-folding
The vote for FLIP-452: Allow Skipping Invocation of Function Calls While Constant-folding [1] has concluded (discussion thread [2]). The vote will be closed [3]. There were 4 approving votes, all binding, and there were no disapprovals: - Stefan Richter (binding) - Timo Walther (binding) - Benchao Li (binding) - Lincoln Lee (binding) Therefore, FLIP-452 was accepted. Thanks for the feedback! -Alan [1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-452%3A+Allow+Skipping+Invocation+of+Function+Calls+While+Constant-folding [2] https://lists.apache.org/thread/ko5ndv5kr87nm011psll2hzzd0nn3ztz [3] https://lists.apache.org/thread/2jdyj5bnj12n385td2lcdtj4fdlogp6j
Re: [PATCH 1/6] drm/bridge: analogix: remove unused struct 'bridge_init'
(oops the patch numbering in these 3 are wrong, they're all independent
patches)
Dave
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> 'bridge_init' is unused, I think following:
> commit 6a1688ae8794 ("drm/bridge: ptn3460: Convert to I2C driver model")
> (which is where a git --follow finds it)
> Remove it.
>
> Build tested.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index df9370e0ff23..1e03f3525a92 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -36,11 +36,6 @@
>
> static const bool verify_fast_training;
>
> -struct bridge_init {
> - struct i2c_client *client;
> - struct device_node *node;
> -};
> -
> static int analogix_dp_init_dp(struct analogix_dp_device *dp)
> {
> int ret;
> --
> 2.45.1
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH] virt: acrn: Remove unusted list 'acrn_irqfd_clients'
* li...@treblig.org (li...@treblig.org) wrote: > From: "Dr. David Alan Gilbert" > > It doesn't look like this was ever used. > > Build tested only. > > Signed-off-by: Dr. David Alan Gilbert Ping > --- > drivers/virt/acrn/irqfd.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/virt/acrn/irqfd.c b/drivers/virt/acrn/irqfd.c > index d4ad211dce7a3..346cf0be4aac7 100644 > --- a/drivers/virt/acrn/irqfd.c > +++ b/drivers/virt/acrn/irqfd.c > @@ -16,8 +16,6 @@ > > #include "acrn_drv.h" > > -static LIST_HEAD(acrn_irqfd_clients); > - > /** > * struct hsm_irqfd - Properties of HSM irqfd > * @vm: Associated VM pointer > -- > 2.45.0 > -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Build fail in mariadb on fedora 40
Hi, I'm getting: workdir/UnpackedTarball/mariadb-connector-c/libmariadb/ma_client_plugin.c:87:207: error: initialization of ‘struct st_mysql_client_plugin *’ from incompatible pointer type ‘struct st_mysql_client_plugin_AUTHENTICATION *’ [-Wincompatible-pointer-types] 87 |(struct st_mysql_client_plugin *)_socket_client_plugin, (struct st_mysql_client_plugin *)_sha2_password_client_plugin, (struct st_mysql_client_plugin *)_native_password_client_plugin, (struct st_mysql_client_plugin_AUTHENTICATION *)_gssapi_client_client_plugin, | ^ /discs/fast/core/workdir/UnpackedTarball/mariadb-connector-c/libmariadb/ma_client_plugin.c:87:207: note: (near initialization for ‘mysql_client_builtins[3]’) make[1]: *** [/discs/fast/core/solenv/gbuild/LinkTarget.mk:366: /discs/fast/core/workdir/GenCObject/UnpackedTarball/mariadb-connector-c/libmariadb/ma_client_plugin.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:294: build] Error 2 Host: Fedora 40, x86-64 configured with: ./configure --srcdir=/discs/fast/core --enable-option-checking=fatal --enable-debug using --with-system-mariadb fixed it. I originally filed this as: https://bugs.documentfoundation.org/show_bug.cgi?id=161141 However Ilmari pointed out that being a build bug it should be here. See the bug for my config.log. (cc'ing Julien since I see they did some stuff around there.) Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \dave @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/
Re: [MOPO] Megalopolis
Now that’s the kind of movie I like to see! > On May 17, 2024, at 2:20 PM, Kirby McDaniel wrote: > > Yes, it was shown at Cannes and elicited a 7 minute standing ovation. > >> On May 17, 2024, at 4:16 PM, Tom Martin >> wrote: >> >> my son thought it sounded good bbut the finance part of Hollywood seems >> like its a lot different then back in teh 70s...i heard sherry redstone was >> talking about mergeing Paramount with Warner br others and doing mega >> deals... iam so removed from it alli have no idea who is who...you would >> think some one would help copolla do his [assion Projecty... Corman just >> passed so theold Gaurd seemsto be leaving.. >> God bless Francis andhope he gets his project out there.. >> >> Best Tom >> Hollywood dream factory® >> since 1977 >> >> >> >> >> On 2024-05-17 16:33, Alan Adler wrote: >>> Hi Tom - >>> I thought it was finished and being presented at Cannes, but Coppola’s >>> been on the bone of this epic project for decades. The reviews so far >>> fluctuate between better than Godfather and Apocolypse Now and a >>> walk-out-of-the theater head-scratcher (shades of 2001’s premiere). >>> The trailer looks very Chris Nolan, but Coppola’s deep emotions >>> running beneath. Can’t wait for it. Nobody makes game changing pix >>> like FFC. >>> Alan >>>> On May 17, 2024, at 1:24 PM, Tom Martin >>>> wrote: >>>> my son said Fr Francis Ford Coppola was is in Cannes trying to raise money >>>> to promot itas its his life passion film I guesss he sold off some of hiis >>>> winereyin calif to raise funds andis tryingto partner with some >>>> entertainment giants to match his 100 million.. >>>> funny how filmmakers and musicians get a personal passion for projects as >>>> wellas inventors.. like Edison >tesla, Walt Disny etc.. >>>> so considering FRancis is inhis 80s?? its a testament to creative people >>>> andhow they keep thinking new ideas.. >>>> I rememberseeing that film that phillip Glass did the soundtrack itwas a >>>> moving work... >>>> and i loved TUCKer he did with George Lucas... great film >>>> I have not seen anything fromthe movie./ bet its Good.. >>>> the content is so oversatuated by netflix, cable and the streaming >>>> i just havea single antenna and onlywatch basic tv channels and >>>> amoverwhelmed by that,,, I dont stream or even get dvds iam givine a whole >>>> case of DVDS to my son i kept one.. >>>> Jurrassic park...that was one ofthe last wow films i saw in 1993 >>>> Tom >>>> Hollywood dream Factory® >>>> since 1977 >>>> On 2024-05-17 11:25, Alan Adler wrote: >>>>> Anyone from Mopolopolis seen Megalopolis? >>>>> Alan >>>>> Sent from my iPhone >>>>> Visit the MoPo Mailing List Web Site at www.filmfan.com >>>>> ___ >>>>>How to UNSUBSCRIBE from the MoPo Mailing List >>>>> Send a message addressed to: lists...@listserv.american.edu >>>>> In the BODY of your message type: SIGNOFF MOPO-L >>>>> The author of this message is solely responsible for its content. >>>> >>>> Visit the MoPo Mailing List Web Site at www.filmfan.com >>>> ___ >>>> How to UNSUBSCRIBE from the MoPo Mailing List >>>> Send a message addressed to: >>>> lists...@listserv.american.edu >>>> In the BODY of your message type: SIGNOFF MOPO-L >>>>The author of this message is solely >>>> responsible for its content. >> >> >> >> Visit the MoPo Mailing List Web Site at www.filmfan.com >> ___ >>How to UNSUBSCRIBE from the MoPo Mailing List >>Send a message addressed to: >> lists...@listserv.american.edu >> In the BODY of your message type: SIGNOFF MOPO-L >> The author of this message is solely >> responsible for its content. > > Visit the MoPo Mailing List Web Site at www.filmfan.com > ___ > How to UNSUBSCRIBE from the MoPo Mailing List > > Send a message addressed to: lists...@listserv.american.edu >In the BODY of your message type: SIGNOFF MOPO-L > >The author of this message is solely responsible for its content. Visit the MoPo Mailing List Web Site at www.filmfan.com ___ How to UNSUBSCRIBE from the MoPo Mailing List Send a message addressed to: lists...@listserv.american.edu In the BODY of your message type: SIGNOFF MOPO-L The author of this message is solely responsible for its content.
Re: [MOPO] Megalopolis
Hi Tom - I thought it was finished and being presented at Cannes, but Coppola’s been on the bone of this epic project for decades. The reviews so far fluctuate between better than Godfather and Apocolypse Now and a walk-out-of-the theater head-scratcher (shades of 2001’s premiere). The trailer looks very Chris Nolan, but Coppola’s deep emotions running beneath. Can’t wait for it. Nobody makes game changing pix like FFC. Alan > On May 17, 2024, at 1:24 PM, Tom Martin > wrote: > > my son said Fr Francis Ford Coppola was is in Cannes trying to raise money to > promot itas its his life passion film I guesss he sold off some of hiis > winereyin calif to raise funds andis tryingto partner with some entertainment > giants to match his 100 million.. > > funny how filmmakers and musicians get a personal passion for projects as > wellas inventors.. like Edison >tesla, Walt Disny etc.. > > so considering FRancis is inhis 80s?? its a testament to creative people > andhow they keep thinking new ideas.. > I rememberseeing that film that phillip Glass did the soundtrack itwas a > moving work... > and i loved TUCKer he did with George Lucas... great film > I have not seen anything fromthe movie./ bet its Good.. > the content is so oversatuated by netflix, cable and the streaming > > i just havea single antenna and onlywatch basic tv channels and amoverwhelmed > by that,,, I dont stream or even get dvds iam givine a whole case of DVDS to > my son i kept one.. > Jurrassic park...that was one ofthe last wow films i saw in 1993 > > > Tom > Hollywood dream Factory® > since 1977 > > > > On 2024-05-17 11:25, Alan Adler wrote: > > > > >> Anyone from Mopolopolis seen Megalopolis? >> Alan >> Sent from my iPhone >> Visit the MoPo Mailing List Web Site at www.filmfan.com >> ___ >> How to UNSUBSCRIBE from the MoPo Mailing List >> Send a message addressed to: lists...@listserv.american.edu >>In the BODY of your message type: SIGNOFF MOPO-L >>The author of this message is solely responsible for its content. > > > >Visit the MoPo Mailing List Web Site at www.filmfan.com > ___ > How to UNSUBSCRIBE from the MoPo Mailing List > Send a message addressed to: > lists...@listserv.american.edu > In the BODY of your message type: SIGNOFF MOPO-L > The author of this message is solely > responsible for its content. Visit the MoPo Mailing List Web Site at www.filmfan.com ___ How to UNSUBSCRIBE from the MoPo Mailing List Send a message addressed to: lists...@listserv.american.edu In the BODY of your message type: SIGNOFF MOPO-L The author of this message is solely responsible for its content.
[agi] Heads up
This is a PSA. Just wanna tell you guys to lock your tray tables in their upright position, make sure your seatbelt is sinched tight and, um, assume the crash position. Yeah, it's time. Silver is at $31.43 which means it is decisively above the red line of $30. Which means the party has started. The pattern the price riggers have established is that their standard market interventions are always done on Wednesdays and emergency adjustments are sometimes done over the weekends. There is a small chance that they will, again, be able to push the price down into the $2X range. If we are still above $30 by midday Monday then consider this signal confirmed. This WILL bring down the entire financial system, all of it. Banks, derivatives, currencies, equities, debt instruments, all of it. Judging from the feel of things, I expect a CBDC to be introduced roughly the first week of June and then fail, along with the government itself, by the end of September. https://silverprice.org/ Times will be tough as changes will be both rapid and dramatic. The chance of a Boogaloo as I was worrying about several years ago is low at this point though a great many people will have severe and irrational emotional reactions that would normally be quite out of charactor for them. Be prepared for this! Yes there are guilty people out there, THEY MUST BE BROUGHT TO TRIAL!!! WE NEED TO DOCUMENT EVERYTHING THAT HAS BEEN DONE TO US, DON'T LET THEM TAKE THEIR SECRETS TO THEIR GRAVES!!! That is the only way we can restore human civilization to a healthy state. YOU will want to run out and lynch every single one of them; don't! We need information a hundred times more than vengance! The pubilic executions can begin the day after we are sure we have found all of the consiprators with none remaining in any position to hurt us again. Once again, I am expecting 4-5 months of very limited food availability -- You can't out-crazy a Democrat. #EggCrisis #BlackWinter White is the new Kulak. Powers are not rights. -- Artificial General Intelligence List: AGI Permalink: https://agi.topicbox.com/groups/agi/T92315ac1d2bf90d9-M03c28320d9d69bcb4e055ca5 Delivery options: https://agi.topicbox.com/groups/agi/subscription
[MOPO] Megalopolis
Anyone from Mopolopolis seen Megalopolis? Alan Sent from my iPhone Visit the MoPo Mailing List Web Site at www.filmfan.com ___ How to UNSUBSCRIBE from the MoPo Mailing List Send a message addressed to: lists...@listserv.american.edu In the BODY of your message type: SIGNOFF MOPO-L The author of this message is solely responsible for its content.
Re: RFR: 8329825: Clarify the value type for java.net.SocketOptions.SO_LINGER [v3]
On Fri, 17 May 2024 08:46:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the last revision:
>
> reword based on Alan's suggestion
src/java.base/share/classes/java/net/SocketOptions.java line 196:
> 194: * Set the value to {@code Boolean.FALSE} or an integer less than
> {@code 0} with
> 195: * {@link #setOption(int, Object)} to disable this option. An
> integer greater than or equal to
> 196: * {@code 0} will enable the option and will represent the linger
> timeout.
In the referenced description is it "linger interval" rather than "linger
timeout" so I think we should use that here too. Otherwise looks okay.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19243#discussion_r1604770162
Re: RFR: 8315767: InetAddress: constructing objects from BSD literal addresses [v9]
On Thu, 16 May 2024 09:12:20 GMT, Sergey Chernyshev wrote: >> There are two distinct approaches to parsing IPv4 literal addresses. One is >> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another >> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` >> allowing octal and hexadecimal forms [2]). The goal of this PR is to provide >> interface to construct InetAddress objects from literal addresses in POSIX >> form, to applications that need to mimic the behavior of `inet_addr` used by >> standard network utilities such as netcat/curl/wget and the majority of web >> browsers. At present time, there's no way to construct `InetAddress` object >> from such literal addresses because the existing APIs such as >> `InetAddress.getByName()`, `InetAddress#ofLiteral()` and >> `Inet4Address#ofLiteral()` will consume an address and successfully parse it >> as decimal, regardless of the octal prefix. Hence, the resulting object will >> point to a different IP address. >> >> Historically `InetAddress.getByName()/.getAllByName()` were the only way to >> convert a literal address into an InetAddress object. `getAllByName()` API >> relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments >> with `strtoul` (accepts octal and hexadecimal bases). >> >> The fallback to `getaddrinfo` is undesirable as it may end up with network >> queries (blocking mode), if `inet_addr` rejects the input literal address. >> The Java standard explicitly says that >> >> "If a literal IP address is supplied, only the validity of the address >> format is checked." >> >> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods >> `.ofLiteral()` to `InetAddress` classes. Although the new API is not >> affected by the `getaddrinfo` fallback issue, it is not sufficient for an >> application that needs to interoperate with external tooling that follows >> POSIX standard. In the current state, `InetAddress#ofLiteral()` and >> `Inet4Address#ofLiteral()` will consume the input literal address and >> (regardless of the octal prefix) parse it as decimal numbers. Hence, it's >> not possible to reliably construct an `InetAddress` object from a literal >> address in POSIX form that would point to the desired host. >> >> It is proposed to extend the factory methods with >> `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses >> in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation >> is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. >> The changes in the original algorithm are as follows: >> >> - `IPAddressUtil#parseB... > > Sergey Chernyshev has updated the pull request incrementally with one > additional commit since the last revision: > > Update src/java.base/share/classes/java/net/Inet4Address.java > > Co-authored-by: Daniel Fuchs <67001856+df...@users.noreply.github.com> I read through the API docs in the latest revision (664fccb1) and it looks very good. The new method is not easily discovered, which is okay as it's very much a method for experts, I see wonder if we should put a `@see` in InetAddress.ofLiteral. - PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2117286151
Re: jmx-dev RFR: 8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation [v3]
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but
>> older JDKs will send such an array. It could accept the array, and only
>> reject/throw if it contains a non-null Subject (i.e. if an attempt to use
>> subject delegation is really happening).
>>
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - add an 'also'
> - typo
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java
line 961:
> 959: * @param delegationSubjects should be {@code null}, but a non-null
> 960: * array is also accepted for compatibility reasons, which must not
> 961: * contain any non-null entries.
The wording is bit unusual for a parameter description. Just wondering if might
be clearer to say "null or an array of null elements" and put add an `@apiNote`
to explain that it allows an array with null elements for compatibility
reasons. What you have is okay too course, I'm just trying to think of another
way to present this odd case.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1604740107
Re: RFR: 8332303: Better JMX interoperability with older JDKs, after removing Subject Delegation [v3]
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
>> In javax/management/remote/rmi/RMIConnectionImpl.java:
>> addNotificationListener rejects a non-null delegationSubjects array, but
>> older JDKs will send such an array. It could accept the array, and only
>> reject/throw if it contains a non-null Subject (i.e. if an attempt to use
>> subject delegation is really happening).
>>
>> Manually testing JConsole, the MBean tab is fully populated and usable.
>
> Kevin Walls has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - add an 'also'
> - typo
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java
line 961:
> 959: * @param delegationSubjects should be {@code null}, but a non-null
> 960: * array is also accepted for compatibility reasons, which must not
> 961: * contain any non-null entries.
The wording is bit unusual for a parameter description. Just wondering if might
be clearer to say "null or an array of null elements" and put add an `@apiNote`
to explain that it allows an array with null elements for compatibility
reasons. What you have is okay too course, I'm just trying to think of another
way to present this odd case.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1604740107
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
This looks good. Just a few minor comments where future maintainers might
appreciate comments that describe parameters.
src/java.base/share/classes/java/lang/Module.java line 332:
> 330: String caller = currentClass != null ?
> currentClass.getName() : "code";
> 331: if (jni) {
> 332: System.err.printf("""
System.err may change in a running VM. It may be that we will need to change
this at some point to use its initial setting. Not suggesting we changing it
now but we might have to re-visit this.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19213#pullrequestreview-2062832385
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604653749
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/ClassLoader.java line 2448:
> 2446: * Invoked in the VM class linking code.
> 2447: */
> 2448: static long findNative(ClassLoader loader, Class clazz, String
> entryName, String javaName) {
I think this is another place where `@param` descriptions would help as it's
not immediately clear that "javaName" is a method name.
src/java.base/share/classes/java/lang/Runtime.java line 39:
> 37:
> 38: import jdk.internal.access.SharedSecrets;
> 39: import jdk.internal.javac.Restricted;
Runtime has been touched for a while so you'll need to bump the copyright year.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604648529
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604650293
Is commons-digester still an active project?
Hi Is commons-digester still an active project? I ask because while it's not in the Attic, the last release (3.2) was in 2011. There are two CVEs in a dependency (CVE-2019-10086 and CVE-2014-0114). Is there going to be a commons-digester with an uplifted version of commons-beanutils? Or is commons-digester destined for the Apache Attic? regards Alan McLachlan ACI Worldwide www.aciworldwide.com<http://www.aciworldwide.com/> [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg]<http://www.aciworldwide.com> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is >> now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted >> methods, even for FFM API calls. In Java 22, the single >> `--enable-native-access` was used both to specify a set of modules for which >> native access should be allowed *and* to specify whether illegal native >> access (that is, native access occurring from a module not specified by >> `--enable-native-access`) should be treated as an error or a warning. More >> specifically, an error is only issued if the `--enable-native-access flag` >> is used at least once. >> >> Here, a new flag is introduced, namely >> `illegal-native-access=allow/warn/deny`, which is used to specify what >> should happen when access to a restricted method and/or functionality is >> found outside the set of modules specified with `--enable-native-access`. >> The default policy is `warn`, but users can select `allow` to suppress the >> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This >> aligns the treatment of restricted methods with other mechanisms, such as >> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for >> `java.lang.foreign`, to reflect the changes in the command line flags >> described above. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Add note on --illegal-native-access default value in the launcher help src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 288: > 286: * throw exception depending on the configuration. > 287: */ > 288: void ensureNativeAccess(Module m, Class owner, String methodName, > Class currentClass, boolean jni); It might be helpful to future maintainers if we put `@param` descriptions for these parameters. I had to re-read Module.enableNativeAccess to remember the difference between the owner class and the current class. - PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604644767
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/foreign/package-info.java line 170:
> 168: * the special value {@code ALL-UNNAMED} can be used). Access to
> restricted methods
> 169: * from modules not listed by that option is deemed illegal.
> Clients can
> 170: * control how illegal access to restricted method is handled, using the
> command line
I assume this should be "to a restricted method is handled" or "to restricted
methods are handled", either would work here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1604637950
Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]
On Mon, 13 May 2024 21:00:10 GMT, Stuart Marks wrote: >>> If an event class is loaded before JFR is started, the event class needs to >>> be retransformed, but if it is loaded later, we can add instrumentation on >>> class load and avoid the retransformation. More happens when an event class >>> is loaded compared to ordinary class load, for example, a startTime field >>> is added. >>> >>> I did a JMH run and the difference between Event::enabled() and a boolean >>> flag was a fraction of nanosecond. >> >> There are instances of FIS/FOS created in initPhase1 for the standard >> streams so loading as few classes and executing as minimal as possible is >> good. RAF will typically be used early too as the zip code opens zip files >> with a RAF. So doing as little as possible is good. > > My main concern here is the addition of clutter (checking two flags, and > creating two levels of nested "impl" methods) at every call site. We may need > to rearrange our internal API for JFR (jdk.internal.events) in order to clean > up the call sites without loading additional classes unnecessarily. > > I think the main performance comparison to make is the impact on startup time > of loading the additional FileReadEvent class. That is, to compare the > startup time of the baseline with code that loads the FileReadEvent class, > with JFR disabled in both cases. I don't know how to do this. Anyway, if > loading of additional classes imposes unacceptable overhead, then that > justifies doing more work to avoid it. That's separate from whether adding > the `jfrTracing` flag as done in this PR is an effective way to do it. I think `if (jfrTracing && FileReadEvent.enabled())` would be more readable as it would avoid calling going through the traceXXX methods when the flag is enabled but the specific event is not enabled. - PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1604627812
Re: RFR: 8331876: JFR: Move file read and write events to java.base [v5]
On Thu, 16 May 2024 12:10:46 GMT, Erik Gahlin wrote: >> Hi, >> >> Could I have a review of a change that moves the jdk.FileRead and >> jdk.FileWrite events to java.base to remove the use of the ASM >> instrumentation. >> >> Testing: jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional > commit since the last revision: > > Remove dependency on JFR for retransformation src/java.base/share/classes/java/io/FileInputStream.java line 65: > 63: /** > 64: * Flag set by jdk.internal.event.JFRTracing to determines if > 65: * file reads should be traced by JFR. s/determines if/indicate if/ - PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1604617070
Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]
On Sun, 12 May 2024 13:35:42 GMT, Erik Gahlin wrote: > I guess it's not 100% safe if the JIT decides to store the read value > elsewhere over several event checks, but it seems unlikely. Event settings > checks (i.e., Event::isEnabled()) have always used plain reads, so it is not > more unreliable than any other event. > > I'm fine with using a volatile too. I used it for the exception events, but I > now think a plain write/read of jfrTracing is safe for all practical purposes. I'd prefer not introduce another volatile read into all these call paths. As you say, the issue has always been there so maybe it's okay for now and it can be examined later. - PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1604619014
Re: RFR: 8329825: Clarify the value type for java.net.SocketOptions.SO_LINGER [v2]
On Fri, 17 May 2024 05:44:29 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the last revision:
>
> reword the javadoc
src/java.base/share/classes/java/net/SocketOptions.java line 197:
> 195: * can be passed to {@link #setOption(int, Object)} to disable this
> option. An integer
> 196: * value {@code >= 0} passed to {@code setOption(int, Object)} will
> enable the option and
> 197: * the value will represent the linger timeout.
I think the wording could be improved a bit with "Set the value to
Boolean.FALSE or an integer less than 0 with setOption to disable this option".
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19243#discussion_r1604554069
Re: Help with adjustment transaction
Hello, On 2024-05-16 22:57, "Robin H. Johnson" writes: > Our bank statements give us the opening and closing balances for each > statement, and I enter those as an assertion of the balance. > > If I have an error somewhere before that, such as a missing transaction, > or a typo; the assertion flags that something is wrong. > > If your bank statements provide a known balance after each transaction, > you can enter that: > > 2009/04/30 * Interest Earned: AccountName > Assets:Bank:AccountName $ 16.14 = $ 19,016.25 > Income:Interest:AccountName > > If your bank statements provide an opening or closing balance to the > statement, > you can use that: > > 2023/06/30 * Balance Assertion: AccountName > Assets:Bank:AccountName $ 0.00 = $ 52,289.96 This looks very useful, but I have trouble understanding how it works with past transactions that are not yet reconciled (i.e., not part of the balance, yet present and before in the file). Are these transactions ignored? If so, the balance will break once they are reconciled in the future, won’t it? Best, Alan -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ledger-cli/m2ikzdx7bv.fsf%40mac-03220211.irisa.fr. signature.asc Description: PGP signature
Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from any more >>> restricted configuration than previous versions such as JDK 22 >> >> Updated 5/16/2024 >> >> Design change: >> The design is changed to include in the JDK two configuration files that are >> the default jaxp.properties and jaxp-strict.properties, instead of three, >> dropping jaxp-compat.properties. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > remove jaxp-compat.properties from the list src/java.xml/share/classes/module-info.java line 443: > 441: * > 442: * > 443: * This file allows deployments to test the more secure/strict behavior, I think it might be better to reduce this paragraph down to just say something like "Deploying with this configuation prevents processors from unknowingly making outbound network connections to fetch DTDs, or process XML that makes use of extension functions." We could say that a future JDK release may use a strict configuration by default but that opens the door to questions as to whether the system property is needed, whether jaxp.propeteries is going away, so maybe better to leave that out for now. - PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604418621
Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from any more >>> restricted configuration than previous versions such as JDK 22 >> >> Updated 5/16/2024 >> >> Design change: >> The design is changed to include in the JDK two configuration files that are >> the default jaxp.properties and jaxp-strict.properties, instead of three, >> dropping jaxp-compat.properties. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > remove jaxp-compat.properties from the list src/java.xml/share/classes/module-info.java line 443: > 441: * > 442: * > 443: * This file allows deployments to test the more secure/strict behavior, I think it might be better to reduce this paragraph down to just say something like "Deploying with this configuation prevents processors from unknowingly making outbound network connections to fetch DTDs, or process XML that makes use of extension functions." We could say that a future JDK release may use a strict configuration by default but that opens the door to questions as to whether the system property is needed, whether jaxp.propeteries is going away, so maybe better to leave that out for now. - PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604418621
Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from any more >>> restricted configuration than previous versions such as JDK 22 >> >> Updated 5/16/2024 >> >> Design change: >> The design is changed to include in the JDK two configuration files that are >> the default jaxp.properties and jaxp-strict.properties, instead of three, >> dropping jaxp-compat.properties. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > remove jaxp-compat.properties from the list src/java.xml/share/conf/jaxp-strict.properties line 9: > 7: # test the more secure/strict behavior, identify issues such as a processor > 8: # unknowingly makes outbound network connections to fetch DTD, or > processes XML > 9: # that relies on extension functions. There isn't a JEP to propose that XML processing be secure by default on the technical roadmap right now so I think this paragraph will need to be tweaked to avoid making any assumptions. I think just say that the file provides the settings for more secure XML processing and drop the text about testing (and "and create your own configuration file for the experiment" from the paragraph below). - PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604405287
Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from any more >>> restricted configuration than previous versions such as JDK 22 >> >> Updated 5/16/2024 >> >> Design change: >> The design is changed to include in the JDK two configuration files that are >> the default jaxp.properties and jaxp-strict.properties, instead of three, >> dropping jaxp-compat.properties. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > remove jaxp-compat.properties from the list src/java.xml/share/conf/jaxp-strict.properties line 9: > 7: # test the more secure/strict behavior, identify issues such as a processor > 8: # unknowingly makes outbound network connections to fetch DTD, or > processes XML > 9: # that relies on extension functions. There isn't a JEP to propose that XML processing be secure by default on the technical roadmap right now so I think this paragraph will need to be tweaked to avoid making any assumptions. I think just say that the file provides the settings for more secure XML processing and drop the text about testing (and "and create your own configuration file for the experiment" from the paragraph below). - PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604405287
Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from any more >>> restricted configuration than previous versions such as JDK 22 >> >> Updated 5/16/2024 >> >> Design change: >> The design is changed to include in the JDK two configuration files that are >> the default jaxp.properties and jaxp-strict.properties, instead of three, >> dropping jaxp-compat.properties. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > remove jaxp-compat.properties from the list make/modules/java.xml/Copy.gmk line 37: > 35: JAXPPROPFILE_TARGET_FILES := $(subst > $(JAXPPROPFILE_SRC_DIR),$(CONF_DST_DIR),$(JAXPPROPFILE_SRCS)) > 36: > 37: $(CONF_DST_DIR)/%: $(JAXPPROPFILE_SRC_DIR)/% The make file changes to copy the properties files look okay but I'm curious about why the naming changes from "XML" to "JAXPPROFILE". - PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604383246
Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]
On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from any more >>> restricted configuration than previous versions such as JDK 22 >> >> Updated 5/16/2024 >> >> Design change: >> The design is changed to include in the JDK two configuration files that are >> the default jaxp.properties and jaxp-strict.properties, instead of three, >> dropping jaxp-compat.properties. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > remove jaxp-compat.properties from the list make/modules/java.xml/Copy.gmk line 37: > 35: JAXPPROPFILE_TARGET_FILES := $(subst > $(JAXPPROPFILE_SRC_DIR),$(CONF_DST_DIR),$(JAXPPROPFILE_SRCS)) > 36: > 37: $(CONF_DST_DIR)/%: $(JAXPPROPFILE_SRC_DIR)/% The make file changes to copy the properties files look okay but I'm curious about why the naming changes from "XML" to "JAXPPROFILE". - PR Review Comment: https://git.openjdk.org/jdk/pull/18831#discussion_r1604383246
Re: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers [v2]
On Fri, 17 May 2024 00:38:07 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmti.xml line 1008: >> >>> 1006: function descriptions. Empty lists, arrays, sequences, etc are >>> 1007: returned as nullptr which is C programming language >>> 1008: null pointer. >> >> Perhaps instead something like >> >> "returned as a null pointer (C NULL or C++ >> nullptr)." >> >> "null pointer" is the generic phrase used in both the C and C++ standards. > > Thank you, Kim. I like this suggestion. Updated now. That part looks okay but I think all the parameters and error descriptions changed by JDK-8324680 will now need to change to use "null" instead of "nullptr". - PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1604344850
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: jmx-dev RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]
On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
>> * binding a JNI `native` method declaration to a native implementation is
>> now considered a restricted operation
>>
>> This PR slightly changes the way in which the JDK deals with restricted
>> methods, even for FFM API calls. In Java 22, the single
>> `--enable-native-access` was used both to specify a set of modules for which
>> native access should be allowed *and* to specify whether illegal native
>> access (that is, native access occurring from a module not specified by
>> `--enable-native-access`) should be treated as an error or a warning. More
>> specifically, an error is only issued if the `--enable-native-access flag`
>> is used at least once.
>>
>> Here, a new flag is introduced, namely
>> `illegal-native-access=allow/warn/deny`, which is used to specify what
>> should happen when access to a restricted method and/or functionality is
>> found outside the set of modules specified with `--enable-native-access`.
>> The default policy is `warn`, but users can select `allow` to suppress the
>> warnings, or `deny` to cause `IllegalCallerException` to be thrown. This
>> aligns the treatment of restricted methods with other mechanisms, such as
>> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>>
>> Some changes were required in the package-info javadoc for
>> `java.lang.foreign`, to reflect the changes in the command line flags
>> described above.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add note on --illegal-native-access default value in the launcher help
src/java.base/share/classes/java/lang/System.java line 2023:
> 2021: * @throws NullPointerException if {@code filename} is {@code
> null}
> 2022: * @throws IllegalCallerException If the caller is in a module
> that
> 2023: * does not have native access enabled.
The exception description is fine, just noticed the other exception
descriptions start with a lowercase "if", this one is different.
src/java.base/share/man/java.1 line 587:
> 585: \f[V]deny\f[R]: This mode disables all illegal native access except for
> 586: those modules enabled by the \f[V]--enable-native-access\f[R]
> 587: command-line option.
"This mode disable all illegal native access except for those modules enabled
the --enable-native-access command-line option".
This can be read to mean that modules granted native access with the command
line option is also illegal native access An alternative is to make the second
part of the sentence a new sentence, something like "Only modules enabled by
the --enable-native-access command line option may perform native access.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603878829
PR Review Comment: https://git.openjdk.org/jdk/pull/19213#discussion_r1603875920
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v23]
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote: >>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going >>> > into the direction you had envisioned? Any more blockers? The CSR should >>> > be up-to-date and is open for review as well. If no more blockers I'll go >>> > over this patch once more and clean it up to prepare for integration. >>> > Thanks! >>> >>> Thanks for all the efforts on this. >> >> Thanks for looking at this, Alan! >> >>> I've looked through the latest version. I'm a little bit comfortable with >>> LinkDeltaProducer. One reason it's build tool that is tied tied to code in >>> the jdk.jlink module, and secondly is that it copies >>> runtime-image-link.delta into the run-time image. Our long standing >>> position is that the run-time image is created by jlink rather than a >>> combination of jlink and extra stuff copied in by the build. >>> >>> The part that I like with the current proposal is >>> lib/runtime-image-link.delta as it's less complicated that previous >>> iterations that added a resource into the jimage container. >>> >>> What would you (and @mlchung) think of having jlink generate >>> lib/runtime-image-link.delta as a step between the pipeline and image >>> generation? >> >> If I understand you correctly, this would be no longer a build-time only >> approach to produce the "linkable runtime"? It would be some-kind of >> jlink-option driven approach (as it would run some code that should only run >> when producing a linkable runtime is requested)? Other than that, it should >> be fine as the previous iteration basically did that but at a different >> phase. Also note that the previous iteration used a build-only jlink plugin >> so as to satisfy the build-time only approach, yet it ran as part of the >> plugin-pipeline which wasn't desired either. But it was something similar to >> what you seem to be describing now. Did I get something wrong? > >> If I understand you correctly, this would be no longer a build-time only >> approach to produce the "linkable runtime"? It would be some-kind of >> jlink-option driven approach (as it would run some code that should only run >> when producing a linkable runtime is requested)? Other than that, it should >> be fine as the previous iteration basically did that but at a different >> phase. Also note that the previous iteration used a build-only jlink plugin >> so as to satisfy the build-time only approach, yet it ran as part of the >> plugin-pipeline which wasn't desired either. But it was something similar to >> what you seem to be describing now. Did I get something wrong? > > I think it continues to build time, it's just using some hidden jlink option. > So yes, it similar to a previous iteration except that it doesn't run as a > plugin the pipeline and the delta goes to the lib directory. > > Let's see what @mlchung says. You've put a lot of work into this so let's see > if we can converge to avoid too many more rounds. > @AlanBateman @mlchung The latest update now uses the `jlink` build time > option `--generate-linkable-runtime` to add needed resources to the `jimage` > when a runtime linkable JDK image is being asked for using the configure > option. This now runs outside the plugin-pipeline. I think this is what you > meant. Sorry it took longer to get back to this... I think you've got this to a good place and I think the overall solution is good. It may be that JDK should move to this by default in the future, and at the same time re-visit the restriction on generating an image containing jdk.jlink, but let's see if any issues come up. I've added myself as Reviewer to the CSR and I'm working through the code changes. - PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2115298661
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v23]
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote: >>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going >>> > into the direction you had envisioned? Any more blockers? The CSR should >>> > be up-to-date and is open for review as well. If no more blockers I'll go >>> > over this patch once more and clean it up to prepare for integration. >>> > Thanks! >>> >>> Thanks for all the efforts on this. >> >> Thanks for looking at this, Alan! >> >>> I've looked through the latest version. I'm a little bit comfortable with >>> LinkDeltaProducer. One reason it's build tool that is tied tied to code in >>> the jdk.jlink module, and secondly is that it copies >>> runtime-image-link.delta into the run-time image. Our long standing >>> position is that the run-time image is created by jlink rather than a >>> combination of jlink and extra stuff copied in by the build. >>> >>> The part that I like with the current proposal is >>> lib/runtime-image-link.delta as it's less complicated that previous >>> iterations that added a resource into the jimage container. >>> >>> What would you (and @mlchung) think of having jlink generate >>> lib/runtime-image-link.delta as a step between the pipeline and image >>> generation? >> >> If I understand you correctly, this would be no longer a build-time only >> approach to produce the "linkable runtime"? It would be some-kind of >> jlink-option driven approach (as it would run some code that should only run >> when producing a linkable runtime is requested)? Other than that, it should >> be fine as the previous iteration basically did that but at a different >> phase. Also note that the previous iteration used a build-only jlink plugin >> so as to satisfy the build-time only approach, yet it ran as part of the >> plugin-pipeline which wasn't desired either. But it was something similar to >> what you seem to be describing now. Did I get something wrong? > >> If I understand you correctly, this would be no longer a build-time only >> approach to produce the "linkable runtime"? It would be some-kind of >> jlink-option driven approach (as it would run some code that should only run >> when producing a linkable runtime is requested)? Other than that, it should >> be fine as the previous iteration basically did that but at a different >> phase. Also note that the previous iteration used a build-only jlink plugin >> so as to satisfy the build-time only approach, yet it ran as part of the >> plugin-pipeline which wasn't desired either. But it was something similar to >> what you seem to be describing now. Did I get something wrong? > > I think it continues to build time, it's just using some hidden jlink option. > So yes, it similar to a previous iteration except that it doesn't run as a > plugin the pipeline and the delta goes to the lib directory. > > Let's see what @mlchung says. You've put a lot of work into this so let's see > if we can converge to avoid too many more rounds. > @AlanBateman @mlchung The latest update now uses the `jlink` build time > option `--generate-linkable-runtime` to add needed resources to the `jimage` > when a runtime linkable JDK image is being asked for using the configure > option. This now runs outside the plugin-pipeline. I think this is what you > meant. Sorry it took longer to get back to this... I think you've got this to a good place and I think the overall solution is good. It may be that JDK should move to this by default in the future, and at the same time re-visit the restriction on generating an image containing jdk.jlink, but let's see if any issues come up. I've added myself as Reviewer to the CSR and I'm working through the code changes. - PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2115298661
Re: RFR: 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers
On Thu, 16 May 2024 02:37:40 GMT, Serguei Spitsyn wrote: > The following RFE was fixed recently: > [8324680](https://bugs.openjdk.org/browse/JDK-8324680): Replace NULL with > nullptr in JVMTI generated code > > It replaced all the `NULL`'s in the generated spec with`nullptr`. JVMTI > agents can be developed in C or C++. > This update is to make it clear that `nullptr` is C programming language > `null` pointer. > > I think we do not need a CSR for this fix. > > Testing: N/A (not needed) src/hotspot/share/prims/jvmti.xml line 1008: > 1006: function descriptions. Empty lists, arrays, sequences, etc are > 1007: returned as nullptr which is C programming language > 1008: null pointer. Shouldn't this be "NULL"? In any case, I think it would be helpful to expand this a bit to make it clear that usages of "nullptr" in parameter and error descriptions should be read or treated as "NULL" when developing an agent in C rather than C++. - PR Review Comment: https://git.openjdk.org/jdk/pull/19257#discussion_r1602803174
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v77]
On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver wrote: >> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). > > Kevin Driver has updated the pull request incrementally with one additional > commit since the last revision: > > javadoc formatting Back to the question about delayed provider selection and concurrent threads using a shared KDF instance to derive a key or raw data. Is it possible that InvalidParameterSpecException may be thrown intermittently in that scenario? I'm trying to assess if the issues with delayed provider selection is a major design issue or not. - PR Comment: https://git.openjdk.org/jdk/pull/18924#issuecomment-2114248643
Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v2]
On Wed, 15 May 2024 10:21:14 GMT, Maurizio Cimadamore wrote: > I believe we already disable a bunch of warnings from the command line when > compiling these benchmarks. Perhaps we can just tweak the build script in a > similar way and avoid the changes to the sources? E.g. > > ``` > DISABLED_WARNINGS := restricted this-escape processing rawtypes cast \ > ``` > > Should we add `removal` there? That might be better, I assumed the micros were being compiled an empty DISABLED_WARNINGS list. It means that the FFM micros won't need to be updated. - PR Review Comment: https://git.openjdk.org/jdk/pull/19174#discussion_r1602737982
Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v2]
> This is the implementation changes for JEP 471. > > The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated > for removal. This means a removal warning at compile time. No methods have > been removed. A deprecated message is added to each of the methods but > unlikely to be seen as the JDK does not generate or publish the API docs for > this class. > > A new command line option --sun-misc-unsafe-memory-access=$value is > introduced to allow or deny access to these methods. The default proposed for > JDK 23 is "allow" so no change in behavior compared to JDK 22 or previous > releases. > > A new test is added to test the command line option settings. The existing > micros for FFM that use Unsafe are updated to suppress the removal warning at > compile time. A new micro is introduced with a small sample of methods to > ensure the changes doesn't cause any perf regressions. > > For now, the changes include the update to the man page for the "java" > command. It might be that this has to be separated out so that it goes with > other updates in the release. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Add removal to DISABLED_WARNINGS Fail at startup if bad value specified to option - Merge - Update man page - Update man page - Fix comment - Merge - Merge - Whitespace - Initial commit - Changes: - all: https://git.openjdk.org/jdk/pull/19174/files - new: https://git.openjdk.org/jdk/pull/19174/files/5d3ca0aa..bd74a21d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19174=01 - incr: https://webrevs.openjdk.org/?repo=jdk=19174=00-01 Stats: 4378 lines in 194 files changed: 2791 ins; 962 del; 625 mod Patch: https://git.openjdk.org/jdk/pull/19174.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19174/head:pull/19174 PR: https://git.openjdk.org/jdk/pull/19174
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v77]
On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the pull request incrementally with one additional
> commit since the last revision:
>
> javadoc formatting
src/java.base/share/classes/javax/crypto/KDF.java line 202:
> 200: * @param provider
> 201: * the provider to use for this key derivation; if null, this
> method is
> 202: * equivalent to {@code getInstance(String)}
It might be better to disallow null here. If the code doesn't have a provider
name then it would be clearer to use the 1-arg getInstance method. That would
also help catch bugs where the provider name is null due to some bug.
src/java.base/share/classes/javax/crypto/KDF.java line 228:
> 226:
> 227: /**
> 228: * Returns a {code KDF} object that implements the specified
> algorithm from
Missing the `@` here.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18924#discussion_r1602698687
PR Review Comment: https://git.openjdk.org/jdk/pull/18924#discussion_r1602696489
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v77]
On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the pull request incrementally with one additional
> commit since the last revision:
>
> javadoc formatting
src/java.base/share/classes/javax/crypto/spec/HKDFParameterSpec.java line 92:
> 90: * {@code thenExpand} for {@code Extract} and {@code
> ExtractThenExpand}
> 91: * use-cases respectively.
> 92: */
I think it would be useful to say that Builder is not thread safe.
src/java.base/share/classes/javax/crypto/spec/HKDFParameterSpec.java line 115:
> 113: * @return an immutable {@code Extract}
> 114: */
> 115: public Extract extractOnly() {
I think you can expand the method description to say that it builds the Extract
method from the current state of the builder.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18924#discussion_r1602692495
PR Review Comment: https://git.openjdk.org/jdk/pull/18924#discussion_r1602690521
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v77]
On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the pull request incrementally with one additional
> commit since the last revision:
>
> javadoc formatting
src/java.base/share/classes/javax/crypto/spec/HKDFParameterSpec.java line 270:
> 268:
> 269: /**
> 270: * Returns a builder for building {@code Extract}-Only and {@code
> ExtractThenExpand} objects.
The class description speaks of Extract-Only operations. Here we are talking
about the Extract object so I think confusing to have "-Only" appended to the
class name. I see the same in the expandOnly method.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18924#discussion_r1602686623
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v77]
On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>
> Kevin Driver has updated the pull request incrementally with one additional
> commit since the last revision:
>
> javadoc formatting
src/java.base/share/classes/javax/crypto/KDFSpi.java line 85:
> 83: * @param alg
> 84: * the algorithm of the resultant {@code SecretKey} object (may
> not be
> 85: * {@code null})
Now that the method specifying NPE when either param is null then I assume the
"may not be null" is no longer needed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18924#discussion_r1602681710
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v75]
On Wed, 15 May 2024 17:14:55 GMT, Kevin Driver wrote: > An empty ikm and/or salt list is a supported scenario, so this should be > fine. I have added the documentation comment about the order of elements. The context for asking is that HKDFParameterSpec.ofExtract has wording to say that the addXXX methods should be called. It doesn't say "must" but the wording does give the impression that it wouldn't be valid to go straight to the methods that build. - PR Comment: https://git.openjdk.org/jdk/pull/18924#issuecomment-2114111312
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v77]
On Wed, 15 May 2024 19:59:59 GMT, Kevin Driver wrote: >> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). > > Kevin Driver has updated the pull request incrementally with one additional > commit since the last revision: > > javadoc formatting > > * The KDF.deriveXXX methods mention "Delayed provider selection". Is this > > idempotent? If I create a KDF and several threads race to derive keys or > > data, is it guaranteed that the same provider will be selection for any > > ordering of these threads? What does KDF::getProviderName if no provider > > has been selected? > > I believe it would _not_ be guaranteed that the same provider would be > selected for any ordering of the threads (depending on their possibly unique > KDFParameterSpec values). Is this a documentation call-out? Or did you have a > concern about this? It means that a KDF is stateful and mutable. It may be thread safe but it would be a hazard to attempt to use a shared instance. So I think there is a bit of a design smell here, something to look at for the next preview. The behaviour of KDF::getProviderName with delayed provider selection is very surprising. It may be that this method has to throw IllegalStateException when not bound to a provider. - PR Comment: https://git.openjdk.org/jdk/pull/18924#issuecomment-2114096567
Re: RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v75]
On Wed, 15 May 2024 17:14:55 GMT, Kevin Driver wrote: > I'm a bit confused by this question. HKDFParameterSpec.Extract does not > contain an info. Maybe I am missing something. A typo in my comment, I meant Expand rather than Extract. Look at the description of the "info" method and you'll see what I mean. - PR Comment: https://git.openjdk.org/jdk/pull/18924#issuecomment-2114098722
Re: [MOPO] Aw: Re: [MOPO] New Autographs on vintage Posters?
Still cool in mine ..LOL On Wed, May 15, 2024 at 4:34 PM Helmut Hamm < 02a292c4d413-dmarc-requ...@listserv.american.edu> wrote: > Alan, > > a 1940s Bogart autograph on a CASABLANCA poster would certainly be cool, > but if Bogart had survived and written that autograph 50 or 60 years later? > Not so cool in my book. > > Helmut > > *Gesendet:* Mittwoch, 15. Mai 2024 um 22:11 Uhr > *Von:* "Alan Heimann" > *An:* texasmu...@web.de > *Cc:* MoPo-L@listserv.american.edu > *Betreff:* Re: [MOPO] New Autographs on vintage Posters? > Hi group I know we’ve knocked this around in the past..I think it depends > on whose autographing ..my example you want a bogart signature on an orig > Casablanca poster?..I don’t think he signed much so I think that would be > cool..however as to the value of the poster hard to say if it would > increase decrease or do nothing..but if it’s a personalized sig ..to Alan > best of luck HB still cool but no q decreases value of poster > > On Wed, May 15, 2024 at 3:59 PM Helmut Hamm < > 02a292c4d413-dmarc-requ...@listserv.american.edu> wrote: > >> I was wondering what you guys think about newer autographs on vintage >> movie posters? >> >> Personally, I like vintage autographs. I have a Subway Window Card for >> THE WARRIORS that was signed by almost the entire cast back in 1979. Since >> the movie is a personal favorite, I really like that one. >> >> If I had the choice between an unsigned poster and one signed by the cast >> in the last few years, I would definitely go for the unsigned one. >> >> Today, I circled around buying an expensive CLOCKWORK ORANGE poster, >> which turned out be signed by Malcolm McDowell. When you take a look on >> ebay, you find tons of MM signatures on stills, posters, lobby cards, toy >> boxes, hats, masks, and what not. When I mentioned to the seller that this >> guy apparently signs everything you hold in front of him, he was totally >> offended and ended our conversation. >> >> My point being: An original 1973 Bob Dylan autograph on a PAT GARRETT AND >> BILLY THE KID Onesheet might raise the value of this very affordable poster >> to a completely different level. >> >> On the other hand, in my personal perception, a more or less recent >> McDowell signature on a rare and expensive CLOCKWORK ORANGE poster would >> much rather lower the value than enhance it. Again, this is merely my >> personal opinion. >> >> What do you think on this matter? >> >> Helmut >> www.filmposter.net >> >> >> >> >> >> -- >> >> To unsubscribe from the MoPo-L list, click the following link: >> https://listserv.american.edu/scripts/wa-american.exe?SUBED1=MoPo-L=1 >> > > -- > > To unsubscribe from the MoPo-L list, click the following link: > https://listserv.american.edu/scripts/wa-american.exe?SUBED1=MoPo-L=1 > Visit the MoPo Mailing List Web Site at www.filmfan.com ___ How to UNSUBSCRIBE from the MoPo Mailing List Send a message addressed to: lists...@listserv.american.edu In the BODY of your message type: SIGNOFF MOPO-L The author of this message is solely responsible for its content.
[Bug 2065829] [NEW] BTF support missing from kernel
Public bug reported: OS: Ubuntu Server LTS 24.04, 6.8.0-1004-raspi The OS is missing support for BTF which is needed in order to use XDP. BTF is compiled into the x86 Ubuntu kernel but not on the raspi which is missing the directory /sys/kernel/btf. As a result, I am unable to use XDP AF_XDP sockets because my BPF program fails to load with errors: BPF program load failed: invalid argument. btf_vmlinux is malformed Is BTF intentionally removed and can it be added? ** Affects: linux-raspi (Ubuntu) Importance: Undecided Status: New ** Tags: kernel -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2065829 Title: BTF support missing from kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2065829/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [MOPO] New Autographs on vintage Posters?
Hi group I know we’ve knocked this around in the past..I think it depends on whose autographing ..my example you want a bogart signature on an orig Casablanca poster?..I don’t think he signed much so I think that would be cool..however as to the value of the poster hard to say if it would increase decrease or do nothing..but if it’s a personalized sig ..to Alan best of luck HB still cool but no q decreases value of poster On Wed, May 15, 2024 at 3:59 PM Helmut Hamm < 02a292c4d413-dmarc-requ...@listserv.american.edu> wrote: > I was wondering what you guys think about newer autographs on vintage > movie posters? > > Personally, I like vintage autographs. I have a Subway Window Card for THE > WARRIORS that was signed by almost the entire cast back in 1979. Since the > movie is a personal favorite, I really like that one. > > If I had the choice between an unsigned poster and one signed by the cast > in the last few years, I would definitely go for the unsigned one. > > Today, I circled around buying an expensive CLOCKWORK ORANGE poster, which > turned out be signed by Malcolm McDowell. When you take a look on ebay, you > find tons of MM signatures on stills, posters, lobby cards, toy boxes, > hats, masks, and what not. When I mentioned to the seller that this guy > apparently signs everything you hold in front of him, he was totally > offended and ended our conversation. > > My point being: An original 1973 Bob Dylan autograph on a PAT GARRETT AND > BILLY THE KID Onesheet might raise the value of this very affordable poster > to a completely different level. > > On the other hand, in my personal perception, a more or less recent > McDowell signature on a rare and expensive CLOCKWORK ORANGE poster would > much rather lower the value than enhance it. Again, this is merely my > personal opinion. > > What do you think on this matter? > > Helmut > www.filmposter.net > > > > > > -- > > To unsubscribe from the MoPo-L list, click the following link: > https://listserv.american.edu/scripts/wa-american.exe?SUBED1=MoPo-L=1 > Visit the MoPo Mailing List Web Site at www.filmfan.com ___ How to UNSUBSCRIBE from the MoPo Mailing List Send a message addressed to: lists...@listserv.american.edu In the BODY of your message type: SIGNOFF MOPO-L The author of this message is solely responsible for its content.
[oss-security] CVE-2024-21823: Intel DSA and Intel IAA advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01084.html
was published yesterday covering OS/Hypervisor mitigations they recommend
to reduce exposure to a bug in certain recent Intel CPUs.
It states:
Summary:
A potential security vulnerability in some Intel® Data Streaming Accelerator
(Intel® DSA) and Intel® Analytics Accelerator (Intel® IAA) V1.0 for some
Intel® 4th or 5th generation Xeon® processors may allow denial of service.
Intel is releasing prescriptive guidance and software updates to mitigate
this potential vulnerability.
Vulnerability Details:
CVEID: CVE-2024-21823
Description: Hardware logic with insecure de-synchronization in Intel® DSA and
Intel® IAA for some Intel® 4th or 5th generation Xeon® processors may allow an
authorized user to potentially enable denial of service via local access.
CVSS Base Score: 6.4 Medium
CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:H
Recommendation:
Intel recommends following the steps below to address these issues:
Restrict untrusted usage of Intel® DSA/IAA devices on impacted Intel® 4th
Generation and 5th Generation Xeon® scalable processors, from VM guest or
3rd party application. Intel has worked with the OS vendor to provide an
updated Kernel to disallow direct access to Intel® DSA and IAA v1.0 devices
by untrusted software. Intel recommends using the upstream or LTS Linux kernel
with the updated driver containing mitigations. Please contact your OS vendor
for updates.
In addition, Intel is publishing the following libraries for the updated Kernel
version and recommends updating the following:
- Intel® DSA Transparent Offload Library (DTO) to version 1.1 or later. Updates
are available for download at this location: https://github.com/intel/DTO
- OFI Libfabric Shared Memory Provider to version 1.21.1 or later. Updates are
available for download at this location:
https://github.com/ofiwg/libfabric/releases
- Intel® MPI Library before version October 2024 later. The library will be
updated for Intel OneAPI in October 2024.
- Intel® Data Mover Library (DML) before version v1.2.0 or later. Updates are
available for download at this location: https://github.com/intel/DML
- Intel® Query Processing Library (QPL) before version v1.6.0. Updates are
available for download at this location: https://github.com/intel/qpl
- SPDK DSA Driver before version v24.9. Updates are available for download at
this location: https://github.com/spdk/spdk
[Further details, including a table of affected hardware, is in their advisory.]
https://bugzilla.redhat.com/show_bug.cgi?id=2278989 notes:
The fix went public today in Linus' tree with the following commits:
95feb3160eef ("VFIO: Add the SPR_DSA and SPR_IAX devices to the denylist")
e11452eb071b ("dmaengine: idxd: add a new security check to deal with a hardware
erratum")
6827738dc684 ("dmaengine: idxd: add a write() method for applications to submit
work")
I don't know if any other open source kernels or hypervisors support this
hardware yet - if so, they will presumably need to publish equivalent
mitigations.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
[agi] To whom it may concern.
I was banned from the singularity waiting room discord today for trying to issue a warning about an upcoming situation. When I am eventually proven right, I will not recive an apology, nor will I be re-admitted to the group. I'm sorry, but the people with control over these decisions are invariably the most ban-happy people you can find, they basically never have the patience to investigate or ask questions or implement any kind of 3-strikes policy. The last thing I was allowed to say on the server was a call for trials instead of the lynch mobs that will be forming in the fall of this year... -- You can't out-crazy a Democrat. #EggCrisis #BlackWinter White is the new Kulak. Powers are not rights. -- Artificial General Intelligence List: AGI Permalink: https://agi.topicbox.com/groups/agi/T18515c565721a5fe-M89a285b75c48aeec253ec875 Delivery options: https://agi.topicbox.com/groups/agi/subscription
