JAXB 1.5 installed under C:\Sun\jwsdp-1.5
J2SE 1.4.2 installed under C:\j2sdk1.4.2_08
copied sample.xsd file to C:\Sun\jwsdp-1.5\jaxb\bin
went to C:\Sun\jwsdp-1.5\jaxb\bin and ran xjc.bat -p com.package sample.xsd
got error message: Unrecognized option: -p
Could not create the Java virtual machine.
Please help me out, thanks a lot
This page seems to indicate tha xjc.bat needs Java 1.5+ :
http://forums.sun.com/thread.jspa?threadID=5359378
The last JAXB version that is compatible with java 1.4.2 is JAXB 1.0.6. I've never heard of a version 1.5... Where did you get it?
Edit
This error message is not generated by jaxb but by the JVM. Looks like, the jvm thinks, the '-p' parameter is a jvm parameter. Here's another page where the same error message was generated at a simple java --version call.
And another explanation for the error.
I faced the similar problem and I resolved it using the following approach.
I specified Jdk1.5 as the JDK while installing jwsdp1.5. But the system had jdk1.4 also installed. So I created the following batch file:
set JAVA_HOME=D:\apps\BEA\Weblogic\jdk150_04
set ANT_HOME=H:\Sun\jwsdp-1.5\apache-ant
set JWSDP_HOME=H:\Sun\jwsdp-1.5
set PATH=%JAVA_HOME%\bin;%PATH%;
%JWSDP_HOME%\jaxb\bin\xjc -p package -dtd sample.dtd
This resolved the error. Alternatively we can remove the Jdk1.4 path in the PATH environment variable, in that case, we need to write the batch file.
Related
This question already has answers here:
uiautomatorviewer - Error: Could not create the Java Virtual Machine
(11 answers)
Closed 1 year ago.
The following error is displayed when the command is executed:
username#device:~/Android/Sdk/tools/bin$ ./uiautomatorviewer
Djava.ext.dirs=/home/username/Android/Sdk/tools/lib/x86_64:/home/username/Android/Sdk/tools/lib is not supported. Use -classpath instead.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
then I use --class-path in uiautomatorviewer file and face this error:
I use this method for editing uiautomatorviewer file: https://www.programmersought.com/article/53371586152/
error: unable to initialize main class com.android.uiautomator.uiautomatorviewer caused by: java.lang.noclassdeffounderror: org/eclipse/swt/widgets/control
mychange:enter image description here
original:enter image description here
And when I got the above error, I turned back to the previous state
And now I have the first issue again.
extera information:
$JAVA_HOME => /usr/lib/jvm/java-8-openjdk-amd64
$ANDROID_HOME => /home/username/Android/Sdk
Android studio version: 4.1.3
This is the output that I asked for in the comments.
+java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.20.04)
OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.20.04, mixed mode, sharing)
+exec java -Xmx1600M -Djava.ext.dirs=/home/alielyasi/Android/Sdk/tools/lib/x86_64:/home/alielyasi/Android/Sdk/tools/lib -Dcom.android.uiautomator.bindir=/home/alielyasi/Android/Sdk/tools -jar /home/alielyasi/Android/Sdk/tools/lib/uiautomatorviewer-26.0.0-dev.jar
-Djava.ext.dirs=/home/alielyasi/Android/Sdk/tools/lib/x86_64:/home/alielyasi/Android/Sdk/tools/lib is not supported.
Use -classpath
Firstly, we can see that the Java command that is being used is java, not a specific (absolute) pathname.
That is OK, but it means that $PATH will be used to resolve java to the actaul pathname of a Java launcher. (Not $JAVA_HOME.)
Second, we can see that java -version is telling us that it is using Java 11.0.11. As I mentioned in my comments, Java 9 and later do not support the "ext.dirs" mechanism.
Unfortunately, the java command's suggestion to use -classpath is not going to work (as-is).
So I am going to give you two ways to solve this:
Solution #1: Just use Java 8.
You need to make sure that you have Java 8 installed, and that running the java -version prints out that that the version number is 8.0.xxx, where xxx is (ideally) the latest available Java 8 patch release.
Since you are using using Ubuntu 20.04, there are two ways to make sure that you are using Java 8 rather than Java 11.
You could make Java 8 the default Java version globally using the "alternatives" system. Run man update-alternatives for the documentation. (You need to run update-alternatives as root ...)
You could make Java 8 the default for the current user or the current shell by changing the PATH environment variable.
Solution #2: Adjust the script so that Java 11 will work.
As I said above, simply converting -Djava.ext.dirs=... into a -classpath option doesn't work. That is because the exec line is using the -jar option, and when -jar is used -classpath is ignored. But -jar means this is an "executable JAR", and the entrypoint class name is coming from the JAR file's manifest.
So we need to unpick this.
First we need to know what the (full) entrypoint class name is, and also JAR file is setting its own classpath. We can determine by using the jar command to extract the META-INF/MANIFEST.MF file and looking it.
Next we need to form a classpath consisting of
the path that is currently given by $frameworkdir
the path for the main JAR file (i.e. $jarpath)
the path specified in the manifest file
The order of the path could be significant.
The entire classpath needs to be given to the java command via a -classpath or -cp option. (Not --class-path.)
Finally remove -jar $jarpath and replace it with the full entrypoint class name. (It is a class name, not a pathname. Don't change the dots to slashes, add a suffix or do anything like that. Use the name exactly as the manifest file gives it.)
This approach should work, but I can't test it. If it fails, please comment below.
When I try to use the EvoSuite testing tool from the command line, I get the following error:
Fatal crash on main EvoSuite process. Class using seed 1428172877144. Configuration id : null
java.lang.RunTimeExceptionConfiguration:Did not manage to automatically find tools.jar. Use –Dtools_jar_location = <path> properly
at org.evosuite.runtime.agent.ToolsJarLocator.getLoaderForToolsJar<ToolsJarLocator.java:71> ~[evosuite-0.1.1.jar:na]
at org.evosuite.Evosuite.parseCommandLine<Evosuite.java:152> ~[evosuite-0.1.1.jar:na]
at org.evosuite.Evosuite.main<Evosuite.java:304> ~[evosuite-0.1.1.jar:na]
Could someone help me with this?
Make sure you use your JDK to run Evosuite, not the JRE. That may mean either going into the JDK /bin dir and running from there or fully quantifying the executable java binary file when you run (JDK..../bin/java.exe on windows for example).
Copy the tools.jar from JDK to your JRE lib folder...it worked for me..The problem, its not able to find the tools.jar.
As pointed out by Makoto, you need to use a -D option. Note: no space between variable name and assigned value, ie -Dx=v is OK, whereas -Dx = v is wrong. So:
java -jar evosuite-0.1.1.jar -Dtools_jar_location="C:\Program Files\Java\jdk1.7.0_75\lib"
I'm desperate. I have read all topics about this problem here and it doesn't help.
I had written a simple app and tried to run it using Jetty Runner. It works well on my local machine. But after that I tried to add servlet filter (because Jetty has issues with servlets on welcome-file-list). Now it prints to me:
org.apache.jasper.JasperException: PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
My JDK and JAVA_HOME is OK. I'm using jdk1.8.0_25.
I read about:
<Call class="java.lang.System" name="setProperty">
<Arg>org.apache.jasper.compiler.disablejsr199</Arg>
<Arg>true</Arg>
</Call>
or
-Dorg.apache.jasper.compiler.disablejsr199=true
I got this problem with it:
org.apache.jasper.JasperException: PWC6349: Cannot find a java compiler for compilation. If running with JDK 5 or before, Ant or JDT compiler can be used, if the corresponding jars and bridge classes (org.apache.jasper.compiler.AntJavaCompiler or org.apache.jasper.compiler.JDTJavaCompiler) are included
I'm using IDEA, Maven and .sh-file to run Jetty.
java -jar target/dependency/jetty-runner.jar target/*.war
The strange thing is - I've tried to deploy this app with servlet filter on Heroku and it WORKS WELL.
Could you help me please with this problem?
Set -Dorg.apache.jasper.compiler.disablejsr199 to false and make sure you jave jdk on the path, meaning your path should look like "C:\Program Files\Java\jdk1.7.0_67\bin" NOT C:\Program Files\Java\jre\bin.
I'm trying to install MapServer on my Linux CentOS 5.9 server but keep getting the same error.
checking if --with-java-include-os-name specified... no, autodetected linux
checking for javac... /usr/bin/javac
checking symlink for /usr/bin/javac... /etc/alternatives/javac
checking symlink for /etc/alternatives/javac... /usr/lib/jvm/java-1.4.2-gcj/bin/javac
checking symlink for /usr/lib/jvm/java-1.4.2-gcj/bin/javac... /usr/bin/ecj
configure: error: cannot find java include files
I read somewhere else that this could be fixed by installing sun-jdk packages instead of gjc. Now, the thing is is I don't have root access on my work computer currently. So I tried downloading the jdk files onto my desktop and configuring using
./configure --with-java-include-os-name=~/Desktop/jdk1.7.0_21
but still got the same error.
checking if --with-java-include-os-name specified... yes (~/Desktop/jdk1.7.0_21)
checking for javac... /usr/bin/javac
checking symlink for /usr/bin/javac... /etc/alternatives/javac
checking symlink for /etc/alternatives/javac... /usr/lib/jvm/java-1.4.2-gcj/bin/javac
checking symlink for /usr/lib/jvm/java-1.4.2-gcj/bin/javac... /usr/bin/ecj
configure: error: cannot find java include files
I'm not really sure I'm using that command right. But my main question is how do I fix this error without root access? Is that possible? Do I need to ask for the root password to install sun-jdk? And if I did that how do I change where the configure file will look for the include files it needs so that it stops looking in the gcj files?
Thanks.
I was facing the same issue with Macports version of Mapserver. They are still on version 6.2.1, which is one the last versions not to use CMake. As of version 6.4, Mapserver is using CMake.
To get around the issue, you need to edit configure script. Search for string "cannot find java include files" and just comment out the line which halts the execution when java include files are not found.
This isn't a fix, but just a dirty workaround to get you through a bug in configuration process. This should give you a fully working build.
I have a .jar file that works perfectly on my mac, but I need to run it on the web server... So when I use command line to make this file work it gives me this error:
[root#mysite.com dist]$ java -jar PDFparser.jar ffive.pdf
Exception in thread "main" java.lang.NoSuchMethodError: method java.lang.String.getBytes with signature (Ljava.nio.charset.Charset;)[B was not found.
at org.apache.commons.io.IOUtils.write(IOUtils.java:1527)
at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:1929)
at org.apache.commons.io.FileUtils.writeStringToFile(FileUtils.java:1962)
at pdfparser.PDFparser.main(PDFparser.java:171)
I am not the one who created that .jar app but it works just the way I need on my mac... but it need it for the site, so I need it to be working on the web server... Does anyone know what does this error mean and what should I do? I don't know Java language so it would be awesome if you explain to me what should I do like I'm very stupid person...step by step... :)
String.getBytes(Charset c) has only been available since Java 1.6. Most likely, the Java version on your Mac is 1.6+, but your target server is less than 1.6.
You will need to update to at least Java 1.6 on your web server for this method to be available.
Source
This
java.lang.NoSuchMethodError: method java.lang.String.getBytes with signature (Ljava.nio.charset.Charset;)[B was not found.
means that a class in your jar file couldn't find a corresponding method in the Java installation. I suspect your jar file was created with a java version greater/newer than that installed on your web server.
On your working server, type
$ java -version
and do the same on your web server, and compare the version numbers.
There is no issue with your mac or the webserver. The jar was created with a lower version of Java (1.5 or below) while String.getBytes() is only available with java 1.6+.
There is a version mismatch.