On 3/24/20 9:23 am, Philip Race wrote:
One might consider what is happening on mac to be the preferred behaviour
for edit()
I am not sure I would consider this a bug to open finder on a folder.
How would you be able to achieve that after this change ?
Can't we open Explorer on Windows to align behaviour ?
We have separate method to open the folder java.awt.Desktop.open(File), it
works on windows and macOS:
* <p> If the specified file is a directory, the file manager of
* the current platform is launched to open it.
https://docs.oracle.com/javase/8/docs/api/java/awt/Desktop.html#open-java.io.File-
The print() case it seems less useful - does that also open finder ?
Yes, it also open the finder.
Looking at the exception text for each case if we do go the route of
the current code :-
442 * @throws IOException if the specified file has no associated
443 * editor, or the associated application fails to be launched
I think it would be prudent to expand this text to be explicit about
this directory case since you aren't failing to launch anything since the code
doesn't try and "no associated editor" is and of course that will need a CSR.
and for print then do the same :
478 * @throws IOException if the specified file has no associated
479 * application that can be used to print it
maybe that should be done even if we still allow the edit() case.
I think that in theory, it should be possible for some implementation
to print the content of the folder, or edit its content via some separate
program. It is just by accidental that on windows and mac we do nothing useful.
Probably the message in the exception should be changed to "cannot print a
directory: XXX"?
--
Best regards, Sergey.
