Support for Apple Extensions

[Johannes Schindelin]

Hi Alan,

On Fri, 5 Jul 2013, Kaydell Leavitt wrote:

> I would say that I absolutely need the following things:
> 
> 1. JFileChooser Save dialog  that is native for both files and for folders
> 2. JFileChooser Open dialog that is native for both files and folders.
> 3. Print Command that is native
> 4. A menu jar at the top of the screen -- not at the top of the window.  (Where a Mac user expects it to be.)
> 5. Preferences menu item where it is expected to be (in the application menu calling an ApplicationListener)
> 6. About menu item where it is expected to be (in the application menu calling an ApplicationListener)
> 7. The quit menu item working in where the user expects it (in the application menu calling an ApplicationListener).
> 8. The Services menu should just work.

In addition, we are heavy users of handleOpenFile() and handleAbout(),
printFiles(), handleQuitRequestWith(), userSessionActivated(),
userSessionDeactivated(), systemAboutToSleep(), systemAwoke(),
screenAboutToSleep(), screenAwoke(), appHidden, appUnhidden(),
appMovedToBackground(), appRaisedToForeground, and appReOpened().

Alan, I think you might be surprised what kind of reactions your
suggestion to remove -- even parts of -- a well-established, wide-used API
elicited.

After all, Sun worked very hard -- and successfully so -- on an incredible
backwards-compatibility, so much so that you can still execute code that
was compiled for Java 1.1 without *any* problems. That is what makes Java
so much nicer to use than, say, C# or C++, where you have to adjust things
all the time just to keep them compiling, let alone running.

Maybe you can explain what benefits there are in removing that established
API, and maybe you could elaborate why those benefits outweigh the costs?

I am curious,
Johannes