Java development tools
JUnit |
|
Java Editor |
|
| Call Hierarchy on Ctrl+Click |
|
Java Views and Dialogs |
|
Java Compiler |
|
Java Formatter |
|
| New Javadoc html format option |
When the formatter option Comments > Javadocs > Format HTML tags is selected, the default behavior for block tags (<pre>, <p>, <dl>, <ul>, <ol>, <hr>, and <dir>) is to put each tag and it's closing tag on separate lines. A new sub-option: Do not put block tags on separate lines has been added to specify not to do this and instead have the tags start on a new line and have their closing tags end a line.
For example, without the option, the following:
is formatted to:
and with the option specified, is formatted:
|
Debug |
|
| New launch config name preference |
For launch configurations, a name is often generated on behalf of the user which is simply the type name of the Java application, Java applet, or the JUnit test class. In some instances, a user may have classes with the same name in different packages or projects. Creating launch configurations for each will reuse the type name and add (nn) for each configuration created after the first. Looking in the Run Configurations or Debug Configurations dialogs or the pull-down for Run or Debug, it may be difficult to determine via the name which type the configuration is referring to.
To alleviate this, a new set of preferences has been added to specify that the launch configuration name generated use the fully qualified type name. Once set, new configurations (either manually created in the Run Configurations or Debug Configurations dialogs or as a result of specifying Run as... or Debug as... from the context menu will qualify the generated name. Existing configurations are not altered. To specify the new preferences, go to Preferences > Java > Launching
Launching a Java application results in:
|
JDT Developers |
|
| Method to mark message keys used |
When developing Java code, there are set mechanisms for handling message translation. There is also a context action Source > Find Broken Externalized Strings which checks .properties file and Java message translation classes that access the .properties file. The action checks for a number of issues including whether a message key is unused or missing and provides the results in the Search dialog.
When detecting unused keys, it is possible for the action to generate false positives. For example, a message could be used by another plug-in or product which is not in the workspace or a message key could be dynamically created and the action cannot detect this. A new mechanism has been added for a developer to denote that a message key is known to be used and should be ignored by the Find Broken Externalized Strings action. Simply copy any known used messages from the existing .properties file into a .usedproperties file with the same name, in the same package. The .usedproperties file follows the same syntax as a .properties file and any message keys added there will not be marked as unused by the action. The message data in the .usedproperties file is ignored and can be removed if desired. |
| Updated CompilationParticipant API |
New |
