JNA 5.7.0 no longer triggers macOS compatibility behavior

[Florian Kistner]

Hi all,
we noticed a potentially unexpected change with what's now released as 5.7.0.

As previously, discussed in #1238 and #1297, JNA no longer links against JavaVM on x86_64 (a long deprecated framework) when building with current SDKs. This is inline with how things work for arm64, where Apple doesn't even ship said framework.

However, as we found out (reported in our tracker as IDEA-260593, see for details), if the JRE does not load any instance of the JavaVM framework, macOS might not apply some compatibility tweaks. Java applications can therefore experience unexpected behavior, such as modal dialogs implicitly entering full-screen mode.

Our investigation is on-going and this is not strictly related to JNA, however I wanted to give you all a heads up. It is likely that in a lot of projects JNA was the last reference to JavaVM, just like it was for us.

Please advise, if you'd like me to file bug on GH, nevertheless.

Best Regards,
Florian

--
Florian Kistner

JetBrains GmbH
Christoph-Rapparini-Bogen 23
80639 München

Handelsregister: Amtsgericht München, HRB 187151
Geschäftsführer: Maksim Mosienko, Yury Belyaev

[Tres Finocchiaro]

modal dialogs implicitly entering full-screen mode.

Florian,

Are these swing or awt dialogs?  Do you use a JNA API to open them?

I'm confused as to what causes this and I'd love to know more about how the bug is reproduced so that we can come up with a viable workaround.

I too am happy to work from GitHub, it's probably a better place for the technical details.

- Tres.Fin...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/73881f21-95ad-4326-83d9-853b14d7aeb4n%40googlegroups.com.

[Florian Kistner]

Hi Tres,

Are these swing or awt dialogs? 

We observed the behavior with Swing dialogs, but that's not to say it does not happen with Awt.

Do you use a JNA API to open them?

That seems to be irrelevant. AppKit merely checks for the present of the NSJavaVirtualMachine class, which JavaVM provides, and applies different behavior for newly opened windows amongst other things.

I'm confused as to what causes this and I'd love to know more about how the bug is reproduced

It appears this is simply macOS no longer recognizing the process as a (legacy?) Java application and therefore no longer applying compatibility workarounds on their side. Please see the linked issue for a discussion of possible workarounds and a reproduction in the IntelliJ platform. I'll try to come up with a minimal reproduction in plain Swing/awt.

so that we can come up with a viable workaround.

Honestly, I am not sure this ultimately should be addressed on JNA’s side, but if the goal is to avoid a breaking change on a minor release, for now we can simply continue linking against JavaVM on x86_64 (though that obviously does not work for arm64). For now, I just wanted to raise awareness. Either way, maybe it makes sense to add this to docs/release page.

Imho, only the application author can decide what behavior is desired. Frankly, this might currently be causing head scratches the other way around, when Java applications implicitly opt into different AppKit behavior just by loading JNA at runtime.

[Florian Kistner]

I'll try to come up with a minimal reproduction in plain Swing/awt.

Follow up: I added a repo using plain Swing/Awt to our ticket, see https://youtrack.jetbrains.com/issue/IDEA-260593#focus=Comments-27-4689594.0-0.

[Daniel B. Widdis]

I'm in agreement this probably doesn't require any update in JNA code (beyond at most a "demo" class on a workaround) but ought to be included in 5.7.0 change log/release note comments.

--

You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/EA921572-E43A-4075-B86B-FA957449925A%40jetbrains.com.

--

Dan Widdis

[Matthias Bläsing]

Hi Florian,

Am Freitag, den 12.02.2021, 02:49 +0100 schrieb 'Florian Kistner' via Java Native Access:

Do you use a JNA API to open them?

That seems to be irrelevant. AppKit merely checks for the present of the NSJavaVirtualMachine class, which JavaVM provides, and applies different behavior for newly opened windows amongst other things.

I'm confused as to what causes this and I'd love to know more about how the bug is reproduced

It appears this is simply macOS no longer recognizing the process as a (legacy?) Java application and therefore no longer applying compatibility workarounds on their side. Please see the linked issue for a discussion of possible workarounds and a reproduction in the IntelliJ platform. I'll try to come up with a minimal reproduction in plain Swing/awt.

so that we can come up with a viable workaround.

Honestly, I am not sure this ultimately should be addressed on JNA’s side, but if the goal is to avoid a breaking change on a minor release, for now we can simply continue linking against JavaVM on x86_64 (though that obviously does not work for arm64). For now, I just wanted to raise awareness. Either way, maybe it makes sense to add this to docs/release page.

Imho, only the application author can decide what behavior is desired. Frankly, this might currently be causing head scratches the other way around, when Java applications implicitly opt into different AppKit behavior just by loading JNA at runtime.

thank you for your analysis. My understanding from the description is, that the linkeage of JNA caused mac OS to apply some legacy behviour to the process running it. If that is the case I agree with your assessement, that this might even be considered a bugfix.

The interesting question is, whether you can change the behavior of the system with plain Java code or whether you need native code to change the the behavior. If it can be done by providing a property file / adding some calls at runtime, this would be valuable information, that I'd like as an author. The problem is, that I'm not an apple developer, so i need to ask for help.

Greetings

Matthias

[Tres Finocchiaro]

Florian,

As Vyacheslav Karpukhin kindly provides in the YouTrack bug report,

 -NSWindowAllowsImplicitFullScreen False 

should fix this as a program argument.  This is unitutive to most, as it's provided as what appears to be a program argument.  e.g.

java -jar myapp.jar -NSWindowAllowsImplicitFullScreen False 

Slightly related, for developers supporting dark mode on MacOS, they may already be familiar with:

  -NSRequiresAquaSystemAppearance False

... to fix the title bars to work with dark themes, so if already using this technique, it can safely be added to the launch arguments.  I've tested these flags back as far as macOS 10.8 and they seem to be safely ignored by the OS.

As an aside, I can't find one single Google result using this NSWindowAllowsImplicitFullScreen property, so big thanks to Vyacheslav for pointing that out.

If there's a way to handle this in pure Java, the answer may lie somewhere in the FullScreenUtilities.java: https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/d08179796bd1de747c9afb79177f999481116821/src/java.desktop/macosx/classes/com/apple/eawt/FullScreenUtilities.java#L68

Note, since fullscreen was added in macOS 10.7 it may be beneficial to document when this bug started and submit a proper bug report to OpenJDK.

-Tres

- Tres.Fin...@gmail.com