As far as the latter is concerned, I soon realized that 'pain' is an understatement. Central to the gargantuan (for those Tarantino fans - yes I rarely have the opportunity to use that word in a sentence) stack is the
Now the normal development environment is an IDE supplied by the portal vendor and is painfully slow at starting up its built in server, which means that the flow of development - well, doesn't. If you make a quick 1 line code change and then try to test it - well, go get yourself a coffee and come back later.
We have been investigating an opportunity to use Flex inside a portlet at an attempt to be able to deliver business value much faster (believe me I'm not reaching for the sky here), using Java to serve up data over HTTP courtesy of JSON.
Because deployments are not consistent, we need to restart every time we redeploy, to make sure it works first time, every time. Since the aforementioned portal takes upwards of 5 minutes to start, (on a good day, with a tail wind) we are considering using Tomcat and plain Eclipse as a local development environment. Sounds ok so far, until you consider that the portal uses an old version of Java JVM, not only that, but rather than use a standard Sun JVM, they use their own. To try to get some consistency, we downloaded the JVM, but it wouldn't install on Windows XP for some reason. We then decided to use a Sun version, which reaches end of life later this year, but no matter.
Summing up, because the stack is so heavyweight, we cannot iterate quickly, so we make a pragmatic choice to enable us to move at a bearable pace. The cost of doing this though, is an inconsistent deployment environment and inconsistent JVMs. In addition, our development and target deployment procedures also have to be completely different.