<AWT Dev> Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

[Michael Hall-14]

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?

[Philip Race]

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?
>
>

[Michael Hall-14]

> 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.

[Alan Snyder-3]

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.
>

[Michael Hall-14]

> 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.

[Philip Race]

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-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. 

[Michael Hall-14]

On Mar 18, 2021, at 6:35 PM, Philip Race <[hidden email]> wrote:

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.

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.