We Keep Coding

Difference in execution speed between eclipse and my compiled program

I have a strange problem. I noticed that on operations where there are variable manipulations in for loops with a lot of iteration, there were big differences in terms of execution time between these two situations:
The program is launched by Eclipse
The program is launched in terminal with a "java -jar ..."
The same loop takes 1 hour with the terminal and 1 minute under Eclipse! (it is about reading a CSV file and putting the columns in a table)
I specify that my program has these VM parameters:
-Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.http.auth.proxying.disabledSchemes="" -Dsun.net.http.allowRestrictedHeaders=true -Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2" -Xms2g -Xmx40g -Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2"
But the problem doesn't come from there I think. To validate this point I proceeded as follows:
I went in the VM arguments of the program launcher in Eclipse and checked that they were there
I looked at the default JVM used by Eclipse in the general settings and I used this path to launch my program in terminal with this command :
"C:\Program Files\Java\jdk-11.0.11\bin\java.exe" -Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.http.auth.proxying.disabledSchemes="" -Dsun.net.http.allowRestrictedHeaders=true -Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2" -Xms2g -Xmx40g -Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2" -jar run.jar
Is there anything that can explain this performance difference? I would like to get it back so that my program can run faster.

Running java program through command-line jdb executes correctly but fails when executed as java command-line

I am relatively unexperienced in java, so hopefully I will be able to provide enough information here for this to be relevant and useful for other people.
I am trying to run someone else's codebase that takes two input files, prints some information to STDOUT while running the code through them and quits.
I compiled the code with a command like the one below:
java -g -cp .:../../deps/dep1.jar:../../deps/dep2.jar:../../deps/dep3.jar nameofclass/Nameofclass.java nameofclass/File1.java nameofclass/File2.java nameofclass/File3.java
I can then execute with jdb as shown below:
jdb -classpath ".:../../deps/dep1.jar:../../deps/dep2.jar:../../deps/dep3.jar:" nameofclass.Nameofclass file1.ext file2.ext
Then in jdb:
run nameofclass.Nameofclass file1.ext file2.ext
When I do so, in jdb I get the print out of the process that correctly runs the code, and finishes with a The application exited:
Set uncaught java.langh.Throwable
Set deferred uncaught java.langh.Throwable
>
VM Started: /path/to/src
<print out of the code running correctly>
The application exited
So far, so good. When I try to run the same code with java instead of jdb, I get:
java -cp ".:../../deps/dep1.jar:../../deps/dep2.jar:../../deps/dep3.jar:" nameofclass.Nameofclass file1.ext file2.ext
Exception in thread "main" java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: java/lang/invoke/StringConcatFactory
with the trace pointing to a line of code at the very beginning of the main function, which does not seem to have any issues running with jdb.
Any ideas how to run the code that I can run successfully with jdb but simply with java on the command-line here?

It turns out the StringFactory error was pointing the fact that my Java installation was borked in my Ubuntu 16.04, with jdb running Java 9 but java pointing to a /usr/bin/java version much older than that. I corrected the issue with:
https://askubuntu.com/questions/176121/dpkg-error-trying-to-overwrite-file-which-is-also-in
and finally running:
sudo update-alternatives --config java
After doing that, running java similarly to jdb worked.

Running batch file from java causes hang, but not when running it normally

I am running a batch file which runs a battle in Robocode from within java, and then collecting the results of the battle. The code I am using to run the batch file is:
Process p = Runtime.getRuntime().exec("cmd /c C:\\Users\\Joel\\Documents\\ver5Files\\battle.bat");
p.waitFor();
The contents of my batch file are:
cd "C:\robocode"
java -DNOSECURITY=true -Xmx512M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar robocode.Robocode -nodisplay -battle battles\DT_battle.battle -results resultsv5.txt
exit
This works fine if I run a battle with less than 35 rounds in robocode, however when I try and run one with 35 or more battles the code hangs and never returns to the java code.
I investigated further by running modifying the batch file so that it ran with a display, so I could watch the battles and find out where it was hanging. Once the 35th battle is done, it enters the "Round 35 cleaning up" step, and basically gets hung up there. The program isnt frozen or anything, it just wont initialize the next battle.
I have discussed it with someone who is working on a similar project and they are not having these issues, nor does our code differ significantly for this part. I have tried running it on two different machines, but get the same result on both.
Any advice?

Try to use /k instead of /c and tell me if it works.
Well, if you look at cmd.exe commands you will see it has many options. Some of them are:
/C Run Command and then terminate
/K Run Command and then return to the CMD prompt.
This is useful for testing, to examine variables
You may find more options here.

Running Java Infinite Loop in Ubuntu

Hello I am making a Java program in an Ubuntu Web Server but it is always supposed to be running in an infinite loop, or at least until I stop it. When I run it in the Ubuntu console it won't allow me to keep using the console. To work around this I have been using the "screen" command and detaching the screen.
I was wondering if there is a better way of doing this without working with the screen command?

Run a program immune to hangups
If you're happy with starting the Java program up manually from the command line, but just want to not have screen running, you can use the "nohup" command to start the Java process in such as way that the Java program will continue running even if you close the console window or log out.
$ nohup java ...
nohup: ignoring input and appending output to `nohup.out'
$
Run a program in the background
If you don't mind the Java program stopping if you close the console window or log out, you can skip using "nohup" and only append a "&" to the end of the command to tell your shell to run the application in the background. You may also want to add " > program.log 2>&1" to the command to avoid having any output from the program show up in the console window while you're using it for other purposes.
$ java ... > program.log 2>&1 &
[2] 3128
$ jobs
[2]+ Running java ... > program.log 2>&1 &
$
Run a program as a daemon
If you want the Java program to automatically start up every time you reboot the machine, you should look into creating a SYSV init-script, or as you're running on Ubuntu, an Upstart Job definiton.

How to start a java-web-start application and wait until it exits?

I just found out that javaws -wait doesn't do what is supposed to do on Windows. It will return before the aplication finishes.
This bug is more than 5 years old and closed as won't fix
6281477, so we need a workaround.
I looking for a clean solution that will:
run unattended (no user intervention):
currently if JNLP file is not accessible, Java will display an error window.
if application fails for any reason we need a return code different from 0
It would be preferable to have a cross platform solution for this Java or Python but it would be acceptable even a Windows batch solution.

If you don't need your application to be booted from the web (which, from your question, I assume is the case), use javaw instead.
I believe it will give what you want.

I know this question is pretty old, but here is an alternative to javaws -wait: javaws will start a javaw process with com.sun.javaws.Main as main class.
The jcmd can come to the rescue:
while jcmd com.sun.javaws.Main PerfCounter.print > /dev/null 2> /dev/null ; do
echo "still running !"
sleep 2
done
One down side of this is to determine the actual java cmd: if multiple webstart application are ran, then the command will exit only if all application are down.