Java Problem: Generic Inheritance and Calling GetMethod().getReturnType()

In my current project, I have classes which are modeled like the following. At some point, a method like getReturnTypeForGetId() is called on classes A and B. Calling the method with A returns Integer as expected, but B returns Serializable.

What am I missing here? Am I getting bitten by some heinous erasure thing, or am I just missing out on some sort of generic context-clobbering?

EDIT: Adding an over-ridden getId() method to B fixes the problem, but I would still like to understand what I am running into.

I've also asked this question on stackoverflow.

import java.io.Serializable;

public class WeirdTester {
    static interface Identifiable<T extends Serializable> {
        T getId();
        void setId(final T id);

    static abstract class BaseEntity<T extends Serializable> implements Identifiable<T> {
        private T id;
        public T getId() { return id; }
        public void setId(final T id) { this.id = id; }

    static class A implements Identifiable<Integer> {
        private Integer id;
        public Integer getId() { return id; }
        public void setId(final Integer id) { this.id = id; }

    static class B extends BaseEntity<Integer> {}

    private static <T extends Serializable, Q extends Identifiable<T>> Class<T> getReturnTypeForGetId(
            final Class<Q> clazz) throws Exception {
        return (Class<T>) clazz.getMethod("getId", (Class[])null).getReturnType();

    public static void main(final String[] args) throws Exception {
        // CONSOLE: "class java.lang.Integer"
        // CONSOLE: "interface java.io.Serializable"


Quick Hint: Command-line tools for MonoDevelop on Mac OS X

In doing some investigation for doing contract-first development for web services on .NET, I ran into the wsdl command-line tool. Unfortunately, I was unable to find its equivalent in the MonoDevelop IDE. I finally did some digging around in the terminal and found the MonoDevelop command-line tools at: /Library/Frameworks/Mono.framework or /Library/Frameworks/Mono.framework/Versions/current/bin.


Using MonoDevelop to Create an ASP.NET Web Service

NOTE: instructions below are for MonoDevelop 2.6 Beta 2 - built on 2011-04-06 03:37:58+0000

Getting Started

Create a new ASP.NET Web Application in MonoDevelop:

  1. From the menu, select: File → New → Solution…
  2. Expand C#.
  3. Select ASP.NET → Web Application.
  4. Enter a name for the ASP.NET project that will be created in the solution in Name:.
  5. Change the root location for the solution in Location:, if desired.
  6. Change the name of the root solution in Solution Name:, if desired.

The Results – I

What you have after executing the new ASP.NET Web Application project wizard is a solution containing one ASP.NET Web Application project. In the default project view in MonoDevelop, you'll find the following items:

  • Default.aspx – This is the default web form rendered and presented in the browser when http://<server>:<port>/ is accessed.
    • Default.aspx.cs – This C# file contains the developer-created common code and event handlers which can be used to affect the processing of the form.
    • Default.aspx.designer.cs – This C# file contains the IDE-generated code for the page.
    Both of the above files contain partial class definitions which are compiled together into a single code-behind class at runtime.
  • Global.asax – This file contains the basic information which is available to the entire application.
    • Global.asax.cs – This C# file contains methods and event handlers for the entire application. These include event handlers for: application initialization, application termination, session handling, error handling, and request handling.
  • web.config – This file contains the primary configuration for the application when deployed to a server. A secondary set of configuration options can be found in the server's Machine.config file.

If you go out to the location where you created the solution/project, you will also find a few other files:

  • /<solution name>/<solution name>.sln – This file contains configuration information for the entire "workspace" of projects.
  • /<solution name>/<solution name>.userprefs – This file is generated by MonoDevelop and contains information specific to the user of the MonoDevelop application. The consensus is that this file should not be included in source-control.
  • /<solution name>/<project name>/<project name>.csproj – This file contains configuration information for the particular project.
  • /<solution name>/<project name>/<project name>.pidb – This binary file contains meta-data generated by MonoDevelop. The consensus is also that this file should not be included in source-control.

Setting Up the Web Service

Since I'm only really interested in exposing a web service using this project, I felt that I really don't need the Default.aspx.* or Global.asax.* files as they are currently not doing anything for the project. I deleted all five of the files.

Create a new ASP.NET Web Service file in MonoDevelop:

  1. In the Solution pad, right-click your project and select: Add → New File…
  2. Select ASP.NET → Web Service.
  3. Enter a name for the file that will be created in the project in Name:.

The Results – II

After the ASP.NET web service wizard has completed, you'll find a new asmx file in your project. This file will contain the basic WebService directive, some using statements (System and System.Web.Services), a namespace, and a class definition.

Exposing a Method in the Web Service

Next, you'll want to create a method that you want to expose as a method on your web service. Add the WebMethod attribute to it. Your asmx file will now look something like this:

When you run this project, you can view a simple front-end for the service at http://localhost:8080/<web service file name>.asmx. This web form is created at runtime by the ASP.NET container.

What? No code-behind?

While it is normally a good practice to separate a view from the code which contains its logic, as in an aspx file, there is really no reason to do so in an asmx file as there is no visual component which must be separated from the code.


Getting Started with .NET on the Mac

I'm setting out to learn .NET and get some experience creating a non-trivial project. Microsoft does provide Express (free, Windows-only) editions of the Visual Studio application in a few flavors as well as basic version of IIS with ASP.NET and SQL Server. But, since my current personal development environment is a MacBook Pro (OSX 10.6.7), getting started with development on .NET can actually cost money (mostly due to the Windows tax). The primary development tool for .NET developers on non-Windows systems seems to be Mono with MonoDevelop.

The latest stable release of Mono (2.10.1) supports much of the functionality of the .NET 4.0 platform and some portions of Microsoft's extended .NET eco-system: F#, IronRuby, IronPython, ASP.NET MVC(1, 2, and portions of 3).

The latest beta build of MonoDevelop (2.6 beta 2) provides a lot of support for developing applications using C# and the rest of the CLR.

I'll be using these in the coming months to do some experiments in the creation of a blogging engine in .NET. As part of proving that I can work in the .NET world. You can see the results of my experiments on my github page.

Mono also provides two other interesting projects:

  • Mono for Android -- run .NET applications on Android devices.
  • MonoTouch -- run .NET applications on iOS devices (iPhone, iTouch, iPad).


Testing Toolbelt: Testing non-xml attributes of responses in SoapUI

I spend a large part of my time developing web services, so I spend a lot of my time testing web services. One of the major tools I have in my toolbelt for automating web service tests is SoapUI. SoapUI does a lot of things, and even does a lot of things which I don't need, but it does the things I need very well. Today, I was trying to set up some testing for the security on my current project. As I was setting up the test request and pointing SoapUI at the appropriate endpoints with invalid http basic authorization credentials, I realized that there was no straight forward way to assert that the http response code was 401 (unauthorized) or 403 (forbidden). I did some digging, and found that you could create a Script Assertion (using Groovy) in the SOAP Test Step and use the pre-defined variable, messageExchange, to examine contents and statistics for the test step.

Asserting that a SOAP request with no credentials was responded to with a 401

Asserting that a SOAP request with invalid credentials was responded to with a 403

The Script Assertion also has access to two other pre-defined variables: context and log. context contains methods which allow you to examine the request and response programmatically and log, well I haven't had to use yet. These are posts for another day.

Maven Note: Securing a temporary Jetty instance in the jetty-maven-plugin

One of my tasks for the current iteration was to add security constraints to the J2EE web service that we are currently developing. This is the easy part. Simply define the appropriate security-constraint, login-config, and security-role elements in the project's web.xml.


From the above, you can see that I defined an expected role, AUTHORIZED_USER, an expected realm for http basic authentication, APP, and a set of resources, / and /*, which can only be accessed through SSL by a user who is a member of the AUTHORIZED_USER role. This is the easy part and should work for most application servers which are worth their salt.

Enter jetty-maven-plugin

This project is already using the jetty-maven-plugin to run a test instance of the application. I thought it would be a good idea to make sure that the security on the localhost instance for testing would work in the same manner as the WebSphere server to which the application is to be deployed. This would help me to ensure that I, as a lazy programmer, would not have to change the functional tests (SoapUI) between localhost and dev.

By default, the jetty instance created by executing mvn jetty:run-war does not include a user realm for defining users and groups, a login service for handling attempted logins, or even the capability for handling SSL connections. In order to bring these components into the localhost instance, I had to make some changes to the configuration of my project's jetty-maven-plugin. First, the changes for enabling the user realm and login service.

pom.xml (version 1)


Using the keytool-maven-plugin for generating a certificate for SSL

In order to enable server authentication, the Jetty instance needs to have access to a server certificate to be sent out in the SSL handshake. I did some investigation and found that there was a plugin, keytool-maven-plugin, which would allow you to automate self-signed certificate generation in the maven execution. I modified the project's pom as follows:

pom.xml (version 2)

Adding SSL support to Jetty

Now, we have a way for the client to authenticate itself, a realm for assigning that client's roles, and a keystore. We just need to tell Jetty how to expose an SSL port to the world.

pom.xml (version 3)

A big thank-you to mrhaki and his article Configure Maven Jetty Plugin for SSL Communication for the assist.


Testing Toolbelt: SpringJUnit4ClassRunner

The org.springframework.test.context.junit4.SpringJUnit4ClassRunner class is another implementation of the JUnit TestRunner class which is used to enable various features of Spring for every run of the test class and every test within it. To use the features provided by the SpringJUnit4ClassRunner class, you need to mark the class using the RunWith annotation using SpringJUnit4ClassRunner as its parameter.

In addition to the custom test runner, you will want to mark the class with the ContextConfiguration annotation. The ContextConfiguration annotation is used to mark classes which will automatically read a Spring configuration file and use it to create an ApplicationContext. By default, this file located at <package path>/<test class name>-context.xml. Use the locations argument to over-ride.

The ApplicationContext used by the Spring-integrated test will only be loaded once for the whole test class. This behavior can be over-ridden by annotating a test method with the DirtiesContext annotation, which causes the ApplicationContext to be reloaded after the test method completes.

Test Property Injection

Fresh versions of the properties for the test, including the class under test, can be automatically injected for every test, either by name or type. A test class property marked with the Autowired annotation will be automatically set by type from the test's ApplicationContext. However, if there are multiple instances of the property's type, it could be better to set the property by name. The Resource is used to mark test class properties which should be set by name from the test's ApplicationContext.

Transaction Management

With the declaration of a TransactionManager bean, and the use of the Transactional annotation, transaction boundaries are declarative and are automatically managed. Simply fire up the test and forget about whether or not your integration test changed the state of the database you're using to test.

The Transactional annotation is used within transactional Spring tests to mark test classes and methods which should have a transactional nature applied to them. When used to annotate a test class, a transaction context will be created before each test method is executed. After each test method, the transaction will be rolled-back. This will add the overhead of creating and managing a transaction for every test method in that class, so it is usually better to annotate the test methods with @Transactional instead. This will cause a similar effect to annotating the class, but only annotated test methods will be transactional. Usage of this annotation requires a TransactionManager named transactionManager to be defined in the test's ApplicationContext.

Similar in purpose to the Before and After annotations provided by JUnit, methods decorated with either the BeforeTransaction or AfterTransaction annotation will be run before/after any test method which is affected by the Transactional annotation (i.e. all methods in a class decorated with @Transactional, or each annotated test method when marked individually. Methods annotated with the BeforeTransaction or AfterTransaction annotations must be public and return no value.

Integration Test Helper Classes

When using the SpringJUnit4ClassRunner, you're given access to the ApplicationContext instance and a simplified interface for interacting with your integration test database through JdbcTemplate/SimpleJdbcTemplate.


Testing Toolbelt: Groovy

Groovy, the apparent golden child of Java, is a mostly dynamic-typed JVM language which seeks to add functionality to the core Java language such that writing and testing code is much easier and requires less boiler-plate code. Some of the features provided by Groovy that I have found useful for testing are:

GroovyBean Properties and Constructors

Groovy attempts to simplify the usage of bean-type object by providing some shortcuts for accesses and assignments. By default, every class accessed through Groovy code is decorated with a default constructor which takes a map (property->value), and a getter and setter for each field defined in the class (for which there is not already a getter/setter). The constructor is a simple way to provide values to properties of the new instance.


Token Replacement

In Groovy, the String class is enhanced to allow for the use of tokens within a String literal. These tokens are of the form ${<property>} and will use the properties values available at the time of creation. Refer back to the above example to see some at work.

Collection Literals

Easily create a list by using the [] syntax, a range by using the <start>..<end> syntax, and a map by using the [<key>:<value>] syntax.



Closures are simply blocks of code surrounded by curly braces, which can be treated as reference types. Closures may declare arguments and may return values. Closures may be stored in variables.


Iteration (each)

Iteration of arrays, ranges, lists, and maps has been simplified by the addition of the each method.


Coercion (Map and Closure)

Any map or closure may be interpreted as an instance of a specific type simply by using as <type>. This allows you to easily create stand-in objects, provided they have a public default (no-arg) constructor.



Through the default meta-class implementations used by Groovy, many useful methods (many taking advantage of closures) have been added to the standard Java classes. There's too much to list here, but know that many of the above examples use GDK methods.


The GroovyTestCase class contains a large portion of the testing functionality used by basic Groovy. Since the Groovy team have pledged backwards-compatibility with JDK 1.4, they have also stuck with the non-annotation-based version of JUnit(3.8.*) as a basis for their testing helper class. This is not as bad as it sounds, as many of the language features of Groovy make up for the missing capabilities of JUnit 4.4. Every test class defined using groovy must be a sub-class of GroovyTestCase. Each test method must be public, return void, and be named test<something>.


all of the assert* methods provided by JUnit are also present in the GroovyTestCase class.


similar to the Test annotation when used with the expected argument, the shouldFail method takes a Throwable class type and a closure, executes the closure, and fails if an instance of Throwable is not thrown within the closure.


StubFor and MockFor

The StubFor/MockFor classes can be used within Groovy to create stand-in objects when coercion won't work or when you need to over-ride the behavior of a constructor.



Spring Note: SqlUpdate

The org.springframework.jdbc.object.SqlUpdate class is another tool that I use a lot. This class encapsulates INSERT, UPDATE, and DELETE queries as beans defined within your application context. In most situations, you will be using the SqlUpdate class as-is with multiple configurations within a DAO's context. Since the class is not abstract, it is quite easy to extend for creating dummy/mock instances for testing.



New Group: Columbus Software Craftsmanship

As you may or may not know, I have two homes: SW Indiana, and Columbus, Ohio. Since I spend 75% or more of my time in SW Indiana and there are few opportunities in this area for networking/learning the craft, I'm always happy to learn about new groups of like-minded people in my other home.

I found this group through a random tweet from Marc Peabody. He mentioned that they would be trying out some Scala Koans and included a link to the group's Google Groups site. Since joining the group earlier today, I've found the details for the Scala Koans night and I've been informed of interest in running a Code Retreat event at the beginning of April in Columbus.

I haven't made it to any meetings yet (they're still a pretty new group), but I've had some friendly conversations in e-mail with members of the group and have met some of the other members through NFJS, COJUG, CRB, etc... Sounds like it should be a pretty good time when I'm able to make it.

Maven note: exec-maven-plugin

I'm currently working on a development package containing a series of .xsd files which will be used to define the external interface for our web service. Due to some other project constraints, it was decided that this package also needed to include the .wsdl files which will further define the web service.

I'm a lazy (the good kind) programmer, so I decided that I did not want to update these files every time the schema changed nor did I want to make anyone else figure it out later. I wrote a quick utility for creating the .wsdl files, based on the current .xsd files. Since we're already expecting to use Spring-WS for message dispatching, I wrote some file generation code around the org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition class and wrote up a Spring configuration which put it all together.

My next task was to figure out a way to get this utility to run within the context of the Maven package phase. Since the code needed to generate the .wsdl files was the only code in this development package, it made sense to hook into the prepare-package phase instead of the generate-sources phase. Now that I knew when the utility should run, I just needed to figure out a way to do it. One Google search later, and I had the exec-maven-plugin. This Maven plugin provides two goals which can be hooked into arbitrary phases in the Maven life cycle:

  • exec -- execute an arbitrary executable from within the Maven runtime
  • java -- execute the main method, with arguments, of a specified class, from within the Maven runtime

So I set up my pom as shown below, and ran mvn package. The end result was a .jar file which contained both the .xsd and the .wsdl files we need. One mvn deploy later and these files were now available to all who needed them.


Testing Toolbelt: Hamcrest Matchers

The Hamcrest Matchers framework contains a series of Matcher classes which help implement comparison and assertion methods in a type-safe, declarative manner. When used in tests, the Matchers framework will produce more legible test code and more helpful failure messages. The Matchers framework is partially included in the JUnit 4.4 package and some portions can be used effectively. But, the full power of the framework can only be unleashed by including the real Hamcrest Matchers jar within your testing environment.


The org.hamcrest.Matchers class in the Hamcrest framework provides a series of methods, intended to be used with import static, which supply various pre-defined org.hamcrest.core.Matcher instances.
  • is -- The simplest matcher, most times behaves just as syntactical sugar around other matchers. But, if an instance of Class is passed, it behaves like the Matcher produced by instanceOf. If passed any other value, behaves like the Matcher produced by equalsTo. see org.hamcrest.core.Is
  • equalTo -- Verifies that the test value is equal to the value used to instantiate the Matcher. see org.hamcrest.core.IsEqual
  • instanceOf -- Verifies that the test value is assignable to the Class value used to instantiate the Matcher. see org.hamcrest.core.IsInstanceOf
  • nullValue/nonNullValue -- Verifies that the test value is null-valued/not-null-valued. see org.hamcrest.core.IsNull
  • startsWith/containsString/endsWith -- Verifies that the test value (String\-typed) begins with, contains, or ends with the value used to instatiate the Matcher. see org.hamcrest.core.StringStartsWith, org.hamcrest.core.StringContains, and org.hamcrest.core.StringEndsWith
  • arrayWithSize/emptyArray/hasSize/empty -- Verifies that the test value is an array/collection that either has the given number of elements/is empty. see org.hamcrest.core.IsArrayWithSize, org.hamcrest.core.IsCollectionWithSize, and org.hamcrest.core.IsEmptyCollection
  • lessThan/lessThanOrEqualTo/greaterThanOrEqualTo/greaterThan -- Verifies that the test value is strictly less than/less than/greater than/strictly greater than the provided value. see org.hamcrest.core.OrderingComparison


Testing Toolbelt: JUnit

The JUnit framework is arguably the de-facto standard for unit testing java code, and is also the basis of many other testing frameworks (unit or otherwise). Using the JUnit framework, one can quickly run a test method, class, or suite and get one of three responses:

  • Success: All of the assertions in the test method passed, no fail calls were encountered, and no unexpected exceptions were thrown.
  • Failure: One of the assertions in the test method failed or a fail call was encountered.
  • Error: An unexpected java.lang.Throwable was thrown within the test method's body.

For the sake of brevity, and since I am mostly using Java 1.6 these days, this discussion will focus on JUnit 4.4 which is based on annotations and static imports instead of specially-named methods and the extension of the junit.framework.TestCase class.


Every method that should be run as a test should be annotated with the org.junit.Test annotation. The Test annotation must be used on only public void methods and the annotated method can only take parameters when used in conjunction with the Parameterized annotation discussed below. The Test annotation can take two optional arguments:

An optional argument to the Test annotation which declares that the test method is expected to throw a Throwable of the defined type. If the method does not throw a Throwable of an appropriate type, the test will fail. If any other Throwable escapes the method body, the test will be considered in error.
An optional argument to the Test annotation which declares that the test method is expected to complete within the defined number of milliseconds. If the method does not return in time, the test fails.


Public methods marked with these annotations will be run before each test (setUp()), after each test(tearDown()), before each test suite, or after each test suite. These annotations are usually used to setup and reset the environment in which the tests are running.


The org.junit.Assert class is expected to be used through the use of static imports, and contains a large number of static methods which can be used to ensure that the elements of a test are in an expected state. Each of the assert* methods has two forms:

assert*(actual, expected)
performs the assertion and fails with a default failure message.
assert*(message, actual, expected)
performs the assertion and fails with a custom failure message. (sometimes in addition to the default message)

Here are some of the main assertion methods:

Asserts that the parameter is(not) null-valued.
Asserts that the parameter is true|false?
assertEquals(actual, expected)/assertArrayEquals(actual, expected)
Asserts that actual and expected are equal().
Causes the current test to immediately fail. Use this when writing custom assert methods or when creating new empty test methods.
assertThat(actual, Matcher)
The entry point into the Hamcrest Matcher framework, which will be covered by itself in a different post. This method, when used in conjunction with a Matcher instance is more capable, and produces more helpful failure output than the other JUnit assert* methods.


The org.junit.runners.Parameterized class is a non-default JUnit TestRunner implementation which allows for the creation of a series of test class instances, one for each of the parameter sets defined in the parameter generation method. Each of these test class instances will then be executed.

Every class which uses the Parameterized class as a runner must provide a source method for the parameters. The parameter source method is marked using the org.junit.runners.Parameters annotation. The parameter source method must be static and return a Collection of values or arrays. Each element in the returned collection represents a single test class execution and will be passed to the constructor for a new instance of the test class. The constructor must accept the same number of arguments and those arguments must be of a compatible type to those contained in each element of the returned collection.

An example of Parameterized usage:


Spring Note: RowMapper/MappingSqlQuery


The RowMapper class is an interface which defines only one method which turns a single row from a ResultSet into a domain-useable object. While you can use a generic implementation of this class for producing column name/value Maps, my typical usage has been to create domain objects from the result of a specific set of queries.


The MappingSqlQuery class is intended to be used for SELECT queries and can use a RowMapper implementation to create a result List of the appropriate type, hiding the intermediate ResultSet from the outside world.

These classes, when taken together, provide excellent tools for creating the read methods for DAO classes which are concise and testable.



Clearing the Backlog

I've had several posts brewing in the background. I'm going to pump out a few posts tonight and finally bid them a fond adieu. So, here they come fast and furious, and maybe not as deep as I originally expected them to be.