Posts Tagged: eclipse

Debugging Ant tasks in Eclipse

Today I came  an issue that required me to debug a custom Ant task that we have. While the Eclipse integrated debugger allows you to step through the targets and tasks in the build.xml file using the action Debug As -> Ant Script, it doesn’t actually let you step into the java class that implements the task. This is a major drawback, as most of the complexity (and issues :-)) tend to be in the task implementation code.

After searching around for a bit, I came across the Eclipse Remote Debugger debug configuration. This configuration allows you to remotely debug applications, by establishing a JDWP (Java Debug Wire Protocol, part of JPDA – Java Platform Debug Architecture) connection between the running application and the debugger. After learning about this, setting up the environment to debugg Ant tasks from within Eclipse was pretty straightforward.

The first step is to setup the Ant script launcher to run in debug mode and attach to the debug server. The following should be used as JRE arguments for the Ant configuration:

-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,address=8000

You can setup your Ant configuration by going to Run -> External Tools -> External Tools Configurations and creating a new Ant Build configuration. Inser the location of the build file in the main tab and setup the arguments in the JRE tab:

After the Ant configuration is setup, we need to take care of the remote debugger configuration. Go to Run -> Debug Configurations… and create a new configuration for Remote Java Application. Make sure you set the same port number that you used in the Ant configuration, and you are good to go.

Now, place the breakpoints in your build.xml and java classes. In order to debug, you need to first launch the Ant script and then attach the debugger to it. Do right click in the build.xml file and select Debug As -> Ant Script. Then go to Run -> Debug Configurations… select the Remote Ant Debugger and click Debug. The debugger will now attach to the running proccess and let you step through both the xml file and the java classes:

Have fun!

Mylyn task manager

When I migrated my development environment to Eclipse 3.4 Ganymede, one of the things that caught my attention on Eclipse’s update website was a plugin called Mylyn. A visit to the website, a look over the webcast and it sounded something promising.

It definitely is! Mylyn is a task manager that changes your IDE context based on tasks. You create a task, add resources to its context and when you activate the task, it hides all the other (unneeded) resources from your views (project/package explorer, outlines, editors, etc…). It provides integration with several task repositories, like Bugzilla and Trac. Unfortunately, it doesn’t provide a connector to Clearcase, but I’m still able to use it in an automated way.

I find the tool really awesome when I do something basic like switching tasks: it just closes all the editor windows and projects in the explorer for the task I’m leaving and opens all the files I was working on for the task I’m switching to. This would take me several minutes to do by myself, so having a tool that does that in 1 second is pretty neat!

Here are some more things I like about Mylyn:

  • ability to customize CVS/SVN checkin comments based on templates. Most, if not all, of my commit comments are in the form of “Bug#xxxxx: 1 line description of the bug and fix”. With Mylyn, I can get the comment populated automatically with information from the associated task.
  • when I (re)activate a task, it positions the cursor in the file and method (if java file) I was working on.
  • I can use the URL feature to link to the Clearcase defect page for each one of my defects
  • dynamically adds resources as we follow method references
  • Mylyn filters unrelated content from all views, but I especially like the end result for the package explorer and outline view. When working with classes that have tens of methods, showing just a handful of them in the outline simplifies things a lot!

And the things I don’t like that much:

  • no connector to Rational ClearCase. I have to copy some notes and Defect info from Clearcase to my task manually.
  • the option to show filtered content only shows content at the same level. I would like to have a “show all” option for when I need to look for some resource.
  • It slows down the system a bit. Not too bad, but I do notice it when I have several eclipse instances running.

Overal, I think Mylyn is a great tool and very useful! Even more if you are working with Bugzilla/Trac projects.

If you want to give it a try, this is Mylyn’s homepage and this is a Mylyn tutorial.


Static SQL vs Dynamic SQL

I have been wanting to write a few technical articles here on the blog, so I’ll start with something that is related with what I have been looking into at work: Static and Dynamic SQL.

From the conversations I have had with both DBAs and developers, it is clear that DBAs prefer static SQL, while developers prefer Dynamic SQL.

The difference between static and dynamic SQL is that static SQL needs to be compiled and bound to the database before application runtime, while dynamic SQL is compiled during runtime. Next, I’ll show a list of pros and cons regarding each one. 

Static SQL


  • compile at bind time. Since the statement is compiled only once and before we run our workload, we have all the database resources in order to generate the most optimal query execution plan. In DB2, there are 9 levels of optimization, being 5 the default one. When we bing our application package, we can pick the highest optimization level – 9 – and get the most optimal execution plan. Using a higher optimization level requires more resources for the compile phase, but since our workload is not yet running, we can afford this high resources requirement.
  • security. Security is probably the most common reason why people use static SQL instead of dynamic SQL. Static SQL allows the DBA to set authorization at the package level. For example, consider an application package app1, that provides SQL functionality to select employee’s name and address from the table employees. The DBA can five user JOHN execution privileges on package app1, even if user JOHN does not have SELECT authority on table employees. Static SQL provides a much finer layer of security.


  • need to bind before runtime. Although binding before runtime usually allows for more optimized access plans, doing this in a test or development environment can be cumbersome.
  • lack of tooling support. most of current IDEs provide coding assistance with support for APIs like JDBC. The lack of support from development tools discourages the use of static SQL.

Dynamic SQL


  • IDEs and APIs: using eclipse to develop Java code that interacts with the database using JDBC or JPA is much simpler than developing a SQLJ application.
  • statement caching. Dynamic statement caching avoids the need to compile the same statement multiple times, increasing the performance to values close to static SQL. However, bear in mind that a cache miss will be extremely expensive.
  • better statistics. Because the statement is compiled at runtime, it uses the latest statistics available, contributing to a better execution plan.


  • compile at runtime. There are a few reasons why compile at runtime can be a bad thing:

    • every time a statement is executed, it needs to be compiled, increasing the total statement execution time
    • the compile time will account for the total execution time, so using higher optimization levels may slow down the overall performance instead of improving it.
    • because the statement is only compiled at runtime, errors in the SQL statement won’t be detected until runtime.

As you can see, there are several reasons why you would choose one over the other. There is no perfect solution! But if you ask me, I would suggest the following: use Static SQL if security is your main concern and use Dynamic SQL if ease of development is your main concern.