Nilesh Kapadia

As you may already know, Java's generics are just compile-time checking and are not implemented in the JVM, whereas C#'s generics have type-checking implemented in both the compiler and the CLR and is more strongly-typed. However, Java's looser implementation allows the following, whereas C#'s does not:

Lets say we have a generic interface:

public interface GenericInterface<T> {
    public int getSize(T t);
}

And we have interfaces that extend this interface:

public interface StringInterface extends GenericInterface<String> {
}

Example of how to write functions that return the name of the calling method (only works in Java 1.5):

	public static String getCallingMethod() {
		return trace(Thread.currentThread().getStackTrace(), 2);
	}

	public static String getCallingMethod(int level) {
		return trace(Thread.currentThread().getStackTrace(), 2 + level);
	}
	
	private static String trace(StackTraceElement e[], int level) {
		if(e != null && e.length >= level) {
			StackTraceElement s = e[level];
			if(s != null) {
				return s.getMethodName();
			}
		}
		return null;
	}

JUnit test for this (assuming the methods above were written in a class called StackUtil):

A common complaint with the Spring Framework is that doing configuration in XML is problematic. You don't know at compile-time if your configuration is valid and it doesn't work with existing Java refactoring tools.

Now you can use annotation-based Java code for configuration. It is in development but looks promising. Read about it at Rod Johnson's blog or a blog at Spring-Loaded. Download a copy of it here.

For one of my projects, I have used Java 5 Generics to simplify creation of Hibernate DAO's. I no longer have to duplicate the typical CRUD operations in every DAO class. Note that I am using Spring's HibernateDaoSupport. If you want to see an example of a non-Spring generic DAO, the authors of Hibernate have posted one on their blog. Though mine may not be the best practices for Hibernate, I thought I'd post it just to show an example of what can be done with Java 5 generics and how much code can be reduced with it.

I recently migrated a web project that was using MyEclipse to using Eclipse WTP. It was actually quite simple. This assumes you have Eclipse 3.1 and WTP 0.7 installed (WTP also requires EMF and GEF to be installed). I started by creating a web project using WTP's template (create a new "Dynamic Web Project"). Then I inspected the files it created and applied the differences to my existing MyEclipse-based project.

I came across an Eclipse plugin that adds an "Open Implementation" option so you can right-click on declarations/instances/method calls of interfaces and open an implementation for it (if there's only one, it goes straight to it, if there is more than one gives you a choice first). You can also assign a hotkey to it (defaults to ALT-F3).

I know I wrote an entry before with some links to how to do this before, but I just recently went through the process again and wanted to write down the specific steps.

First to install Java 5, go to the Sun download page, select JDK, and get the non-RPM installer for Linux.

There are two issues with Axis(Java)/.Net interop that were discovered in a project I am involved in. We are using doc/literal web services as mentioned in my last entry about Java/.Net web services interop.

1. Empty arrays received from Java are interpreted as null objects on the .Net side. I have not fully researched why this happens, but we work around it by checking for null.
   

Although I had heard about it before, I had never actually tried out Hibernate Synchronizer. I was using Middlegen to generate my Hibernate mappings as well as the Java classes for my domain objects (which I think is actually using some of Hibernate's own tools to generate them from the mappings). The Middlegen generated mapping files tended to have a lot of imperfections in them, mainly in the name of properties for objects involved in relationships (one-to-many, many-to-one, etc). It would name the property to that of the name of the class, which was often inappropriate. If there was more than one relationship property with the same class type, it had a different scheme that would disrupt the existing code in a project (for which refactoring ahead of time might help prevent, but still an inconvenience). There were also some bugs I discovered where sometimes two properties were named with the same name, named with a starting capital letter (defying Java convention), or incorrectly read from the database. To solve all these issues, I was doing a lot of regexp replace (in the Ant script), but that tends to get unmanageable after a while. In the end, although Middlegen may provide a good starting point, I decided that hand-editing the mapping files is the best approach. Also, the generated Java classes had the disadvantage that I couldn't really edit them because if I regenerated them I'd lose my changes, so even using HBM2Java was inconvenient and lead me to start hand-editing the Java classes as well.

This entry can be summed up in two statements: