Author: geek

The default JFileChooser doesn’t prompt to overwrite files when saving. It also doesn’t automatically add an extension to the file if the user didn’t type one. I had to do a custom one to support these features for better usability.

The limitation of this specific implementation is it only supports one “image” extension, and it’s not i18n-ed. Customize it more for your own needs.

private class CustomFileChooser extends JFileChooser {
  private String extension;
  public CustomFileChooser(String extension) {
    super();
    this.extension = extension;
    addChoosableFileFilter(new FileNameExtensionFilter(
      String.format("%1$s Images (*.%1$s)", extension), extension));
  }

  @Override public File getSelectedFile() {
    File selectedFile = super.getSelectedFile();

    if (selectedFile != null) {
      String name = selectedFile.getName();
      if (!name.contains("."))
        selectedFile = new File(selectedFile.getParentFile(), 
          name + '.' + extension);
    }

    return selectedFile;
  }

  @Override public void approveSelection() {
    if (getDialogType() == SAVE_DIALOG) {
      File selectedFile = getSelectedFile();
      if ((selectedFile != null) && selectedFile.exists()) {
        int response = JOptionPane.showConfirmDialog(this,
          "The file " + selectedFile.getName() + 
          " already exists. Do you want to replace the existing file?",
          "Ovewrite file", JOptionPane.YES_NO_OPTION,
          JOptionPane.WARNING_MESSAGE);
        if (response != JOptionPane.YES_OPTION)
          return;
      }
    }

    super.approveSelection();
  }
}

In this example, node is the XML node (which can be a document) you want to dump. You’ll see the XML in System.out. If you like the output in a String (e.g. for logging), use a StringWriter as the output.

Transformer serializer = TransformerFactory.newInstance().newTransformer();
serializer.setOutputProperty(OutputKeys.INDENT, "yes");
serializer.transform(new DOMSource(node), new StreamResult(System.out));

Declaring Enums in a non-static inner class is explicitly disallowed by the JLS. This is because a nested enum type is implicitly static.

I’m trying to find out why.

Workarounds:
1. Declare inner class as static.
2. Move Enum to outer class/top-level class.

Avoid referencing resources by absolute paths as they are likely to end up in jars. Depend on a delegated strategy which uses Class.getResourceAsStream().

Avoid using i18n for non language purposes. It should be used solely for text shown on the screen. Code properties should be kept in property files. And vice versa.

Eclipse has a powerful debugger, which allow breakpoints, code stepping, variable inspection, expressions, hot code replacement etc. Therefore any application that is run from Eclipse can be debugged.

Even if it is a built and released application running on a separate machine, it can also be debugged remotely from an Eclipse IDE. As this option is built into the JVM, it can work on any kind of Java application; from simple Java applications to web applications to complex Eclipse RCP plugins.

Just add these JVM options to the command that starts the application/web server.

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1234

When the application is started, it will wait for a debugger to be attached.

From Eclipse, Open the Debug dialog, and create a new “Remote Java Application”. Set the host and port in the “Connection Properties” section to the waiting application. Click “Debug” and watch it go! Set the breakpoints and it can be debugged as if it was locally run.

Don’t catch NullPointerException. Check for it.

String concatenation to create a hash key or to store multiple values is easy but fragile. Prefer an object key with a proper hashcode. Prefer an object to store multiple values. Otherwise use a standard such as CSV instead of using your own “dash-separated values”. Use a library to handle escaping problems (a name may also contain a comma).

If you do need to concat Strings, use StringBuilder/StringBuffer. Know the difference between the two.

Emma is a coverage tool.

EclEmma is an Eclipse plugin that generates Emma coverage. It installs via an update site. It executes via the Run Dialog, so any existing run configuration can be easily “coveraged” (including RCP JUnit tests). An additional coverage tab in the Run Dialog allows you to select which packages will be instrumented.

Results are shown graphically in an Eclipse view, grouped by packages. The view allows you to drill into classes and into methods, showing the coverage of each level along the way. Double-clicking in the view brings up the source code, which is color coded to represent which lines were covered.

This is very useful during the personal development process, as individuals can selectively run unit tests to check for coverage in the related modules they are working with. The results are interactive and allows the developer to quickly see which areas require coverage improvement. This is much easier than waiting and going through a Continuous Integration report later (if any). In fact, I have successfully employed this approach to identify areas lacking coverage, and discovering bugs after having test cases for those areas identified.