There is a JavaPosse interview with “Crazy” Bob Lee from JavaPolis that went up recently that is very interesting [audio, video]. The first big chunk of the interview is about Guice and that’s good stuff, but not what caught my ear. At about the 21:00 mark (or section 9 in the video), they start talking about a standard framework for injection annotations that could be used with a number of injection-based frameworks like Guice, EJB, JPA, Spring, etc.

Apparently Bob has been kicking around the idea of proposing such a thing as a JSR for inclusion into Java SE and Java EE. I think this would be a fantastic addition to the Java platform. Now that we’ve moved (you have moved, haven’t you?) out of the old school EJB container model and into a new world of lighter-weight annotation-based frameworks, I think we are finding (as a community) the sweet spot for annotations and dependency injection.

In this way, you could have your Spring bean and eat your EJB too, if you get my drift. It would almost be sort of a new standard for lightweight composition. I can certainly envision ways I would want to leverage this myself. Certainly I could imagine using annotations to indicate Terracotta clustering behavior on a Spring bean or an EJB. You can do that now, but I imagine it could be even more seamless (and maybe use some common annotation infrastructure) if it was part of the platform.

Unrelated to the topic of injection, Bob also talks about some of the pieces he supplied for the Google Collections API, which was pretty interesting. Bob created a ReferenceMap that lets you choose whether to use strong, weak, or soft references on either key or value and uses equals() checking instead of == checking. He gives a good overview of the differences between strong, weak, and soft references and mentions that Doug Lea is working on a new kind of map reference for Java 7 that would allow the value to have a strong reference back to the key but not prevent the whole key/value entry from being GC’ed.

He also talks a bit about where the ReferenceMap came from, which was a thing called ReferenceCache which is a cache that knows how to create an item if it’s absent. He refers to it as “supplyIfAbsent” in comparison to “putIfAbsent” in ConcurrentMap. Your options for doing this in existing Maps are to either check for existence (while holding a lock), then create and put the object if missing OR to preemptively create the object and call putIfAbsent() on ConcurrentHashMap. In the former, you are introducing a lock while creating the object and in the latter you have to pay the object creation cost regardless of whether you need it. So, having a Map implementation that could take a factory would be a nice side-step as it could avoid locking until it’s known whether the object creation is needed, then invoke the factory while causing other callers to block and wait. You can imagine an even better implementation if we had closures – just pass the block to create the object if needed rather than using a factory – just invoke if necessary.