Friday, October 06, 2006

The mile high stack

Since getting back into doing some Java/J2EE web development, I'm constantly struck by the sheer number of mega-frameworks that I feel I probably should know. It's overwhelming, it gives me a nervous twitch, like I could be investing lots of time in some framework that turns out to be inferior because I have no way of comprehending what else is out there.

How do Java web app developers ever get anything done?
Here's a list of frameworks and APIs that I've come across in my current project, all of which could have some relevance to my project:
  1. Java Servlet API
  2. JSP syntax
  3. JSTL
  4. JSF
  5. MyFaces/Tomahawk JSF components
  6. Oracle ADF JSF components
  7. Java Facelets
  8. Hibernate
  9. iBATIS
  10. EJB 2
  11. EJB 3
  12. JBoss SEAM
  13. Spring
  14. Struts
  15. WebWork
  16. SiteMesh
  17. Tapestry
  18. AppFuse
  19. Log4J
  20. JUnit
  21. JMock
  22. JDBC
  23. DBUnit
  24. Cactus
  25. Maven
  26. Cargo
  27. Ant
  28. Tomcat
  29. JBoss
  30. Eclipse
  31. MyEclipse
Oh ... and I need to determine which ones of these can work together, and which of my tools will tolerate which technologies. Aaaaah!

To be clear, my application is basically just forms that drive SQL queries. I don't even care so much about security. However, a goal was to try and use best-practice patterns and technologies, to ensure the application could scale up in the future.

Now, I'm pretty good developer, I know Java (the language) well and I learn quickly. But several of the pieces above would take me a week or more (each) to learn properly. Obviously some are easier than others, and many are directly competing. But how do I know what to choose? How do I know where to invest my time?

I looked for books, but it seems that many of them are out of date by the time they hit the printers. In the blogsphere, there are people who seem to be able to pick and choose between all of these. Power to them, but there is not a great consensus on what is best this week.

If there is some canonical book that covers an end-to-end process with best practices - please, I'd like to know. :)

But I started thinking about how this works in the Plone community. Im sure new users feel a bit overwhelemed, and that we could do things to make it easier for them. However, based on own experiences from when I first played with Plone, it wasn't nearly so bad:
  • Plone is there, you can touch it and feel it and play with things to see how they break.
  • Python is terse and readable.
  • Although Java kicks our ass on API docs, it's easier to follow the actual code since the .py files are all there and legible.
  • I learn best by example. Like most people, I started with a few copies of some page templates and later some Archetypes classes. That meant I could get results very quickly.
  • Plone let me worry about my application and not think about security, user management, URL dispatch etc.
Of course, I'm comparing apples to oranges here. Plone is a CMS and a platform for CMS-like systems. J2EE is much wider in scope. However, my application is not so unique - I need forms, page flow logic and database queries. Maybe one day some CRUD logic, and a few pages of text.

Obviously, this is all in the terriotory of that infamous Better Web App video, and the cliche exodus of Java coders to Ruby-on-Rails. Fair enough, but I'd like to think that it's not impossible to be productive and feel in control of a Java-based solution. This is often a question of skills (people learn Java in school), of prior investment (people have been trained in Java already), of back-end systems (that already run in Java), and of trust (for business-critical components that may feasibly need a web front-end). I refuse to believe that just because Java is strongly typed and compiled, this can't be done right. So most likely I just haven't discovered that framework yet.

However, there is another argument - Java is great for the middle tier, but less productive for the front end. Perhaps we should put more time into finding a bearable way of defining service layers that would let you build your user management and GUI in Plone or Django or Rails and let actual business processes take place in Java beans or EJBs. At least I think that separation would make a lot of decision makers more comfortable - Hibernate, EJB, Oracle (or Postgres) on the back-end, sexy GUI app on the front end that is infinitely more dispsable and lower risk, and is more likely to be what users want if it is written in a framework that encourages agile and rapid development. It may even help to ensure that the middle/back-end business objects are completely decoupled from the GUI and facilitate SOA.

Pipe dreams. Anyone got a good Java book to recommend?


Ian Bicking said...

"However, there is another argument - Java is great for the middle tier, but less productive for the front end."

It might also be that a software stack or framework that is right for the middle tier is not right for the front end. So even if you are writing both in Java, they should be fully seperated with framework designs driven by their different goals.

If they are written in different languages, then you are sure to have different frameworks. But maybe it's the framework separation and not the language separation that is really the important part.

Martin Aspeli said...

Amen, Ian... I just wish I knew how to do it without inventing my own frameworks (plural)

Jean-Marc said...

"forms that drive sql queries?"

you could check out:

Example showing you how to generate a CRUD web application from a database using JBoss Eclipse IDE

Martin Aspeli said...

Thanks for the pointer. I guess the point is, your platform of choice is JBoss SEAM, including its toolset. The further you stray from that "known good" configuration, the harder, I imagine, it will be to make the pieces fit together.

It is not all too dissimilar to our use of MyEclipse, which worked great until we needed JSF which it didn't support at that time. Ironically, SEAM looks quite good (but new, and thus more risky and less documented), though I'm feeling a bit ambivalent about JSF these days - some things that should be quite easy are just incredibly hard, and there is way too much magic going on behind the scenes. I imagine the tools and framework components all make assumptions about the view technology I'm using.

Jean-Marc said...

Indeed there are lots of different frameworks available especially for the presentation stack. However they all do MVC in more or less the same way, so they are not so different after all.

As far as using the JBoss product line is concerned, I suppose that you can compare the situation with all the Linux programs available: there are just too many of them to make a choice, at some point one needs a distribution.

The RedHat JBoss line of products is vertical from the application server to the portal, to the IDE. So I guess that this is a choice that makes sense.

mrenoch said...


mrenoch said...

This is a good one Better, Faster, Lighter Java, but it left me wondering why the authors stuck with java at all...

Seriously, I feel your pain. We have had to wrestle with the java framework jigsaw puzzle for a while now too, since that is all that Central IT supports, and we are closely tracking Sakai , and may one day want some of our tools to converge with their universe.

Absurdly, for one of our larger applications we actually protyped the thing in Plone so we could sic the UI team on the project sooner (much of the work was front end). We ended up going with spring-hibernate-velocity - To me, JSF smells as bad as EJBs, and was horribly at odds w/ the way the rest of the web (especially this newfangled 2.0 thing) works. Its statefulness was really hampering our ability to interact with it ways that the rest of the web is currently expecting.

Good Luck!


Chun said...

Well, there is a thing called, henh.. ".NET".
Seriously I feel your pain everyday. There are just too many J2EE stuff out there. We would be far better off if there is just one central JavaSoft to control everything in Java. Well, that is called monoploy. Freedom has a cost.

Clint's Blog said...

My compliments on your blog. To get it more widely noticed, grab your
free copy of
Links Explode

matt said...

"It may even help to ensure that the middle/back-end business objects are completely decoupled from the GUI and facilitate SOA."

And what you mention, of course, is the holy grail - the complete decoupling.

We perl folks have lots of web application frameworks too - Jifty, Catalyst, Maypole, CGI::App ... The list goes on, and I know that I could have spent lots of time working on figuring out how to use them. At work, we have a legacy mod_perl application framework which is so vast that decoupling our libraries to fit into another framework would be a waste of time.

My suggestion would be to build your libraries to be framework and presentation agnostic (Not that I've been able to accomplish this in its entirety ... hey, i can dream, eh?) Make your libraries pass all tests from the command line. Then, you can be free to try these frameworks without too much of an investment. You are especially in good fortune that your application does not need to do anything unique. Because of this, you may be able to bootstrap two or three that catch your eye at first glance, and choose from those.

Where is your application most likely to grow? Presentation? Reporting? Does any one framework cater to the most likely area of growth?

Oh - and if JSP is anything like PHP, I'd avoid it like the plague unless you have a templating system ready to go! :)

黃水晶 said...


黃水晶 said...


Joe said...

Hey nice blogs.. you're pages are real interesting!

Please take some time to fill out a survey for a school project of mine, I need to have atleast 50 results by wednesday! Please tell your friends and family i'd greatly appreciate it if you could help me out! Thanks!

Survey for my School project!

helen said...

I have read your blog carefully and like it a lot! We have the same opnion! Could you check my blog at: to check my blog title: helenwang`s blog"? May be we can talk further and be friends.

Anonymous said...



A片,色情,成人,做愛,情色文學,A片下載,色情遊戲,色情影片,色情聊天室,情色電影,免費視訊,免費視訊聊天,免費視訊聊天室,一葉情貼圖片區,情色,情色視訊,免費成人影片,視訊交友,視訊聊天,視訊聊天室,言情小說,愛情小說,AIO,AV片,A漫,av dvd,聊天室,自拍,情色論壇,視訊美女,AV成人網,色情A片,SEX





Anonymous said...







Sara Reid said...

This stack alone is nearly a mile high! What am I supposed to do with this mess?

vitamin c

zXc said...
This comment has been removed by the author.
zXc said...
This comment has been removed by the author.
zXc said...
This comment has been removed by the author.
zXc said...

download Coldplay Yellow

Anonymous said...

Hello Admin something you are really a great article :)
klimatyzacja i klimatyzatory w biurze, klimatyzatorfirmie, domu, klimatyzacja Warszawa, co trzeba wiedzieć. Urządzenie serii HTS stanowi klimatyzator uzupełnienie oferty HiRef CCAC Telecom (klimatyzacji precyzyjnej) stanowiąc klimatyzacja
zespół złożony z części zewnętrznej iklimatyzacja Warszawa wewnętrznej, spełniający wszystkie niezbędne wymagania dla klimatyzacji precyzyjnej pomieszczeń telekomunikacyjnych i klimatyzacji technologicznych
klimatyzacja w domu• Układ sterowania zainstalowano na karcie jednostki parowacza z zabudowanym lub przenośnym wyświetlaczem
klimatyzacja• Łatwość obsługi oraz pełny dostęp od spodu urządzenia gwarantuje możliwość szybkiej interwencji serwisowej
klimatyzacja • Sterowanie mikroprocesorowe - dostępne w różnych konfiguracjach - umożliwiaklimatyzacja zarządzanie pracą dwóch urządzeń w trybie czuwania i trybie pracy rotacyjnej.
klimatyzacja wszystko co powinieneś wiedzieć o klimatyzacji i klimatyzacja wentylacji w pigulce, jak wykonać klimatyzacja czy wentylacja wie wielu jak dobrze to klimatyzacje zrobić już mniej, szczególnie dobrą klimatyzację
Mini Shiki Sai Kan posiada większość funkcji swojego większego „brata” i jest doskonałym rozwiązaniem dla klientów z klimatyzacje ograniczonym budżetem, ale wymagających wysokiej jakości Thanks to confirm my comment will not accept lives