Feeling fickle: Let’s use POJO, JSF, Swing, Spring, and of course, some good old J2EE


Suddenly there are a million ways to do things – JSF, POJO, Spring, Swing, Struts, Tapestry, Ruby on Rails, and on and on. Many of them do not stand alone and as such require overlap and lots of manual coding (although that’s half the fun) in order to get these variants to resemble a final application. This is especially true if we want that resemblance to emerge in the form of some type of UI. So off we go digging around the internet to find where one stops and another starts, where the overlap is, why is one better than the other. Be careful which book you read, which vendor site you end up on or which serverside discussion you end up in. Pick a side, pick a flavour, get a plan. Well, not today.

I still love my enterprise Java – good old J2EE. Not that I am so old fashioned, that I can’t change. But the reality is, we know the patterns. We have improved them. We have bloated them beyond recognition in some cases (oops!) maybe because of the community process but that is starting to turn around. And the good news – my boss understands the model and he knows he can move me on and replace me with someone else and they can pick up where I left off. Wait, is that a good thing? Aah, now I am starting to understand why we do the things we do.

Let’s tackle some of the technologies and in the spirit of having some good fun at my expense, I’m going to pick some sides based on how I’m feeling today and see where the conversation goes.

JSF reminds me of a loose cannon API or according to some developers “JSF is just not as refined as Tapestry.” Yes, it allows developers to use every other technology into the framework, in fact it actually forces developers to pull pull in other frameworks in order to make it suitable for consumption. But will we actually see software vendors reach out and embrace Tapestry just because it works, or does this leave no room for them to sell a “product” and therefore we won’t support it (I will get to this point in a later entry). JSF on the other hand is a completely different market animal; people need to be retrained, you probably should buy some tools, etc so that brings on the vendor support.

JSF-Spring provides the glue code for some comprehensive integration of JSF and Spring (thus the obvious name), but unfortunately this has been done in an implementation independent way which means you cant actually use it with JSF. Back to Tapestry for minute – you have to marvel at all that power with no invasiveness. But on we go in JSF, with relational databases and some other lagging techs dragged into the mix for good measure. Wait, I want to be implementation independent – what a luxury.

That makes it kind of like POJO – people don’t and won’t sometimes because it doesnt have a fancy name and a vendor stack and it’s maybe just too darn easy. When we were at JavaOne this year there was a lot of questions at the Adobe booth about running outside of the EJB container, moving off the app server, etc…but it was just that – discussion and questions. Are you using these emerging technologies? How are you using them? More importantly to me, what do you want vendors to do?

And as long as you can get to our APIs when you need them – do we really have to do to declare total support for this? It’s becoming so complex that I suspect I will need a small army of engineers to get through the responses to this blog.

For the record, how I really feel – it’s all good, it’s all Java, and that’s all good enough for me. I’m going to see who is available to help me get my next job done and I intend to absolutely base my decision on whatever they are really good at. Hopefully, it’s PDF-L at the end of the day (I like things in Reader instead of a browser), rendered through XFA (abstract away) and sitting on top of some Adobe LiveCycle APIs (whew, some good old J2EE) – but who knows, maybe they can sway me today. I’m feeling a little fickle. Maybe Flash…? At least it’s easy, and wow, is it ever beautiful when I’m done. I know my marketing counterparts will support me if it’s beautiful, even if my vendor of choice doesn’t – yet(smile). This is too hard…

3 Responses to Feeling fickle: Let’s use POJO, JSF, Swing, Spring, and of course, some good old J2EE

  1. Darren Melanson says:

    You’re not along in this endless battle of technology trends Ben… I consider myself “old school” as well when it comes to J2EE and seeing -frameworks- replace my ideal code solution is sorta like the auto worker from 1975 seeing that 8000lb robot being rolled into the plant for the first time. :)-

  2. Ben Watson says:

    Perhaps I can find a partner here in Japan that could build me a friendly little robot named Pojo. Pojo would attend design and architecture meetings and log into various interfaces, generating code automatically whenever he felt there was 51% or greater consensus on themes. That way the developers and architects could stay in the meetings all day instead of having to go back to their desk and code. Pojo, the friendly coder robot, could be trained to automatically use standards, and always adopt the latest frameworks, thus avoiding costly retraining of us 1975 auto workers.

  3. cameron baker says:

    it’s the first time i ran through your site and i found it very informative and interesting. nicely done!