After upgrading Java from 1.6 to 1.7 x64 (on Windows 7), I suddenly can't launch java.exe via Python 2.7's subprocess module anymore. The following script used to just work:
import subprocess
subprocess.check_call([r"C:\Windows\system32\java.exe"])
Now it fails like this:
Traceback (most recent call last):
File ".\tst.py", line 2, in <module>
subprocess.check_call([r"C:\Windows\system32\java.exe"])
File "C:\Python27\lib\subprocess.py", line 506, in check_call
retcode = call(*popenargs, **kwargs)
File "C:\Python27\lib\subprocess.py", line 493, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python27\lib\subprocess.py", line 679, in __init__
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
I have also confirmed that C:\Windows\system32\java.exe does indeed exist, is an application, and can be executed from the command shell.
What goes wrong here?
EDIT:
I've found that I can start C:\Program Files\Java\jre7\bin\java.exe from Python, so C:\Windows\system32\java.exe must be some weird pseudo-shortcut although technically a Windows application. Version 1.7 must've messed it up somehow, since I just confirmed Version 1.6 is fine.
Assuming that there is a java.exe at "C:\Windows\System32" is not a particularly safe assumption. Even the assumption there is a "C:\Windows\System32" on the system isn't safe: Windows could reside on any fixed drive on the computer.
But even if there is a "C:\Windows\System32\java.exe", this might not be visible for 32-bit processes under Win64. Windows does some interesting things here in the name of backwards compatibility, you might want to look at http://en.wikipedia.org/wiki/WoW64.
Finding the Java version you're looking for - and there can be many - can be a thankless task. If you don't particularly care about which Java you find, try the JAVA_HOME environment variable. It's not always there, but if it is, you're done and it's probably the most portable way of finding a JVM. If it's not there, you can't go wrong by setting it, and many Java applications can make use of that variable.
Then again, Java just might be on the PATH, in which case removing the everything but 'java' in the subprocess call will do the trick. It can't hurt to try.
You might also want to check if the PATH environment variable has quotation marks "" around the jre's bin path. Python doesn't seem to like them:
C:\bin>set PATH=C:\Python27;c:\Program Files\Java\jdk1.6.0_35\bin
C:\bin>python -c "import subprocess; subprocess.Popen(['java', '-version'], stderr=subprocess.PIPE)"
C:\bin>set PATH=C:\Python27;"c:\Program Files\Java\jdk1.6.0_35\bin"
C:\bin>python -c "import subprocess; subprocess.Popen(['java', '-version'], stderr=subprocess.PIPE)"
Traceback (most recent call last):
[...]
WindowsError: [Error 2] The system cannot find the file specified
C:\bin>
Related
I had SunOs 5.10 unix server , where i had written a script to execute a java file which is as below
#!/bin/ksh -x
export JAVA_HOME=openjdk1.8.0_331/bin
$JAVA_HOME/java com.myclass.MyClient
in this script there is alot of code which includes log file, and other binaries class path added before exporting JAVA HOME. But when i am executing i am getting the below error
openjdk1.8.0_331/bin/java : Cannot execute
i had changes lot of java versions but getting the same error
Your JAVA_HOME is not an absolute path. This is broken; many tools will just fail when you do this. Just make it an absolute path. It may or may not explain your error, but it's a ticking timebomb.
JAVA_HOME cannot be bin; its the level above bin.
It looks like you're using JAVA_HOME as an ersatz script variable to make your script work, but this is wrong: JAVA_HOME is used by all sorts of tools and has a very specific meaning, and it's not whatever you think it is.
There are 2 obvious explanations for your error:
Some tool sees JAVA_HOME, attempts to run java based on this, and fails, because your JAVA_HOME is broken. There's a ton of infra that is 'custom' per OS, and it may well be that the SunOS setup didn't fail if you set JAVA_HOME to broken values, but it does fail here. The fix is to not have broken JAVA_HOME, not to start looking for a setup on your new OS that can deal with broken JAVA_HOME settings. In other words, your script was always broken, it just so happens that your specific set up on that specific server on that specific version of sun OS so happened to be capable of dealing with the mess.
A much simpler explanation is also possible: That executable does not run on your OS+Architecture combination. trivially testable: Do NOT set JAVA_HOME at all and just try to run that java executable by e.g. cd ing to the path and running ./java -version. See what happens. If that also gives you cannot execute, voila - the script isn't the problem (though it still has a broken JAVA_HOME you should be fixing), you need to install a JVM that works on your OS+Architecture.
As a total noob in Java faced with the task of making this program work asap, unfortunately I'm stuck on a loop after consuming the basic bibliography.
The scenario is a 32-bit Linux machine (Ubuntu 16), which has installed both OpenJDK 8 and 11.
And a Java Software where tree . yields
- shiftone-jrat.jar // <-- Special jar because it's outside "lib"?
- fooModule
- foo.class
- foo.java
- ...
- barModule
- bar.class
- bar.java
- ...
- ui
- Main.class
- Main.java // <-- Special Code because it has "main()"
- ...
- lib
- jogl.jar
- vecmath.jar
- gluegen-rt.jar
- ...
- run.bat
- .classpath
The presence of run.bat files suggest that it was compiled in Windows, and after opening .classpath one can note the process was managed from the Eclipse IDE.
As far as I understand Java is very portable so there is no need to recompile the files, we only need to run it.
The only command that has worked without errors is
java -jar shiftone-jrat.jar
But after a quick Google search one can note that jrat is only a profiler.
Thus, the relevant call has to be
java ui.Main
Nevertheless, that yields noClassDefFoundError: the first thing it can complain about before termination is a package called 'vecmath' which is part of our jars in ./lib. Therefore the option cp is added to the command java, like this
java -cp "lib/*" ui.Main"
In this case the problem is that ui.Main itself is not found, so the option is passed a new argument like this:
java -cp ".:lib/*" ui.Main"
Up to this point the previous questions on the same topic here on StackOverflow are very informative. For this particular case they are not sufficient, as the previous command opens a (blank) window that reports the following error:
no gluegen-rt in java.library.path
Where java.library.path includes common root places (e.g. /usr/lib/jni, /usr/lib, /lib and /usr/java/packages/lib).
Please note that there is a .jar called gluegen-rt.jar at ./lib, the same folder that made the previous error vanish by providing a jar called vecmath.jar.
Without fully understanding what .jars are, I downloaded libgluegen2 (and perhaps also jogamp,or it is included? sorry, I don't remember) from ubuntu apt.pkgs (which is the only one I've found, i.e. the "2"), and replaced the
lib/gluegen-rt.jar file with the jar from
/usr/share/java/gluegen2-2.3.2-rt.jar.
Again, I ran
java -cp ".:lib/*" ui.Main"
And now the NoClassDefFoundError mentions gluegen/runtime/DynamicLookupHelper.
A quick (cd /usr/share/java ; grep -r "DynamicLookupHelper") shows that jogl2.jar also matches and thus I also overwrite
lib/jogl.jar file with the jar from
/usr/share/java/jogl2.jar.
Finally the NoClassDefFoundError error is thrown again, this time because there is no such thing as javax.media.opengl, which is often used in the program java's files at imports.
A quick Google search yields that Java's implementation of OpenGL had "some" changes at "some" point in time, thus the lines
javax.media.opengl should be changed to
com.jogamp.opengl to comply with our "newest" version.
I made the changes but then some other lines were broken, so finally I appear to be faced with either (1) looking for the "right" jogamp and/or gluegen or (2) continue the migration. There may be 5k lines.
Questions such as: Is there any other option I'm missing? Is the whole procedure correct? Where are old versions available? Can I leverage the xml-styled .classpath file?
Thanks
I am running saxonhe9.jar from the command line (java -jar saxonhe9.jar -versionmsg) on MacOS El Capitan. No matter what .jar I download, the command returns "Saxon-HE 9.7.0.1J from Saxonica". I am not sure if this is an issue with just the version message or that version 9.7.0.1J is somehow hardwired to run when I call ANY saxon jarfile.
I've tried versions 9.4.0.9J, 9.7.0.15J, PE version 9.7.0.15J (trial version) and others. I have tried to clear my $PATH variables and change the $JAVA_HOME. I have uninstalled related packages (e.g. libxml2, libxslt) with Hombrew and pip (e.g. lxml). I'm all out of ideas. What could the issue be and how I could upgrade saxon?
The $PATH and $JAVA_HOME variables are irrelevant here. The presence of absence of other software products like libxml2 or libxslt isn't going to affect things either.
Your command will run whatever is in the JAR file named saxonhe9.jar in your current working directory. Start by doing "ls -l" to see what is in that directory (if necessary, show us the output).
Note that the Saxonica-issued JAR files would be named "saxon9he.jar" or "saxon9pe.jar". Perhaps "saxonhe9.jar" is a typo, and refers to some older JAR which has been renamed for some reason.
OS: Windows 7, 64-bit
Here I learn that the latest version of Jython (downloads/installs as "2.7.0") includes the "ensurepip" module, which hopefully installs pip.
This is what I get... NB there is no drive "Z:" on my machine
D:\apps\jython2.7.0\bin>jython -m ensurepip
Traceback (most recent call last):
File "<string>", line 444, in <module>
File "<string>", line 435, in main
File "Z:\jythondev\jython27\src\shell\build\jython\out00-PYZ.pyz\subprocess",
line 522, in call
File "Z:\jythondev\jython27\src\shell\build\jython\out00-PYZ.pyz\subprocess",
line 710, in __init__
File "Z:\jythondev\jython27\src\shell\build\jython\out00-PYZ.pyz\subprocess",
line 958, in _execute_child
WindowsError: [Error 2] The system cannot find the file specified
In fact I get the above error if I simply enter "jython" [Return]!
In the readme.txt file I see this:
This is the final release of the 2.7.0 version of Jython. Along with
language and runtime compatibility with CPython 2.7.0, Jython 2.7
provides substantial support of the Python ecosystem. This includes
built-in support of pip/setuptools (you can use with bin/pip) and a
native launcher for Windows (bin/jython.exe), with the implication
that you can finally install Jython scripts on Windows.
I have no idea what they mean by "you can use with bin/pip"... the bin directory (\bin on Windoze) contains 2 files: jython.exe and python27.dll.
Furthermore I don't know how to get the interactive terminal for Jython running with this
15 mins later
2 up votes! I wasn't expecting that. I thought it was likely something anomalous I had done on my machine was to blame. Now I'm beginning to wonder whether the Jython team (who are geniuses by the way) are just so uninterested in Windoze boxes that they just packaged this up and flung it out there without testing it on any Windoze boxes at all!
a few days later
Followed Jim Baker's advice: perfectly smooth installation. "pip install" working fine!
JAVA_HOME must be set such that %JAVA_HOME%\bin\java.exe is the Java executable, and the target java.exe must be Java 7. See this Jython bug. It is important to note that some other possible settings for that environment variable do not work - we expect that bin\java.exe can be joined to JAVA_HOME (using os.path.join to be precise). Also it is important to set JAVA_HOME exactly per what Windows expects in terms of quoting, etc:
set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_55
but not
set JAVA_HOME="C:\Program Files\Java\jdk1.7.0_55"
(Not at all the same! Just try it to see what I mean.)
The easiest way to debug these problems is with jython --print; for example on my system I get the following:
C:\jython2.7.0>set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_55
C:\jython2.7.0>bin\jython.exe --print
"C:\Program Files\Java\jdk1.7.0_55\bin\java" -Xmx512m -Xss1024k -classpath C:\jython2.7.0\jython.jar;. -Dpython.home=C:\jython2.7.0 -Dpython.executable=C:\jython2.7.0\bin\jython.exe -Dpython.launcher.uname=windows -Dpython.launcher.tty=true org.python.util.jython
Let me next explain the opaque error you are seeing. There are two things going on:
jython.exe is actually the Jython launcher; the real Jython we use is seen in the output of jython --print; it is org.python.util.jython, plus a bunch of other options. But we need an exe so that pip and other tooling can work. On Windows (or on other OSes if profiling for example is turned on), the launcher uses subprocess to invoke the Java executable. This subprocess invocation is in line 435 of jython.py.
Yes, that's jython.py. It actually uses CPython 2.7 (thanks for being around CPython, we like you!), and is wrapped into an executable by PyInstaller. The whole thing about "Z:\jythondev\jython27\src\shell\build\jython\out00-PYZ.pyz\subprocess",
is due to the fact that I built jython.exe on my Z: drive, onto which my install of Windows 8.1 on VMWare has mapped my OS X homedir. (Yes, I'm completely responsible for this build.) Next, out00-PYZ.pyz refers to some internal scheme used by PyInstaller.
We need to complete the release notes wiki update I mention on that bug! And of course fix that bug so it provides a better error message and possibly can recover in certain cases.
I also installed the Jython and was facing the same error after setting the JAVA_HOME to C:\Program Files\Java\jdk-10.0.2 works for me.
set JAVA_HOME=C:\Program Files\Java\jre1.8.0_281
jython
I am trying to run my java program from command line.
I read an article about setting up classpath, but I get an error of javac is
not recognized as internal or external command. What should I do? (I dont want to set a permanent CLASSPATH)
This is what I have done in my command line
D:\user> set path=%path%;C:\Program Files\Java\1.7.0_07\bin
D:\user> cd testing
D:\user\testing> javac firstProgram.java
'javac' is not recognized as an internal or external command,
operable program or batch file.
Thank you
Assuming that the PATH is correct1, the most likely cause is that you have a JRE installation ... and a JRE doesn't include a java compiler. You need a JDK installation if you want to compile from the command line.
(You can confirm this by looking in the C:\Program Files\Java\1.7.0_07\bin directory to see if it contains a javac.exe file. A JRE won't ...)
Where can I find the Java compiler to download..
You need to download one of the JDK installers; see http://www.oracle.com/technetwork/java/javase/downloads/index.html
1 - I don't think quotes are required in a PATH variable on Windows. At least that's what various examples that Google found for me seem to imply. But I've never really understood the logic behind quoting in Windows ...
Its an issue related to Program Files.
First make sure that your JDK Folder is installed in Program Files or Program Files(x86) or any other folder.
Then you should use the path of bin folder in " ". Because command prompt does break the string at space. When you will write it in " " then it will take is as a whole String.
You try these commands
set path=%path%;"C:\Program Files\Java\1.7.0_07\bin"
or
set path=%path%;"C:\Program Files(x86)\Java\1.7.0_07\bin"
It might help you to get out of this.
Better do it in Environmental variable and check it!
try below command is recognized from command prompt
C:\Program Files\Java\1.7.0_07\bin\javac ab.java
This is just to verify your javac
Here's how you can set the path temporary, meaning if you close and reopen "command prompt" you will have to set the path again.
Assuming the path is C:\Program Files\Java\jdk1.6.0\bin
TYPE IN C:\Program Files\Java\jdk1.6.0\bin AND HIT ENTER
that's it.
The commands D:\user> set path=%path%;C:\Program Files\Java\1.7.0_07\bin works well for me
Adding few more information to this:
Please check the version of JDK and JRE installed on your computer. Recently I faced the same problem even after setting the PATH. It gives the error "javac - command is not recognised"
Solution is there must be similar versions of JDK as well as JRE
E.g.: JDK 1.7.75 along with JRE 1.7.75