|Warning Inconsistencies Between The ECJ Batch Compiler And The IDE [message #899858]
||Thu, 02 August 2012 16:05
| Rob Hatcherson
Registered: July 2009
Location: Fort Worth, TX, USA
Relevant version info:|
ECJ: I'm using ecj-4.2.jar, though it reports its version as:
Eclipse Compiler for Java(TM) 0.C58, 3.8.0, Copyright IBM Corp 2000, 2012. All rights reserved.
Juno IDE: Build id: 20120614-1722
We recently switched from Indigo to Juno for routine development, and from ECJ 3.7.2 to the ECJ version mentioned above for command-line/scripted builds.
I've been struggling to get the warning and error options set up identically between the IDE and ECJ so one doesn't let something slip by while the other squawks. This is a beating because the correlation between the ECJ command-line options and the choices in the IDE compiler preferences is not clear, and it seems like one always offers at least a few things that the other doesn't have.
One fat spreadsheet later and I think I've managed to get the two mostly generating the same complaints. However, I can't get them to agree about unchecked type operations.
We have a handful of lines in our code base where if I pass ECJ the -warn:+unchecked option it will issue a complaint similar to:
Type safety: Unchecked cast from ...someClass... to ...someOtherClass..
I can add @SuppressWarnings("unchecked") to stop the complaint (and will worry about actually fixing it properly later; the relevant discussion at the moment is getting the two build systems singing the same song).
However... if I go to the "Generic types" section in the Juno IDE's Java compiler Errors/Warnings preferences panel and change "Unchecked generic type operation" to "Warning" it does not issue a warning, and if the @SuppressWarnings annotation is still in there it complains that it's not necessary.
The 4.2.1 maintenance build M20120726-1200 of ECJ also continues to issue the warning.
When using Indigo and ECJ 3.7.2 both the IDE and ECJ would issue the warning.
Bug or feature?
Powered by FUDForum
. Page generated in 0.01911 seconds