Develop Reference

Eclipse compiling with JRE or JDK

I have one question in my mind and I should note that I know the differences between JDK and JRE. I am not a new programmer in Java.
What I would like to ask is in Eclipse I can specify the compilation environment (correct me if I a wrong) in window> Preferences but we can also change it for a specific project.
OK. I added jre and jdk folder in the options. I can use both.
But JRE has no javac (no java compiler) in it. So how it is possible that some projects requires that I need to change to jre1.7 to COMPILE?
I was getting some minor.major version error and setting JRE solved my problem?
How can this be possible?
In fact now I realized something.
Ok the question changes a little.
I saw that these are VM not compiler. I understood.
Does JDK have also JRE in it? so if I specify JDK1.8 I am setting jre1.8 as VM and if I specify JRE1.7 I am setting jre1.7 as VM?
Is it right?
It makes confusions. Why JDK has JRE in it?

JDK has whole JRE (regular Java VM) inside, in order to allow you to run what you will develop with it.
Theoretically someone could make some small-JDK with just tools and without JRE, but it would make a whole lot more confusion as to which tools version run with which JVM version (most JDK tools needs JVM to be run). Look at you, how many people have only this problem? So it is bundled together, tools and JRE as a whole named JDK, thanks to that you have some guarantee that those JRE and tools will work together.
JRE - Java Runtime Environment - allows you to run java programs
JDK - Java Development Kit - allows you to run and develop java programs
JDK = JRE + tools for developer
Also note, that You can choose for the java compilation process two things:
compatibility with source version - this is basically the syntax you are allowed to use.
compatibility with VM version - this is the minimum VM level on which you can run the compiled binaries.
example from your post: If you have compiled something as Java 8, you can't run it on Java 7, this is the minor/major version problem you have. But the opposite (to run something for Java 7 on Java 8) is valid.
in your example JDK8 and JRE7 both are just fully functional VM's, but JDK8 has additionally (in comparison to JRE) development tools inside it.

what does b in java -fullversion indicates?

When we use java -fullversion, we get output like java full version "1.7.0_45-b18".
what is this b18 in java full version?
I went thorough some oracle java articles which says that it is indicates build versions. So what is this build version supposed to be?
Also I see that some bugs on http://bugs.java.com/ which says that they are backported from higher version. For example : http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8018840
It says that "Affected Versions: 7u45" and "Fixed Versions: 7u45 (b01)".
So what is this Fixed Versions: 7u45 (b01) indicates? Does this mean it is fixed in some later build of same java version?
Also as my current java -fullversion command says : "1.7.0_45-b18". SO does it mean that there are 18 different build for 7u45?

b18 does not refer to having 18 builds in your system.
The concept is like:- Once code completion is done by developers on few features of the software, the lines of code is converted to a software or application so that we can use it.
Each Build is numbered and it keeps changing with every release of that new version.
So b18 has all previous features and new features included i.e an updated version of the software and your OS will update the software(if automatic update is enabled) rather than keeping copy of each build.
Hope this clarifies your doubt to some extent... :)

From the Javadoc source:
JRE Family Version JRE Security Baseline
(Full Version String)
7 1.7.0_45
6 1.6.0_65
5.0 1.5.0_55
So as you have already found b means the "build" and 1.7.0_45 is the JRE Security baseline which represents JRE Family Version 7. And b18 is the Build 18.

Is setting eclipse java compiler compliance level 1.6 same as compile using JDK 1.6?

I'm trying to consume a third-party API, where I get support for the third party API upto JDK 1.6.
I have other few projects which are built using JDK 1.7 and as part of the product I'm also packaging JRE 1.7.
if compiler compliance level is set to JDK 1.6, compile & run using JDK 1.7 libraries produce same result as of compile & run using JDK 1.6?
Would it be safe to claim support from third-party vendor when compiler compliance level is set to JDK 1.6.
Update:
I presumed that setting compiler level in eclipse is same as setting -source & -target options of javac.
I'm not sure if compiling using JDK 1.7 setting source & target to 6/1.6 is same as compiling in jdk1.6.

The problem is in changes of Java API between versions. There are some classes and methods that are available in Java 7 but not in Java 6 and other way round. The code compiles with Java 7 but it will not run with Java 6 because of missing classes or methods.
Unless you compile with Java 6 JDK, you cannot be 100% sure.

Yes, if you compile with compliance level set to 1.6, it will be able to run on java 6 - compiler will guarantee that. It should be able to run on java 7 as well, since JRE is backward-compatible.

You can actually specify the .class files version compatibility in the "Preferences->Java->Compiler" (project specific), so at worst you are benefitting from a more recent compiler building probably exactly the same bytecode as using JDK 1.6.
"Compliance 1.6" however does not ensure that you get exactly the same result as using JDK1.6, but java standard ensures applications built with 1.6 will run the same on a >= 1.6 JRE.
So if you are really afraid of incompatibilities, build the project (on your CI server I suppose) with a project specific setting 1.6 on a machine with both JRE 1.6 for this one, and 1.7 for other projects, and bundle a 1.7 in your distribution, it is guaranteed to run ok by Sun/oracle/java.
i.e. if the code is built with JDK 1.6, and used by other JDK >= 1.7 code you are fine with respect to versioning. Probably this is the case of many jars you use everyday.
However, building the code that is stamped 1.6, with a real JDK 1.6 is the only sensible thing to do if you are afraid of real world problems (money involved).
So I think then you are safe to "claim support", build in 1.6 and use the jar in 1.7.

In my experience with Eclipse, Compliance level set to Java 5 is not the same as compiling with JDK5. It has allowed Java 6 methods to pass compilation locally when the Installed Java was set to Java 6 and the compliance was set to 5 and then our build failed when the files were checked in.

Updating Heroku App to Java 8

I have a Play 2.2 app I'm using with Java 8 that I'm having trouble getting to work. The code compiles locally for me using OpenJDK 1.8, but when I try and push the code to Heroku, I get the following error, which was the error I was getting earlier locally when I was running on OpenJDK 1.7 with lambdas by accident.
java.lang.RuntimeException: Unknown constant: 18
I set system.properties to use Java 1.8 and I know that's working because it's starting up with the following text:
Play 2.x - Java app detected
-----> Installing OpenJDK 1.8...done
Is there something I'm forgetting to do to update to Java 8?
I tried updating the PATH as well as specified here but that didn't do anything.

Unknown constant: 18 most probably refers to CONSTANT_InvokeDynamic tag in the class file’s constant pool which has the value 18. This can’t be a JDK issue as even Java 7 understands that tag.
So it is an indicator for a byte code manipulation tool running in your runtime not understanding newer class files (but trying to process them despite the unknown version number). That worked with Java 7 as the invokedynamic feature exists but is not used with ordinary Java 7 class files (i.e. produced by javac).
Since you knew if you used bytecode manipulation by yourself, it must be part of a framework, i.e. you named heroku and the playframework. So you problem is not about updating the JDK but updating the frameworks to Java-8-aware versions, if such versions already exist.

As an add-on to Holger's response, here's what Heroku support had to say:
Hi,
Java 8 is still on an old pre-release due to delays on a linux distribution of OpenJDK. You can track the status of JDK 8 here:
https://github.com/heroku/heroku-buildpack-jvm-common/issues/10#issuecomment-38006175

What are the pitfalls when upgrading to Java 7

I am switching an enterprise application built on Spring 3.1.0, Hibernate 3.6.0 from Java 6 32bit to Java 7 64 bit.
Has anybody done that? Any problems? Are there any resources on the subject?

Here are the pitfalls I know about:
You might have to upgrade your IDE to be able to enable Java 7 features.
Make sure that command line tools and your IDE use the same Java version. If you're using Maven, for example, look into $HOME/.mavenrc and/or check the environment variable JAVA_HOME
Check the source/target options of the Java compiler.
Java 7 supports generics better than Java 6 so some code will now compile that failed with Java 6
The 64bit version of Java uses a lot more memory than the 32bit version
The first release of Java 7 had a severe bug in the JIT compiler which broke Lucene. Use at least b2 or better.

Java 7 uses the newer JAXB 2.2 instead of 2.1 (the full change on the XML stack is described here). These versions are not compatible on generated code for Boolean getters and setters!