Community
Participate
Working Groups
As part of its increased support for Javadoc, the model will support extracting Javadoc from attached source or HTML. It will allow defining optional classpath entries. The codeassist engine will be support pluggable extensions which can participate and contribute new proposals and/or filter others. Codeassist will support CamelCase pattern; and provide completions on new artifacts such as Javadoc, break/continue label. [JDT Core, JDT Text]
Note that while bug 106000 has been set to later, it *is* possible to participate in the code assist process on jdt-ui level. So, extensions can contribute proposals (see bug 91496) and plug-in their own sort order (bug 119603). Filtering is not currently supported as this goes against the rule to "add, don't replace".
Typo in original description: The codeassist engine will *be* support pluggable extensions ... --> The codeassist engine will support pluggable extensions ...
The CamelCase pattern can be extended to make plugins participant the matching process. Currently "CharOperation.prefixEquals(...) || CharOperation.camelCaseMatch(...)" is used in CompletionEngine. We can make it pluggable. This happens when the word (in candidate list) can be typed in different keystrokes (different from the word). CamelCase is an example. And asian characters (like Chinese and Japanese) which need composition is another example. (Bug 26528 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=26528).
Javadoc extraction got completed (bug 110172) - Added new API org.eclipse.jdt.core.IJavaElement#String getAttachedJavadoc(IProgressMonitor monitor)(bug 122506) - Added API org.eclipse.jdt.core.IMember#ISourceRange getJavadocRange() throws JavaModelException. This API can be used to retrieve the source range of a javadoc comment attached to the corresponding member. Optional classpath entries got added in 3.2M5 (bug 124117)
# Added Camel Case support in completion. When you perform code complete, the proposals list contains proposals whose name match with the camel case pattern. eg. a possible proposal for TT| is ToTo. # Added option to control Camel Case completion. /** * CODEASSIST / Activate Camel Case Sensitive Completion * When active, completion show proposals whose name match to the CamelCase pattern. * - option id: "org.eclipse.jdt.core.codeComplete.camelCaseMatch" * - possible values: { "enabled", "disabled" } * - default: "disabled" */ JavaCore#CODEASSIST_CAMEL_CASE_MATCH (bug 102572)
Completion engine now supports completion inside Javadoc. User can complete after any word in Javadoc and get most appropriate proposal depending on area of completion. Here is a breaf summary of code assist functionality in javadoc: * Completion of javadoc tag now only gives valid proposals. Some examples: o complete @pa| will give @param proposal only in javadoc of method or generic type declarations, o complete {@co| will give {@code } proposal only if your compiler compliance has been set to 1.5 or over, o etc. * Completion in "formal reference" of @see, @throws, @exception, {@link}, {@linplain} or {@value} tags will behave like completion in java code. Type qualification for types will be inserted depending on "Add import instead of qualified name" Code Assist preferences. * Completion is now available in text area of javadoc comment. Some examples: o complete at caret in following code: /** * This is an example of completion inside text area: S| */ public class Sample {} will propose both String and Sample, but also {@link String } and {@link Sample }. Currently each proposal is available either as java code type name or direclty inserted as a {@link} tag. This part is still under work and final behavior should depend on a new JDT/UI preferences... o complete at caret in following code: /** * This is an example of completion inside text area: #m| */ public class Sample { void method() {} } will propose {@link #method() }. New API methods have also been added to CompletionContext: /** * Tell user whether completion takes place in a javadoc comment or not. * * @return boolean true if completion takes place in a javadoc comment, false otherwise. * @since 3.2 */ public boolean isInJavadoc() {...} /** * Tell user whether completion takes place in text area of a javadoc comment or not. * * @return boolean true if completion takes place in a text area of a javadoc comment, false otherwise. * @since 3.2 */ public boolean isInJavadocText() {...} /** * Tell user whether completion takes place in a formal reference of a javadoc tag or not. * Tags with formal reference are: * - @see * - @throws * - @exception * - {@link Object} * - {@linkplain Object} * - {@value} when compiler compliance is set at leats to 1.5 * * @return boolean true if completion takes place in formal reference of a javadoc tag, false otherwise. * @since 3.2 */ public boolean isInJavadocFormalReference() {...} (bug 113506, bug 113376, bug 113374, bug 106466, bug 87868, bug 86112, bug 67732, bug 22043)
# Code Assist: added support for completing on label in break/continue statement. (bug 22072)
# Added new CompletionContext API (first part of fix for bug 110181) : /** * Returns the completed token. * This token is either the identifier or Java language keyword * or the string literal under, immediately preceding, * the original request offset. If the original request offset * is not within or immediately after an identifier or keyword or * a string literal then the returned value is <code>null</code>. * * @return completed token or <code>null</code> * @since 3.2 */ public char[] getToken() /** * Returns the kind of completion token being proposed. * * The set of different kinds of completion token is * expected to change over time. It is strongly recommended * that clients do not assume that the kind is one of the * ones they know about, and code defensively for the * possibility of unexpected future growth. * * @return the kind; one of the kind constants declared on * this class whose name starts with <code>TOKEN_KIND</code>, * or possibly a kind unknown to the caller * @since 3.2 */ public int getTokenKind() /** * Returns the character index of the start of the * subrange in the source file buffer containing the * relevant token being completed. This * token is either the identifier or Java language keyword * under, or immediately preceding, the original request * offset. If the original request offset is not within * or immediately after an identifier or keyword, then the * position returned is original request offset and the * token range is empty. * * @return character index of token start position (inclusive) * @since 3.2 */ public int getTokenStart() /** * Returns the character index of the end (exclusive) of the subrange * in the source file buffer containing the * relevant token. When there is no relevant token, the * range is empty * (<code>getTokenEnd() == getTokenStart()</code>). * * @return character index of token end position (exclusive) * @since 3.2 */ public int getTokenEnd() /** * Returns the offset position in the source file buffer * after which code assist is requested. * * @return offset position in the source file buffer * @since 3.2 */ public int getOffset()
