Community
Participate
Working Groups
Code quality can be further improved by new advanced configurable compiler diagnostics, available either when building or when editing Java files. The compiler will conduct some null reference analysis in order to anticipate some NullPointerException at runtime. For cleaning up code, the compiler will detect obsolete $NON-NLS$ tags and unused break/continue label. Assigning a parameter will be configurable as a poor coding style. For assisting migrating existing code to Java 5.0, the compiler will optionnally signal any reference to a raw type, not only unchecked ones. Additionally, users will be able to configure optional errors as being non fatal, and thus allow valid classfile generations. [JDT Core]
One late addition: detection of switch case fall-through scenario (see bug 67836). Here is the reworded description: Code quality can be further improved by new advanced configurable compiler diagnostics, available either when building or when editing Java files. The compiler will conduct some null reference analysis in order to anticipate some NullPointerException at runtime, and signal possible fall-through into next case inside switch statements. For cleaning up code, the compiler will detect obsolete $NON-NLS$ tags and unused break/continue label. Assigning a parameter will be configurable as a poor coding style. For assisting migrating existing code to Java 5.0, the compiler will optionnally signal any reference to a raw type, not only unchecked ones. Additionally, users will be able to configure optional errors as being non fatal, and thus allow valid classfile generations. [JDT Core]
Added optional null reference analysis for local variables. It can be activated using the following preference: Window>Preferences>Java>Compiler>Errors/Warnings>Potential programming problems>Null reference. Also see bug 110030 for details. Note that the analysis is fairly conservative, aligned on definite assignment rules. It is intentionally not complaining on all possible cases, but only considering these for which a suspicion gets introduced (e.g. if later on a null check is performed). The analysis could be further improved by introducing annotations (@CanBeNull, @CannotBeNull) but these would need to get standardized first. Null reference warnings can be silenced using @SuppressWarnings("null"). (bug 110030)
Added optional compiler diagnosis for signaling fall-through switch cases. * COMPILER / Reporting Switch Fall-Through Case * When enabled, the compiler will issue an error or a warning if a case may be * entered by falling through previous case. Empty cases are allowed. * * - option id: "org.eclipse.jdt.core.compiler.problem.fallthroughCase" * - possible values: { "error", "warning", "ignore" } * - default: "ignore" Fall-through warnings can be silenced using @SuppressWarnings("fallthrough"). Also see bug 67836 for details.
Support for detecting unused NON-NLS tags got added (bug 48976)
Added compiler diagnosis to signal unused label (from labeled statement). Note that a label is considered to be used if explicitly referenced only. * COMPILER / Reporting Unreferenced Label * When enabled, the compiler will issue an error or a warning when encountering a labeled statement which label * is never explicitly referenced. A label is considered to be referenced if its name explicitly appears behind a break * or continue statement; for instance the following label would be considered unreferenced; LABEL: { break; } * - option id: "org.eclipse.jdt.core.compiler.problem.unusedLabel" * - possible values: { "error", "warning", "ignore" } * - default: "warning" (bug 63840)
Added optional compiler diagnosis for signaling method parameter assignments. * COMPILER / Reporting Parameter Assignment * When enabled, the compiler will issue an error or a warning if a parameter is * assigned to. * - option id: "org.eclipse.jdt.core.compiler.problem.parameterAssignment" * - possible values: { "error", "warning", "ignore" } * - default: "ignore" (bug 53773)
Tuned new compiler diagnosis for raw type references. This problem can now be enabled independantly from unchecked type operations, and carries its own severity settings. Removed "Type safety:" prefix from problem description as it is not truly fragilizing type integrity. This warning can still be silenced by @SuppressWarnings("unchecked") * COMPILER / Reporting Raw Type Reference * When enabled, the compiler will issue an error or a warning when detecting references to raw types. Raw types are * discouraged, and are intended to help interfacing with legacy code. In the future, the language specification may * reject raw references to generic types. * - option id: "org.eclipse.jdt.core.compiler.problem.rawTypeReference" * - possible values: { "error", "warning", "ignore" } * - default: "ignore"
Added compiler option so as to specify whether optional errors should be fatal or not. By default, an optional error is treated as fatal as a normal language error (as defined by the language spec book), when disabling this option, clients will be able to treat optional errors as severe warnings only, which will be rendered as errors, but no longer prevent from running the code. There is some work planned on UI side so as to better distinguish amongst mandatory vs. optional errors. * COMPILER / Treating Optional Error as Fatal * When enabled, optional errors (i.e. optional problems which severity is set to "error") will be treated as standard * compiler errors, yielding problem methods/types preventing from running offending code until the issue got resolved. * When disabled, optional errors are only considered as warnings, still carrying an error indication to make them more * severe. Note that by default, errors are fatal, whether they are optional or not. * - option id: "org.eclipse.jdt.core.compiler.problem.fatalOptionalError" * - possible values: { "enabled", "disabled" } * - default: "enabled" (bug 107282)
All items got covered in 3.2.0
