Fast-ClassPath-Scanner
https://github.com/lukehutch/fast-classpath-scanner using latest version.
On executing(get names of all classes in war which includes all jars and classes)
new FastClasspathScanner(basePackage).scan().getNamesOfAllClasses()
getting:
unsupportedclassversion error with jre 6
Please provide a solution to it or alternative to perform same.
FastClasspathScanner is compiled for java 1.7
When you try to load it in a 1.6 (JRE6) environment it fails with an UnsupportedClassVersionError. This error indicates that the class version (here 1.7) is not compatible with the JVM version (here 1.6).
Java 7 is not backwards compatible with Java 6. You could try to build the FastClasspathScanner library yourself unter 1.6 (not sure if that's possible). Or upgrade your project to Java 7.
Correct, I am the author of FastClasspathScanner, and it's not a goal to get this working with JRE6. However, patches for supporting 1.6 are welcome.
Related
On the main page I noticed that JJWT is supposed to run on all JDK, which - since our project for all sorts of reasons is still stuck on v1.6 - sounded great.
With the last version maven retrieves however, the class version is not compatible.
And afterwards in the build wiki I noticed it specifies version 7.
Anyone have a clue what does run on v1.6.
Can I use an older version, or should I compile it myself maybe.
On the main page I noticed that JJWT is supposed to run on all JDK ...
That is definitely incorrect / inaccurate. The initial commits for the JJWT project were for JDK 1.6. And I can see that the code uses generics, so compiling / running for earlier than JDK 1.5 will be impossible.
The POM.xml file for the latest version of the project sets the source and target version for the project to JDK 1.7. So certainly the artifacts that a standard build will generate now will NOT run on a Java 6 platform. The class file version will be too recent for a Java 6 JVM to understand.
Now you could try changing the JDK level to 1.6 in the POM file in the HEAD version. However, the JDK version for JJWT was bumped past 1.6 four years ago, so there are liable to be build issues if you wind back. (The developers could have introduced Java 7+ dependencies; e.g. using try with resources syntax or Java 7+ APIs.)
A better idea would be to use an old version of JJWT. You should be able to figure out what version you need to use (or build) for JDK 1.6 compatibility by looking at the project's git history on Github. Look at the relevant changes to the POM file and when they happened. I think it is version 0.9.0 or thereabouts.
Of course a better solution would be "unstick" your project. JDK 1.6 is 8 years past its end of life, and 3 years past the end of Oracle's JDK 1.6 (paid) extended support.
Does VS Code (code-runner extension) support JDK 1.8? In the morning I was using JDK 12 , but then I downgraded to JDK 1.8 to try out applet viewer and stuff. Unfortunately now it doesn't even highlight the code.
Someone please tell me the problem and its solution.
JDK 1.8 is supported by VSCode.
Read https://code.visualstudio.com/docs/languages/java and install needed extensions.
Update 2021
Currently to use the Java extension in VSCode its required JDK 11, but you can still use older versions of JDK in your projects. See this to get information about how to configure other JDK version for your project.
Java 1.8 was no longer supported since "Language support for Java" extension upgrade to 0.68.0, I downgraded to 0.64.1 which works for me.
As stated here:
Note: Although the Java language server requires JDK version 11 or above to run, this is NOT a requirement to your project's runtime.
This means that you need to have JDK 11 or higher installed. You can also install older JDKs and configure the runtimes. Just open the Command Palette (Ctrl+Shift+P) and type the command Java: Configure Java Runtime. If you have JDK 8 installed and have properly configured maven or gradle, this isn't even necessary. Visual Studio Code will correctly pick up the correct JDK.
VS Code no longer supports JDK 1.8. The "Java Extension Pack" relies upon "Language Support for Java(TM) by Red Hat" which documents Java 11 is the minimum requirement. See here: https://marketplace.visualstudio.com/items?itemName=redhat.java
Tis unfortunate, guess I'm switching back to eclipse
I am using JDK8 on my normal desktop and I have a separate linux box that I am trying to run the Java program on.
The problem I'm running into is that the linux box is running jdk7, so the computer has JRE7 basically that it is running off of. My question is, is it possible to create a jar file in JDK8 that will be compatible with java 7?
I'm using IntelliJ to compile. I tried to compile in 1.7, but it gave an error when I did end up trying to do it. I compile it here:
In 1.8 it works fine to compile, but when I try to compile in 1.7 it doesn't work.
I know the short answer is to update the linux to JRE 8. But I am curious, is there a way to make it backwards compatible? Or is the other answer to simply install JDK7 on the desktop in order for it to run on the linux box using JRE7?
Java programs built with JDK 8 will only run on machines running JRE 8 (or higher).
I found this when trying to compile classes on my local Linux machine (using JDK 8) and deploying to a remote server running JRE 7. The classes just wouldn't work (like you're finding).
If you want to use JRE 8 on linux, I recommend using the oracle-java8-installer package from webupd8team. Installation instructions found here (assuming Debian based distro).
If you want to compile to JDK 7, it's not good enough to only have JDK 8 installed and pick to compile 1.7. You need JDK 7 installed to and restage your project to use JDK 7.
The thing you have to remember is that the difference between JRE/JDK versions is not just the extra features developers can use (e.g Lambda functions) but it's also that the JRE itself is improved (efficiency, garbage collection, etc.).
As a extreme example: If you wrote code that only used JDK 1 features but compiled it using JDK 8, it wouldn't run on a machine running JRE 1 because the Java classes had been compiled with JRE 8 in mind.
Do note though, that if you're Java Code uses only features from JDK 7 or 6 etc., you might think it good practice to compile using the minimum JDK required to allow for compatibility with more machines. Well...you'd have that compatibility but at a cost of using inefficient, out of date, possibly vulnerable compiled classes (At little extreme, but you get my point).
Are you using any new Java 8 features? Because if you are, this means you cannot build the project against the JRE7.
If you are not using any Java 8 features, you can build to Java 7 most easily by downloading the JDK7 and switching the project to use that instead of the JDK8.
You should also set project language level to 1.7 (and module language level(s) as well, if they're different). It's done in Project Structure settings dialog. After that the project should compile.
Note that you shouldn't use any of the APIs that appeared in 1.8, but such usages will most likely be highlighted in the editor.
I am looking for clarification in jdk versions.
I am getting error
java.lang.UnsupportedClassVersionError:Bad version number in .class file"
I hope this error is for different jdk version. I am having myeclipse6.0.1 and weblogic10.3.
Now, in my systems has jdk1.5 but weblogic has jdk1.6, as well myeclipse supporting 1.5 only.
I read the all forums and they said compile is different version and running different version.
So, here i thought program compliling 1.5 and running 1.6.
Is it correct ?
This means that the Java program was compiled for a newer version of Java than you are trying to run it with.
The easiest way to be certain is to use the same version of Java for compiling and building as is to be used on the final system. For you, this is most likely Java 5.
I have a problem deploying compiled classes in a Tomcat web application: I'm deploying a class which is to be called from a servlet, but when I run the application it fails telling me of a ServletException: Error allocating the servlet instance due to an UnsupportedClassVersionError: Bad version number in .class file.
Tomcat is using Java 1.5.0_06 as reported by the manager. My class was compiled using Java 1.6.0_14. Running javap on any of the classes already present tells me "Major version 46, minor version 0" which should be 1.2.0 initial and which isn't available anymore for download. The oldest I can find is 1.2.1_004 which doesn't even compile.
Do i need to match my Java version to the Tomcat environment or to the classes already there? Re-compiling the whole project using more modern Java is not feasible for me at the moment, although I'd love to do so.
That's easy: You compiled your application with a later version Java compiler than the Java runtime underneath Tomcat.
Update
The java compiler, javac, supports the options
-source release
Specifies the version of source code accepted. The following values for release are allowed:
1.3 the compiler does not support assertions, generics, or other language features introduced after JDK 1.3.
1.4 the compiler accepts code containing assertions, which were introduced in JDK 1.4.
1.5 the compiler accepts code containing generics and other language features introduced in JDK 5. The compiler defaults to the version 5 behavior if the -source flag is not used.
5 Synonym for 1.5
...and even more importantly,
-target version
Generate class files that will work on VMs with the specified version. The default is to generate class files to be compatible with the JDK 5 VM. When the -source 1.4 or lower option is used, the default target is 1.4. The versions supported by javac are:
1.1 Generate class files that will run on VMs in JDK 1.1 and later.
1.2 Generate class files that will run on VMs in JDK 1.2 and later, but will not run on 1.1 VMs.
1.3 Generate class files that will run on VMs in JDK 1.3 and later, but will not run on 1.1 or 1.2 VMs.
1.4 Generate class files that will run on VMs in JDK 1.4 and later, but will not run on 1.1, 1.2 or 1.3 VMs.
1.5 Generate class files that are compatible only with JDK 5 VMs.
5 Synonym for 1.5
... which will allow you to compile code for a certain version of the JVM.
In other words, you can continue to use your 1.6 compiler, just throw these options at it and you can make it generate 1.5 code which Tomcat will be able to handle.
Do i need to match my Java version to the Tomcat environment or to the classes already there?
You need to ensure that your code is compiled with a version (less than or equals) supported by the JVM you are using; but no, this doesn't need to be the same version that the Tomcat code base was built from - the two code bases can be jvm version independent of each other, as long as they are both supported by the jvm you are using.
Instead of recompiling your source to be 1.5 compatible you could update the JDK that Tomcat is using to 1.6.
You should be able to change this by setting the JAVA_HOME environment variable to point to a Java 1.6 install.
I got the same UnsupportedClassVersionError issue a while ago. The root cause there was not my own compiled code, but some libraries that were needed, which were compiled with a newer JDK.