Overengineering

Empty layers of abstraction that are at best unnecessary and at worst restrict you to a narrow, inefficient use of the underlying API. ― Michael Borgwardt

In the cases where we've considered things over engineered, it's always been describing software that has been designed to be so generic that it loses sight of the main task that it was initially designed to perform, and has therefore become not only hard to use, but fundamentally unintelligent. ― Darasd

It fascinates me how some people are willing to spend so much time and brainpower on the so-called "application infrastructure" they unknowingly replicate, rewrite existing frameworks--mature ones, even those they are already using; they turn a blind eye to economy of execution, development productivity, and the fact that these things often take longer than developing parts that actually fulfill the requirements.

I've recently seen many cases of over-engineering and over-tinkering.  For example my superior was recently fretting about object casting.  So basically we store our project configuration in a database table, and these configuration parameters are sometimes used as method arguments.  They also store the data type name for each parameter in the table.  And then they already do the casting during query result mapping.  And for some reason, they have a global Map of String and Object to retain the result, completely making all of that casting useless, and to use it as a method argument they have to cast it again from Object into the required type.  And he wanted to come up with generics and a layer of abstraction on top of, well, what it is I don't have the slightest clue--to "avoid object casting".  I was completely speechless.  My rationale is that object casting is unavoidable when you: 1. keep them all, of different types, as values of a single Map, 2. store them as strings in the database, and 3. use Java (in Scala you can do a type matching to avoid explicit object casting).  Although, well, now that I think about it again, this is probably not a case of over-engineering but probably leans more towards a case of uninformed engineering.

Back to JSP

Alright, so JSP is old and perhaps no longer endorsed by Oracle (there's no section on JSP in the Java EE 6 tutorial).  But it, I find, remains a sane, mature, and better-supported choice of technology for generating web content.  Many other templating engines suffer from lack of support and continued development (due to less usage), crippled integration with other technologies (i.e. frameworks), or unsatisfactory tooling.

Most of the hate-bordering rants on JSP that I see have nothing to do with the JSP technology itself.  The problems they face arise from anti-patterns: spaghetti code, lack of separation of concern, or simply outdated version of JSP spec.

What would be cool for the next JSP spec update is a way to supply partial XML directly from the controller, like that in Lift web framework.  With CDI, yeah.  Something like:

@Produces
@XmlNode
@Named("calendar")
def getCalendar:XmlNode = {
  return 
Calendar
Monday to Sunday
}

JAX-RS ftw

I never realised this before, partly because the Java EE 6 documentation doesn't make it obvious, but apparently one can use the JAX-RS to create web page controllers.  It seems to be implementation specific, however.  JBoss Resteasy, with Seam Resteasy, has built-in support for freemarker and Velocity templates as well as undocumented for JSP.  Jersey, on the other hand, afaik, only does for JSP.  It's pretty snazzy considering the features JAX-RS has and its deep integration with the Java EE stack--all those REST methods, CDI scopes, streamlined authentication and authorization, etc.
Bottom line, Java EE 6 hasn't abandoned stateless web!  Or something like that.

My Little Take on Backend Development

Update 29-10-2012:
I found this blog post more comprehensively in defense of Java EE 6.
Original post:
This comes from someone who only just recently read about JTA and JTS. Take this with a grain of salt, so to speak.

I have some experience using the Spring Framework, mainly the Spring MVC sometime about 2years ago, and some again just recently (as indicated in my previous post).  Back then, it was first a multifinancing application, second a message broadcasting engine, sort of.  Neither of which I created from the ground up.  I was merely adding features and so on.  I couldn't compare it against the Java EE 6 at that time, lack of understanding of their internals and so on.

The message broadcasting engine had to be improved so that it could support more load.  There were topics such as clustering, high availability, parallelism, concurrency, etc.  I think it was then that I came across the JMS and some asynchronous processing features provided by the EJB 3.  That was to be my gateway to Java EE 6.   Afterwards it was a haphazard series of choice to learn the actor model, CSP, Scala, Erlang, Haskell, NoSQL, etc.

So I wonder what was it again, Spring Framework's winning points.  Their documentation is among the best.  Their framework itself is rock solid, for what it is.  What it is, really, is a little confusing, though.  It appears to be sort of an alternative to the Java EE stack, but heavily relies on it.  It manages the object lifecycles.  Java EE does that as well, manage object lifecycles.  Two things manage your object lifecycles.  Obviously you can run Spring Framework on a standard servlet container, but I see everywhere that it is recommended that you use, say, the JTA provided by the container when available.  It would be unavoidable that both containers will manage the object lifecycles if you used CMT alongside Spring.  And how is it that one could share a bean across deployments in Spring?  Even if you could, I think using Spring remoting, your object lifecycles management would be more complicated because it would be a communication between two unrelated containers.  It looks to me that the EJB specification is superior in this regard, with its local and remote beans concept and tighter integration with JTA and the rest of the Java EE specification.

Anyway, honestly I'm not a big fan of dependency injection, Spring or CDI.  It's a little too much magic for me.  Language level singleton object construction available in Scala and programmatic lookup and vending are easier to work with.

Lift Web Framework is Easy

It's ubiquituously said that the Lift web framework has a steep learning curve.  Hard to believe when

<div class="lift:surround?with=default;at=content" id="real_content">
 <h1>Welcome to your project!</h1>
 <lift:Hello.world />  
</div>

object Hello extends DispatchSnippet {
 val dispatch: DispatchIt = {
  case name => render(name) _
 }
 def render(name: String)(ignore: NodeSeq): NodeSeq = Text("Hello, " + name)
}

LiftRules.snippetDispatch.append {
 case "Hello" => id.openfx.openshop.snippet.Hello
}

simply wraps the page with the template 'default.html' and makes a snippet Hello.world lookup.

Everything in Lift is easy and transparent, I daresay. Most things can be reasoned as you write code, instead of having to read its specification. I can't quite describe it precisely, but I'll give it a shot anyway. Because Scala allows "mix in" of traits, there is, CMIIW, no hidden container-managed proxy code is needed. Let's compare this with CDI used in the JSF framework. To cater to different scopes, a CDI bean can be annotated with @RequestScoped, @SessionScoped, @ConversationScoped, etc. How does it look like when constructed? Honestly I don't know. I only know how it should work thanks to the CDI spec's documentation. But I think the container would have to create a specific proxy for each bean depending on its scope, and inject its proxy dependencies and so on. The proxy might also be different when you add @Stateful to, say, a @ConversationScoped bean.

On the other hand, in Lift, it's much simpler. Snippets are normal methods registered via the LiftRules object during boot. Request and session states are just plain objects extending either RequestVar or SessionVar, used directly by snippets. The separation between controller logic and session/request data is clear here. You know what's happening to your stuff by checking out what's inside what you're extending.

Huh, OpenJPA?

Purpose of this post is primarily to help add hype around OpenJPA (there is lack of hype, from community and Apache/OpenJPA all the same).

Contrary to the plain vanilla JPA implementation vibe the project site gives off, OpenJPA might actually have its own distinctive virtue.   A popular phrase among Haskellers perhaps, "do one thing, and do it well."

Configuration might be a little daunting at first because it takes a rather different approach from such that Hibernate and EclipseLink share.  But that aside it has worked well for me (after about two-weeks use for development purposes) and perhaps most importantly for me is that its documentation is awesome.  The content feels well-thought out.  It comes in the usual online help and PDF formats.  Haven't you ever stumbled across duplicate or outdated content somewhere in EclipseLink's wiki-style 'Documentation Center'?

On that note, actually Hibernate comes with similar documentation formats as well.  The difference is that with Hibernate documentation feels more like a long tutorial (a JBoss thing perhaps?) while with OpenJPA (an Apache thing perhaps?), documentation is more formal.

Anyway one nice feature I've recently found is a native UUID generator assignable via the usual GeneratedValue annotation.  Excerpt from the documentation:

OpenJPA also offers additional generator strategies for non-numeric fields, which you can access by setting strategy to AUTO (the default), and setting the generator string to:

• uuid-string: OpenJPA will generate a 128-bit type 1 UUID unique within the network, represented as a 16-character string. For more information on UUIDs, see the IETF UUID draft specification at: http://www.ics.uci.edu/~ejw/authoring/uuid-guid/
• uuid-hex: Same as uuid-string, but represents the type 1 UUID as a 32-character hexadecimal string.
• uuid-type4-string: OpenJPA will generate a 128-bit type 4 pseudo-random UUID, represented as a 16-character string. For more information on UUIDs, see the IETF UUID draft specification at: http://www.ics.uci.edu/~ejw/authoring/uuid-guid/
• uuid-type4-hex: Same as uuid-type4-string , but represents the type 4 UUID as a 32-character hexadecimal string.

These string constants are defined in org.apache.openjpa.persistence.Generator.

So there goes my preliminary hype around OpenJPA.

Resources Publishing for WTP Maven Projects

I never realised this before but apparently these Eclipse Builders work really well to avoid collision between each other.
It was nightmare having to 'clean package jboss-as:deploy' the entire EAR again and again even when change was only on the xhtml--no recompiling!
The EAR project retains its skeleton structure even without the Maven EAR plugin (which is to be expected really, duh).  Which means you can deploy, undeploy, and redeploy part or all of the EAR into your web container via the usual Add or Remove menu.  What a pleasure!