You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is a good idea given that the primary purpose of this plugin is to use the detected architecture to load .dll or .so. If we returned x86_64 for 32-bit JDK, the chosen shared object will not be loaded.
I'm not sure if this is a good idea given that the primary purpose of this plugin is to use the detected architecture to load .dll or .so. If we returned x86_64 for 32-bit JDK, the chosen shared object will not be loaded.
To the OP's point, if it's being used for building/packaging decisions, it's not necessarily true that the JDK is ever being invoked for a runtime decision. I agree that it should be non-default but I can also see why it would be useful.
When 32-bit JDK is running on 64-bit OS the plugin detects
x86_32
arch.Is there a way to avoid this? As a temporary workaround I do additional check
System.getenv("ProgramFiles(x86)")
and fix final value.The text was updated successfully, but these errors were encountered: