Blogs
Perhaps as a secondary title I should put: "Why is every Liferay plugin writtin in plain old JSP?".
There is a very big trend toward wanting to build portlets using some form of fancy framework. It is a seductive notion. One filled with all manner of "potential" benefits.
There is also a very dangerous side effect. One that we don't initially consider, at least not until too much time and money has been spent. The problem is the design of the java classloader.
While great for security it forces each WAR to load it's own version of classes into the VM, these are not shared between apps. We all know this, right?
In the case of portals, this becomes a little bit of a problem because you tend to want to deploy portlets as separate bundles (WARs). But imagine what happens if you installed a whole bunch of individually packaged portlets which all use heavy frameworks. This will start to consume all the available perm gen space with class meta data.
You might wonder "Why is Liferay so slow?" But I assure you, the same problems would happen with a whole bunch of regular old webapps all using heavy frameworks.
If all the Liferay plugins used Spring MVC for instance, (this is not a knock at Spring MVC, it's a great framework, I'm just using it as an example, the same issue would arrise with any JSF or other heavy framework) by the time you reached the 7th or 8th plugin you might start to notice the effect these are having on the VM's memory consumption.
If your project is planing for lots separation (as Liferay's plugins are generally designed), consider using the lightest possible framework, or using a framework that you can share globally between the plugins (as is the case with JSP, and some Liferay specific portlet bridges, and why we use plain old JSP almost exclusively).
I don't like the idea of building huge bundles, BUT in the case of heavy design frameworks you may find you have no choice but to bundle portlets into groups in order to save on memory.
So keep this in mind!

