Contributing Java Editor templates via a plugin

JDT provides several editor templates. You can also add your own via the Templates View. However, if you want to share the templates between your several workspaces or with others you can also create a plugin.

As a first step, define the following extension for the extension point org.eclipse.ui.editors.templates.

   <extension
         point="org.eclipse.ui.editors.templates">
      <include
      file="templates/default-templates.xml"
      translations="$nl$/templates/default-templates.properties">
      </include>
   </extension>

The xml file just contains the template descriptors. For example, here is a template for printing the enclosing type and the enclosing method.

<template name="debugout" description="%Templates.debugout" id="com.eclipse.jdt.ui.templates.debugout" context="java-statements" enabled="true" autoinsert="true">
System.out.println("${enclosing_type}#${enclosing_method}(..)");${cursor}
</template>

You can read about the available template variables in Eclipse help.

I have also shared a plugin with the above code on GitHub.

Eclipse Tip: Stepping into selection and hyperlink debugging

The Java debugger allows you to step into a single method within a series of chained or nested method calls. Simply select the method you wish to step into and select Step into Selection from the Java editor context menu. I prefer to use the shortcut Ctrl+F5.

You can also step into a method by using hyperlink navigation. Simply place the cursor over the method you wish to step into and use Ctrl+Alt+Click to step into the method (rather than Ctrl+Click which will navigate to the source code).

JDT Tip: Toggle between inserting and replacing content assist

When content assist is invoked on an existing identifier, it can either replace the identifier with the chosen completion or do an insert.

The default behavior is to insert. You can toggle this behavior while inside the content assist selection dialog by pressing and holding the Ctrl key while selecting the completion. The highlighted text is overwritten.

If you wish the completion to overwrite without pressing the Ctrl key then you can select 'Preferences > Java > Editor > Content Assist > Completion overwrites'.

JDT Tip: See different hovers in Java editor by using modifier keys

•  When you move the mouse over an identifier that has no error or warning, by default a hover with the Javadoc is shown. 

• However if there is an error or a warning on the identifier then the corresponding message is shown.

  

• To see the Javadoc even in this case, you can enable the Javadoc hover on this preference page and define a key modifier e.g. Ctrl+Shift. 

  

• Now press Ctrl+Shift while hovering to see the javadoc.

JDT Tip: Mark Occurrences in Java editor

I think everyone knows that the Java editor highlights occurrences of variables and method calls.

But did you know that it also highlights

• Method exit points - select (or place caret in) the method return type

• Method calls or statements throwing an exception - select (or place caret in) an exception in a catch block

• Break/Continue targets - select (or place caret in) break or continue keywords

Evaluating expressions in JDT Debugger

You can use the Display View to type in an expression and evaluate it in the context of the current stack frame. (The name Display is not great - see bug 342144).

- Use content assist to type expressions

- Select the expression and use Ctrl+Shift+I (Inspect) to show the result in a pop-up. You can also invoke the Inspect command from the context menu.

- Press Ctrl+Shift+I again to persist the result in the Expressions view.

See also Eclipse help.

Printpoints : Debugging by writing to console

There are two ways of debugging

• Breakpoints - I typically use breakpoints when
• I do not have much idea of the code and need to inspect variables and expressions at a number of places to gain an understanding of what is happening.
• I am making some changes and want to see how these changes affect a particular variable/expression, also I am confident that one or two iterations of this change-test process will suffice

• Printpoints - There are scenarios when the breakpoints fail or are inefficient, in these cases I just use System.out.println(). This is typically when
• the breakpoint hits too often, for example keypress, focus, mouse events
• I want to see the order of thread execution
• I am making some changes and want to see how these changes affect a 'few' variables/expressions, also I am confident that it will take 'a number' of iterations of this change-test process to fix the bug. Printing everything to console in this case proves to be much more efficient than stepping through the code.
  

Most developers (including me till recently) insert the print statements in their code and the problem with that is that you have to take them out later. I know you can sometimes leave them in the source as tracing statements, but most of the time they have to be taken out. But there is a solution...

The conditional breakpoint editor in Eclipse can be 'tricked' to create what I like to call as Printpoint - and define as a 'point' in code where the debugger does not 'break' but only 'prints' to console. Essentially a Printpoint is a conditional breakpoint that never suspends execution but only prints to console. To set a printpoint, set a conditional breakpoint with Suspend when 'true' option and a condition which is always false. e.g.

Code templates are available in the condition editor, so you can create a template under 'Java statements' context and use it here. Bug 315404 has been filed to have this available in JDT by default.