Develop Reference

Compiling for Java 6 using Java 7 without installing Java 6

The target system, on which my application is supposed to run, uses Java 6. On my development machine, I have Java 7. Can I do the development, without downloading Java 6?
I found on http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html one example for cross compilation:
javac -source 1.6 -target 1.6 -bootclasspath C:\jdk1.6.0\lib\rt.jar -extdirs "" OldCode.java
However, this too requires the existence of a rt.jar, which belongs to Java 6. Is there a simpler way?

New Java versions generally change both the Java Language (source and class file format) and the Java API.
The Java compiler can emit class files in the old format, even if the source is in a new format (these versions are specified by -target and -source, respectively). Therefore, you don't need the old compiler to target an old JVM.
However, the changes to the Java API are somewhat harder to account for. The easiest is to compile using the API of the Java version you target (-bootclasspath). Of course, you may feel confident that you are not using newer APIs, and skip this step, but the only way to make sure is actually compiling against, and testing on, the old runtime library.
In short, while cross compilation is helpful in that the same source can be used with different Java versions, you should compile and test against the actual Java version you intend to use, which does require the old JRE (or JDK).
BTW, all of these settings are also available in Java IDEs. For instance, in eclipse, one would set the compliance level in the project's compiler settings, and add the appropriate "JRE System Library" to the project's "Build Path":

The below command should suffice to meet your requirement.
'javac -source 1.6 -target 1.6 OldCode.java'
With this command you are telling that the compiler should generate class file that is compatible with java 6. Any java 7 specific will result in compilation error. Regarding rt.jar, you don't need to have java6 specific version. As mentioned the above command automatically ensures output is java6 compatible.
UPDATE/CORRECTION:
After going through the following link http://www.javaworld.com/article/2077388/core-java/what-version-is-your-java-code.html it is clear why it is recommended and is important to use -bootstrap flag along with -source and/or -target flags.

Java wrong major version

On our hadoop cluster my Pig UDF fails complaining
[main] ERROR org.apache.pig.tools.grunt.Grunt - ERROR 1069: Problem resolving class version numbers for class <classname>
I read writing a udf in pig kind of like tutorial and the problem seams to be clear, but unfortunately I cant solve it. My manifest does not contain a version (is this necessary?) and javap reports major version 52, representing java 1.8, although I compiled it with 1.7. So how can I solve this?

My manifest does not contain a version (is this necessary?)
The version manifest entry is not relevant to this. The classloader pays no attention to the version manifest entry.
and javap reports major version 52, representing java 1.8,
That is the relevant fact.
although I compiled it with 1.7.
This all boils down to how you compiled your code, and I think you are incorrect when you say that you compiled with Java 1.7.
Why do I say that? Because the Java 1.7 java compiler is not capable of creating a ".class" file with the Java 1.8 version numbers. It simply doesn't understand the Java 8 syntax extensions, and the corresponding enhancements to the classfile format.
So how can I solve this?
The way to resolve this is to look carefully at your build process and figure out how and why the offending class got compiled using a Java 1.8 compiler. Because there can be no doubt that that is what has happened.
If you are building by hand (e.g. by running "javac" and "jar" from the command line, or by clicking buttons in your IDE) then now would be a good time to learn about build tools like Maven, Ant and Gradle.
FOLLOWUP
That not true. My setting proofs this, but I guess I found the issue: .settings/org.eclipse.jdt.core.prefs contain several 1.8. entries. This may be due to the fact that at the time of the project creation I had 1.8. installed.
Actually, it doesn't "prove" anything ...
What this is telling me is that you are probably compiling with the Eclipse Java compiler, not the Java compiler from your JDK.
In fact, your Eclipse compiler is (or was) compiling for a Java 1.8 target ... because that is what your Eclipse settings say that the Eclipse Java compiler should do. If you are using the Eclipse compiler to compile your code, the version of your JDK or JRE install doesn't determine the classfile version number.
Once again, I strongly recommend that you learn to use a Maven, Ant or Gradle so that you build process is more repeatable and less error prone.

I guess Stephen C's is the most general answer.
In my special case the problem was, that the project specific compiler compliance settings were wrong, because I used JDK 1.8 locally when I created the project and installed 1.7 later, when I got the error on the cluster.
The option is quite hidden and can be found here:
Window > Preferences > Java > Compiler > "Configure project specific settings" > [projectname] > "Compiler compliance level"

Jar compatibility with all JRE Version

My applet application compiles at JRE 7 and created signed jar. I deployed .jar file at my client machine. But I got exception i.e.,"Unsupported major.minor version 51.0" at IE. I want provide an applet jar file to compatibility all browsers. How to make compatibility a jar file?

The best way is to compile your application using an older JDK. I guess that is the only way you will directly see that you are using the correct JDK API available on older JREs and also dependencies (3rd party JAR files on the classpath) in the correct binary version usable on the older JRE/JDK. Go as far as you need, i.e. use the JDK in version 1.3, 1.4, 1.5, or 1.6.
If the library is not available for older JRE version, you will need to somehow back-port it (and possibly its transitive dependencies too). This may get quite tricky and may involve a lot of effort (using tools such as RetroWeaver or similar). So make your backward compatibility choice very carefully.

Compile your source files to a lower target version - specifically, the target JVM version you want to support, using the -source and -target flags in javac.
So, for instance:
javac -source 5 -target 5 -sourcepath /path/to/code -d /path/to/compiled/code *.java

JDK compiler version issue

I'm using Ant to compile Java.The project has to be compiled using JDK 1.5 , however some part of the code references a package compiled with JDK 1.6 version.
I set the JAVA_HOME to 1.5 , error is thrown at this reference as
[javac] class file has wrong version 50.0, should be 49.0
What is the way out without downgrading the reference version to 1.5

What you are asking isn't possible. You should compile your library with JDK 1.5.

Once Java has been compiled at a certain version, you cannot use that version on older versions of Java.
The package you are using might have a version available which is suitable for an older version of Java, alternatively you may be able to get the source code and recompile with the older version (if it doesn't use any Java 6 libraries / features).

Think this way:
The library you use has been compiled using JDK 6. It may be using some features introduced in Java 6 (that were not part of previous versions of Java)
When you use JDK 5 to compile and run, what do you expect the compiler (and the runtime) to do when this "new" feature is encountered? The JDK 5 does not know this feature and will be "confused"
To avoid this confusion at runtime, the compile itself fails.
You have two options:
Compile your project using JDK 6.
Get a JDK 5 compiled version of your library
If your project were using JDK 6 and the library was compiled with JDK 5, then you wouldn't have faced this issue because of backwards compatibility.

Exception while compiling: wrong version 50.0, should be 49.0

I am working an application with JXL API and when i tried compiling using eclipse IDE, it's working fine and the same is not compiling when i am trying to compile in Command prompt and showing the below exception..
Extract.java:6: cannot access jxl.read.biff.BiffException bad class file: C:\Program Files\Java\jdk1.5.0_01\jre\lib\ext\jxl.jar(jxl/read/biff/BiffException.class)
class file has wrong version 50.0, should be 49.0
Please remove or make sure it appears in the correct subdirectory of the classpa
th.
import jxl.read.biff.BiffException;
^
1 error
EDIT:
I am able to executing using JDK 1.6. Since JDK 1.6 must also be compatible with lower versions, why doesn't it support the class files which were compiled in JDK 1.5.

The library you're using was compiled with Java 6
Your compiler is Java 5 that's why it doesn't understand that format.
To fix it you have to get a 1.5 version of the library or upgrade your compiler to 1.6 I suggest the later.

Per http://www.jnode.org/node/2140...
Submitted by Stephen Crawley on Fri, 11/30/2007 - 07:15.
I suspect that you are mixing code compiled with different versions of Java. Class file version 50.0 is used by Java 6.0, and 49.0 is used by Java 5.0.
Try doing a "build clean" to get rid of all existing class files, followed by a regular build.
JNode is being developed using Java 6.0 only. Last time I tried, it didn't build using Java 5.0 (aka 1.5). (It is a problem with the program that builds the JNode boot image.)
Try changing the builder in Eclipse. If you're using 3.4, it's Project - Properties - Java Compiler - Enable Project Specific Settings - Compiler Compliance Level = 1.6. You'll prolly also need to have JRE 1.6 installed, as well.

Check you class path in eclipse and make sure that its the same class path your compiling to in the command prompt, also check your library imports

It means that, you have compiled that class with Java 6 and trying to execute with Java 5.
Solution :
If your using ant, execute below steps on the project root directory
ant clean
ant deploy
If your using eclipse, just
clean the workspace(remove the class files which were compiled with Java6)
and build again

this could be that in you IDE you point to latest version of JDK but when you build your program outside the IDE(maybe with maven) your java_home is the older version to the one on your IDE.