Java: Find all instances of System.out.println()

A good Java application should print only the absolute necessary to standard out. Not to do so can mean a serious hit in performance and can make it difficult to debug issues.

Unfortunately either we ourselves or our colleagues put System.out.println() statements in the code and then forget to remove them.

Here are two solutions how to find all those nasty statements.

Solution 1: Do a Full Text Search

Use your IDE and search for all occurrences of the string “System.out.println()” in your code. In eclipse this can be done through Menu / Search / File …

Make sure to use *.java for the file name pattern.


Solution 2: Put a Breakpoint in PrintStream

The above solution might not be practical if there are many System.out statements in the code which are legitimately there. In that case, you can also put a break point into the Java standard class PrintStream.

In eclipse, open the search for class dialog (Ctrl+Shift+t) and type in the class name PrintStream from the package


In this class, find the print(x) method and add a breakpoint:


Then run your program in debug mode. You can then find the places where System.out is called from the stack trace.


Setting Up Xtend with Maven and eclipse (Luna)

Xtend is currently my favourite alternative language for the JVM (closely followed by Kotlin). Unfortunately, I did not find a good guide of how to set up a Maven project within eclipse (Luna) which uses Xtend.

Specifically the following guide will allow you to allow you to write test cases in Xtend for your existing Java projects. A great way to get started with Xtend I suppose.

The following describes the necessary steps.

  • Install the Xtend plugin for eclipse as described here.
  • Add the xtend-maven-plugin to your pom.xml as follows:


  • Also add a dependency to the Xtend runtime libraries
  • Right click the project and select Maven / Update Project … and update the project.
  • Right clock the project and select Properties
  • Go to the Xtend / Compiler page
  • Set as the ouput director src/test/java

  • Go to the folder src/test/xtend. If the folder does not exist, create it.
  • Right clock the folder src/test/xtend and select Build Path / Use As Source Folder
  • Create a package in the new src/test/xtend folder and right click the package. Select New / Xtend class and define a class such as the following:

import org.junit.Assert
import org.junit.Test

class TestThatNumbersAreEqual {
    def void test() {
        Assert.assertTrue(3 == 3)
  • Immediately after you save the class a translated class should be created in the folder src/test/java

Now, have fun writing tests using Xtend’s concise syntax – while not affecting any step of your build and development workflow!

To see an example configuration in a complete project, also check out async-map on GitHub.

Setting Up eclipse Luna with Maven for Android

As of August 2014, don’t even try this.

Officially, the Google Eclipse plugin supports Eclipse 4.4 (Luna) at present. However, in order to be able to create projects which are both Maven projects and Android projects you will need to install the m2e-android plugin. This currently does not support eclipse Luna. Probably, if you create a new Android project based on the archetype suggested by the m2e-android plugin, you might get errors such as:

  • …R cannot be resolved to a variable
  • Plugin execution not covered by lifecycle configuration: (execution: default-generate-sources, phase: generate-sources)
  • Project configurator “” is not available. To enable full functionality, install the project configurator and run Maven->Update Project Configuration.
  • Plugin execution not covered by lifecycle configuration: (execution: default-proguard, phase: process-classes)

My recommendation is to use Android Studio.

You can easily add Maven dependencies to projects in Android Studio. Just locate the ‘build.gradle’ file in your application directory and add a compile dependency.

New Repository for OSGi-ready Maven Artifacts

UPDATE 2015:

For good repositories for OSGi artifacts also check:

SpringSource Enterprise Bundle Repository

Eclipse Bundle Recipes Project

Here the original post:

Although the onedb libraries are currently deployed as vanilla Java JAR files (onedb downloads), I have used the PDE tooling of eclipse heavily in the development process.

One core advantage of using OSGi in the development process is that OSGi allows to enforce information hiding between modules in a large Java application.

Unfortunately, most open source projects do not provide versions of their libraries, which are ready made for an OSGi environment. There is some great tooling available to create bundles from vanilla Java Jars, my favorite one being the Maven Bundle Plugin, which wraps the BND tool.

However, it can still be an annoyance to create your own OSGi-enabled maven artifacts for every dependency you want to use in your OSGi project.

This is my motivation to publish OSGi wrappers for all the third party dependencies I come across in my projects:

-> osgi-maven on github <-

Basically, these wrappers provided nothing more but a simple pom, which is pre-configured to generate valid OSGi declarations for the wrapped dependency:

OSGi Wrapper Artifacts

If the project is easy to build and/or there is no single artifact available, which could be wrapped, the wrapper might also contain the source code of the third party dependency. Therefore, please make sure that you use all wrappers in accordance with the source code license of the wrapped artifact.

Currently, the wrapper artifacts provide the following key features:

The following libraries are defined in the repository:

… and more coming.

Eclipse and Github Tutorial

Github is an awesome repository to share your source code. Although there are numerous tutorials discussing how to use git and eclipse, I got stuck again today while trying to upload an existing eclipse project to github. This tutorial walks thus through all the steps from signing up for github to uploading an eclipse project to the site!

Please note that the focus of this tutorial is the mere upload of source code and not any of the more sophisticated features git and github offer.

The following steps will be discussed in this tutorial:

  1. Sign Up for github
  2. Installing EGit
  3. Create a DSA Key in Eclipse
  4. Register DSA Key with github
  5. Create Repository on github
  6. Import github Repository into eclipse
  7. Link Eclipse Project with github Repository
  8. Uploading Project Sources to github

Step 1: Sign Up for github

That’s the easiest part, just go to and register!

Step 2: Installing EGit

You will need to install the git plugin for eclipse, EGit, in order to upload code from eclipse projects.

  • In eclipse, go to Help / Install New Software

  • Open the eclipse Indigo repository

  • Select Collaboration / Eclipse EGit

  • Click [Next]
  • JGit should have been selected for you automatically

  • Click [Next] and confirm the licence agreement
  • Restart eclipse and the EGit plugin should be installed

Step 3: Create a DSA Key in Eclipse

In order to be able to upload source code to github, you need to define a secure key, which must be known both to your local eclipse installation as well as the github service. Luckily, eclipse provides all the tooling necessary to generate the appropriate key.

  • Open Menu Window / Preferences
  • In the preferences, go to General / Network Connections / SSH2
  • On the SSH2 page, open the tab ‘Key Management’

  • Click on [Generate DSA Key …]
  • At the bottom of the page, enter a passphrase of your choosing

  • Click [Save Private Key …] (what’s going on with these three dots in the button captions … strange)
  • Save the key at a location of your choosing (best in the location specified as your SSH2 home on under the tab General)

Step 4: Register DSA Key with github

  • Open the file you have saved in the previous step with a text editor (e.g. Notepad on windows)
  • Select the contents of the file (Ctrl + A) and copy the complete text
  • Go to the github website ( and login
  • On the top right of the screen, click on ‘Account Settings’

  • On the left hand side of the account settings, click on ‘SSH Keys’

  • Click on [Add SSH key]
  • Provide an appropriate title for your key (e.g. ‘EGit 1’ ?)
  • Paste the contents from the text file containing your DSA key into the text box ‘Key’

  • Click [Add Key] at the bottom of the form

Step 5: Create Repository on github

In order to upload source code from a project in eclipse to github, you will need to create a github repository.

  • Go to github homepage ( and log in
  • At the top right corner, click on ‘Create a New Repo’


  • Chose a repository name and description to your liking and click [Create Repository]

Step 6: Import github Repository into eclipse

Before you can link an existing eclipse project to a github repository, you must import the repository you have created on github first. For this:

  • In eclipse, open Menu / Window / Show View / Other …

  • Select Git / Git Repositories and click [Ok]

  • You might see a warning message such as the one show below (even setting the environment variable did not help me to get rid of the message, but everything seems to be working okay) – you can confirm with [Ok]

  • You should have a new view ‘Git Repositories now’
  • Click on ‘Clone a Git repository’ within the new view

  • Now go back to and to your newly created github repository
  • Under your repository description, you can get the URI for your project. Copy the text starting with ‘git@’ (make sure that SSH is selected)

  • Go back to eclipse. You can paste the URI you have just copied into the field ‘URI’
  • Further select as Protocol ‘ssh’
  • Click [Finish]

  • If asked to select a branch, select the ‘master’ branch

Git (in difference to subversion) allows storing a full blown repository on your local machine rather than just a local copy of the files. This requires to store all source you want to synchronize with git at least twice on your local machine: one copy will be stored in the clone of the remote git repository and another one will be stored in your eclipse project.

Hence, when you close the git repository from github, you should define a repository location, which lies outside the eclipse project you want to upload:

  • Select one such location and click [Finish]

  • Now you should have one ‘Git Repository’

Step 7: Link Eclipse Project with github Repository

After you have created a local clone of the repository from github, you can link the eclipse project you would like to upload to this local repository.

  • Right click your eclipse project and select Team / Share Project …
  • Select ‘Git’ as Repository Type

  • Select under ‘Repository’ the repository you have cloned in the previous step and click [Finish]


Step 8: Uploading Project Sources to github

After you have linked your project with the local clone of the github repository, you can ‘Commit’ all the source files in your existing project to this repository. After you have committed the files to your local repository, you can ‘Push’ them to the github repository.

  • Right click your project and select Team / Commit … from the popup menu

  • Write a beautiful commit message and click [Commit]

  • In the ‘Git Repositories’ view, open <your repository> / Remotes / origin
  • Right click on the second icon (with the red arrow) and select ‘Push’

  • You should receive the results of the push, click [Ok] to confirm

  • You can now go to github and your project sources should be displayed in your repository:

(hmm, did it really took 2 hrs to get this done …)


Git with Eclipse (EGit) – Tutorial (

Getting Started with Git, EGit, Eclipse, and GitHub: Version Control for R Projects

git push rejected (

A Short Tutorial on Eclipse/EGit/GitHub

Tutorial: Using the EGit Eclipse Plugin with GitHub



JavaDoc Editor for eclipse

Formatting JavaDoc using plain HTML can be a troublesome and time-intensive experience. Today I installed the JDocEditor plugin for eclipse, which allows editing JavaDoc in eclipse using a small rich text editor.

Here, a quick evaluation, a few screenshots and a little getting started guide.



  • Free
  • Helps to reduce the hassle of dealing with line breaks and paragraphs in JavaDoc
  • Allows to compose lists and do simple formatting like using bold and italics

Not so good:

  • The editor has no native support for JavaDoc annotations such as @link, …
  • The editors handling of line breaks, paragraphs and basically any more sophisticated formatting can be unpredictable at times


  • Good tool to enhance productivity in editing JavaDoc documentation with simple formatting.


The Editor:

Generated JavaDoc (rendered):

Generated JavaDoc (html):

Getting Started

  • Install using the update site
  • After the plug in has been installed, add the view of the plugin to your workspace as shown below

  • The view can be found under the category JavaDoc Editors/ JDocEditor


StackOverflow Discussion “JavaDoc editor for Eclipse to create formatted text”

Blog post on JDocEditor from 2005

JDepend Plugin for Eclipse

The other day I came across another interesting static source code analysis plugin for eclipse: JDepend. JDepend calculates a number of quality metrics for Java packages (therewith it has a slightly different unit of analysis to other tools, which focus on methods, classes or projects).

I found that Andrey Loskutov has created an excellent eclipse plugin based on JDepend called JDepend4Eclipse.

After installation of the plugin, context menus for packages (not projects) will feature another item ‘Run JDepend analysis’.

Executing this analysis will result in a nicely formatted report being generated. The results can easily be interpreted with the JDepend documentation.

I tend to build very small modules, in which I place a kind of factory for concrete implementations along with some essential interfaces in the main package of the module. It seems that JDepend is not fond of this practice, since the factory depends on the concrete implementations (in the .internal* packages) and these in turn depend on the essential interfaces within the main package. However, I am not yet convinced that this practices is very bad, as long as circular reference between modules are avoided.

Eclipse and SVN to manage Apache Web Server

In order to configure a simple Apache Web Server, I found myself many a time connecting to a UNIX system using putty, fiddling around with various configuration files using pico or vim. I don’t want to count the times I deleted some configuration I later missed dearly or forgetting to close some xml element. Two of the main problems for me were:

(1) As much as some might be convinced of the productivity of text-based editors like pico and vim, for me it just doesn’t fly. Of course one shouldn’t use the mouse for everything but windows, the mouse cursor, tabs, and various visualizations such as trees seem just too useful to me to be completely abandoned.

(2) I have become too used to the convenience of a versioning system when developing source code. Although I know there are various ways to backup a UNIX-based system, I would like all the convenience modern source code management systems offer in organizing the versions of text-based files.

I decided to try using two established technologies to address these problems:

  • Eclipse is a well-known integrated development environment primarily for the Java programming language, allowing for many conveniences in editing text-based files.
  • Subversion (or SVN) is a centralized versioning system for just about anything. Although Subversion can be very cumbersome at times (talk about deleting folders …), it is supported by many platforms and can become almost usable when one knows of its limitations.

The following is a description of the necessary steps to set up a development environment for Apache web server configuration files (and basically any other kind of configuration files one might encounter on a remote server) build on eclipse and subversion.

Step 1: Install Subversion on your web server

Installing Subversion on the various flavours of UNIX is very straightforward and Google quickly yields useful instructions. Here, for instance the instructions for Ubuntu Server.

Please note that you need to install subversion on your web server primarily for the SVN command line client, so omit any configuration steps regarding setting up a subversion server.

You can check the success of this step by typing in your remote console ‘svn –version’.

Step 2: Install Subversion Server

It is sensible to install a subversion server on a different machine than your web server. This will also allow for an easy way to backup various configuration files from your web server.

Again, there are numerous instructions for setting up a subversion server. See for instance, this post for setting one up on Ubuntu. One of the easiest ways is using VisualSVN to install a subversion server as a windows service.

Step 3: Create a Repository on your Subversion Server

You can either use one for your already set up repositories (if you use subversion for other project) or create a new repository dedicated for web server configurations.

In VisualSVN, you can right click ‘Repositories’ and select ‘Create New Repository’ which opens the dialog given below.

Step 4: Create a project in your repository

Since the folders in which the configuration files lie on the web server are already filled with files and folder, we need first to create an empty project on the subversion server.

In VisualSVN, we can right click the newly created repository and create a new Project Structure as shown below.

Step 5: Add the folders on your web server to version control

After we have created a ‘skeleton’ project on the SVN server, we can start to upload the configuration files from the web server.

For this we go to the folder, from which we want to upload the files. For instance, /etc/apache2.

cd /etc/apache2

In this folder, we initialize the SVN checkout operation:

sudo svn checkout https://%5Byour SVN server]/svn/webRepro/webMyApacheConf/trunk/ .

Next, we can add the folders we want under version control. For instance, the folder conf:

sudo svn add conf

Finally, we commit and upload the files to the SVN server:

sudo svn commit

Step 6: Import the files into eclipse

In order to import the files uploaded to the subversion server, we need to install the Subversive eclipse plugin. After doing so, the following option should be available under File / Import:

In the following dialog, we first specify our SVN repository (../webRepro/) and the project (../webRepro/webMyApacheConf). Note that you should select the ‘trunk’ folder rather than the project root.

Chose to check out the project as a project configured using the New Project Wizard.

As type for the project, select General / Project.

Step 7: Edit configuration files in eclipse

Now, the configuration files from your web server should be available as eclipse project.

Just click and edit these files in the eclipse editors. If you have made changed, right click the project and select Team / Commit, which will commit the changed files to the subversion server.

Step 8: Import changed files to web server

Finally, if you have changed files in eclipse, you need to reimport these files onto your web server. For this connect to your web server and navigate to the directory you have placed under version control. For instance:

cd /etc/apache2

To download the changed files, type

sudo svn update

As a result, the changed files should be downloaded to your web server.

Then, don’t forget to restart your server to see the effect of the changes.





Maven and Eclipse: New Website

After having published a number of posts on Maven and integration between Maven and eclipse in particular, I have been thinking for a while to summarize some best practices in a post. I have found that these best practices are actually too long and too interdependent to fit nicely in a blog post. Therefore, I have created a little webpage:

I will start to publish a number of templates for Maven pom.xml files there. The first two templates are already defined:

Most notably, I have found that it safes lots of trouble to separate clearly between projects, which establish a dependency to a third party library, and those, which implement new logic. This is of particular importance when defining the projects as OSGi bundles. Since the OSGi metadata can be defined automatically by Maven, I think there is no excuse to write any module without OSGi metadata: maybe someone will require it at some point in time and it also aids in improving modularity (Walls, 2009).

Relocating SVN repository for multiple projects in eclipse workspace

Although an SVN server is possibly a fixed anchor in dynamic and distributed development efforts, even these servers might have to be relocated from time to time. Surprisingly, this can be done quite swiftly, even in complex set ups, for instance an eclipse workspace comprised of dozens of projects stored on a number of different repositories. In the following, a few simple steps are listed to inform eclipse of the relocation of an SVN server or repository.

First, the SVN repositories view must be opened. This can be accomplished through Menu / Show View / Other …

And then selecting the view “SVN Repositories” under SVN (please note that Subversion must be installed for this view to be present).

The opened view shows all the SVN repositories, which are used by projects in the workspace (or which have been defined in eclipse otherwise). The SVN repositories here should correspond to the SVN labels/server addressed displayed after the project name in the eclipse workspace overview.

Now, right click the SVN repository, you want to relocate. And select “Location Properties” in the pop up menu.

Here, you can specify the new address of your SVN repository. Just rewrite the given URL (in the example, you would rewrite for instance “; to “; )

Click finish and the repository locations of all projects in the eclipse workspace using the repository will be updated to the new location.


Make sure that the repository you want to move FROM is available when the relocation operation is performed. Otherwise, eclipse might produce all kind of undesirable errors.