File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes IDEs, Version Control and other tools and the fly likes Difference between 'Installed JREs' and 'Compiler Compliance Level' in Eclipse Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Difference between Watch "Difference between New topic
Author

Difference between 'Installed JREs' and 'Compiler Compliance Level' in Eclipse

Pankaj Poshirkar
Ranch Hand

Joined: Dec 31, 2009
Posts: 53
Dear All,

I want to understand the significance of these two options in eclipse 'Installed JREs' and 'Compiler Compliance Level'.

What I understand by 'Compiler Compliance Level' is that Eclipse will compile that particular project according to the JRE mentioned in the Compiler Compliance.
Isn't this option enough? What is 'Installed JREs' required for?

Also what is the significance of 'Project Facets' if 'Compiler Compliance Level' is already provided?

Thanks in advance,
Pankaj
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5842
    
    7

The "Installed JREs" is where you can lists all of the JREs and JDKs that you have installed on your system. I usually have both a 1.5 and 1.6 JDK referenced, along with the JRE that Eclipse found by default.

The "Compiler Compliance Level" setting equates to the -source option to javac. It indicates which JDK level the source should conform to. This setting does not have to be the same as the JDK level. For example, your default JDK could be 1.6 but the source set to 1.4.

The "Project Facets" identifies third-party libraries (that are not part of the JDK) that are to be included in your project. It is an easy way to include additional JARs in such a ways that Eclipse knows that you are working with and thus can provide extra editing capabilities


JBoss In Action
Pankaj Poshirkar
Ranch Hand

Joined: Dec 31, 2009
Posts: 53
Peter Johnson wrote:The "Installed JREs" is where you can lists all of the JREs and JDKs that you have installed on your system. I usually have both a 1.5 and 1.6 JDK referenced, along with the JRE that Eclipse found by default.

The "Compiler Compliance Level" setting equates to the -source option to javac. It indicates which JDK level the source should conform to. This setting does not have to be the same as the JDK level. For example, your default JDK could be 1.6 but the source set to 1.4.

The "Project Facets" identifies third-party libraries (that are not part of the JDK) that are to be included in your project. It is an easy way to include additional JARs in such a ways that Eclipse knows that you are working with and thus can provide extra editing capabilities


Ok... so do you mean to say that 'Installed JRE' is global to the workspace and ''Compiler compliance level' is local to a particular project? I mean if Installed JRE is set to JRE 6 and one of the projects say 'Project 1''s Compiler compliance level is set to java 1.4, it means 'Project 1' will be compiled with JRE 1.4 but rest all the other projects will be compiled with JRE 6 (as per 'Installed JREs)... is it so??? Please confirm.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16228
    
  21

Not quite. But first of all, each project has the option to set its own language levels or (default) inherit them from the workspace settings. Saves having to tailor each project minutely in cases where you don't care.

When you say "source compliance level" and "generated class code level", you're setting the options for the selected JDK to compile with, not selecting the JDK itself (which is a completely different option).

In other words, you're doing something like "/usr/java/jdk1.6/bin/javac -source 1.4 XXXXFile.java", not switching to JDK 1.4. However, by setting the JDK 1.4 source level, the 1.6 compiler knows, for example, that "enum" is a valid variable name (as it was in JDK 1.4 and earlier) and not a reserved word (JDK 1.5 and later).

This is where Java shows that it was designed for Enterprise use. A certain other platform I could mention lacks those options, and if you need legacy support in an emergency, well, tough luck.

Obviously, it's one thing to be backwards compatible, and another to be prescient, so while you can declare 1.4 compatibility mode on the 1.6 JDK, you can't declare 1.6 compatibility mode on JDK 1.4.

There's more than just one reason why Eclipse supports multiple JDKs, however. While legacy code occasionally does end up requiring the actual 1.4 compiler rather than 1.6 running in 1.4 mode, you may also have things like 1.6.0_u10 and 1.6.0_u20 JDKs installed at the same time. Say, for example, where there's a project that happens to crash the 1.6.0_u20 VM when you debug it, so you have to fall back to the 1.6.0_u10 version (these aren't necessarily real JVM names, but you get the idea, I hope!).


Customer surveys are for companies who didn't pay proper attention to begin with.
Pankaj Poshirkar
Ranch Hand

Joined: Dec 31, 2009
Posts: 53
Tim Holloway wrote:Not quite. But first of all, each project has the option to set its own language levels or (default) inherit them from the workspace settings. Saves having to tailor each project minutely in cases where you don't care.

When you say "source compliance level" and "generated class code level", you're setting the options for the selected JDK to compile with, not selecting the JDK itself (which is a completely different option).

In other words, you're doing something like "/usr/java/jdk1.6/bin/javac -source 1.4 XXXXFile.java", not switching to JDK 1.4. However, by setting the JDK 1.4 source level, the 1.6 compiler knows, for example, that "enum" is a valid variable name (as it was in JDK 1.4 and earlier) and not a reserved word (JDK 1.5 and later).

This is where Java shows that it was designed for Enterprise use. A certain other platform I could mention lacks those options, and if you need legacy support in an emergency, well, tough luck.

Obviously, it's one thing to be backwards compatible, and another to be prescient, so while you can declare 1.4 compatibility mode on the 1.6 JDK, you can't declare 1.6 compatibility mode on JDK 1.4.

There's more than just one reason why Eclipse supports multiple JDKs, however. While legacy code occasionally does end up requiring the actual 1.4 compiler rather than 1.6 running in 1.4 mode, you may also have things like 1.6.0_u10 and 1.6.0_u20 JDKs installed at the same time. Say, for example, where there's a project that happens to crash the 1.6.0_u20 VM when you debug it, so you have to fall back to the 1.6.0_u10 version (these aren't necessarily real JVM names, but you get the idea, I hope!).


Thanks a lot Tim... that really helped enhancing my knowledge
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Difference between 'Installed JREs' and 'Compiler Compliance Level' in Eclipse