His Last Framework

Its been a while since I visited my pyschiatrist and now, Chiropractor Dr. Pear – Perspective Readjustment Specialist. Last time, he helped me cope up an aggressive experience with pair programming. The front-desk handed me a big chunk of forms to fill up my software history.

Years of experiencing web frameworks: About 18.
First framework of pain: JSP Model 2, perhaps Applet, can’t remember.
Latest framework of pain: AngularJS
History of major pain points: EJB, WebSphere, WebLogic, Spring, Fusion Middleware, Wicket, ASP.Net Web/MVC, SharePoint, Grails, SpringBoot, Backbone, Ember, AngularJS and innumerable minor ones.
What type of pain is this? (Select one: Sharp, Shooting, Numb): All of them
Approximate location of pain: Initially Back-end. Then moved to Front-end.
Exact location of pain: Depends on Mood.
Frequency of occurrence of major pain: About every 18 months.

I physically submitted the forms and started checking my tweet feed. New tweets from dzone on Top 20 Javascript frameworks; AngularJS Jobs; Best 35 CSS Frameworks; Top 15 build tools for Javascript; AngularJS vs.., no wonder I needed a therapy.

The nurse called me in and after the initial handshake of pulses and vital stats, she said 200. I was idly looking at the magazines – PlayWeb, Maximum Frameworks… Dr. Pear entered after a knock.

Dr. Pear (browsing thru my history rather than looking at me): Oh, Hello! Its been a while from your last visit.
Me: Yes, Doctor.
Dr. Pear: And what brings you here?
Me: Well, Ive been spinning my head with the next web application framework and I haven’t been able to decide quite…
Dr. Pear: Well, the short answer is “As a consultant you should learn all of them !”, ha ha ha… (after a pause) Yeah, yeah I know. Its the viral season of frameworks. The Javascriptarix flu shot we gave last month was really a placebo. So what kind of framework you are really looking for?
Me: (a bit hesitantly) Not sure, Ive been taking the Javascript MVC Kool-aid for the last couple of years, but it looks like the pain isn’t gone…
Dr. Pear looked at me a bit condescendingly and said “MVC eh? in Javascript? Didn’t you get high enough on it in the Java/.Net world?”.
Me: Well, the Java web frameworks are kinda relegated to providing data services these days…

I had not finished. It must have triggered a raw nerve in him and he went on to a mini lecture of sorts.

“You see, web frameworks come in two general flavors – MVC and Component. Java failingly flirted with the Applet component model initially, and then took a stab at MVC via JSP Model 2, while ASP.Net took the component route after its success with Visual Basic. Interestingly, Java increasingly adapted the component framework model, but Microsoft abandoned ASP.Net Web in favor of ASP.Net MVC. Java/JVM probably tasted all kinds of frameworks in many levels – MVC (Struts, Stripes, Spring, Grails, Play) and Component oriented (Seam, Tapestry, JSF & Co, Wicket, GWT). The fundamental problem with MVC is – it sprays your logic and model everywhere. Many developers struggle to organize it between “what-they-are” vs “what-they-do”. As the complexity increases, the code gets re-organized by features, each of which in turn have the m-v-and-c. Add on top of that, the domain models and view-models are usually different, the whole thing about models start looking like a beauty pageant.”

He paused a second, probably aiming for me to get the pun.

“Component frameworks couple model and view tightly, because a view makes no sense without a model. But the biggest problem for them came from somewhere else: Javascript. Many pure java web frameworks are relatively stable, because of a stable and backward-compatible Servlet API. But component frameworks relied too much on encapsulating Javascript and HTML and in JS world, Friday’s release is outdated by next day Matinee show. Ajax, jQuery and related libraries innovated way too fast and library encapsulation really made no sense. When the JS libraries went unsupported, it dragged the Java frameworks along. With NodeJs, NPM-modules and unit-testing frameworks offering a vastly superior build ecosystem, life became miserable for frontend developers, bogged down by verbosity and slowness of JVM build tools.”

Me: Well, that’s exactly why I am here for. What is the JS framework you would really recommend?
Dr. Pear: Of course Backbone. I love backbones, especially if they aren’t straight. Get it? Ha ha !

He realized I didn’t look at him very admiringly. He continued.

Dr. Pear: Ok. Well, I hate to say it depends, because you didn’t pay me to hear that. So let me tell you something else. With JS frameworks like Backbone, Knockout and Ember becoming first class citizens, server-side slowly mellowed down to doing CRUDGE-work (Create, Read, Update, Delete, Gather and throw Exceptions), now gloriously termed as Microservices Architecture. With AngularJS offering a complete MVC stack, it doesn’t make sense to write Views in server-side anymore.”

Me: So should I still stick with AngularJS MVW ? Besides its barrage of new vocabulary redefinitions like service, factory, provider, scope, directive, the next version 2.0 promises to be completely different and backward incompatible…
Dr. Pear: Yeah, I heard that. It appears that you really need to work on your persuasion skills on convincing your team about writing in new framework every year.
Me: (I looked at him awkwardly, wondering what to say)
Dr. Pear: (Ignoring my awkward pause) Well, the web has to evolve. Why do you think Javascript is going bonkers with frameworks – they have to compete with rapidly advancing browser features, handheld and wearable devices. Who knows, Javascript could be running inside your brain tomorrow. Ok, so you are now tired of MVC in Javascript world also. What about Facebook ReactJS?
Me: ReactJS. Yes I’ve heard of it. Isn’t that a component oriented JS framework?
Dr. Pear: It sure is. You write HTML directly within Javascript or CoffeeScript or Typescript in an XML like syntax and compile them to Javascript.
Me: Im not sure I like the sound of that. Thats not even the best practice.
Dr. Pear: Well, its time to Refactor the Best Practices too. IMO, ReactJS may indeed work out well, because unlike the Java component frameworks, its closer to Javascript, it uses Virtual DOM providing fantastic rendering speeds and helps write isomorphic apps. If you get used to JSX, you will love it.
Me: What about Services?
Dr. Pear: Use one of the many flavors of Flux, Reflux, Fluxxor, Alt – the Action oriented one-way-data-flow-store.
Me: Hmm, that eerily reminds me of Struts. So, there is no really a best framework?
Dr. Pear: There is one – come up with your own. You will surely get a few fans.
Me: What if I get bored and jump ship to another framework? What about the developers who depend on my framework?

“Send them to me!” Dr. Pear said calmly, washing his hands for no reason. “If anyone thinks JS frameworks have more than 18 months of fame, they need a Perspective Readjustment”.

As I was leaving, he gave a parting shot, “Just remember one thing, if it makes you feel any better: no matter which framework, you are solving only a single problem: Delivering html to a browser. And by the way, if you haven’t selected your styling framework, I am open on Saturday afternoon”.

“Er.. Thanks, I will think about it”, I said as I flipped my phone to follow @ReactJS feed on my twitter.

As I was walking out I could see him frantically typing on the screen “Successfully readjusted for component framework. Will likely come here in the next 12 months looking for Web Component and Polymer adjustment.”

Note: Title is a tribute to AC Doyle’s His Last Bow.


Extensions via metaclass in Grails

Even after several releases and wrapper utilities, representation of time in Java seems to be an unconquerable mess that it originally was. At the same time, surprisingly, web services have been there for a long time now, still there is no magic wand to create webservices and clients.

Webservices is something Groovy/Grails should have made it ridiculously easy to work with, by default. When xml, json, http and so on have been outrageously simplified, the natural expectation is that the webservice call would be like:

WebServiceObject ws = new WebServiceSlurper().parse('http://someweathersite.com/weather.wsdl')
WeatherObject w = ws.getWeatherObject()
Temperature[] temperatures = w.findTemperature(zipcode: '11505', days: 5, unit: 'farenheit')

There are so many wrapper api-s, every webservice client generation is lacking in someway, making a new comer to Grails to try and find what works. axis, axis2, groovyws, xfire, cxf, jws, jaxb – there are so many acronyms and some of them are just wrappers over others, the choice may be overwhelming. Forums do provide lot of answers, but most times what works for one goose, does not work for even for its goose twin.

So after my friend pointed out the pot-holes of webservices in Grails, I started using the jws. All good until I hit the xs:date object in our wsdl, which translates to XMLGregorianCalendar. Like we all wanted a new class to represent date and time. I seriously hope Java/Groovy will deprecate and delete all its Date and Calendar classes and introduce just one class with a philosophical outlook:

* Dead yesterday, unborn tomorrow, why fret about them, if today be sweet?
class StarDate{
public double day;
public double increment(double unit) { day += unit }
public String toString() { return "Captain's log, stardate $day"  }

Conversion between a date in String to XMLGregorianCalendar goes like this:

SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy")
Date d = sdf.parse(dateString)
GregorianCalendar g = new GregorianCalendar()
def date = DatatypeFactory.newInstance().newXMLGregorianCalendar(g)

So much for a date? I tried to generate the client classes with a custom binding to Date instead of XMLGregorianCalendar. No matter what I tried, the value inside the webservice always ended up as long format “Sun Dec 4 …”. Fed up, I changed it back to XMLGregorianCalendar and now I saw the date as 1995-03-28T06:00:00. So where did the timezone come from and how do I avoid it? Stackoverflow had an answer:


Seriously, DatatypeConstants? Minimum integer value to specify undefined? Anyway, with that undefining of the timezone, the webservice was correctly seeing the date as just 1995-03-28. But I still dont like the fact that I had to convert this in the service class or that I had to put this in an utility class.

And all this while I was developing a Grails plugin. I wanted to make the conversion as an extension to String, so that my call is like:


Recall that Grails plugin will load the *BootStrap.groovy when it starts up. We need to inject a metaclass method into java.lang.String so Grails runtime knows about it. (Only when run standalone, not after installing within an application).

public class MyPluginBootStrap {
def init = { servletContext ->
println "booting the plugin"
new GroovyShell(this.getClass().getClassLoader()).evaluate(new File("grails-app/conf/MetaFunctions.groovy"))

And define the MetaFunctions.groovy:

String.metaClass.toXmlGregorianCalendar = {
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy")
Date d = sdf.parse(delegate)
GregorianCalendar gcal = new GregorianCalendar()
def dob = DatatypeFactory.newInstance().newXMLGregorianCalendar(gcal)
return dob

In .Net doing this may be simpler – just define StringExtensions. But they are static methods and cannot override existing methods. But in Groovy that is entirely possible, which makes a powerful feature, because if you don’t like the behaviour of a plugin class, just override it via metaclass using the above technique.

Groovy OLC #3 – Perfect numbers

At a time when new JVM based languages are mushrooming as fast as frameworks were being written a few years ago, it is interesting to reflect upon a few trends. About 6th century CE, there were already several languages in India and several grammar works were being written. But there is one work outstanding in its contribution to the world of linguistics. A linguist named Bhartruhari wrote vAkyapadIya (Book of sentences and words). Instead of grammar, he pondered on the Philosophy of Languages, where he traces formation of a sentence all the way back to the abstractness of sound. This sixth century work contains some very fine abstraction thinking, which has formed the basis of much of 20th century linguistics.

An analogy can be seen with programming languages too. The underlying “language” of ’em all is 1s and 0s, but the syntaxes and semantics vary vastly. With so many languages being created, one question to ask is the Philosophy of the Programming Language. Every language, every framework must have a philosophy, or in loose terms, the “why” behind it. Why did you select your syntax the way it is? Why did you name something this and not that? What can you solve with your language that the others cant?

The philosophy of Java is “Write once run anywhere. And screw the pointers”. The philosophy of C# is like “Something like Java, but sorry, no Js. And screw the conventions”. The philosophy of Groovy seems to be “You are a programmer, you know better. I will standby and hint functions, you do whatever you want with it. And screw the configurations”. The philosophy of TFS, the rich man’s poor version control, is like “I know everything. You programmers don’t know sh*t. Beg me to keep your source safe. And screw You”. In essence it is like “I dont like this feature in this language. So I am creating a new language without that feature”.

So on the lines of the philosophy of Groovy, in which simplicity and intuitiveness seem to be the gravest concern, there are three built-in closures, that I find extremely powerful – the find, collect and inject. If used correctly, they reduce some complex code to really trivial and make a mockery of standard loop syntaxes.

Perfect numbers are indeed a very fascinating math phenomenon. They are few and far between and whether there are infinite perfect numbers is a not yet solved mystery. I will spare writing about perfect numbers as there is an abundance of online literatue on them. Here’s a very simple Groovy OLC that finds perfect numbers upto a given number.

def find_perfect_numbers(def number) {
(2..number).findAll { x-> (1..(x/2)).findAll{ x % it == 0 }.sum() == x }

assertEquals(find_perfect_numbers(10000), [1,6,28,8128]

The internal closure finds all the factors of a give number, while the outside closure finds all those whose sum is equal to that number.

Groovy #6 – Curious case of pedantic ignorance

If you know C, its easy to pickup C++.
If you know C++, its easy to pickup Java.
If you know Java, its easy to pickup Groovy.

We have all heard this. Yeah its easy to pickup something. But how easy it is to fit into it? Despite Java being touted as oo language, programmers still write a lot of procedural-type code in it. It is easy to ‘learn’ a language, but much more not easy to assimilate the philosophy of the language or familiarize with its idiosyncracies. I’m still somewhat finding difficulty in fitting into the philosophy of C#/.Net, where the Rate of Entropy (ie the time taken for the code to get into a disorderly or unorganized state) is way lower than that of Java.

When you realize that Groovy treats configuration files as yet another Groovy script, the concept of .properties is thrown out of the window. Along with that key=value pair, the .xml configs are also given a boot. Groovy allows a more compact, more predictable, less verbose, and a much more powerful way of handling configurations.

Consider the following snippet:

Eye = {
colors = ['black', 'blue', 'brown', 'green', 'gray']

class Person {
def config = new ConfigSlurper().parse(Eye)

boolean allowedEyeColor(def color) { color in config.Eye.colors }

Person p = new Person()
assert true == p.allowedEyeColor('black')

Ok, assuming that this is all the code, what is the most glaring mistake here?

a) In Person, parsing Eye is incorrect
b) Code will not work because allowedEyeColor is not a public method
c) Assert does not fail, the programmer is cheating
d) Assert should not have failed, the groovy compiler is cheating

If you had already spotted the bug, good for you. But you get bonus points if you say that Configuration.groovy is not unit tested 🙂

Now lets add a unit test case to directly test the Eye configuration and see the value of Eye.colors:

def config = new ConfigSlurper().parse(Eye)
assert Eye.colors.size() == 5
//Result: assert fails!

The problem had me scratching my head for a few minutes, until I realized that the Orwellian theory applies to programming languages as well – All languages are equal. Some are more equal than others.

Literally more equal, yes.

The Configuration.groovy has the following line:

Eye = {
colors = ['black', 'blue', 'brown', 'green', 'gray']

Perfectly normal for the Java-tinted eyes.

But in Groovy, the above code is actually declaring a closure. In order to make it a “property”, it has to be declared like this:

Eye {
colors = ['black', 'blue', 'brown', 'green', 'gray']

Now, this is actually a config dsl, and Eye.colors can be accessed as expected.

But in the closure case, it has to be accessed like a method:

assert config.Eye().colors.size() == 5

The equals sign had creeped into the code while typing. Call it a habit, reflex or a case of pedantic ignorance.

WebLogic Tips #3 – Missing Weblogic WrapperImpl

I was running a JUnit Test on a code that accessed data from a database via a stored proceudre. The output of the stored proc is an Oracle Type object. It threw the following error:

java.lang.NoClassDefFoundError: weblogic/utils/wrapper/WrapperImpl
…. (application related methods)…

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

But the same use case worked fine within the web environment. Turns out that the missing jar was com.bea.core.utils.wrapper- Add this to your test classes or if you are using Maven – add it to pom.xml in test scope:


Groovy #4 – A list of map of lists OLC

Find key by value in a map with a list of values

One of the greatest assets of Groovy syntax is how easy it makes to manipulate lists and maps. In fact, the second most clumsy part of Java syntax and implementation are the Collections. The Calendar takes the honors. Collections are functional, but very cumbersome and laborious to implement, ie when compared to Groovy. Even if one is hesitant to learn functional programming or succumbing to the Obsessive Closure Designer syndrome, it is illustrative to know how easy it is to manipulate collections in Groovy.

def mapOfListValues = [a:[1,2], b:[3,4], c:[5,6], d:[7,8]]

So find the key to which a given number belongs to and return a default value if not found.

def findKey = { value -> (mapOfListValues.find { value in it.value }?.key)?:'Not Found' }
assert findKey(3) == 'b'
assert findKey(10) == 'Not Found'

My friend says that I should also put equivalent Java code to lighten up readers’ minds :-). So here goes …

HashMap<String, List<Integer>> mapOfListValues = new HashMap<String,List<Integer>>() {
put("a", Arrays.asList(1,2));
put("b", Arrays.asList(3,4));
put("c", Arrays.asList(5,6));
put("d", Arrays.asList(7,8));

public String findKey(...) {
blah blah, iterator, find, check if rest of world is not null,  catch exceptions and then a lot of code goes here

Yawn… you get the point..

From Java to Sharepoint

Having worked mostly on Java technologies for food and some Visual Basic/C# for fun, it was a bit of a challenge to take an exam on SharePoint. And so here are some thoughts on both of them.

Microsoft has really hit it nice on SharePoint. The ease with which one can be productive, at least with the basics, is amazing. Lets say you are starting a company with like 10-20 people and hope to grow more. What do you first need? A good Document management tool. Then you need a way of collaboration. Wiki for info, and discussion thread, a Calendar for who is doing what. Well if you can get this in a few clicks, isn’t it productive? Great!

But dive under and look at the underlying generated code by SharePoint from a developer’s perspective. It is impossible to write those .aspx files by hand. There are just too many tags and ids. What is that GUID anyway ? I never had to worry about creating a huge hexadecimal id in any of the enterprise apps I have written so far. A simple readable String id was sufficient enough most of the time.

I have wondered creating SharePoint in Java. I thought about what web framework would I really choose to achieve that. And the only answer I could come up was Wicket. Its structure would fit fantastically within SharePoint’s idea of Templates, WebParts, Pages, Sites etc in a portal (Of course, SharePoint does hell a lot more than portal). Wicket’s Panels are basically WebParts. Writing WebParts in plain Html and having a small java code (feature) supporting it would be a very clean solution. In fact, by integrating with groovy, the WebPart can be supported by a groovy script rather than a Java class.

Overall SharePoint has matured a lot from its inception. The Java-world could learn a lot from it, instead of spending energy in creating yet another web framework.