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 <philip.r...@oracle.com> 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.
