A Bridge Too Far

Engineering | Rob Harrop | January 16, 2007 | ...

In my last entry I presented a technique for creating strategy classes that take full advantage of any generic metadata that is present in your application. At the end of that entry I showed this code snippet:

EntitlementCalculator calculator = new DividendEntitlementCalculator();
calculator.calculateEntitlement(new MergerCorporateActionEvent());

You'll remember that DividendEntitlementCalculator was defined as:

public class DividendEntitlementCalculator implements EntitlementCalculator<DividendCorporateActionEvent> {

    public void calculateEntitlement(DividendCorporateActionEvent event) {

    }
}

As such it is not correct to pass an instance of MergerCorporateActionEvent into the calculateEntitlement method of the DividendEntitlementCalculator class. However, as I mentioned in my last entry that code will compile. Why? Well, EntitlementCalculator.calculateEntitlement() is defined to accept any type that extends CorporateActionEvent so it should compile. So in this scenario what happens at runtime and how does Java enforce type safety? Well, as you might imagine running this code gives you a ClassCastException saying that you cannot cast a MergerCorporateActionEvent to DividendCoporateActionEvent. In this way, Java can enforce type safety for you application - there is no way that the MergerCorporateActionEvent can creep into a method where DividendCorporateActionEvent is expected.

The real question here is: 'Where does that ClassCastException come from?' The answer is pretty simple - the Java compiler adds the code to create and throw it as appropriate by introducing a bridge method. Bridge methods are synthetic methods that the compiler will generate and add to your classes to ensure type safety in the face of generic types.

In the case shown above EntitlementCalculator.calculateEntitlement can be called with any object that is type compatible with CorporateActionEvent. However, DividendEntitlementCalculator accepts only objects that are type compatible with DividendCorporateActionEvent, but, since you can call the DividendEntitlementCalculator via the EntitlementCalculator interface it too must accept CorporateActionEvent. So what does this translate to in the compiled class file? We have the user supplied method:

public void calculateEntitlement(DividendCorporateActionEvent event) {
    System.out.println(event);
}

Which translates to this bytecode:

public void calculateEntitlement(bigbank.DividendCorporateActionEvent);
  Code:
   Stack=2, Locals=2, Args_size=2
   0:   getstatic       #2; //Field java…

Unit Testing with Stubs and Mocks

Engineering | Dave Syer | January 15, 2007 | ...

I was on site with some clients the other day, and they asked me about unit testing and mock objects. I decided to write up some of the discussion we had as a tutorial on creating dependencies (collaborators) for unit testing. We discuss two options, stubbing and mock objects and give some simple examples that illustrate the usage, and the advantages and disadvantages of both approaches.

It is common in unit tests to mock or stub collaborators of the class under test so that the test is independent of the implementation of the collaborators. It is also a useful thing to be able to do to…

What's New and Cool in Spring 2.0?

Engineering | Ben Alex | December 17, 2006 | ...

Last month Rod Johnson presented at three Australian Spring User Group meetings a session entitled, "What's New and Cool in Spring 2.0". Rod mentioned during those meetings that I'd make his presentation available, so here it is.

There are some other recent presentations that people have also been emailing me about. In no particular order, here is the latest:

For those of you who attended the presentations, I hope you enjoyed them.

Why the name Interface21?

Engineering | Rod Johnson | December 16, 2006 | ...

A few weeks ago I blogged about the origins of the name Spring. We also get many questions about the origins of the name Interface21.

For anyone who's read my books or considered the design of Spring, the interface part is hardly a surprise. It plays on both the OO concept of an interface (for which I've always had a deep love) and the notion of the interface to a system. For example, putting a web interface onto an existing green screen system--something I was actually doing when I first thought of the company name.

So far, so good. The real problem is with the numbers.

As with the name Spring, some of the theories are more interesting than the real explanation. So let's start with the theories I've heard regarding the 21

What happened to getConfigLocations()?

Engineering | Ben Hale | December 08, 2006 | ...

I was on site at a customer last week and a question came from the crowd, "Why isn't getConfigLocations() abstract anymore?" After working in front of customers for a while, it becomes rare that you're speechless, and yet I was. To be honest, my first thought was that there was no way the customer could be right. But lo and behold, in revision 1.3 of AbstractSingleSpringContextTests it clearly states that getConfigLocations() is no longer abstract. I hadn't created any new integration tests against 2.0.1, so I hadn't even seen the change.

Surprised by this, I put in an email to Juergen to…

What you have to look forward to at The Spring Experience 2006...

Engineering | Keith Donald | November 30, 2006 | ...

These shots of our venue were taken yesterday (proximity to places like this is one of the perks of Interface21 having an office in Florida).

 
The Majestic Westin Diplomat
Complete with an infinity pool
A lazy river underneath
On beautiful beach-front property

We are incorporating several of these shots into the main conference banners to be draped from the towering ceilings of the Diplomat. Everything is set for a great show. See you at The Spring Experience next week!

SimpleJdbcTemplate: Spring 2.0 and Java 5

Engineering | Ben Hale | November 28, 2006 | ...

In the run up to The Spring Experience I've been busy but I've noticed that Rod's been really active on the blogging front. So in some spare time in airports and on planes today, I've decided to do a little blogging.

One of the biggest balancing acts that we in the Spring community have is to make sure that we stay backwards compatible while still innovating. Part of that innovation is taking advantage of new features and constructs in later versions of Java such as Java 5. Since the 1.2.x branch, we've seen some of this with things like the @Transactional annotation and our JMX auto-detection based on the @ManagedResource annotation. In the end these are great features and have greatly simplified development (at least mine anyway), but they really amount to moving metadata into the code. What we hadn't seen was…

A Java configuration option for Spring

Engineering | Rod Johnson | November 28, 2006 | ...

Thanks to our philosophy of pluggability and a lot of hard work in the implementation, the Spring IoC container (like most of the rest of Spring) is extremely flexible.

One point that is often missed is that Spring configuration need not be in XML, although the XML format is by far the most commonly used. Spring has its own internal metadata format in the form of the BeanDefinition interface and subinterfaces. The BeanFactory and ApplicationContext implementations that represent IoC container instances are powered by this Java metadata, and are quite separate from metadata parsing, which is…

XML Syntax Sugar in Spring 2.0

Engineering | Rod Johnson | November 26, 2006 | ...

If you've followed October's Spring 2.0 release, you will know that one of the big new features was XML extension name spaces: the ability to define new XML elements and attributes that generate Spring metadata, and can be used alongside regular bean definitions. This provides a valuable new extension point and makes Spring configuration both more simpler to use for many repeated tasks and more powerful.

However, there is also a sweet little piece of syntax sugar that you may not have noticed--probably because no one in the Spring team has gotten around to telling you... Having promised myself…

Spring Framework: The Origins of a Project and a Name

Engineering | Rod Johnson | November 09, 2006 | ...

I am regularly asked about the origin of the name “Spring.”

The name goes back to late 2002. In November 2002, I published Expert One-on-One J2EE Design and Development. The book was accompanied by 30,000 lines of framework code, which had accounted for a good deal of the year full-time I put into writing the book. (Writing a 750 page book is enough work on its own; writing a substantial framework to go along with it is sheer masochism. It was hard.) Many of the fundamental concepts of the Spring Framework were there: an already capable IoC container, with BeanFactory and ApplicationContext…

Get the Spring newsletter

Stay connected with the Spring newsletter

Subscribe

Get ahead

VMware offers training and certification to turbo-charge your progress.

Learn more

Get support

Tanzu Spring offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.

Learn more

Upcoming events

Check out all the upcoming events in the Spring community.

View all