Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Pankaj Poshirkar
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5852
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Pankaj Poshirkar
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18169
53
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!).
 
Pankaj Poshirkar
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic