When I try to run a code snippet in Java Scrapbook, Eclipse cannot start the VM with the following error:
Unable to launch scrapbook VM
Exception occurred executing command
line.
Cannot run program "C:\Program
Files\Java\jdk-14\bin\javaw.exe" (in directory "C:\tmp"):
CreateProcess error=206, The filename or extension is too long
There was a bug report in Eclipse's Bugzilla, but it was closed without a satisfactory answer.
The other similar answers on SO have different causes:
Starting in directory with an unusual name
Starting in an Android project
I tried changing the working directory to C:\tmp so that any issues caused by directory structure are solved, but to no avail.
Environment: OpenJDK 14, Eclipse 2020-06, Maven project
The actual problem is that Windows cannot start a program whose command line is longer than about 32000 characters. This can happen if you have so many dependencies that the command line arguments reach the limit. This is why changing the directory to C:\tmp did not help, the size of this part is negligible when compared to all the dependencies on the command line.
There's a nice answer to a different question which contains some useful tips which can help out.
I initially worked around the issue by running the code snippet in a newly-created project, but this was only possible because I did not need any parts of the project I'm working on.
The real solution was to switch to Linux because pretty much all distributions have limits which exceed those of Windows by an order of magnitude or more.
Related
I'm new to Stack Overflow (though a long time lurker).
I'm struggling to install elasticsearch on my laptop. It's windows 8, I've just updated java to Java 8 and I've set the new path using set JAVA_HOME.
However, whenever I try to run the elasticsearch.bat file on the command line, I get this error:
\elasticsearch-5.0.2\bin\..\config\jvm.options was unexpected at this time
Any help would be greatly appreciated on this matter
I've also tried to setup the ElasticSearch on my Windows 2016 R2 Datacenter (64-bit). Let me share some of my experiences on how to solve this.
Setting up JAVA_HOME
Ensure that you have JDK/JRE installed. You can download it here.
Set the JAVA_HOME environment variable. To do this, open the Start menu and type in "path".
Then click on Environment Variables. If you don't have JAVA_HOME variable set yet, click New.
The JAVA_HOME variable should only lead up to the JDK/JRE directory, not including /bin.
C:\Progra~1\Java\jdk1.8.0_112
Progra~1 corresponds to Program Files. If you use Program Files (x86), change Progra~1 to Progra~2
Restart your computer. Once your computer is restarted, open up CMD and type in echo %JAVA_HOME%. The output should be
C:\Progra~1\Java\jdk1.8.0_112
If you get the following output, your JAVA_HOME is setup correctly.
Running ElasticSearch
The first time I tried to run ElasticSearch, I get the following output.
The odd directory I pointed out here gave me a hint that the batch file might be reading from the wrong directory. So what I did was tinker around with the batch file a bit. Open elasticsearch.bat using any text editor.
Scroll all the way to the end, somewhere above the last lines you'll see something similar to the following.
Remove the highlighted line, save the file and try running the batch file again via command prompt.
It works in my case.
Once you have this, open up your browser and navigate to localhost:9200.
I think that's it?
Your problem is most likely caused by parentheses in the path to where you unzipped and are running Elasticsearch from. The related issue in the Elasticsearch repository is #24712 which will be fixed with Elasticsearch 5.4.1.
Be aware that by applying Nicholas Lie's "fix" you are telling Elasticsearch to effectively ignore all settings in config/jvm.options. While this may help you to start Elasticsearch in this specific case, it will only start with default JVM options which might lead to surprising behavior down the road.
After a long time I tried to run my Eclipse, I got:
Failed to create java virtual machine
So I searched and tried changing some eclipse.ini lines to -Xmx512m.
I thought it was Eclipse problem, I tried command prompt but the java command returned:
/lib/ext exists, extensions mechanism no longer supported; Use -classpath instead.
.Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I have jre1.9.0 (which I don't remember installing this version).
The extensions mechanism was removed in Java 9, much to my irritation. You could specify an extensions directory on -Djava.ext.dirs or extension jars could be put in $JAVA_HOME/lib/ext and all the jars would be loaded before loading your classpath, and even before a lot of standard libraries. The lords of Java decided that nobody was using this, but I beg to differ. JDK9 release notes.
Disclosure: I'm not super familiar with Java, so if anything rings untrue below, please point out
I'm trying to run some microbenchmarks with Caliper for instrumented code, with an instrumented JRE.
I set my JAVA_HOME to point to the instrumented JRE, (so that $JAVA_HOME/bin/java is appropriate). I setup various options using $JAVA_TOOL_OPTIONS (including a bootclasspath and javaagent).
I then run caliper as I usually would (which when using a non-instrumented JRE works fine), and I keep getting the following exception
An exception was thrown from the benchmark code.
java.lang.RuntimeException: failed to start subprocess
at com.google.caliper.Runner.measure(Runner.java:278)
at com.google.caliper.Runner.runScenario(Runner.java:229)
at com.google.caliper.Runner.runOutOfProcess(Runner.java:378)
at com.google.caliper.Runner.run(Runner.java:97)
at com.google.caliper.Runner.main(Runner.java:423)
Caused by: java.io.IOException: Cannot run program "java" (in directory "extra/"): error=2, No such file or directory
I've tried making sure the $JAVA_HOME/bin/ is first in $PATH, tried symlinking $JAVA_HOME/bin/java to the current working directory, but all to no avail.
Anyone have any suggestions? I've probably spent upwards of 5 hours trying to work through this one...
[EDIT]
So I think this might be a broader question, focusing on the instrumented JRE. I ran a simple test, where I create a ProcessBuilder that just runs ls. It works fine with non-instrumented java, but fails with the instrumented version, with the same kind of error (error=2). Any suggestions?
The issue was not with caliper, or broader instrumented JREs, but rather I had not chmod +x jre/bin/* and chmod +x jre/lib/*. After that, the issue was resolved.
I get the following error.
Cannot run program "/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java" (in directory "/Users/samschmid/Privat/dev/amsf/App-Management-System-Framework/App Management System"): error=7, Argument list too long
Cannot run program "/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java" (in directory "/Users/samschmid/Privat/dev/amsf/App-Management-System-Framework/App Management System"): error=7, Argument list too long
i search on google for 7 hours and no solution worked for me. Does anybody have a hint for me?
Probably your project has a huge list of dependencies, so when gwt compiler or dev mode is launched, such a classpath generates a long command line.
Your problem is not related with java nor gwt, but with your OS limits.
Change the limits in your system. Take a look to this post:
http://www.cyberciti.biz/faq/argument-list-too-long-error-solution/
I launch the following command line (process) from a Windows VC++ 6 program using CreateProcess (or _spawnv()):
java -cp c:\dir\updates.jar;c:\dir\main.jar Main
and class updates in updates.jar (overiding some in main.jar) are not read or found. It is as if the updates.jar library cannot be found or read.
If I launch the same line from a shortcut, or from the command line proper, everything IS found and executes properly.
If I launch a JVM from the command line, keep it running, AND THEN launch the executable stub (above), then everything works OK also. (This makes it look like the issue is a file rights thing).
Any insight would be greatly appreciated!
--Edward
Try using Microsoft's FileMon utility to figure out what's happening. Set the include filter to "updates" to focus in on the problem.
http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx
Have you tried this on another machine? Another OS? Which JVM are you using? Have you tried different JVMs?
Can you provide us with a minimal example which demonstrates the problem?
Thanks jdigital!
I tried FileMon and it showed me what I was doing wrong. The executable calling CreateProcess() had an unclosed file handle to updates.jar from an attempt to copy the update JAR earlier. Bad code that works in the production environment, but not in the test environment.