Community
Participate
Working Groups
Eclipse 3.2 M4 with 1.5 JRE Did a code completion on Collections.s Got Collections.emptyList(). Which is 1.5 specific. Broke head for 1.4 users. Correct version was Collections.EMPTY_LIST Is there a workaround? Or do you just guarantee bytecode is 1.4 but can't do anything but the java class libraries themselves? Thanks, Chris
> Did a code completion on Collections.s typo. I meant 'Did a code completion on Collections.e'
If you put 1.5 classlibs on your classpath, then you get completions which maybe 1.5 specific. We are not excluding 1.5 specific constructs, simply because we don't really know what level they are. In 1.4 target mode, we issue 1.4 classfiles, which are guaranteed to use any 1.5 constructs in their sources, but if you compiled them against 1.5 libs, then you might have 1.5 binary dependencies from thereon. So though you produced 1.4 classfiles, they will need a 1.5 JRE to be executed, due to the dependencies you did introduce. Best for 1.4 compliance to use 1.4 libs on your classpath, unless you like to live dangerously. Closing as invalid.
I think this is a serious usability problem. I just did the same thing and almost borke a nightly build, if Kevin had not stayed late that night and caught it we would have been broken for several days (Cheers Kev). org.eclipse.ui.ide has it's compiler compliance set to 1.4. I am using a 1.6 VM. I accidentally used some 1.6 API and released it to the ide plug-in. We should at least have a warning marker generated that I am using API that is not compatible with the compliance level of our code - there is no way a user is going to figure this out on their own.
Probably would require a custom JRE version checking tool that knows about the official public API's and their JRE requirement. That's some work...
You might start by properly settings your installed JRE. You installed a JRE1.4 and you set it as an exact match. It should be picked up as the JRE of your project.
Darin - can't execution environment help us here ? I would expect some access rules to kick in in such a scenario ?
The access rules for execution environments only go to the class level - not methods within classes. If access rules supported finer granularity, we could potentially expand the rules.
Would it make sense to introduce a stricter mode for the compiler where the compiler tests that the classfile compatibility of the used JARs is not higher than the configured source/classfile compliance? Genereate an error: 'Trying to compiler 1.4 source against a 1.5 library'.
There would be a problem then in mixing plug-ins. For instance I am using Eclipse but developing another plug-in with 1.5 compliance so I would get errors if there were a mix of compliance levels in my setup. However an error that flags me using an API with a higher than specified compliance level would be ideal.
Re: comment 8 There is already a build preferences for checking incompatible required libraries.
Re: comment 9 Once API tooling defines a set of rules, we should leverage these as (finer-grain) access rules, or something along these lines; for JDT users to see leveraged as they code.
Given option already exist as per comment 10, and API tooling is around the corner to go after such issues, I don't think we should invest more in compiler support. Right now, the real answer is to make sure to have the proper level of libs on your classpath (and to detect inconsistencies, enable the option mentioned in comment 10). No further action planned. Is that ok?
Philippe when you say have the proper level of libs on your classpath do you mean only use Foundation libs? No good for us as we have a mix of compiler levels. If you have something better on the way I agree we should just wait for this but I am not sure how to easily set up your solution so that we don't continually have this problem.
I personally have installed several JREs on my machine. Foundation 1.0, Java4, Java5 and Java6 (amongst others). Given this, with required execution environments properly set on my projects, each of them is picking the right flavor at compile time (through JREContainer resolution). This guarantees that each project is compiled against the right library. As you observed indeed, there is no one JRE to rule them all...
Would it make sense to set the 'incompatible required libraries' to 'warning' by default?
I would be happy to set to error myself - this is what we would do in our project preferences. But warning is a good start
I wouldn't change its default, because of the lib packaging issue (not us, but libs causing grief). Java4 means target 1.2 in 1.3 source mode. However, some of the standard libs are stamped as 1.4, hence from the compiler standpoint it looks like these are incompatible with the fact you want to deliver code to a 1.2 target... Ideally, the JRE container should rule these libs out of the classpath, to ensure that you do not accidentally code against them and really mean to deliver code for 1.2 targets. In reality, not many people do code for target prior to 1.4, so the glitch is tolerable, but still the warning would be kind of proeminent.
Verified for 3.4M4
