<AWT Dev> Java 9 on OS X internal API com.apple.eio.FileManager

Phil Race philip.race at oracle.com
Tue Sep 26 17:20:10 UTC 2017


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



More information about the awt-dev mailing list