Recent versions of Java issue a warning about restricted use of java.lang.System::load

[eclab]

When I launch an application using CoreMidi4J on a very recent version of Java I get the following ugly warning:

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by uk.co.xfactorylibrarians.coremidi4j.Loader in an unnamed module (file:/........ [this is my application jar file, which contains uk.co.xfactorylibrarians.coremidi4j.Loader] )
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

That doesn't look good.

[DerekCook]

Hello

It would be useful if you can provide some information on your environment such as vendor and Java Version you are trying where this warning is being given as I this is the first time this is reported.

I have not moved beyond Java 17 LTS myself as I have no real need to, but am thinking of moving to the latest LTS version if and when I get some time just to keep up to date.

Just looking at the error message, you are getting a future compatibility warning around native methods being called.

CoreMID4J HAS to access native methods to work around the Core MIDI SYSEX issues. This will not change unless it ever gets fixed in Java and CoreMIDI4J is no longer needed.

So the question is whether or not we can do something in the library to keep native methods enabled or whether or not this will always be something that the application has to do, which the warning message appears to be hinting at as it appears to be a command line argument.

This is something you can do yourself to get rid of this warning that you subjectively consider to be "ugly", but I would say is actually helpful that this future compatibility issue is being flagged.

I'll keep this issue open until either James or myself have had time to look at it, but please note that I have little time for programming these days. Or if it really bothers you, then fork the code, investigate and offer the solution as this is meant to be a public project where contributions can be made.

[brunchboy]

Yes, Derek is right. The warning is pretty clear, if you want to use software like CoreMIDI4j on more recent versions of Java, you need to provide the command-line flag that it shows. I'd recommend building it into your application launcher if you use one.

[brunchboy]

As for whether there is a way to avoid this warning purely from the library side, that seems unlikely. Perhaps if we completely rewrite it to use the latest approach for Java to native linking there may be a way to move the declaration of intent into a module descriptor or something but that would still be the responsibility of the application that is adopting the library, just as the command line argument is.

[DerekCook]

All good observations, James (as always). From my perspective (based on the amount of time for programming I have right now) a command line argument that keeps native access in the current library compared to a complete rewrite is what I will be going for.

That is not to say I wouldn't mind modernising CoreMIDI4J at some point, but in the grand scheme of things on my TODO list, that is really low priority for me. I would say my strongest preference would be for Java to finally resolve this Mac OS problem (like they did on PC over 20 years ago now!) and CoreMIDI4J is no longer needed.

In the meantime this is a public project that anybody can contribute to if they want to improve on what we have achieved between us - would you believe a decade ago now!

[brunchboy]

Yes, I agree completely, Derek, I was not proposing that either of us undertake a rewrite! This library fixes a (strangely neglected) broken part of the Java standard library, works well, and as long as it continues to do so is perfectly good as it is. I was just trying to point out that there likely wouldn’t even be a significant benefit for users of the library as an outcome of such an effort.

[eclab]

I absolutely should have provided more information, and I apologize. I have been testing the problem on MacOS (10.15. Sequoia and 12.6 Monterrey, on M1 laptops). If I run my applications using Java 25, installed from brew, I will get the warning. If I run from Java 20.0.2, there is no warning. So this has just showed up in recent versions of Java.

I can of course embed a flag in my MacOS launcher. But I thought you should know this is now showing up. There is no good reason for Java to be doing this. But they are.

[DerekCook]

Thanks for the extra info, which helps, and of course it was right to point it out. At least we are now aware of it.

I was also not sure why they are doing this either, unless there is a general concern that "native code is dangerous" and is being discouraged. I just did some digging and this indeed appears to be the case as suggested by the following link

Quality Outreach Heads-up - JDK 24: Prepares Restricted Native Access

The good news is that they are not deprecating JNI, they just seem to want to force a concious decision on application developers to be allowing its use to ensure what OpenJDK call Integrity by Default (we could call it an utter PITA). I'd still say we have good reason to use JNI if OpenJDK do not fix the issues that CoreMIDI4J was written to work around.

The following also describes it.

JEP 472: Prepare to Restrict the Use of JNI

If I am reading it correctly (but have only skim read so far), the only option we have if we wish to continue using libraries that use JNI (like CoreMIDI4J is to use those command line options.

[DerekCook]

Yes, I agree completely, Derek, I was not proposing that either of us undertake a rewrite! This library fixes a (strangely neglected) broken part of the Java standard library, works well, and as long as it continues to do so is perfectly good as it is. I was just trying to point out that there likely wouldn’t even be a significant benefit for users of the library as an outcome of such an effort.

Hi, James. Yes, I assumed that's what you meant, and a rewrite would only be on the cards if really needed, or I was really bored. But as per post above, it seems like putting in the command line option for Java 24 and above is the only solution. This may be something to add to the documents at least, referencing those articles.

[brunchboy]

Adding a note to the documentation is a good idea indeed.

[DerekCook]

I've added a note to the README.md file. I decided to put it close to the start of the description, but we can review that.