How to debug Getdown when it is not working (but running the command it says it will run does)

[Colin Fraser]

Hi,

The subject pretty much says it all.

We have a getdown app that we are now running on Windows 10. I am having trouble getting the getdown version of the app to work.

I have this from the launcher log:

...

2019/05/29 14:40:13:348 INFO Install completed.

2019/05/29 14:40:13:348 INFO Didn't find any custom environment variables, not setting any.

2019/05/29 14:40:13:348 INFO Running C:\Program Files\Java\jre1.8.0_192\bin\javaw.exe

  -Dcom.threerings.getdown=true

  -Djava.library.path=C:\BalApp\lib\native\Win64

  -DJSP_OSNAME="Windows 7"

  -DJSP_OSARCH=amd64

  -jar

  C:\BalApp\lib\balance_gui-3.2.5.jar

Error: Could not find or load main class 7

And the app doesn't start... I assume because of the error mentioned. However, if I take the above and paste it into the terminal as:

C:\BalApp>"C:\Program Files\Java\jre1.8.0_192\bin\javaw.exe" -Dcom.threerings.getdown=true -Djava.library.path=C:\BalApp\lib\native\Win64 -DJSP_OSNAME="Windows 7" -DJSP_OSARCH=amd64 -jar  "C:\BalApp\lib\balance_gui-3.2.5.jar"

Then it works.

So it would seem that the starting process of getdown is causing things not to work...

Any help appreciated.

Regards

Colin

[Colin Fraser]

Note when running the app from the command line, I think the app may throw an exception early on which is caught in the App's gui and shown to the user, then the app continues on to load the main window... not sure if this has any effect when the app is run from the getdown launcher... either way, it still behaves differently (i.e. it works) when run from the command line.

Colin

[Michael Bayne]

I'm guessing it's the -DJSP_OSNAME="Windows 7" argument that is somehow causing trouble because the error is consistent with the quotes somehow getting lost and Java thinking that "7" is the name of the class to be loaded.

Getdown executes the Java process using the form of Runtime.exec that takes the command line arguments as individual strings and should thus not be subject to parsing by a shell (which might split them on whitespace). So it's very strange that this is happening.

Maybe somehow javaw.exe is further processing the arguments?

As an experiment, you could try to remove the -DJSP_OSNAME config to see if it launches successfully. If that does fix it, then that will be useful to know to further debug the problem. Specifying a JVM argument like that on macOS doesn't cause problems with launching the app, so it must be a Windows-specific issue.

Attention:

The information in this email and in any attachments is confidential. If you are not the intended recipient then please do not distribute, copy or use this information. Please notify us immediately and then delete the message from your computer. Any views or opinions presented are solely those of the author.

--
You received this message because you are subscribed to the Google Groups "OOO Libs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ooo-libs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ooo-libs/daa28b35-d802-4505-a768-9c83235139ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- m...@samskivert.com

[Colin Fraser]

Thanks, that might be it... 

I removed this parameter and the class not found error went away... The app seems to be getting past that now, but has other problems which might not be related to getdown. I can't test it properly until I am back in the office next week, so I will report back for sure then.

Thanks

Colin

[Colin Fraser]

I can confirm that adding

jvmarg = -Dtest_arg="Item with space"

stops the app from launching, and removing the argument, doing nothing else and rebuilding, the app will launch as normal.

So yes, seems to be a bug with jvm args with spaces (note this was using version 1.7.1).

Regards

Colin