System Mobile, Inc

Despite Java’s age, there are a few hidden methods that sometimes escape developer attention. One of these is Class#isAssignableFrom(Class). It’s understandable if you’ve reviewed this method and your eyes glazed over at the documentation - it’s horrible:

Determines if the class or interface represented by this Class object is either the same as, or is a superclass or superinterface of, the class or interface represented by the specified Class parameter. It returns true if so; otherwise it returns false. If this Class object represents a primitive type, this method returns true if the specified Class parameter is exactly this Class object; otherwise it returns false.


Specifically, this method tests whether the type represented by the specified Class parameter can be converted to the type represented by this Class object via an identity conversion or via a widening reference conversion. See The Java Language Specification, sections 5.1.1 and 5.1.4 , for details.

That’s a long was of saying that calling this method on a subclass or implementing interface returns true. Otherwise it returns false. Here’s some example code you can compile and run to get a clear explanation:


import java.util.*;
public class AssignableTest {
  public static void main(String[] argv) {
    ArrayList implementation = new ArrayList();
    Class interfaceClass = java.util.List.class;
    System.out.println(interfaceClass.isAssignableFrom(implementation.getClass()));
    System.out.println(implementation.getClass().isAssignableFrom(interfaceClass));
  }
}


So it’s clever, but when is this method useful? If you’re using something like Hibernate that deals with CGLIB proxies, class equality can break. CGLIB proxies are subclasses of your object, so code like:


if (myInstance.getClass() == MyDomainObject.class) {
  //...
}


doesn’t work if ‘myInstance’ is actually an instance of a CGLIB proxy, rather than your persistent object. Instead, isAssignableFrom(Class) works as expected:


if (MyDomainObject.class.isAssignableFrom(myInstance.getClass())) {
  //...
}


Granted, it’s not useful very often, but it can avoid some ugly reflection hacks if you didn’t know it existed.

nick Entry

I spent some time looking at various profilers and settled on YourKit. It came highly recommended from other developers, and integration with IDEA is excellent. However, running it on my 15″ Powerbook creates a problem when using IDEA’s “Edit configuration…” window. The YourKit additions cause the window to extend past the Dock, making the buttons at the bottom of the screen unavailable.

Not a major problem by any means, but highly annoying. I sent an email to the kind folks at YourKit and, after a few more emails to get the details of the problem, I was notified today that a fix is forthcoming in the next early access build. Excellent turnaround for a small software vendor, especially for a minor bug.

Support aside, YourKit is a very good profiler, helping me to diagnose even the smallest performance problems.

nick Entry

When I started using Wicket, one of the things that wasn’t obvious to me was how to change, or add, attributes to markup elements. It’s pretty simple once it’s pointed out. Here’s the markup sample:


<a wicket:id="myLink" class="nav1" href="#">Link</a>


The code to change the ‘class’ attribute is pretty clear, and is written from the perspective of your Page class, although this can happen from anywhere and the code is the same:


WebMarkupContainer myLink = new WebMarkupContainer("myLink"); 1
myLink.add(new AttributeModifier(”class”, new Model(”nav2″));2
add(myLink);3


1. Create a new container with the same ID as the wicket:id value.

2. Add an attribute modifier for the ‘class’ attribute in the A tag, changing it to “nav2″ from “nav1″. There’s another AttributeModifier constructor that will create the attribute if it doesn’t exist.

3. Add the markup container to the Page class.

And that’s it.

nick Entry

As you might know, Don Brown and I have been working on the second edition of ‘Struts In Action.’ With WebWork moving in as the next version of Struts, we’ve postponed additional work on the manuscript to see what the resulting codebase will be. Instead of using the first edition of SIA as the base, we’re going to use the more recent ‘WebWork In Action’ since Struts will look more like WebWork than the-framework-formerly-known-as-Struts.

While it’ll take a few more months to get a book on the shelves, the end result will be much more relevant. We’re still very excited about producing the book. Let’s hope people are still excited about buying it.

nick Entry