Community
Participate
Working Groups
In the current UI, one can independently switch to a Java 1.4 level compiler, but not realize that one is still compiling against Java 5 level JRE libraries. The result can be earning a clown nose. :-) I suggest that the UI be restructured so that either: - the settings for the compiler level and the JRE are adjacent to each other in the UI so that the current behavior is obvious to the user or - when the compiler setting is changed to not match the JRE level for a project (or the entire workspace, as applicable), prompt the user if she wants to switch to a JRE that matches the compiler level. If no JRE matching the compiler level is installed, simply warn the user of the mismatch between compiler level and JRE level.
Actually, the problem is worse than this. If the project was created in an IDE running under JRE 1.4 and used the IDEs JRE, it will still use the IDEs JRE when it is shared to CVS, then downloaded into an Eclipse that is powered by the Java 5 JRE. Thus, the project's JRE can change independent of the wishes of the one who created it. The second developer who pulled from CVS is then in a position to accidentally commit code that uses Java 5 library features back to CVS, thus breaking the build.
In either case, I suggest (at a minimum) having a warning show up if the compiler build level doesn't match the JRE level.
I think the "problem" is that the workspace default JRE is used. But the compliance level is a project setting and is therefore commited/checked out from cvs. This is not a bug but the expected behavior. The following is a possible solution: 1. On your project right click on 'JRE System Library' 2. Select 'Configure...' 3. Enable 'Alternate JRE' 4. Select a 1.4 Library 5. OK This will store the vm type in the .classpath file and can therefore be commited to cvs. The problem with this approach is, that the project will only compile in other workspaces when checked out from cvs if the other workspace knows the exact same vm. I agree that a warning should be shown in Properties->Java Compiler if the compliance level is 1.4 and the JRE is 1.5 (a 1.5 compliance with a 1.4 vm shows a warning).
(In reply to comment #3) In general, you should *not* commit an "Alternate JRE" to CVS (path is install-specific)! "Execution Environments" are the ones that can safely been shared between Eclipses > 3.1 (not yet supported in 3.1). Clients can then map these EEs to appropriate installed JREs in their preferences. What we could do is automatically changing the JRE to the appropriate EE when the user changes the compiler compliance level (should ask the user whether the change is OK, since .classpath files with EEs are not backwards-compatible).
(In reply to comment #4) > (In reply to comment #3) > > In general, you should *not* commit an "Alternate JRE" to CVS (path is > install-specific)! Your sure about that? My entry looks like: <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/j2sdk1.4.2_09"/> > > "Execution Environments" are the ones that can safely been shared between > Eclipses > 3.1 (not yet supported in 3.1). Clients can then map these EEs to > appropriate installed JREs in their preferences. Yes, that's nice, I didn't knew that...
Yes, I'm sure. "j2sdk1.4.2_09" is the name that you chose when the JRE was added (or Eclipse chose as default the folder name). This name can be changed by the user and is not portable. Only EEs are portable.
(In reply to comment #6) > Yes, I'm sure. "j2sdk1.4.2_09" is the name that you chose when the JRE was > added (or Eclipse chose as default the folder name). This name can be changed > by the user and is not portable. Only EEs are portable. 1) So how does one set up an EE? We need to make sure that our projects retain the correct compiler AND jre settings when downloaded from CVS into a new workspace. 2) In either case, perhaps we should to supply a warning in two places: - When the compiler setting is changed - When the project is downloaded from a team provider if the compiler and JRE level don't match.
> 1) So how does one set up an EE? See steps in comment 3, but choose an Execution Environment instead of an Alternate JRE. Or use 'Project Properties > Java Build Path > Libraries'. I already filed bug 134257 to add this to the New Java Project wizard as well. > 2) In either case, perhaps we should to supply a warning in two places: > - When the compiler setting is changed > - When the project is downloaded from a team provider Warning in the dialog is subject of this bug. Warning on build if JRE for EE is unavailable: bug 120596.
Allow me to close this bug in favor of more specific bug reports. We are aware of the problem of the separate JRE and compliance settings. We will tackle this as a major item in 3.3, e.g by assigning a compilance to a JRE or an execution environment.
(In reply to comment #9) > Allow me to close this bug in favor of more specific bug reports. We are aware > of the problem of the separate JRE and compliance settings. We will tackle this > as a major item in 3.3, e.g by assigning a compilance to a JRE or an execution > environment. Understood. :-) No problem.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
