MacOS Path Randomization Problems

[Michael P Ellis]

I am using OS-X 10.15.6 and have run into the MacOS Path Randomization problem that prevents ImageJ finding its plugins. The suggestion of moving the application out of the containing directory and back again does not seem to work for me. Does anyone else face this problem?

Would it make sense if instead of presenting the user with the "Plugins were not loaded due to..." message, the use is instead presented with a directory chooser dialog is to invite the user to locate the ImageJ plugins directory?

The result can then be saved as a Java Preference for subsequent invocations.

I would be prudent to add a "Locate Plugins..." in the Plugins directory so that should the application be moved, it would be possible to re-find the plugin directory.

Any thoughts?

-- Michael Ellis

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

On Dec 31, 2020, at 5:43 AM, Michael Ellis <[hidden email]> wrote:
>
> I am using OS-X 10.15.6 and have run into the MacOS Path Randomization problem that prevents ImageJ finding its plugins. The suggestion of moving the application out of the containing directory and back again does not seem to work for me. Does anyone else face this problem?

Hi Michael,

I suspect you are not using the latest macOS distribution at

    https://imagej.nih.gov/ij/download.html

With this distribution, everything, including plugins, is inside the ImageJ.app bundle and ImageJ is able to find its plugins even when Path Randomization is enabled.

I can disable Path Randomization using these steps:

1. Download ij153-osx-java8.zip from https://imagej.nih.gov/ij/download.html into the Downloads folder.
2. Extract ImageJ.app from the ZIP file.
3. Copy ImageJ.app into the Applications folder.
4. Right click on ImageJ.app and click on “Open” in the dialog.
5. Path Randomization should now be disabled and you can run ImageJ by double clicking on ImageJ.app.

-wayne


> Would it make sense if instead of presenting the user with the "Plugins were not loaded due to..." message, the use is instead presented with a directory chooser dialog is to invite the user to locate the ImageJ plugins directory?
>
> The result can then be saved as a Java Preference for subsequent invocations.
>
> I would be prudent to add a "Locate Plugins..." in the Plugins directory so that should the application be moved, it would be possible to re-find the plugin directory.
>
> Any thoughts?
>
> -- Michael Ellis\

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael P Ellis]

Wayne,

Again thanks for the feedback.

I need to dig a bit further since I need to do my own packaging because I am dependent on Java 11.

Modifying the Apple package contents of the official download breaks Apple security checks.

Regarding getting your latest version, I am currently downloading your source from your git https://github.com/imagej/imagej1.git

Ideally, I would like to go back to using the central maven repository

                        <dependency>
                            <groupId>net.imagej</groupId>
                            <artifactId>ij</artifactId>
                            <version>1.53***</version>
                        </dependency>

Who should I ask when will the maven repository be updated to your latest version?

Also FWIW, Nashorn javascript is deprecated from Java 11 and withdrawn from the next LTS release 15.

I have started using the Oracle GraalVM community edition and have found that the javascript and it's language interoperability features look really great. I have built imageJ and JavaFX plugins which use JNA and javascript and it (touch wood) seems to work.

GraalVM makes language interoperability MUCH easier and promises some real performance enhancements amongst other interesting features. Any thoughts as to whether this is something ImageJ should be following?

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html