https://bugs.openjdk.java.net/browse/JDK-8270549 describes a thread safety problem with ProcessEnvironment
due to concurrent use in JDK code of getenv and setenv/putenv which are (according to that bug) not thread safe anyway

Whilst there are a number of places in JDK native code that setenv/putenv is used,  the cases in the launcher code for macOS are where a problem was observed by graal snapshotting

These macos launcher cases are :

APP_NAME_<pid>  : set if -Xdock:name=<str> is specified
APP_ICON_<pid>   : set if -Xdock:icon=<str> is specified
JAVA_MAIN_CLASS_<pid> : set unconditionally
JAVA_STARTED_ON_FIRST_THREAD_<pid>:  set if -XstartOnFirstThread is specified

You can see these set in java.base/macosx/native/libjli/java_md_macosx.m

All except the last one are used to set the names seen on the macOS desktop such as the system menu bar.

Also this old bug https://bugs.openjdk.java.net/browse/JDK-7131021
added comments to all of them that :

     * NOTE: It is used by SWT, and JavaFX.

The bug also says these were set all the way back in the Apple  JDK 6 days

The bug JDK-7131021 also says
SWT relies on APP_NAME and APP_ICON. We should not drop support for these variables.

I think that is more precise than the source code comment since I've looked at SWT 2011 v2.7 and 2021 latest SWT
and I see (in both) that APP_NAME and APP_ICON are used but neither uses the others.

FX also does use APP_ICON but not APP_NAME

JAVA_STARTED_ON_FIRST_THREAD is for the *benefit* of FX but it is AWT that uses it not FX

So in summary
JAVA_STARTED_ON_FIRST_THREAD - JDK internal
    - I need to understand the splash screen case here - code there reads this and splash can be running
      early on but this is set in post VM init code ...
JAVA_MAIN_CLASS_<pid> - JDK internal - set unconditionally
APP_ICON_<pid> - JDK internal + SWT + FX
APP_NAME_<pid>  - JDK internal + SWT

APP_ICON and APP_NAME  may be difficult to get rid of because of SWT but they are not set unless the app explicitly asks for it.
And it appears they are set before the VM is up and running so it is still in single-threaded mode and not likely to be a problem


JAVA_STARTED_ON_FIRST_THREAD perhaps has potential to be an issue but again it is only set in extremely rare cases

The real problem is JAVA_MAIN_CLASS_<pid>

I think we can get rid of setting that.  The AWT code already checks another env. var a system property and various
Apple app bundle values as well .. so let's just set it as the System property AWT is already looking for.