Variance in C# Generics to Follow Scala

This paper by Burak Emir, Andrew J. Kennedy, Claudio Russo, Dachuan Yu, slated for ECOOP 2006, has proposed modeling variance in C# generics in line very much similar to what Scala does. The proposed notation is based on definition-site declarations (as in Scala) and uses +/- to model covariance / contravariance, as also in Scala.

This proposed extension will make the following declarations possible:

// Covariant parameters used as result types
interface IEnumerator<+T> { T Current { get; } }

// Covariant parameters used in covariant result types
interface IEnumerable<+T> { IEnumerator<T> GetEnumerator(); }

// Contravariant parameters used as argument types
interface IComparer<-T> { int Compare(T x, T y); }


Here is the corresponding syntax in Scala using a covariant type parameter:

class Array[+a] {
  def apply(index: int): a
  ...
}

In order to ensure type-safety through static type checking, the new extension to variance annotations in C# allows covariant parameters only in producer positions in signatures and contravariant paramaters only in consumer positions. These restrictions are, however, overcome through the use of type constraints:

class List<+T> {
  ...
  List<U> Append<U>(U other) where T : U { ... }
  List<U> Append<U>(List<U> other) where T : U { ... }
  ...
}


Quite similarly we have the same solution in Scala by using a polymorphic method with a lower type parameter bound:

class Stack[+a] {
  def push[b >: a](x: b): Stack[b]
    = new NonEmptyStack(x, this)
  ...
}


As a sidenote, it may be mentioned that Java Generics addresses the variance problem by employing wildcards and using use-site declarations (as opposed to defintion-site in C# and Scala).

Does Ruby need AOP ?

With its strong metaprogramming facilities providing interceptors, hotswapping, mixins and hooks for injecting custom codes, it seems that Ruby developers can very well do without a separate vehicle for addressing crosscutting concerns. Bruce Tate, in his book Beyond Java, has opined that for Ruby developers, AOP is not quite as urgent, because you've already got robust tools to deal with these kinds of concerns ... Another Ruby champion David Heinemeier Hansson of Rails fame, has also expressed similar opinion in the same book:

A standardized AOP framework has never really taken off in Ruby because the language itself already supports most of the desirable functionality of AOP.

MetaProgramming - A Substitute for AOP ?

Never! Metaprogramming can at most be the vehicle for implementing AOP. The most important aspect (no pun intended) of AOP is the semantics, which it enforces for the problems which are supposed to be solved by metaprogramming. AOP is NOT about inserting code snippets at various places, it is about the semantics of abstracting the crosscutting behaviors of an application. The man who brought AOP to the world (Gregor Kiczales) was himself an expert of metaprogramming before and he has the following to say on the semantics of AOP :

Another advantage of a direct semantics for AOP is that it helps with abstraction. When we look at a complex object model, it's simpler to think of it as describing the behavior of the objects, rather than describing transformations on method tables that implement the behavior of objects. The same is true of AOP—it's simpler to think in terms of aspects of an object's behavior, rather than transformations on classes, which transform method tables, which implement the behavior of objects.

So, AOP is all about semantics, abstraction and behavior of the application and is at a much higher level of implementation than the raw power of metaprogramming.

Metaprogramming in Ruby - Too Much Power ?

Metaprogramming operates at a much lower level, empowers developers with too much raw power, which may be too potent for most applications. Let us look at the following snippet from Rails code (adopted from Beyond Java book) :

base.class_eval do
    alias_method :render_without_layout, :render
    alias_method :render, :render_with_layout
end

The code snippet displays metaprogramming prowess of Rails, which implements hotswapping behavior of the base class with improved functionality. But, as discussed above, this is too low a level of abstraction. Using AOP we would have had semantics first - a neat aspect consisting of advices operating on pointcuts. No wonder, Ruby has decided to introduce AOP constructs from Ruby2.

AOP - Only for Statically Typed Languages ?

This is a myth. The real truth is that dynamically typed languages have not yet reached the sufficient level of adoption in the community to feel the need of AOP. Hence Ruby programmers are quite content at the extreme power of meta programming features to implement crosscutting concerns in their applications. Once they reach the maturity in acceptance and we start seeing millions of lines of code written in big enterprise applications, they are sure to feel the need for more abstraction power in addressing the crosscutting concerns. Because of large scale adoption, we have rich tooling support for AOP in Java - when the same happens for Ruby and other dynamic languages we will definitely see the emergence of tools which allow us to program in aspects.

TailPiece

Irrespective of what Gavin King thinks about AOP (he recently snubbed AOP as totally overhyped, failed technology), I am a big fan of aspect oriented programming - recently this technology has delivered a world of good to our team in a Java based enterprise application. But that's for another day, another post ..

Stateful Thinking with JBoss-Seam

A couple of days back I listened to the great interview of Gavin King at JavaPosse. Lots of voices have been burnt over this interview in TSS and elsewhere. In the interview Gavin talks about Hibernate, EJB3, JSF and the latest from JBoss, Seam. He lambasted stateless architectures and dismissed the thought that stateful session beans do not scale as an ancient canard in the Java community. He made some insightful comments regarding the architecture of Seam and how the stateful and contextual components of Seam manage application state for POJOs.

The main reason why the above interview of Gavin has raised so many eyebrows is that it has hit the community right on the nail and has attacked the most pervasive architecture in today's Java EE space. Rod Johnson led Spring community has successfully evangelized the stateless architecture backed by the most mature IoC container, since the dark ages of EJB 1 and EJB 2. In his landmark book, Rod mentions

Applications that don't hold server-side state are usually the most scalable. In a web application, for example, if we need to hold only minimal user state, we might be able to hold it in cookies, avoiding any need for HTTP session state replication.

Give me a break! Can u have a meaningful enterprise application without any requirement for holding server-side state ? What about the conversational applications that thrive on long running business processes necessitating application state management in multiple contexts ? I guess the Extended Persistence Context (EPC) was designed in EJB specifically for this purpose. I personally have been an admirer of the Spring technology and the simple yet powerful programming model that it has evangelized leading to a significant impact in developer's productivity. But Gavin King definitely has a point, which all of us need to ponder over - one size doesn't fit all. As I mentioned in my last blog, the developer community needs to make the proper judgement before deciding whether to eat the elephant or not.

HTTPSession or SFSB ?

This is one of the questions that has been raging the floors and blogs of all Java EE developers. The Spring community thinks SFSBs are sin - maintain state (if required), in HTTPSession and use session state replication for scalability. They suggest minimal state on the server side using fine grained session objects, which can be easily replicated across servers. But, as I mentioned above, how do we handle optimistic transactions, long sessions, conversational applications ? Gavin is justified when he FUDs Spring on this ..

Huh? You don't have SFSBs (or anything equivalent). How could you implement EPC (optimistic transaction) support without difficulty? If you could do this without difficulty, why did you not do it years ago, and save Hibernate users from years of pain with LazyInitializationException?!

Enter Seam - a grand unification of the component models of JSF and EJB3. The mission - Deprecate the stateless architecture that we have learnt to adopt so naturally. Seam adopts SFSBs as the main container of managed application state - a theory that Gavin King believes in from way back in 2004 while ruminating on the notion of "application transactions" in a hotel room in Thailand.

Why does Gavin believe that HTTPSession is NOT the place to hold application state and that doing so is NOT scalable ?

In order to answer this, let us first assume that any meaningful enterprise application needs to maintain server-side state. In a clustered environment, replicating state for transparently managing failover is expensive. Typically SFSBs-are-unscalable-school architects adopt either of the following solutions (based on Gavin's presentation on Seam at JavaOne) :

• Maintain state in the database. This is very expensive since it involves heavy I/O with the slowest layer in the tier. Inevitably they land up with a second level cache that needs to be kept transactionally consistent between the database and every node on the cluster – even more expensive!


• Maintain state in HttpSession as JavaBeans. This has 2 problems -




• The contract for HttpSession does not have dirty-checking - session replication means a bulk copy of the entire coarse grained object across servers. Though implementations like JBoss HttpSession and caching solutions like Tangosol Coherence offer attribute level buddy replication, it is definitely not the standard. Hence u need to re-set the attribute each time you change the bean state, which is extremely bug-prone and difficult to test.


• A JavaBean is not transactional - hence u need to have an indirection of the session stored JavaBean through SLSBs for implementing business logic.

OTOH, SFSBs are managed by the container, provides complete transaction semantics and JBoss SFSB, being implemented on top of JBossCache provides attribute level replication. Hence stateful session beans provide much richer semantics than the dumb JavaBeans. Cool Stuff! An application which involves long transactions needs to maintain conversational states in multiple contexts - Seam scaffolds all these state management under the hood of stateful session beans as contextual components. Hence what we get is an efficient implementation for EPC. Of course, in order to synchronize the lifecycle of the SFSBs with the session events, we need to maintain a ref/handle/proxy of the bean in the HttpSession. Even the new session scoped beans introduced in Spring 2.0 will not be able to offer an as efficient implementation, since HttpSession is not the suitable place to keep this "big" information and will have the usual problems of clusterability.

Lessons Learnt

Stateful session beans are not as black as they are painted. In fact they may be the best bet to store the application state. And Seam exploits these capabilities to the fullest and provides a very elegant framework to model conversational applications. So, keeping in line with my last post, I would like to end this musing with the belief that we, the developers should not be carried away by the current hype that open source Java has created. The developer community should always try to embrace the standards, critique the standards and make the standards better instead of trading it for an implementation.

Spring, JBoss and The Elephant

Interface 21 and BEA recently announced the release of Pitchfork, the EJB3 implementation within the Weblogic container, built using Spring. It is actually more than an implementation of EJB3 specification and provides the additional capabilities offered by Spring, viz. full use of AOP and AspectJ integration, advanced DI capabilities etc. Every EJB u build can use all Spring backed services along with JSR 250 annotations and EJB style interceptions.

This release has sparked off a war of words between the Spring and JBoss community. The trail at Raible's blog is an interesting read and provides in depth analysis and invaluable judgement to architects and developers building up their Java EE stack. At the same time it also opens up a new can of worms, enough to put the entire Java EE developer community into a bed of confusion. After struggling with the hell of deployment descriptors and the infamous programming model of EJB2, I had been enlightened with the lights of the landmark book by Rod Johnson, which instantly indoctrinated me to the Spring world of POJOs, Dependency Injection and IoC Containers. I had always felt that Spring + Hibernate make my day. But some of the recent developments in the Java open source world like the tie up of Spring with BEA/WLS has pitchforked me (no pun intended!) into a world of uncertainty. Myself, being a Java developer by heart (of course my CEO thinks otherwise and does not give me a raise for architecting a good piece of Spring bean :-(), can't help but seek replies from the elite community regarding the following questions :

Question 1

Regarding EJB 3, Bruce Tate once mentioned "Don't make me eat the elephant again". We all know, EJB is a standard and being compliant with the standard is like programming to the interface. I don't like to get locked in an implementation. EJB 3 is designed for extension - as Gavin has rightly mentioned in the same trail, we should strive to provide add-ons via extension points provided in the EJB specification and offer them portably on all application servers. JBoss is pledging to provide opensource extension to EJB3 that adds pointcuts, which would spruce up EJB 3's anemic dependency injection functionality. As of this day, JBoss offers an Embeddable EJB3 Container using which u can deploy applications in Tomcat. Next time when I offer my Java EE stack to my client, should I go for the most trusted IoC container (a.k.a. Spring) and run the risk of locking myself to a concrete implementation OR try to eat the elephant again.

Question 2

Is there anything under the hood in Spring's tie up with BEA ? With the open source community raging amock, BEA has started losing grounds, they have lost their innovation trail and has come to the hard realization that they need to have Spring in their arms to beat the time to market of their competitors. But what is the value proposition of Spring in this entire deal - are they trying to trade in their quasi-EJB3 container (quoted from Gavin King in the comments trail in Matt Raible's blog entry) with the standards based implementations used by the huge customer base of BEA and WLS.

Parting Thoughts

The deficiencies of the current EJB3 specfication and implementation have been documented in many burning blogs and articles. OTOH, all is not green in the Spring world either. Spring does not have SFSBs - hence cannot provide an efficient implementation of EPC, modeling conversations in Spring is also broken (I have not yet looked at Spring 2.0) and above all u need to deal with reams of XML for whatever u want to do. Gavin King, trying to desperately defend his stake on the EJB3 specifications, has branded AOP as an overhyped and failed technology - possibly all for the sake of pushing the JBoss camp. Believe it or not, the open source world of the Java community is on fire. They have realized that all innovation happens here but the technology needs to carry the endorsement of Sun for it to reap the commercial benefits. As Peter Thomas has rightly pointed out in his blog, the open source landscape is getting increasingly commercialized nowadays. The developer community needs to make the proper judgement before deciding whether to eat the elephant or not.