I didn't do the work here so I am answering as best I can.
FileManager is not directly exposed but is used in implementing
a couple of APIs on the java.awt.Desktop class.
If you think some important use case that is appropriate there is
missed then you can file an RFE on that.
The example below seems to be something that would be better
off in java.nio.files and so would not have been appropriate for the
desktop JEP and you may want to file an RFE against core-libs/java.nio
Unfortunately, I can't answer licensing questions for you.
-phil.
On 09/26/2017 01:53 AM, Michael Hall wrote:
I know JEP 272 covered the com.apple.eawt API’s.
Is there nothing to cover the eio.FileManager?
I have code using it to try and determine platform specific location’s for files
public static Path getFolder(DataTypes option) {
File f = null;
try {
if (option == USER) {
f = new
File(FileManager.findFolder(FileManager.kUserDomain,
FileManager.OSTypeToInt("asup")),app);
if (!f.exists()) f.mkdir();
return f.toPath();
}
…etc...
When I run jdeps against my application I get…
jdeps -jdkinternals halfpipe.jar
fhalfpipe.jar -> java.desktop
us.hall.osx.OSXApplication ->
com.apple.eio.FileManager JDK internal API (java.desktop)
recognizing it as a java.desktop internal API.
If I look at the web page suggested to find replacements I see only
com.apple.eawt and not com.apple.eio?
If there is no ongoing intention to support this API in the JDK I had at some
point included them with a GitHub project.
Would there be any problems or licensing concerns with me providing them that
way? I think all the Apple contributed was Classpath Exception but I’m not
entirely sure what requirements that involves for my use of it?
