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.
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).
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.