Nilesh D Kapadia

Previously I had blogged about using JavaHL in Linux. JavaHL is the bindings to the native Subversion libraries which uses JNI, and it sometimes requires a bit of effort to get working. I no longer find using JavaHL necessary as I no longer have problems with the pure Java library SVNKit (formerly known as JavaSVN). I also have switched to Subversive instead of Subclipse because I have found it to be less problematic.

Despite being an official Eclipse project now, Subversive won't install from Eclipse 3.4's default repository, and you still need to get some plugins directly from Polarion. If you want to use the latest Subversive and SVNKit that supports Subversion 1.6, add the following update sites:

• http://download.eclipse.org/technology/subversive/0.7/update-site/
• http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/

And then install the following from those update sites:

• Subversive SVN Connectors (2.2.0)
• Subversive SVN Team Provider (0.7.8)
• SVNKit 1.3.0 Implementation (2.2.0)

Note that the version numbers will change in the future, but these are the current versions that work with 1.6.

Let's say you have a method call like this:

List<Object> list = (List<Object>) beanWrapper.getPropertyValue(key);

And beanWrapper.getPropertyValue returns an Object. If you have the "Unchecked generic type operation" compiler setting set to warning, you will get the following warning:

Type safety: Unchecked cast from Object to List<Object>

If you are using Eclipse, it will give you a quick fix to add a @SuppressWarnings(value = "unchecked") annotation, but only give you the option to add it to the current method.

(the current method in this case is getBean())

But we may not want to suppress warnings for the entire method. We can just put the annotation on the method call itself:

@SuppressWarnings(value = "unchecked")
List<Object> list = (List<Object>) beanWrapper.getPropertyValue(key);

I recently created some SOAP web service clients using Apache CXF (which is a project that resulted from the merging of XFire and Celtix). Rather than hunt down all the jar files I needed and write an Ant script to do the build, I decided to use Maven for this. It worked nicely and saved me some time (I can't say the same for some of the more complex projects I've tried to use Maven with).

I found the following blog entry very useful for setting this up:

How to create a WSDL-first SOAP client in Java with CXF and Maven

One thing I did different was use a property to specify the CXF version in one place:

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <cxf.version>2.2.1</cxf.version>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-rt-frontend-jaxws</artifactId>
      <version>${cxf.version}</version>
    </dependency>
    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-rt-transports-http</artifactId>
      <version>${cxf.version}</version>
    </dependency>

Pay attention to what it says about the cxf.xml file. I used the Maven Eclipse Plugin to generate my Eclipse project files. If you do this, but forget the cxf.xml file, your client may still work fine in Eclipse, but when you try to use the Maven-built jar file, you will get an error like this:

javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException
	at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:314)

Running a Java web application (that would normally run in a servlet container) using embedded Jetty is pretty useful because it means you can run it in a debugger with hot code replace without needing a special app server launcher.

To do this, I downloaded Jetty and included the jars as described in this document in my classpath:

http://docs.codehaus.org/display/JETTY/Embedding+Jetty

Then I followed the instructions here that Sanjiv Jivan had wrote up, making modifications that were specific for my environment:

http://jroller.com/sjivan/entry/embedding_jetty_in_a_spring

I have a class that looks like this:

import org.springframework.context.support.FileSystemXmlApplicationContext;
 
public class JettyLauncher {
    public static void main(String[] args) throws Exception {
    	new FileSystemXmlApplicationContext("path/to/jetty.xml");
    }
}

Update: This has been fixed in MyEclipse 7.1.

There is a bug in MyEclipse 7.0 which causes the template configuration preference to quit functioning. When I go into the template configuration, I get a dialog with the heading "Could Not Accept Changes" and the following error message:

The currently displayed page contains invalid values.

And the configuration page is almost completely blank. It just says "Create, edit or remove templates:".

This has been reported at this forum topic and they are aware of the bug. It exists in 7.0 M2 and 7.0 GA. MyEclipse 6.5 (w/ Eclipse 3.3) doesn't have this problem.

Workaround

I use this rather inconvenient workaround to get around this:

My workaround is to use a clean copy of Eclipse (that doesn't have MyEclipse installed) with its own workspace, and edit my custom templates in that copy. Eclipse stores custom templates in this file (along with a lot of other configuration):

ECLIPSE_WORKSPACE/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs

So what I do is I copy the line that starts with "org.eclipse.jdt.ui.text.custom_templates=" followed by XML from the clean copy to the one with MyEclipse installed. And restart Eclipse to pick up the change.

If you try this workaround make sure to make a backup of this file before you edit it, just in case something goes wrong.

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

public class StackUtilTests extends TestCase {
 
	public void testGetCallingMethod() {
		String callingMethod = StackUtil.getCallingMethod();
		System.out.println("callingMethod = " + callingMethod);
		assertEquals("testGetCallingMethod", callingMethod);		
	}
 
	public void testGetCallingMethodWithLevel() {
		String callingMethod = StackUtil.getCallingMethod(0);
		System.out.println("callingMethod = " + callingMethod);
		assertEquals("testGetCallingMethodWithLevel", callingMethod);		
	}
 
	public void testGetCallingMethodOneLevel() {
		String callingMethod = testGetCallingMethodOneLevelPrivate();
		assertEquals("testGetCallingMethodOneLevel", callingMethod);
	}
 
	private String testGetCallingMethodOneLevelPrivate() {
		String callingMethod = StackUtil.getCallingMethod(1);
		System.out.println("callingMethod = " + callingMethod);
		return callingMethod;
	}	
 
}

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



Here is my generic class:

public abstract class AbstractHibernateDAOImpl<T extends Serializable, KeyType extends Serializable>
        extends HibernateDaoSupport {
 
    protected Class<T> domainClass = getDomainClass();
 
    /**
     * Method to return the class of the domain object
     */
    protected abstract Class<T> getDomainClass();
 
    @SuppressWarnings("unchecked")
    public T load(KeyType id) {
        return (T) getHibernateTemplate().load(domainClass, id);
    }
 
    public void update(T t) {
        getHibernateTemplate().update(t);
    }
 
    public void save(T t) {
        getHibernateTemplate().save(t);
    }
 
    public void delete(T t) {
        getHibernateTemplate().delete(t);
    }
 
    @SuppressWarnings("unchecked")
    public List<T> getList() {
        return (getHibernateTemplate().find("from " + domainClass.getName() + " x"));
    }
 
    public void deleteById(KeyType id) {
        Object obj = load(id);
        getHibernateTemplate().delete(obj);
    }
 
    public void deleteAll() {
        getHibernateTemplate().execute(new HibernateCallback() {
            public Object doInHibernate(Session session) throws HibernateException {