I'm on step "Running project on the Server" from https://developers.google.com/appengine/docs/java/webtoolsplatform#dynamic_web_project and I ran into a problem:
Error occurred during initialization of VM
agent library failed to init: instrument
Error opening zip file or JAR manifest missing : C:\Program
Another person reported a similar problem here: Error opening zip file or JAR manifest missing : C:/Program. But the solution was for a different set of technologies. I'm using Eclipse, Web Tools Platform, and Google-App-Engine.
Most likely it's because my Java is installed in C:\Program Files, a directory which contains a space. But I'm not sure how to fix this. I’m not sure how to safely move the Java\jre7 directory to a directory without a space in it.
Jordan Fish from Google Cloud Platform Support helped me solve this problem. He said:
As far as the error message when you try to start the dev_appserver, I believe this is probably due to a vm argument in the run configuration for your project. Can you please go to the run configuration (with the project selected, go to the Run menu and select Run Configurations), click on the Arguments tab, and see what is listed in the VM arguments text box?
Here was my original VM arguments:
-javaagent:C:\Program Files\eclipse\plugins\com.google.appengine.eclipse.sdkbundle_1.9.4\appengine-java-sdk-1.9.4\lib\agent\appengine-agent.jar -Xmx512m -Dappengine.fullscan.seconds=5 -Ddatastore.default_high_rep_job_policy_unapplied_job_pct=50
Here is what I changed it to (added double quotes around the directory that's passed as the -javaagent: param):
-javaagent:"C:\Program Files\eclipse\plugins\com.google.appengine.eclipse.sdkbundle_1.9.4\appengine-java-sdk-1.9.4\lib\agent\appengine-agent.jar" -Xmx512m -Dappengine.fullscan.seconds=5 -Ddatastore.default_high_rep_job_policy_unapplied_job_pct=50
This fixed my problem, I was able to complete step "Running project on the Server" from https://developers.google.com/appengine/docs/java/webtoolsplatform#dynamic_web_project
You just have to add "" to your jar file behind -javaagent:
If you use IntelliJ the solution appears to be slightly different. You need to edit the Run Configuration the same way that the Eclipse users do, but add the "VM Options" using this format instead:
-javaagent:[/absolute/path/DMEnhancerJava-1.0.jar][classes=META-INF/]
Note the formatting with the brackets after the colon with no spaces for each parameter. If you miss that you'll get a runtime error message about JavaAgent expecting that input format.
Also, remember that if you use a build tool like Maven or Gradle and add this to your JAVA_ARGS variable (via something like MAVEN_OPTS) you'll need to wrap the whole thing in double quotes.
The second parameter appears to be necessary to tell DMEnhancer what to instrument (mine was relative to the top level of my classpath; because my compiled POJOs were in the META-INF directory).
Lastly, you may notice that you sometimes get an error talking about a class being implemented in two places in the classpath internal to the VM:
Class JavaLaunchHelper is implemented in both <Two full classspaths shown here> One of the two will be used. Which one is undefined.
This seems to happen because of a bug in the JVM and is fixed (on MacOS X) in 1.8u152 (at the time of writing, this is considered an Early Access Release available here). See this other answer for more information on this JVM bug.
Run your cmd as an Admin. When you try to startup your server and you are not starting it up as an admin you get this error.
Rebuild your project or try mvn clean install
Export jar with manifest file in eclipse as follows:
OR
Merge manifest file with created jar.
CMD: jar ufm /Users/inzamam/Desktop/inzaa.jar META-INF/MANIFEST.MF
Related
My objective is to generate very basic unit tests for a lot of legacy code we are migrating to a new platform. (I know unit tests are not useful this way, but sometimes it happens). We are only blocked for covering percentage so it is good to go with basic tests in the methods we need, so going with an automatically generated tests will be the most efficient strategy.
I found RANDOOP https://randoop.github.io/randoop/ and start trying to make it work. However I found a problem, which in part is due to my almost zero knowledge of java ( I did something similar in .net with just a few clicks and in less than 4 hours).
I´m following official manual here https://randoop.github.io/randoop/manual/index.html#getting_randoop and the video of this guy who just makes it work https://www.youtube.com/watch?v=nPdb-72-EJY.
The Problem
Plain words the problem is the following error when I run this command
java -classpath 'C:\randoop-4.2.1\bin;C:\randoop-4.2.1\randoop-all-4.2.1.jar' randoop.main.Main gentests --testclass=ClassName
> Throwable thrown while handling command:
> java.lang.IllegalStateException: Cannot find the Java compiler. Check
> that classpath includes tools.jar java.lang.IllegalStateException:
> Cannot find the Java compiler. Check that classpath includes tools.jar
> at randoop.compile.SequenceCompiler.<init>(SequenceCompiler.java:64)
> at randoop.compile.SequenceCompiler.<init>(SequenceCompiler.java:48)
> at randoop.condition.SpecificationCollection.<init>(SpecificationCollection.java:82)
> at randoop.condition.SpecificationCollection.create(SpecificationCollection.java:102)
> at randoop.main.GenTests.handle(GenTests.java:279)
> at randoop.main.Main.nonStaticMain(Main.java:66)
> at randoop.main.Main.main(Main.java:30)
>
> Randoop failed. No sequences generated.
what is this above?
I run the command from console placed at the bin folder of randoop "installation" folder.
C:\randoop-4.2.1\bin is the folder where I unzipped Randoop download. Some weird thing is that none of the Randoop version downloads contains the bin folder, so I created it arbitrarily. I don't know if that is right or wrong, but I just did it.
At the beginning the video runs the following command, which is really basic and it worked ok on my system.
java -classpath .\randoop-4.2.1\randoop-all-4.2.1.jar randoop.main.Main help gentests
There is also a text file named myclasslist I don't understand why this guys never talk about. I don't have it.
I have Java 8 installed at c:\program files\jdk1.8.0_231and the Paths and environment variables are set like this.
EDIT
In the video, the guy has the .java file in the randoop root folder. I don´t since I have a real project in intellij. i just found the classs file and copied it to bin folder.
Your screenshot doesn't show System PATH environment variable.
Double check the actual PATH. It may point to JRE instead of the JDK and the System PATH has priority over the User PATH.
Randoop requires JDK to work, not JRE.
Try running:
"c:\program files\jdk1.8.0_231\bin\java.exe" -classpath 'C:\randoop-4.2.1\bin;C:\randoop-4.2.1\randoop-all-4.2.1.jar' randoop.main.Main gentests --testclass=ClassName
If it works, the issue is that default java.exe in your PATH is from JRE not from JDK.
Note that -classpath argument points to the jars or the directories with .class files, not to the individual .class files. See the documentation.
Above command should work if your ClassName.class file is in C:\randoop-4.2.1\bin.
See the related answer for JDK PATH configuration.
My maven build in failing on jdeps plugin (we need it to upgrade to jdk11).
The command line is too long for windows.
Here is the error I get:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jdeps-plugin:3.1.1:jdkinternals (default) on project myproject:
[ERROR] Exit code: 1 - La ligne de commande est trop longue.
[ERROR]
[ERROR] Command line was: cmd.exe /X /C
"
"C:\Program Files\Java\jdk-11.0.2\bin\jdeps.exe"
-cp "
C:\Users\Me\.m2\repository\com\something\firstJar.jar;
C:\Users\Me\.m2\repository\com\somethingElse\secondJar.jar;
C:\Users\Me\.m2\repository\com\somethingDifferent\someOtherJar.jar;
... and one more
... and another one
... I think you get the idea......."
--multi-release 9 D:\git\myworkspace\myproject\target\classes
"
How to shorten this command-line? (and make sure it is not user dependant)
Restriction: It is a shared project, changing anything only on my computer is not a solution.
The maven-jdeps-plugin is using plexus-utils to fork out a child process to run the jdeps executable. plexus-utils implements this by building up a command-line and passing it to cmd.exe. This is the wrong approach as it will be subject to the 8192 char limit imposed by cmd.exe. The correct approach would be to use the Java ProcessBuilder API. This itself uses ProcessImpl.create API method, which, on Windows, is implemented by a Win32 API call to CreateProcess. The latter API has a 32k char limit, which should be enough for most use cases.
There is a plexus-utils bug report for this. You may want to raise one with maven-jdeps-plugin as well - the Java ProcessBuilder API is quite usable, so there's no need to use plexus-utils just to run jdeps.
If you are using Windows 10 Anniversary Update or Windows Server 2016, or later, you can increase the maximum path length beyond the 260 character default.
You can either copy the following two lines into a file with a .reg extension and open it,
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001
Or, open the Registry Editor and browse to the location, and change the value from 0 to 1.
The best is to create empty jar file with classpath configured in manifest.
Official oracle document is at Adding Classes to the JAR File's Classpath
maven-jar plugin does support updating manifest classpath attribute: How to add Class-Path to the manifest file with maven
maybe a bit of a cheeky solution but...
what about using an env variable?
set MR=C:\Users\Me\.m2\repository\
"C:\Program Files\Java\jdk-11.0.2\bin\jdeps.exe"
-cp "
%MR%\com\something\firstJar.jar;
%MR%\com\somethingElse\secondJar.jar;
did not test, hope it works...
This is the reason Maven is meant to mange a large amount of dependency as you can simply place all of them in the .pom file. The use of the a centralized dependency list allows Maven to be able to see nearly everything you need to run your program. Take a look at this post that does what you're trying though add each of your jar's for Maven to see them. How do I package and run a simple command-line application with dependencies using maven?
Also, a good guide to the .pom basics
Read the pom guide on www.maven.apache.org.
Maven will not use cmdline arguments the way you are trying because of the Manifest specifications. This is the fundamental reason programmers, including myself, love Maven so it will really make life much simpler as it's built to do exactly what you need. As the files change you have one file to make your updated versions.
So I did struggle with this problem for a long time and finally found solution to this issue with too long classpath while doing maven build.
This is a workaround but it works perfectly.
Run build from linux - that't not a joke (sic!)
Turn on WSL(Windows Subsystem for Linux) on Windows by following
https://learn.microsoft.com/en-us/windows/wsl/install-win10
After all done just Run your Linux subsystem on windows
edit linux maven settings.xml /usr/share/maven/conf/settings.xml
Add or override <localRepository>/mnt/c/.m2</localRepository> (/mnt/c/.m2) - is my windows maven repo path seen from WSL
cd /path/to/your/project
mvn build
This is probably the most frequent question you get in the world, and I apologize, but I have to ask anyway. I recently downloaded the newest version of java (1.7.0_45-b18), and I recently finished making a small program for a local community of mine in Eclipse. I'd like to share it with them so anyone can run it by clicking it, but opening the jar file just hasn't seemed to work for me.
I attempted opening it with command prompt by using
java -jar StatCalc.jar
but it always tells me
'java' is not recognized as an internal or external command, operable program or batch file.
I looked up many solutions for this, the most common being to change your Path. So I went to the environment variables, and changed the path to
C:\Program Files (x86)\Java\jre7\bin\java.exe
But it still gives me the same result. Only when the directory is exactly in java, and the jar file is in the java bin folder can I run the program. I wan't any person to be able to run this.
How do I get command prompt to work and allow this program to be run by both me and other people in this small community?
The path shouldn't contain the executable itself - just the directory containing java.exe. So you want this on your path:
C:\Program Files (x86)\Java\jre7\bin
Restart your console, check that the path is correct (just run path and look at the output) and all should be well.
Note that if you're going to be developing Java code, you should probably use the JDK path instead of the JRE path. For example, my path contains c:\Program Files\Java\jdk1.7.0_17\bin. (Yes, I need to update :)
I hope you do not have changed your PATH variable, only added (...);C:\Program Files (x86)\Java\jre7\bin\ (on UNIX systems, use a colon (:) as the separator instead) at the end. Otherwise, you will have many issues with all other Windows applications. Note that you must add the folder that contains java.exe, not the path to the executable itself.
Then, try to restart your Command-Line or even your Windows session.
Optional: You may set JAVA_HOME to specify JDK location. See this link.
Here you have a tutorial of oracle for setting the path
http://docs.oracle.com/javase/tutorial/essential/environment/paths.html
C:\Program Files (x86)\Java\jre7\bin --> This would be your PATH variable.
I've built a JAR file and it executes fine on my PC (XP) which has Eclipse installed. It also works on another PC, which also has Eclipse.
I've tried running it on another PC(XP) that does not have Eclipse. Though it contains the JDK and multiple JRE. The JAR file just does not execute by clicking or from the command prompt.
I am not entirely sure, but my best guess is the Environment Variables are not set properly. Here is the error I receive from the command prompt:
Exception in thread "main" java.lang.NoClassDefFoundError: ...
Any help would be appreciated.
It must be a CLASSPATH issue.
The stacktrace should also say which class it failed to find. Once you have that, then find which jar has that class. Then add that jar file to your classpath or add it to the classpath env variable.
This is likely a classpath issue as others have said.
One thing to note is how your jar is constructed. You have a number of options in the dialog for exporting a runnable jar;
Extract classes into jar
Zip dependencies into the jar - creates jar-in-jar-loader.jar inside the jar.
Place jars in a subdirectory next to the jar.
Depending on what you have chosen for this depends on how the jar will behave. If the classes are extracted, dependent classes not in the JDK should be on the classpath. I'd recommend this course of action as it is simpler.
Now, the question is - are you using a dependency on your classpath not in the build dependencies of the eclipse project? If so, it won't be packed with / zipped into / put next to the jar because eclipse doesn't know about it (but java will still find it on your system because it's on the classpath). Also, if you've saved an ANT script and updated the build path in eclipse, eclipse won't update that ANT script - that is generated once only.
Environment variables are not considered when invoking a jar file when clicking on it (equivalent to running javaw -jar your.jar).
I'm pretty sure that it doesn't work on your first PC outside of Eclipse either.
I have a Java program that is calling C code through JNI that I'm attempting to run on Linux. The external code consists of two .so files: one for the JNI bindings (built with swig) and the other with the actual functions. I have the two libraries in the same directory and LD_LIBRARY_PATH is set correctly. ldd reports no problems when running from the command line, but when I set the LD_LIBRARY_PATH to the same value in the "run configurations" dialog in the Eclipse editor and attempt to execute the program, it gets the following error:
java.lang.UnsatisfiedLinkError: [path to libraries]/[JNI binding library].so: [actual code library].so: cannot open shared object file: No such file or directory
This leads me to believe that the JNI wrapper library is loaded successfully, but there is a failure when that library attempts to load the library containing the actual code. Is there any way to debug this further?
I will further note that this problem is happening in the eclipse editor itself and that I haven't attempted to package the code into a jar and run it within a free-standing jvm instance.
I think the issue is with the call to System.loadLibrary(String) and using LD_LIBRARY_PATH. Using loadLibrary("foo") will look in your java.library.path for something named libfoo.so. If nothing named libfoo.so is found you will get this error.
Now if you just set up the LD_LIBRARY_PATH, the native symbols you want will automatically be picked up by the linker, so you don't need to set up -Djava.library.path.
In my experience with swig in the gdal project, this error is actually harmless and since the LD_LIBRARY_PATH is set up, this will work fine.
I would recommend using -Djava.library.path and calling loadLibrary explitly, the reason being that if you ever decide to deploy your app with webstart, you will explicitly need to call loadLibrary to get your native libs picked up.
When I use eclipse I follow the instructions that Daff gave where you edit the native library under the jar in the Libraries tab in the Build Path. Just to mention again, this just sets java.library.path under the covers.
It may be that you just have to find the right place on the run config dialog to put the -Djava.library.path=... option. Offhand I think you want -D defines in the "vm arguments" on the arguments tab, whereas if you want to define LD_LIBRARY_PATH that goes on the environment tab. Eclipse will merrily let you put things in places where they won't mean what you think they mean. Anyway, I've used libraries this way before and if I get a chance I will look up what I did and edit my answer here.
Another thing to try is to play with LD_DEBUG. You can set the environment variable LD_DEBUG to various things (try ALL), and then the linux loader will divulge all sorts of useful information about what an application is trying to load, where it's looking for things, etc. Of course, this pre-supposes you launch eclipse from a command line, so you can both set the env vars and see the loader diagnostics; but as far as the system is concerned, when you run your app from inside eclipse, your app is just something eclipse is doing, so any library loading behavior can be seen in this way.
You could try -Djava.library.path=actual.so in command line parameters perhaps?
On windows, I had similar problems with a 3rd party library, which used a JNI wrapper DLL for its DLLs. My project had the DLL in the lib directory so I added lib to the PATH (e.g. PATH=%PATH%;./lib environment variable and everything started working.
As far as I know the Eclipse doesn't use the LD_LIBRARY_PATH.
The easiest way to set up the right native library path is to go to
Project properties -> Java Build Path -> Libraries
Then expand either the JRE System Library entry or (if available) the
Jar File that uses you native Library,
choose "Native Library Location" then click "Edit..." and choose the folder your libraries are in. Actually it does set the -Djava.library.path variable so you have to include this in your command line if you start your program from outside eclipse.
Are there any other libraries that your two libraries depend on? If so, you need to make sure they are also accessible to the JVM.
Be aware, manually setting "-Djava.library.path" seems to erase the default library path.
So with the following code:
public class LibTest {
public static void main(String[] args) {
String property = System.getProperty("java.library.path");
StringTokenizer parser = new StringTokenizer(property, ":");
while (parser.hasMoreTokens()) {
System.err.println(parser.nextToken());
}
}
}
Launched from eclipse with Java 1.6.0_14 outputs:
/opt/java/jre/lib/i386/client
/opt/java/jre/lib/i386
/opt/java/jre/../lib/i386
/opt/java/jre/lib/i386/client
/opt/java/jre/lib/i386
/usr/lib/xulrunner-devel-1.9.0.11
/usr/lib/xulrunner-devel-1.9.0.11
/usr/java/packages/lib/i386
/lib
/usr/lib
But when I set the JVM arg "-Djava.library.path=/tmp/" I only get:
/tmp/
If you are manually setting java.library.path this may explain why ldd works from the command line but your .so does not from eclipse/java.
You can try not setting java.library.path and use System.load with the absolute path to your library instead of calling System.loadLibrary. This may allow the JVM to find your .so and still use the default path when searching for its dependencies.
Of course, if this is no use then you can also try turning on jni debug output with "-verbose:jni" on the command line. This may give you some clues to the problem.
Yes the LD_LIBRARY_PATH worked for me
Adding this answer may be it can be useful In AIX Machines we need to setup LIBPATH environment variable instead of LD_LIBRARY_PATH.