If I remember correctly this group ended up the keepers of this code. If that is not right please point me to the correct group.
I am getting… Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in unnamed module @0x2a5ca609) cannot access class com.apple.eio.FileManager (in module java.desktop) because module java.desktop does not export com.apple.eio to unnamed module @0x2a5ca609 Could you verify that this is intentional and not accidental? |
I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299
JDK 16 release notes here : http://jdk.java.net/16/release-notes -phil On 3/18/21 1:07 PM, Michael Hall wrote: > If I remember correctly this group ended up the keepers of this code. If that is not right please point me to the correct group. > > I am getting… > Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in unnamed module @0x2a5ca609) cannot access class com.apple.eio.FileManager (in module java.desktop) because module java.desktop does not export com.apple.eio to unnamed module @0x2a5ca609 > > Could you verify that this is intentional and not accidental? > > |
> On Mar 18, 2021, at 3:29 PM, Philip Race <[hidden email]> wrote: > > I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299 > > JDK 16 release notes here : http://jdk.java.net/16/release-notes > I think I ran into a couple related issues. I had a check to see if default Toolkit gave me a Sun class for some functionality VirtualBox seemed to have issues with. I turned it off. I’ll still have to test to see if that gives me VirtualBox issues. For com.apple.eio.FileManager I personally would argue that it was a public not a internal API. It was meant to provide some Mac specific file niceties to developers. I had some code on Github based on the com.apple.eio.FileManager code that I think the macport had as Oracle class exception. I think I reworked it based on a Mac nio FileSystem I did. I can probably with some work get to work for my application. Maybe eve possibly get it to work fairly easily for other apps. If this change is permanent. It’s possible you might hear from some other developers who have older Mac java code that made use of this API. |
I use moveToTrash and revealInFinder, but only with JDK 8. In later JDKs I use Desktop.moveToTrash and browseFileDirectory.
> On Mar 18, 2021, at 2:20 PM, Michael Hall <[hidden email]> wrote: > > > >> On Mar 18, 2021, at 3:29 PM, Philip Race <[hidden email]> wrote: >> >> I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299 >> >> JDK 16 release notes here : http://jdk.java.net/16/release-notes >> > > I think I ran into a couple related issues. I had a check to see if default Toolkit gave me a Sun class for some functionality VirtualBox seemed to have issues with. I turned it off. I’ll still have to test to see if that gives me VirtualBox issues. > > For com.apple.eio.FileManager I personally would argue that it was a public not a internal API. It was meant to provide some Mac specific file niceties to developers. > > I had some code on Github based on the com.apple.eio.FileManager code that I think the macport had as Oracle class exception. I think I reworked it based on a Mac nio FileSystem I did. I can probably with some work get to work for my application. Maybe eve possibly get it to work fairly easily for other apps. If this change is permanent. > > It’s possible you might hear from some other developers who have older Mac java code that made use of this API. > |
> On Mar 18, 2021, at 6:13 PM, Alan Snyder <[hidden email]> wrote: > > I use moveToTrash and revealInFinder, but only with JDK 8. In later JDKs I use Desktop.moveToTrash and browseFileDirectory. > Desktop eliminated the need for some of the FileManager code. I use findFolder to try and determine appropriate file locations on OS/X. if (option == USER) { f = new File(FileManager.findFolder(FileManager.kUserDomain, FileManager.OSTypeToInt("asup")),app); if (!f.exists()) f.mkdir(); return f.toPath(); } else if (option == LOG) { f = new File(FileManager.findFolder(FileManager.kUserDomain, FileManager.OSTypeToInt("logs")),app); if (!f.exists()) f.mkdir(); return f.toPath(); } Thats the code having problems now. I may have other forgotten uses scattered across the application. |
In reply to this post by Michael Hall-14
Many of the com.apple APIs were obsoleted in JDK 9 with
http://openjdk.java.net/jeps/272
We (you and I) even discussed this and the absence from there of FileManager 3 1/2 years ago https://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013120.html It was left off that you wrote here https://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013131.html > All right. If RFE is in fact the correct way to go in resolving the status of the code I will try to figure out how to do that. And you did in fact file such an RFE https://bugs.openjdk.java.net/browse/JDK-8187981 but unfortunately it seems to be in "other-libs" and I don't know who even looks at that category and don't know what really belongs there. core-libs would have been better. I've moved it but it probably needs more than that to get action. -phil. On 3/18/21 2:20 PM, Michael Hall wrote:
On Mar 18, 2021, at 3:29 PM, Philip Race [hidden email] wrote: I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299 JDK 16 release notes here : http://jdk.java.net/16/release-notesI think I ran into a couple related issues. I had a check to see if default Toolkit gave me a Sun class for some functionality VirtualBox seemed to have issues with. I turned it off. I’ll still have to test to see if that gives me VirtualBox issues. For com.apple.eio.FileManager I personally would argue that it was a public not a internal API. It was meant to provide some Mac specific file niceties to developers. I had some code on Github based on the com.apple.eio.FileManager code that I think the macport had as Oracle class exception. I think I reworked it based on a Mac nio FileSystem I did. I can probably with some work get to work for my application. Maybe eve possibly get it to work fairly easily for other apps. If this change is permanent. It’s possible you might hear from some other developers who have older Mac java code that made use of this API. |
I remember talking about it and at least temporarily kept it from getting eliminated. Appreciated that. I don’t remember the RFE. Google com.apple.eio.FileManager 2020 19,300 hits. How many are active current actual uses I don’t know. I have a sort of involved workaround I will go ahead on. Up to you if you think there’s not enough use left to continue providing it. But it is not internal if that’s why it’s gone. |
Free forum by Nabble | Edit this page |