I used to do the following command line in Java 6:
java -cp "d:\mylib\*" com.my.package.program
Now I upgraded to JDK 7 u1 64 bit and it started to complain that a jar can not be found. The jar IS in the mylib folder.
I looked in http://download.oracle.com/javase/7/docs/technotes/tools/windows/java.html
There is nothing specific written for Java 7. But is the info there up to date?
Java 7 single entry classpaths under windows seem to be broken. To work around this issue I split my classpath, because for some odd reason, java 7 classpaths under windows do work if they consist of 2 or more entries.
For example:
java -cp "d:\mylib\*;d:\myLib" com.my.package.program
or even
java -cp "d:\mylib\*;" com.my.package.program
would work with java 7. I am aware that this is by no means a very elegant solution, but at least the programs run.
Related
I changed the Java Compiler in my eclipse workspace to 1.8 and marked the JRE 1.8 as my default.
This change took affect over all java projects in my workspace (I can see that the JRE System Library is pointing to 1.8).
Now I want to generate new jars from these projects with Java 8, but when checking classes version it still points to Java SE 7 = 51 (0x33 hex) !
I made sure by opening classes on hex editor and checking the 6,7 bytes (https://en.wikipedia.org/wiki/Java_class_file#General_layout)
or by running this command:
C:\Program Files\Java\jdk1.8.0_151\bin>javap -verbose < myclass >.class | findstr major
major version: 51
example of one project:
I've just plainly imported the jar files and this error has appeared. I've tried multiple ways online but couldn't solve it.
This is the classpath that i've imported.
In JDK 9, the module java.corba which contains the interface org.omg.CORBA.portable.IDLEntity is not resolved by default and has to be manually added:
Add the module java.corba to the Explicitly included modules as described in this answer for java.xml.bind or use a Java 8 JRE/JDK.
See blog post Prepare for JDK 9 by Yolande Poirier (emphasis by me):
Six Java EE libraries in JDK are no longer shared by default in JDK 9.
Those Java EE deprecated APIs are java.corba, java.transaction,
java.activation, java.xml.bind, java.xml.ws, java.xml.ws.annotation.
They have been deprecated in JDK 9 and will be removed in a future
release. They are disabled by default in JDK 9. Their packages will
not compile in Java 9 and give an error message. The documentation
gives you migration options to enable those libraries in JDK 9. This
should be a temporary solution because they are scheduled to be
removed in a future release.
I created a jar file (compiled it using jdk1.7). When I used this jar in a project(using JRE 1.6), I get the following exception- unsupported major.minor version 51.0 (I suppose 51.0 is meant for jdk1.7). I used eclipse IDE for all these operations.
I am wondering whether this exception is a norm (in this kind of situation) or is it coming just because class loading in eclipse works differently
This is expected. Bytecode specifically compiled for a java version, can't be executed on a lower version. This is because it might have bytecode instructions and/or features not supported by an earlier Java version.
To compile for a lower java version, you need to explicitly specify the target version of compilation, eg:
javac -target 1.6 ...
In Eclipse you can set this under Properties > Java Compiler > "Generated .class files compatibility". However in general it is advisable to just use a Java 6 compiler to make sure you are actually only using features and libraries included in Java 6.
Class loading is performed by the JVM, both within eclipse and outside of it. This error simply indicates the the file format of class files has changed in Java 7, and a Java 6 virtual machine does't know the class file format from the future.
You can instruct the Java compiler to use the class file format of a previous java version (in eclipse, you can find the setting under Properties -> Java Compiler -> JDK compliance).
In addition, you'll want to verify that you only use API elements that also existed in JDK 6.
I try to deploy a simple "Hello Word" in my local server GlasshFish 3, but at the deploy the console print this message
[#|2013-01-15T15:00:02.458+0100|SEVERE|glassfish3.1.2|
javax.enterprise.system.tools.admin.org.Exception while deploying the app
[HelloWorldEJB] :UnsupportedClassVersionError: Class ejb_other.PlaceAuctionItemBean
as unsupported major or minor version numbers, which are greater than those found
in the Java Runtime Environment version 1.6.0_27|#]
My JAVA_HOME has java version 1.6.0_27 (it refers to _C:\Program Files\Java\jdk1.6.0_27_), my Eclipse (indigo) project refers to java 1.6.0_27.
I think (i don't know how to verify) that GlasshFish refers to JAVA_HOME.
In my PC (Windows 7) I found 2 directory having java.exe:
C:\Windows\SysWOW64>java -version -->>java version "1.6.0_29"
C:\Windows\System32>java -version -->>java version "1.6.0_27"
I found more discussions about this exception (f.e. this or this ), but I need of something more specific for Eclipse/Glasshfish, because I can't to solve. I see that the JVM is the same for compilation and execution.
Post Scriptim
I add the screenshot about the places where I declare JVM: it's always 1.6.
one:
two:
three:
Where can I see that I compile with java 7 or it runs with another JVM?
ejb_other.PlaceAuctionItemBean was obviously compiled for Java 7 which won't work if you run it in a Java 6 JVM.
Found solution
There's another place where setting the compiler's options:
how do I get eclipse to use a different compiler version for Java?
I have been struggling to get Buildr to compile my Scala 2.8 project and I was hoping someone might have figured this out already.
Currently I have the standard HelloWorld application with a buildfile like the following:
ENV['JAVA_HOME'] = 'C:\Program Files (x86)\Java\jdk1.6.0_17'
ENV['SCALA_HOME'] = 'C:\scala-2.8.0.Beta1-RC6'
define "HelloWorld" do
#artifact_ns['Buildr::Compiler::Scalac'].library = '2.8.0'
require 'buildr/scala'
puts Scala.version
end
When I run buildr I get the following output:
(in C:/Users/Travis/eclipse_ws/HelloWorld, development)
2.7.5
Building HelloWorld
Compiling HelloWorld into C:/Users/Travis/eclipse_ws/HelloWorld/target/classes
Buildr aborted!
←[31mScala compiler crashed:
#←[0m
The first problem is the NoClassDefFoundError - it cannot find the scala compiler's main class. The second problem is that Scala.version is printing out 2.7.5. This is incorrect because the SCALA_HOME path is pointing to a 2.8 release.
Finally, using the --trace flag shows me that Buildr is generating a somewhat correct scalac command and when I run that command manually everything compiles. I say it's somewhat correct only because some cp entries are duplicated. See the following:
scalac -classpath C:/scala-2.8.0.Beta1-RC6/lib/scala-library.jar;C:/scala-2.8.0.Beta1-RC6/lib/scala-compiler.jar;C:/scala-2.8.0.Beta1-RC6/lib/scala-library.jar;C:/scala-2.8.0.Beta1-RC6/lib/scala-compiler.jar -sourcepath C:/Users/Travis/eclipse_ws/HelloWorld/src/main/scala -d C:/Users/Travis/eclipse_ws/HelloWorld/target/classes -verbose -g C:/Users/Travis/eclipse_ws/HelloWorld/src/main/scala/hw/HelloWorld.scala
One more thing I tried (but errored out builder) was setting the following (which I thought wasn't required w/ the presence of SCALA_HOME):
#artifact_ns['Buildr::Compiler::Scalac'].library = '2.8.0'
So any ideas?
Here is a quick list of my system info:
Win 7 64 bit
JDK 6 32 bit set locally for buildr but JDK 6 64 bit system-wide
Ruby 1.8.6 32 bit
Buildr 1.3.5 32 bit
Scala 2.8.0.Beta1-RC6
One more thing I'm thinking of doing is reinstalling my 32 bit JDK and getting it out the the directory with the (x86) in the name. I've found that screws with the Scala bat files although I'm not sure if this is relevant to my current problems.
Thanks in advance!
Figured it out. Silly problem. In Buildr(or maybe more generically in Ruby?), the require method call must come at the top of the file (or at least not inside the define block).
require 'buildr/scala'
So both the NoClassDefFoundError and the incorrect version displayed by puts Scala.version were corrected by this. The following is what my script should have looked like:
require 'buildr/scala'
ENV['JAVA_HOME'] = 'C:\Program Files (x86)\Java\jdk1.6.0_17'
ENV['SCALA_HOME'] = 'C:\scala-2.8.0.Beta1-RC6'
define 'HelloWorld' do
puts Scala.version
end
BTW: Buildr seems to be pretty sweet (fast, concise, convention over config, etc.) once you figure what you are doing :-)
With version 1.4, at the moment you can do
Buildr.settings.build['scala.version'] = "2.8.0"
require 'buildr/scala'
And it will use scala 2.8.
Buildr 1.4 has support for Scala 2.8 and 1.4.2 will use 2.8 by default.