Thought on a slight change for MacOS?

Question

Thought on a slight change for MacOS?

buthed010203 opened this issue 3 years ago · 45 comments

This isn't so much an issue but more a proposal, I propose something similar to the code below be placed at the top of SDLApplication so that jars can be launched with a single double click rather than having to run it with java -XstartOnFirstThread -jar <jar> every time. The code functions fine in its current state here but that would be required in every project using arc so I think it would be better to just integrate it directly into arc. All it does is relaunch the jar with the same arguments it was originally passed.

Answer 1 · 2021-12-03T15:08:27.000Z

It's better than crashing, at least.

Answer 2 · 2021-12-03T16:30:53.000Z

Okay, I will port it into that file and make a pr then I guess.

Answer 3 · 2021-12-03T16:50:17.000Z

Actually now that I think of it, this poses a problem. I cant get the arguments that were passed to the program through the main method..

Answer 4 · 2021-12-03T16:54:23.000Z

It's fine if you put it in Mindustry instead, it's not as if Arc will be used for anything else by me.

Answer 5 · 2021-12-03T16:55:40.000Z

I just added an optional argument to sdlapplication

Answer 6 · 2021-12-03T17:15:22.000Z

Wait, hold on.

This should be checking the JVM arguments, not the command-line arguments. Your change would make the application restart even when you run it with -XstartOnFirstThread -jar, which would be undesirable (the Steam version would always relaunch, for example, which would likely cause problems)

Answer 7 · 2021-12-03T17:16:25.000Z

Ive reworked it so that it only happens when the application crashes, theres no way to detect -XstartOnFirstThread reliably hence why i pass it an additional -firstThread argument.

Answer 8 · 2021-12-03T17:17:18.000Z

Ive reworked it so that it only happens when the application crashes

XstartOnFirstThread crashes can look really weird on MacOS; how are you detecting these?

Answer 9 · 2021-12-03T17:17:55.000Z

The reason it crashes is because of the window == 0 check throwing a new sdlerror, i just overwrote it

Answer 10 · 2021-12-03T17:18:18.000Z

I'm unaware as to how it affects the steam version but I guess I can try it on an old non m1 mac I have lying around when I get home. I doubt it will cause any problem though considering i'm doing something similar on my windows machine already and everything still works

Answer 11 · 2021-12-03T17:19:09.000Z

The only problem now is that it will get stuck in a loop if you don't pass the args to sdlApplication.

Answer 12 · 2021-12-03T17:19:53.000Z

If that last arg isnt included and it cant find java correctly it will just break..

Answer 13 · 2021-12-03T17:20:05.000Z

Hm wait no I covered that case by just crashing already lol

Answer 14 · 2021-12-03T17:21:50.000Z

With this solution the steam thing is actually a non issue as it already has -XstartOnFirstThread passed so it should never crash there anyways

Answer 15 · 2021-12-03T17:28:41.000Z

Ugh not this again... Its deciding to randomly work sometimes and then not work other times

Answer 16 · 2021-12-03T17:32:07.000Z

The reason it crashes is because of the window == 0 check throwing a new sdlerror

In my experience it would just make the JVM explode.

Answer 17 · 2021-12-03T17:33:16.000Z

For some reason it was working fine before but now it has decided that it hates me. Most of the time it will just abort and sometimes it will just work fine.

Heres what it looks like most of the time:

And then heres the random cases where it will just work:

Answer 18 · 2021-12-03T17:36:42.000Z

It would appear that this check method may just be broken...

Answer 19 · 2021-12-03T17:37:46.000Z

It always makes it to B and aborts or makes it all the way through, very strange

Answer 20 · 2021-12-03T17:39:01.000Z

Ok it just magically explodes here then...

Answer 21 · 2021-12-03T17:41:06.000Z

What the hell.

Answer 22 · 2021-12-03T17:49:20.000Z

Ok now im just plain confused... It somehow still works without initializing the video and events components...

Answer 23 · 2021-12-03T17:51:39.000Z

https://forums.libsdl.org/viewtopic.php?t=6738 Interesting

Answer 24 · 2021-12-03T18:30:58.000Z

I don't think there's a reliable way to detect crashes here.

Answer 25 · 2021-12-03T18:34:37.000Z

Here's what you could do:

Assume that anyone running the jar is not doing it through the bundled JRE, since that adds in the arguments by itself
Use reflection to access the Java management API and check if -XstartOnFirstThread was supplied
If reflection fails, as it would in the Mindustry JRE, do nothing - I don't include the java.management module to save space

Answer 26 · 2021-12-03T18:52:15.000Z

Here's what you could do:

Assume that anyone running the jar is not doing it through the bundled JRE, since that adds in the arguments by itself

Use reflection to access the Java management API and check if -XstartOnFirstThread was supplied

If reflection fails, as it would in the Mindustry JRE, do nothing - I don't include the java.management module to save space

I have considered that second solution but the problem with that is that it is supposedly unreliable. What about just bundling the -firstThread argument on steam and itch the way i was originally?

Answer 27 · 2021-12-03T18:53:59.000Z

it is supposedly unreliable.

In what way?

What about just bundling the -firstThread argument on steam and itch the way i was originally?

I'd rather not, it doesn't solve the problem of someone just launching the JAR with -XstartOnFirstThread.

Answer 28 · 2021-12-03T19:00:56.000Z

In what way?

I cant find the posts that mentioned it but a couple of the ones I found when I originally tried this a few months back mentioned that it wouldn't work on certain systems.

I'd rather not, it doesn't solve the problem of someone just launching the JAR with -XstartOnFirstThread.

I don't really see the problem with this though. It restarts before the gui is even created and takes a tiny fraction of a second to restart so its not even noticeable.

Answer 29 · 2021-12-03T19:10:15.000Z

I suppose another solution would be to use jni or something to call a c function to identify which cpu core the thread is running on however that is... janky.

Answer 30 · 2021-12-03T19:11:35.000Z

it wouldn't work on certain systems.

...but you're only targeting Java 8+ on MacOS specifically, was it known to fail on those? I don't see a problem.

I don't really see the problem with this though.

It might run with the wrong java executable or the wrong VM arguments or cause other problems related to re-launching Java. I just don't like it.

Answer 31 · 2021-12-03T19:33:33.000Z

...but you're only targeting Java 8+ on MacOS specifically, was it known to fail on those? I don't see a problem.

I have no idea on the specifics of this supposed unreliability but i suppose its worth trying

It also seems like libgdx might actually have a fix for it? libgdx/libgdx#6673

Answer 32 · 2021-12-03T19:38:21.000Z

I don't use GLFW, LWJGL or AWT, so libgdx's solution isn't worth investigating.

Answer 33 · 2021-12-03T19:42:46.000Z

~~damn it~~

Answer 34 · 2021-12-03T20:06:44.000Z

Hmm... it doesnt seem to work, my jdk doesnt set the JAVA_STARTED_ON_FIRST_THREAD_... variable

It appears that it doesnt work on either azul or temurin

Answer 35 · 2021-12-03T20:14:19.000Z

I still think that the best solution would be to use an additional command line argument here considering its reliable

Answer 36 · 2021-12-03T21:47:52.000Z

my jdk doesnt set the JAVA_STARTED_ON_FIRST_THREAD_... variable

What is "JAVA_STARTED_ON_FIRST_THREAD_"? What does getInputArguments() return in your tests? Does it return anything at all?

Answer 37 · 2021-12-03T22:41:56.000Z

JAVA_STARTED_ON_FIRST_THREAD_12345 indicates whether or not the program with pid 12345 is on the main thread.
I haven't really looked at getInputArguments but i think its just the stuff passed to the main method

Answer 38 · 2021-12-03T22:51:32.000Z

I just tried that approach on my VM with adoptopenjdk 16, and it worked. What does your code look like?

Answer 39 · 2021-12-03T22:51:46.000Z

Which approach did you try?

Answer 40 · 2021-12-03T22:53:55.000Z

Launch with -XstartOnFirstThread
Get ManagementFactory.getRuntimeMXBean().getName().split("@")[0];
Check that System.getenv("JAVA_STARTED_ON_FIRST_THREAD_" + pid); is 1

Answer 41 · 2021-12-03T22:54:26.000Z

Is it null when you dont run it with that parameter?

Answer 42 · 2021-12-03T22:56:10.000Z

I can't really check since this was run through the JS console on my crappy VM, and I can't use the console without the argument.

Answer 43 · 2021-12-03T22:56:26.000Z

Amazing lol, lemme go find out

Answer 44 · 2021-12-03T22:57:16.000Z

ffs thats what it was.., thats pretty dumb

Answer 45 · 2021-12-03T23:01:46.000Z

Ok, i think im done