jdt core - build notes 3.1 stream
java development tooling core |
Here are the build notes for the Eclipse JDT/Core plug-in project
org.eclipse.jdt.core,
describing bug resolution and substantial changes in the HEAD branch.
This present document covers all changes since Release 3.0 (also see a summary of API changes).
Maintenance of previous releases of JDT/Core is performed in parallel branches: R3.0.x, R2.1.x, R2.0.x, R1.0.x. |
METHOD_NAME_REFERENCE
.
This completion is a reference to a method name.
"import java.lang.Math.co^"
and complete it to
"import java.lang.Math.cos;"
.
ICompletionRequestor
was deprecated. Use CompletionRequestor
instead.
ASTParser#createASTs(ICompilationUnit[] compilationUnits, String[] bindingKeys, ASTRequestor requestor, IProgressMonitor monitor)
.
Note this API is still under development and subject to change without notice.
* COMPILER / Reporting Forbidden Reference to Type with Restricted Access * When enabled, the compiler will issue an error or a warning when referring to a type with restricted access, as defined according * to the access restriction specifications. * - option id: "org.eclipse.jdt.core.compiler.problem.forbiddenReference" * - possible values: { "error", "warning", "ignore" } * - default: "warning"
* CODEASSIST / Activate Access Restrictions Sensitive Completion * When active, completion doesn't show that is access restricted. * - option id: "org.eclipse.jdt.core.codeComplete.restrictionsCheck" * - possible values: { "enabled", "disabled" } * - default: "disabled"
org.eclipse.jdt.core.util.ClassFileBytesDisassembler#SYSTEM
field to support an extra-detailed output from the
disassembler. It can show constant pool contents.
org.eclipse.jdt.core.Signature
have been added to handle var args in the signature decoding.
Signature#toCharArray(char[],char[],char[][],boolean,boolean,boolean)
Signature#toString(String,String,String[],boolean,boolean,boolean)
IProblem.MethodVarargsArgumentNeedCast
& IProblem.ConstructorVarargsArgumentNeedCast
* COMPILER / Reporting Varargs Argument Needing a Cast in Method/Constructor Invocation * When enabled, the compiler will issue an error or a warning whenever a varargs arguments should be cast * when passed to a method/constructor invocation. (e.g. Class.getMethod(String name, Class ... args ) * invoked with arguments ("foo", null)). * - option id: "org.eclipse.jdt.core.compiler.problem.varargsArgumentNeedCast" * - possible values: { "error", "warning", "ignore" } * - default: "warning"
* COMPILER / Reporting Invalid Javadoc Tags with Deprecated References * Specify whether the compiler will report deprecated references used in Javadoc tags. * Note that this diagnosis can be enabled based on the visibility of the construct associated with the Javadoc; * also see the setting "org.eclipse.jdt.core.compiler.problem.invalidJavadocTagsVisibility". * - option id: "org.eclipse.jdt.core.compiler.problem.invalidJavadocTagsDeprecatedRef" * - possible values: { "enabled", "disabled" } * - default: "enabled" * * COMPILER / Reporting Invalid Javadoc Tags with Not Visible References * Specify whether the compiler will report non-visible references used in Javadoc tags. * Note that this diagnosis can be enabled based on the visibility of the construct associated with the Javadoc; * also see the setting "org.eclipse.jdt.core.compiler.problem.invalidJavadocTagsVisibility". * - option id: "org.eclipse.jdt.core.compiler.problem.invalidJavadocTagsNotVisibleRef" * - possible values: { "enabled", "disabled" } * - default: "enabled" *
org.eclipse.jdt.core.dom.EnumDeclaration#enumConstants()
. The enum constants are now in a separate list
from the body declarations. The org.eclipse.jdt.core.dom.EnumDeclaration#getEnumConstants()
method has been deprecated and
will be removed after M3. See bug 76190 for further details.
CompletionRequestor
is implemented inside code assist engine.
IType
for new completion requestor support:
IType#codeComplete(char[],int,int,char[][],char[][],int[],boolean,CompletionRequestor,WorkingCopyOwner)
IType#codeComplete(char[],int,int,char[][],char[][],int[],boolean,CompletionRequestor)
IEvaluationContext
for new completion requestor support:
IEvaluationContext#codeComplete(String,int,CompletionRequestor, WorkingCopyOwner)
IEvaluationContext#codeComplete(String,int,CompletionRequestor)
Signature
to extract package name part or type name part of a type signature:
Signature#getSignatureQualifier(char[])
Signature#getSignatureQualifier(String)
Signature#getSignatureSimpleName(char[])
Signature#getSignatureSimpleName(String)
Flags.isVarargs(method.getFlags())
now returns whether the method is a varargs method.Problem: Libraries are usually packaged to contain both API for compile-time and implementation for runtime; and thus expose a superset of the API contract to client programs, allowing them to make forbidden assumptions on internals (a typical restriction for Eclipse developpers is to not use internal classes from prerequisite plug-ins). One solution for solving this issue is to separate the API from its implementation into 2 distinct libraries (compile-time/runtime) and then use the classpath rules to only include the API portion on the classpath for compiling. However, this usually proves to be unrealistic, since the API is often mixed with some implementation aspects (not officially part of the API) which are carrying references to its internals (supertype hierarchy, field or method signatures). When it happens, then the compiler needs the implementation also to be on the classpath in order to resolve all signatures appropriately; which goes back to the original problem of exposing too much to unaware clients.
Instead, we allowed classpath rules to be associated with some import restrictions so as to select portions
of prerequisite projects or libraries which are legal to use inside this project.
Access restrictions are expressed as inclusion/exclusion rules on classpath entries (using Ant fileset notation
for discriminating on package and/or file names, e.g. excluding='**/internal/'
would exclude
all types defined any internal
package),
and can be associated to project, library, classpath variable or classpath container classpath entries.
Note that restrictions are automatically combined along a classpath chain. For instance, if a classpath container entry is
associated with some restrictions, then when resolved to a set of entries, these will automatically inherit the
container restrictions (and could still provide further custom restrictions on a per entry basis).
When a forbidden reference to a restricted type is detected, the compiler will issue a problem which severity
can be controlled by JavaCore preference "org.eclipse.jdt.core.compiler.problem.forbiddenReference".
Corresponding problem marker ID is IProblem.ForbiddenReference
.
* COMPILER / Reporting Forbidden Reference to Type with Restricted Access * When enabled, the compiler will issue an error or a warning when referring to a type with restricted access, as defined according * to the access restriction specifications. * - option id: "org.eclipse.jdt.core.compiler.problem.forbiddenReference" * - possible values: { "error", "warning", "ignore" } * - default: "ignore"
In order to challenge this new functionality before leveraged in UI or PDE, Eclipse developpers need to perform the following two actions:
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>with
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins" excluding="**/internal/"/>
<workspace>\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.core.prefs
org.eclipse.jdt.core.compiler.problem.forbiddenReference=warningNote: alternatively, it could be specified on a per project basis, by adding line to
<project>/.settings/org.eclipse.jdt.core.prefs
.
import static type.*; import static type.identifier;Java Search is also able to find referenced type, field and/or member in static imports but required the index version to be incremented.
List<String>
in Java Search text and search for type references.List<String> ls;Match(es) will be found if this field is used in the search scope.
java.lang.Math
.IBinding#getJavaElement()
to get the Java element corresponding to a
org.eclipse.jdt.core.dom.IBinding
.
ITypeParameter
s are no longer children of their IType
or IMethod
.
To get the type parameters of a type or a method use IType/IMethod#getTypeParameters()
.TypeParameter#ENABLED
has been removed.ICodeAssist#codeSelect()
) return a ITypeParameter
when a type
parameter is selected.* COMPILER / Reporting Usage of 'enum' Identifier * When enabled, the compiler will issue an error or a warning whenever 'enum' is * used as an identifier (reserved keyword in 1.5) * - option id: "org.eclipse.jdt.core.compiler.problem.enumIdentifier" * - possible values: { "error", "warning", "ignore" } * - default: "warning"
ITypeParameter
that represents a formal type parameter in a generic type or method.
Note types and methods should have type parameters as children, but this is currently disabled as JDT UI doesn't support
this kind of element yet.
To enable set org.eclipse.jdt.internal.core.TypeParameter#ENABLED
to true
.* COMPILER / Reporting Missing Declaration of serialVersionUID Field on Serializable Class * When enabled, the compiler will issue an error or a warning whenever a serializable class is missing a local declaration * of a serialVersionUID field. This field must be declared as static final and be of type long. * - option id: "org.eclipse.jdt.core.compiler.problem.missingSerialVersion" * - possible values: { "error", "warning", "ignore" } * - default: "warning"
isConstructor()
and isSynthetic()
getters to MethodReferenceMatch.
SearchRequestor
) accepts this kind of match,
it can now distinguish between method and constructor reference matches. It can also know
if a constructor reference match is a default constructor or use an implicit super call.
* COMPILER / Setting Compliance Level * Select the compliance level for the compiler. In "1.3" mode, source and target settings * should not go beyond "1.3" level. * - option id: "org.eclipse.jdt.core.compiler.compliance" * - possible values: { "1.3", "1.4", "1.5" } * - default: "1.4" * * COMPILER / Setting Source Compatibility Mode * Specify whether which source level compatibility is used. From 1.4 on, 'assert' is a keyword * reserved for assertion support. Also note, than when toggling to 1.4 mode, the target VM * level should be set to "1.4" and the compliance mode should be "1.4". * Source level 1.5 is necessary to enable generics, autoboxing, covariance, annotations, enumerations * enhanced for loop, static imports and varargs. Once toggled, the target VM level should be set to "1.5" * and the compliance mode should be "1.5". * - option id: "org.eclipse.jdt.core.compiler.source" * - possible values: { "1.3", "1.4", "1.5" } * - default: "1.3" * * COMPILER / Defining Target Java Platform * For binary compatibility reason, .class files can be tagged to with certain VM versions and later. * Note that "1.4" target require to toggle compliance mode to "1.4" too. Similarily, "1.5" target require * to toggle compliance mode to "1.5". * - option id: "org.eclipse.jdt.core.compiler.codegen.targetPlatform" * - possible values: { "1.1", "1.2", "1.3", "1.4", "1.5" } * - default: "1.2" * * COMPILER / Reporting Unsafe Type Operation * When enabled, the compiler will issue an error or a warning whenever an operation involves generic types, and potentially * invalidates type safety since involving raw types (e.g. invoking #foo(X<String>) with arguments (X)). * - option id: "org.eclipse.jdt.core.compiler.problem.unsafeTypeOperation" * - possible values: { "error", "warning", "ignore" } * - default: "warning" * * COMPILER / Reporting final Bound for Type Parameter * When enabled, the compiler will issue an error or a warning whenever a generic type parameter is associated with a * bound corresponding to a final type; since final types cannot be further extended, the parameter is pretty useless. * - option id: "org.eclipse.jdt.core.compiler.problem.finalParameterBound" * - possible values: { "error", "warning", "ignore" } * - default: "ignore"