Google Git
Sign in
eclipse / platform / eclipse.platform.news / 40174f2b06e73b0e3ec8c676221c1abdcfd0e216 / . / platform / 4.2 / final / eclipse-news-part2.html
blob: aa92c8280419e3757c4aa89f7b6d71900d1de6de [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta name="copyright" content="Copyright (c) Eclipse contributors and others 2012. This page is made available under license. For full details, see the LEGAL section in the documentation that contains this page."/>
<meta http-equiv="Content-Language" content="en-us"/>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<link rel="stylesheet" href="default_style.css" charset="ISO-8859-1" type="text/css"/>
<style type="text/css">
table.news td {border-top: solid thin black;}
table.news tr {vertical-align: top;}
table.news tr td.section {font-size: 20px; font-weight: bold;}
table.news tr td.title {vertical-align: top; width: 30%; font-weight: bold;}
table.news tr td.content {vertical-align: top; width: 70%;}
</style>
<title>Eclipse Juno - New and Noteworthy</title>
</head>
<body>
<h2>Java development tools</h2>
<!-- ****************** START OF N&N TABLE ****************** -->
<table class="news" cellpadding="10" cellspacing="0">
<tbody>
<!-- ******************* Java Editor ************************************* -->
<tr>
<td id="JavaEditor" class="section" colspan="2">
<h2>Java Editor </h2>
</td>
</tr>
<tr id="quick-outline-camel-case">
<td class="title">CamelCase in Quick Outline</td>
<td class="content">
The <b>Quick Outline (Ctrl+O)</b> and <b>Quick Hierarchy (Ctrl+T)</b> in the Java Editor now also
support camelCase matching on the element name, quite similar to the Open Type dialog and Content Assist.
<p><img src="images/quick-outline-camel-case.png" alt="Quick Outline of StyledText with pattern 'gCa'"/></p>
The * and ? wildcards still work, of course.
</td>
</tr>
<tr id="jdt-convert-enhanced-for-loop">
<td class="title">Quick Assist to convert enhanced <code>for</code> loop</td>
<td class="content">
Ever encountered an enhanced <code>for</code> loop and needed access to the <code>Iterator</code> or to the loop index?
Now, you can just use a Quick Assist (<b>Ctrl+1</b>) to convert the loop:
<p>
<img src="images/convert-to-for-loop.png" alt="Screenshot of Quick Assist on the 'for' keyword of an enhanced 'for' loop"/>
</p>
<ul>
<li><b>Convert to indexed 'for' loop</b> is available for expressions of array- and <code>List</code>-based types.</li>
<li><b>Convert to Iterator-based 'for' loop</b> is available for expressions of type <code>Iterable</code>.</li>
</ul>
</td>
</tr>
<tr id="bracket-matching">
<td class="title">Improved bracket matching support in Java editor</td>
<td class="content">
The Java editor now supports highlighting of enclosing brackets.
<p><img src="images/enclosing-brackets.png" alt="Enclosing brackets"/></p>
This can be configured on the <b>Java &gt; Editor</b> preference page.
<p><img src="images/bracket-highlighting-preferences.png" alt="Preferences for bracket highlighting"/></p>
<p>Also, the <b>Navigate &gt; Go To &gt; Matching Bracket</b> action <b>(Ctrl+Shift+P)</b> now works everywhere in a file. If a bracket is not selected
before invoking the action, the action navigates to the nearest enclosing end bracket. On invoking the action a second time, it
navigates to the corresponding start bracket. On the third invocation, the original selection is restored.</p>
<p>So far, a matching bracket was found when the caret was placed immediately after a bracket. Now,
a matching bracket is found both when the caret is placed either immediately before or immediately after a bracket.</p>
<p><img src="images/matching-bracket.png" alt="Matching bracket examples"/></p>
<p>You can hover over a closing curly brace and see the source near the matching opening brace in a hover.
This is helpful when you want to see the code near the start of a long code block. The hover also tells the number of lines in the code block.</p>
<p><img src="images/bracket-hover-1.png" alt="Bracket hover example 1"/></p>
<p>The hover is also useful to temporarily 'highlight' a short code block.</p>
<p><img src="images/bracket-hover-2.png" alt="Bracket hover example 2"/></p>
</td>
</tr>
<tr id="javadoc-hover-parameter-annotations">
<td class="title">Javadoc hover shows parameter annotations</td>
<td class="content">
Javadoc hovers now render the annotations on method parameters:
<p><img src="images/javadoc-hover-parameter-annotations.png" alt="org.eclipse.User.User(@NonNull String name, int uid, @Nullable String email)"/></p>
</td>
</tr>
<tr id="JDT-editor-for-class-without-source">
<td class="title">'*.class without source' file type</td>
<td class="content">
The new <b>*.class without source</b> file type allows to associate an internal or external editor
to class files that have no source attached. This e.g. allows to open the class file in a decompiler:
<p>
<img src="images/file-associations-page.png" alt="Screenshot of the 'File Associations' preference page"/>
</p>
</td>
</tr>
<tr id="default-implementations-for-correction-proposals">
<td class="title">Default im&shy;ple&shy;men&shy;ta&shy;tions for correction proposals</td>
<td class="content">
JDT now provides the following default implementations for correction proposals that can be used to contribute quick fixes and quick assists.
<ul>
<li><code>org.eclipse.jdt.ui.text.java.correction.ChangeCorrectionProposal</code></li>
<li><code>org.eclipse.jdt.ui.text.java.correction.CUCorrectionProposal</code></li>
<li><code>org.eclipse.jdt.ui.text.java.correction.ASTRewriteCorrectionProposal</code></li>
</ul>
This makes it easier to implement quick fixes/assists that operate on .java files and use an ASTRewrite.
</td>
</tr>
<tr id="content-assist-package-info">
<td class="title">Content assist in package-info.java</td>
<td class="content">
Content assist (<b>Ctrl+Space</b>) is now available inside package-info.java, which is used to declare package-level annotations and Javadocs.
<p><img src = "images/content-assist-pkg-info.png" alt = "Content assist popup to add package-level annotations on package declaration"/></p>
</td>
</tr>
<!-- ******************* Java Compiler ************************************* -->
<tr>
<td id="JavaCompiler" class="section" colspan="2">
<h2>Java Compiler</h2>
</td>
</tr>
<tr id="ignore-warnings-source-folders">
<td class="title">Selectively ignore errors/warnings from source folders</td>
<td class="content">
You can now configure JDT to ignore optional errors/warnings from certain source folders.
<b>Project properties &gt; Java Build Path &gt; Compiler &gt; Source</b>.
<p><img src="images/ignore-warnings-source-folders.png" alt="Java Build path page with 'Ignore optional compile problems' highlighted"/></p>
<p>
With this option set to <b>Yes</b>, JDT will suppress errors/warnings configured in the
<b>Preferences &gt; Java &gt; Compiler &gt; Errors/Warnings</b> page. This can be desirable
for source folders that contain auto-generated classes or tests.
</p>
</td>
</tr>
<tr id="enhanced-switch-diagnostics">
<td class="title">Enhanced diagnostics for detection of incomplete switch statements</td>
<td class="content">
The JDT's analysis regarding incomplete switch statements is now stronger and can be configured more in detail.
<p>The compiler now separately checks two criteria for a switch statement to be complete:</p>
<ul>
<li>A switch statement on an enum should define one case statement for each of the enum's constants</li>
<li>Each switch statement independent of type should define a default case.</li>
</ul>
<p>By default the compiler warns for an enum switch where both criteria are violated:</p>
<p><img src="images/switch-case-enum.png" alt="Warning on switch over enum with missing default case"/></p>
<p>This warning is controlled by the option <b>Preferences &gt; Java &gt; Compiler &gt; Errors/Warnings &gt; Incomplete 'switch' cases on enum</b>.
This option can be strengthened by selecting the new sub-option <b>Signal even if 'default' case exists</b>,
in which case JDT will flag switch statements over an enum type which may have an enum value covered only through a default statement, but not directly through
a case statement. When new enum constants are added, this option will help in detecting the switch statements that do not cover the new value.</p>
<p><img src="images/switch-missing-case-enum.png" alt="Warning on switch with missing case statement for enum value even though default is present"/></p>
<p><img src = "images/switch-new-warnings.png" alt = "Compiler Errors/warnings preference page with new switch diagnostic options highlighted"/></p>
<p> A second addition in the same section of the compiler preferences, <b>Switch is missing 'default' case</b>, controls whether the JDT will flag switch statements
with a missing default case, because such a switch statement will be skipped entirely at runtime if an unexpected value occurs.</p>
<p><img src="images/switch-missing-default.png" alt="Warning on switch with missing default case"/></p>
<p> Note that in cases like the above, the warning also helps to understand another
error against the last statement:<br/>
"The local variable printString may not have been initialized"
is reported because clients could possibly call the method <code>print(Color)</code> with an
enum value that is not known at the time of compiling this method.</p>
</td>
</tr>
<tr id="JDT-resource-leaks">
<td class="title">New options to detect resource leaks</td>
<td class="content">The compiler can now detect leakage of resources i.e. local variables of type
<code>java.lang.AutoCloseable</code> (compliance &gt;= 1.7) and <code>java.io.Closeable</code> (compliance &lt;= 1.6).
<p><img src="images/resource-leak-default-warning.png" alt="Errors/Warnings page with 'Resource leaks' highlighted"/></p>
<p> When the <b>Resource leak</b> option on the <b>Java &gt; Compiler &gt; Errors/Warnings</b> preference page is enabled,
the compiler will issue an error or a warning if the <code>close()</code> method is not invoked locally on a resource.</p>
<p>
<img src="images/resource-leak-example.png"
alt="Resource leak example"
title="Compiler warning on an unclosed resource"/>
</p>
<p> When you enable the <b>Potential resource leak</b> option on the <b>Java &gt; Compiler &gt; Errors/Warnings</b> preference page,
the compiler will issue an error or a warning if the <code>close()</code> method is not invoked locally on a resource
on all the execution paths.</p>
<p>
<img src="images/pot-resource-leak-example.png"
alt="Potential resource leak example"
title="Compiler warning on a resource not closed on all execution paths"/>
</p>
<p> This analysis is less aggressive if a resource is <em>shared between methods</em>, possibly via a field,
where any party accessing the resource could possibly issue the desired call to close().
In some cases (e.g.: passed as an argument to another method) the warning will be softened
to only report a <em>potential</em> leak, in other cases (stored in a field) the analysis
will be entirely silent.
</p>
<p> Additionally the analysis recognizes certain cases as being <em>practically unimportant</em>.
Some examples where the absence of a close() call does not trigger any error/warning are given below:
</p>
<ul>
<li> Resource-less implementors of Closeable, such as StringReader.
<p><img src="images/os-less-unclosed-resource.png" alt="no resource leak reported if resource-less implentor of Closeable is not closed"/></p>
</li>
<li> Wrapping implementors of Closeable, such as BufferedReader, that simply wrap a resource-less Closeable, directly or indirectly.
<p><img src="images/wrapped-os-less-unclosed-resource.png" alt="no resource leak reported when a resource which wraps a resource-less implentor of Closeable is not closed"/></p>
</li>
<li> Wrapped resources where any resource in the chain is (potentially) closed.
<p><img src="images/wrapped-resource.png" alt="potential resource leak reported when any resource in the chain of wrapper resources is closed along some execution path."/></p>
</li>
</ul>
</td>
</tr>
<tr id="JDT-batch-compiler">
<td class="title">New Batch compiler warning options</td>
<td class="content">Two new batch compiler options are now available to configure the
compile time warnings:
<ul>
<li><b>-warn:all</b> can be used to enable all compiler warnings</li>
<li><b>-warn:resource</b> can be used to enable resource leak warnings</li>
</ul>
</td></tr>
<tr id="JDT-build-path">
<td class="title">New build path option to warn when a source folder's output location overlaps another source folder</td>
<td class="content">JDT now shows a build path error when a source folder's output location overlaps another source folder.
This error can be configured on the <b>Java &gt; Compiler &gt; Building &gt; Output location overlaps source location</b> preference page.
<p>
<img src="images/buildpath-error.png"
alt="Build path error when source folder's output location overlaps another source folder"
title="Build path error because src2's output location is src"/></p>
</td>
</tr>
<tr id="annotation-null-analysis">
<td class="title">Annotation-based null analysis</td>
<td class="content">
JDT can now be configured to use annotations designated as null annotations to
perform enhanced inter-procedural null analysis. This feature can be enabled in
<b>Preferences &gt; Java &gt; Compiler &gt; Errors/Warnings &gt; Null analysis</b>:
<p><img src="images/null-prefs.png" alt="Errors/Warnings preference page with 'Enable annotation-based null analysis' highlighted"/></p>
<p> You can use either the default annotations bundled with JDT or use your own annotations
as null annotations. In addition to enabling the null analysis, the annotations need to be on the
Java build path of your project. The default annotations can be found in the <b>org.eclipse.jdt.annotation</b> JAR
in the <code>plugins</code> directory, which can be consumed as an OSGi bundle or plain JAR.</p>
<p>When annotation-based null analysis is enabled, JDT issues new diagnostics based on the nullness
of a variable or a method return type as specified by a null annotation.</p>
<p><img src="images/null-annotation-problems1.png" alt=" public void foo(@NonNull Object o1) {&para; System.out.println(o1.toString()); // OK: o1 cannot be null&para; }&para; &para; @NonNull Object bar(@Nullable String s1) {&para; foo(null); // cannot pass null argument&para; @NonNull String s= null; // cannot assign null value &para; @NonNull String t= s1; // cannot assign potentially null value &para; return null; // cannot return null value&para; }"/></p>
<p> Similar diagnostics are also elicited when the value assigned/returned may potentially be null or has unknown nullness.</p>
<p> Overriding methods are also checked for correctness:</p>
<p><img src="images/null-annotation-problems2.png" alt="class Base {&para; @NonNull Object method(@Nullable Object o) {&para; return new Object();&para; }&para;}&para;&para;class Sub extends Base {&para; @Override // method parameter must allow null&para; @Nullable Object method(@NonNull Object o) {&para; return new Object();&para; }&para;}"/></p>
<p> You can also use the <code>@NonNullByDefault</code> annotation to set a global default on an element (package, type, method) for all enclosed elements.</p>
<p><img src="images/null-annotation-problems-redundant1.png" alt="@NonNullByDefault&para;class MyClass {&para; // redundant @NonNull annotations:&para; public @NonNull Object foo(@NonNull Object o) {&para; return o;&para; }&para; &para; @NonNullByDefault(false) // cancels the default&para; Object bar(@NonNull Object o) {&para; return o;&para; }&para;}"/></p>
<p> As a result of annotating method signatures, the existing intra-procedural null analysis has even more information
because of user-specified annotations and thus provides better results. In the example below, the compiler would not have
been able to evaluate the null status of parameter 'obj' without the null annotation
(option <b>Redundant null check</b> must be enabled to see the warning).</p>
<p><img src="images/null-annotation-problems-redundant2.png" alt="public void foo(@NonNull Object obj) {&para; if (obj == null) { }&para; }"/></p>
<p>The new diagnostics are classified in three categories:</p>
<ul>
<li><b>Violation of null specification</b><br/>
<img src="images/new-null-analysis-message1.png" alt="This option produces the&para; 'Null type mismatch: required '@NonNull String' but the provided value is specified as @Nullable' warning"/>
<p>Here, 'in' is not a legal return value because of the @Nullable annotation in its <b>declaration</b>.</p>
</li>
<li><b>Conflict between null annotations and null inference</b><br/>
<img src="images/new-null-analysis-message2.png" alt="This option produces the&para; 'Null type mismatch: required @NonNull String but the provided value is inferred as @Nullable' warning"/>
<p>Here, 'local' is not a legal return value, because flow analysis for the un-annotated variable 'local' <b>infers</b> that
it can be null on some path.</p>
</li>
<li><b>Unchecked conversion from non-annotated type to @NonNull type</b><br/>
<img src="images/new-null-analysis-message3.png" alt="This option produces the&para; 'Null type safety: The expression of type String needs unchecked conversion to conform to @NonNull String' warning"/>
<p>Here, the return value from 'getLegacyValue()' may or may not be compatible to '@NonNull String'.
Similar to converting a legacy raw type to a generic type, also here essential type information is missing
since 'getLegacyValue()' has no @NonNull or @Nullable annotation.</p>
</li>
</ul>
<p><b>Note:</b> This is the first version of this feature. We are working on making this
easier to consume in Java project setups.
The implemented features are complete and tested, but e.g. support for annotating fields or
APIs from third-party libraries is currently missing.
An initial set of quick fixes is included which will be further improved in the future.
</p>
</td>
</tr>
<tr id="batch-compiler-null-annotations">
<td class="title">Batch compiler options for using null annotations</td>
<td class="content">
You can now configure the batch compiler to use annotations for null analysis by passing the token <b>nullAnnot(nullable|nonnull|nonnullbydefault)</b> to the <code>-warn</code> option,
where nullable, nonnull and nonnullbydefault are the fully qualified names of the annotation types to be used for null analysis. You can use <b>nullAnnot</b> alone
to use JDT's default annotations.
<p>In addition, you can use the <b>-nonNullByDefault</b> token to globally use nonnull as the default when
annotation-based null analysis is enabled. This implies that all types in method signatures without a null annotation are considered as specified non-null.</p>
</td>
</tr>
<tr id="missing-non-null-by-default-annotation">
<td class="title">Detection of missing default nullness annotation</td>
<td class="content">
In order to make non-null the default for un-annotated types in method signatures you may
use the '@NonNullByDefault' annotation on all packages.
To ensure full coverage of all packages you can configure JDT to detect a missing default nullness annotation.
When <b>Preferences &gt; Java &gt; Compiler &gt; Errors/Warnings &gt; Null analysis &gt; Missing '@NonNullByDefault' annotation on package</b>
is enabled, JDT will issue an error/warning in the following cases:
<ul>
<li> When a package does not contain an '@NonNullByDefault' annotation in the package-info.java:
<p><img src="images/missing-nonnullbydefault-package.png" alt="Missing @NonNullByDefault annotation on package warning"/></p>
</li>
<li> When a type inside a default package does not contain a default nullness annotation.
<p><img src="images/missing-nonnullbydefault-type.png" alt="Missing @NonNullByDefault annotation on type warning"/></p>
</li>
</ul>
</td>
</tr>
<tr id="Assert-like-java-assert-null-analysis">
<td class="title">Null analysis treats org.&#8203;eclipse.&#8203;core.&#8203;runtime.&#8203;Assert like Java assert</td>
<td class="content">
Since <b>org.eclipse.core.runtime.Assert</b> is often used just like the Java <b>assert</b> keyword, JDT's null analysis considers
the boolean expression passed into the former as always true after the Assert reference, since if the condition did turn out to be false,
the control flow will never go further than the org.eclipse.core.runtime.Assert reference.
<p><img src="images/assert-warnings.png" alt="Code snippet showing the boolean expression passed into org.eclipse.core.runtime.Assert.isLegal(..) is considered true after the call"/></p>
</td>
</tr>
<tr id="pre-built-index-support">
<td class="title">Faster search with pre-built indexes</td>
<td class="content">
<i>Note: This feature is mainly intended for plug-ins that implement their own classpath container, not for the end user.</i>
<p>You can now tell JDT search to use pre-built indexes instead of having the compiler generate the indexes the first time a JAR is added to the classpath.
This prevents indexing from occurring on the user's machine and lets the user obtain first search results faster.</p>
<p>You can specify the index file as a classpath attribute <code>IClasspathAttribute.INDEX_LOCATION_ATTRIBUTE_NAME</code> of the library.</p>
<p>See <b>Help &gt; JDT Plug-in Developer Guide &gt; Programmer's Guide &gt; JDT Core &gt; Indexes for the Java search</b> for more details.</p>
</td>
</tr>
<!-- ******************* Java Views and Dialogs ************************************* -->
<tr>
<td id="JavaViews" class="section" colspan="2">
<h2>Java Views and Dialogs</h2>
</td>
</tr>
<tr id="encoding-for-source-attachments">
<td class="title">Encoding for source attachments</td>
<td class="content">
You can now specify the encoding for source attachments for libraries e.g.
in <b>Build Path &gt; Libraries &gt;</b> expand the library <b>&gt; Source attachment &gt; Edit...</b>
<p><img src="images/source-attachment-encoding.png" alt="Dialog to specify encoding for source attachments."/></p>
</td>
</tr>
<tr id="errors-warnings-highlight">
<td class="title">Highlighting on Errors/Warnings preference pages</td>
<td class="content">
On Errors/Warnings preference pages, it is sometimes hard to see which item is selected, especially
when you opened the dialog via the "Configure Problem Severity" button.
<p><img src="images/configure-problem-severity.png" alt="Configure Problem Severity button in Java Editor problem hover"/></p>
Now, an arrow highlights the selected item, and another arrow highlights the item under the mouse.
<p><img src="images/errors-warnings-highlight.png" alt="Highlighting in preference pages"/></p>
The highlighting also works on the PDE and API Tools preference pages.
</td>
</tr>
<!-- ******************* Properties File Editor ************************************* -->
<tr>
<td id="PropertiesEditor" class="section" colspan="2">
<h2>Properties File Editor </h2>
</td>
</tr>
<tr id="JDT-property-key-quick-assists">
<td class="title">Quick assists to reorganize property keys</td>
<td class="content">
If you use Eclipse-style externalized strings, the following new quick assists make it easier to
reorganize keys inside the <b>Properties File Editor</b>:
<ul>
<li><b>Rename in workspace</b> - renames the key in the properties file and updates all references</li>
<li><b>Create field in '...'</b> - creates the corresponding field in the resource bundle accessor class</li>
<li><b>Remove property</b> - deletes the property from the properties file and the field from the resource bundle accessor class</li>
<li><b>Remove properties</b> - deletes the selected properties from the properties file and the fields from the resource bundle accessor class</li>
</ul>
</td>
</tr>
<!-- *********************** Debug ******************************** -->
<tr>
<td id="Debug" class="section" colspan="2">
<h2>Debug</h2>
</td>
</tr>
<tr id="export-detail-formatters">
<td class="title">Export detail formatters</td>
<td class="content">
Detail formatters (which are e.g. used to render objects in the Variables view) can now be exported as separate preferences. Previously, the only way to share detail formatters was to export
all of your workspace settings.
<p><img src="images/detail-formatters.png" alt="Detail formatters in the export dialog"/></p>
</td>
</tr>
<tr id="show-monitors-default">
<td class="title">Show Monitors on by default</td>
<td class="content">
The default setting for displaying monitor information in the <b>Debug</b> view is now set to <em>on</em>.
This change only affects new workspaces and does not change existing settings.
<p>
Showing monitor information can be turned on or off using the <b>Java &gt; Show Monitors</b> view action
within the <b>Debug</b> view.
</p>
</td>
</tr>
<tr id="toggle-bp-mod-keys">
<td class="title">Toggle breakpoint modifier keys</td>
<td class="content">
There is now support for modifier keys while toggling breakpoints in the Java editor:
<ul>
<li><p>Holding the <b>Ctrl</b> key while double-clicking (toggling) a breakpoint will cause the <b>Properties
dialog</b> for that breakpoint to be displayed (on the Mac, use <b>Command</b>)</p>
</li>
<li>Holding the <b>Alt</b> key while double-clicking (toggling) a breakpoint will <b>enable / disable</b> that breakpoint</li>
</ul>
If there is no existing breakpoint, a normal breakpoint toggle takes place even if a modifier key is held down.
</td>
</tr>
<!-- ******************* JUnit ************************************* -->
<tr>
<td id="JUnit" class="section" colspan="2">
<h2>JUnit</h2>
</td>
</tr>
<tr id="junit-4-10">
<td class="title">JUnit 4.10</td>
<td class="content">
The JUnit 4 version shipped with Eclipse has been updated to <a href="https://github.com/KentBeck/junit/blob/r4.10/doc/ReleaseNotes4.10.txt">4.10</a>.
</td>
</tr>
<!-- ****************** END OF N&N TABLE ****************** -->
</tbody>
</table>
<p align="center"><a href="eclipse-news-part1.html">Previous</a>&nbsp;&nbsp;&nbsp;&nbsp; <a href="eclipse-news-part3.html">Next</a></p>
</body>
</html>