Exceptions are shown on launch for the Weka Package Manager. Reflection warnings present since Java 9 seem to have become errors at JDK 16. A todo to remove initialization at that point until a fix is available.
JDK-18 (early access), signed, AppleScript, MacFileSystemProvider now works, Nashorn jjs and JSR 223.
JDK-16, Same features except doesn't include MacFileSystemProvider. Prior to JDK-17 encapsulation changes. (10/6/21)
Yes, with the latest JDK early access the application should be fully functional. When
started you should see at the start...
ready
HalfPipe:Initializer - AppleScript available is true
HalfPipe:Initializer - MacFileSystemProvider available is true
The ready prompt, for the curious, is of course the old mainframe TSO prompt. When I first
started this I wasn't sure what kind of command line interface I was going to go for. It
ended up more Unix shell like for some reason.
This functionality was previously available at HalfPipe with Mac NIO DefaultFileSystemProvider (OS/X only). The attr command is still the same.
By way of an actual demonstration of using the attr command. I tried to make a jdk image including the bug fix for my default provider when it was available. This had problems with paths that were included in the CLASSPATH environment variable. These were from an install of prior different software unrelated to the jdk but which caused an error there.
In the build I got (among other warnings)...
warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/bin": no such file or directoryThe files are really there but I think the problem might be that /Applications/OpenOffice.app/Contents/program is actually a Mac alias that is not getting resolved correctly. It actually seems a little difficult to determine that an alias is involved. For example using the attr command...
error: warnings found and -Werror specified
1 error
2 warnings
attr mac_finder:alias /Applications/OpenOffice.app/Contents/programWell, clearly my so-called file attribute view doesn't work. So I made my own alias...
mac_finder:alias = false
attr mac_finder:alias "/Users/mjh/SmileyFace alias"So it does work although it has problems with the first alias that it doesn't with this one.
mac_finder:alias = true
osascript -e 'set programFile to POSIX file "/Applications/OpenOffice.app/Contents/program"'
file Macintosh HD:Applications:OpenOffice.app:Contents:MacOS
[This is from Terminal, my application has problems with AppleScript containing double quotes, an issue for another time.]
Which does show the path that the alias actually resolves to is the MacOS directory.
Anyhow, this demonstrates that the native api's from my attribute view have problems resolving this path as an alias. This is fairly easy to check with the attribute view but probably would be impossible from Java without it.
I think this is what was causing my jdk build to fail, the alias not resolving correctly. Which is probably something that would not be a very common issue. I seem to find edge cases. But the file attribute does help provide some indication of what the issue here could be. I could still be wrong too.
HalfPipe-1.0.exe via VirtualBox jpackage
JDK-16, Nashorn jjs and JSR 223.
halfpipe_1.0-1_amd64.deb via VirtualBox jpackage
JDK-16, Nashorn jjs and JSR 223.
halfpipe_jdk18_amd64.deb via VirtualBox jpackage
JDK-18, Current 10/3/21 version of HalfPipe with a little Linux customization. Ubuntu 20.04
JavaScript is default installed, I also installed R again on OS/X but have done no new testing with this version. Invocation for interactive on either is through the class us.hall.fastr.SimpleTest. I also installed Node.js on OS/X but the example I tried didn't seem to work. I don't think that is included in the current OS/X download.
I am unclear about exactly how things are divided between the normal JDK and GraalVM for recommended usage and support. I have seen it suggested to migrate to Graal for JavaScript. I had issues with jpackage for Graal app versions on both Windows and Linux. I just filed a bug report against the Windows issue. I'm not sure if it will be accepted yet.
In the meantime, I see no problem providing at least some support for my application with JDK's of either type. Possibly more in depth support if anyone indicates an interest or I find something of more interest myself.
Issues: None encountered.
Issues: I thought there was an issue here and got as far as submitting a bug report. But it was pointed out to me that a correct path should work. Sure enough at that point I was unable to recreate the issue shown at win_graal11.txt. So like OS/X this actually seems to be issue free and should work fine.
A couple things to maybe be aware of that are possibly not issues. You should remove the application before replacing. Otherwise a disappearing small dialog flashed for me and the install just spun. Also for the .exe installer it should be deleted or there is a java i/o error for permissions on replacing. I tried looking for a convenient command line way to remove the application so maybe this could be scripted but on a quick look I didn't see anything that appeared easily scriptable. I'm mostly familiar with OS/X.
Assuming you do want to try using the Graal JDK for your own jpackage application it is
pretty much as simple as including it as the --runtime-image...
--runtime-image 'c:/Program Files/Java/graalvm-ce-java11-21.1.0'
I believe you would have to remove any other jpackage parameters related to jlink...
--add-modules
--module-path
--jlink-options
You could maybe make the alternate JDK the installed one and still have these options available,
I haven't tried. I had limited testing where jlink related parameters didn't seem to work
and got rid of them immediately as not essential to basic use of my app.
Issues: While the application installer should work as far as I know there were problems as shown at linux_graal11.txt. This may also be of interest if you want to use jpackage with a GraalVM jdk for another application on Windows.
Since the Windows issue was accepted even though it turned out to be a non-bug. I went ahead and submitted a bug report for this. It seems there is at least limited jpackage support for other jdk's.
NOTE: There is currently no reason to use this as the latest version works fine with my Mac FileSystemProvider. Unless you prefer a JDK 12 version of the application to the bleeding edge one. But no updates will be made to this version.
Due to a couple JDK issues, unsigned and JDK 12, no AppleScript.
Runs with a Mac specific DefaultFileSystemProvider. Mostly involving OS/X specific native File system API's accessed as nio file attributes. HalfPipe runs everything with this as the default file system provider. Although, almost all access should pass through to the JDK default provider with the exception of the native attributes.
HalfPipe provides an 'attr' command to display these attributes.
Usage:
attr with no args lists provided views and attributes
attr view attribute file | list file's attribute for view
attr view:attribute file | list file's attribute for view
attr view:* or view * file | list all file's attributes for view
This version added the 'attr' '*' all attributes parameter option and refactored some of the string conversion code I had added from the FileHelper class back to the 'attr' command that is actually supposed to display them as strings. Actual attributes can be of any type: an array of Path's, a boolean, an integer, or whatever.