Zato me je prilično iznenadio jučerašnji mail kojim sam obaviješten o novom komentaru, dodanom dakle pune dvije godine nakon diskusije. Obično takve komentare letimice pročitam i odmah obrišem mail, ali ovaj me je iznenadio prije svega svojom dužinom, ali i sadržajem, zbog čega ga prenosim u cijelosti i bez ikakvog komentara.
hi-
I have been working with j2ee in corp. shops in the usa (boston) since nineties. I agree wholeheartedly with the original poster.
It is possible to see j2ee corp apps that run fast, but the entire j2ee tech stack must be configured perfectly and every line of java code perfectly written. Never happens in practice, or very rarely.
Programmers that write in java are less productive because of all the framework configuration, discovery and learning curves, etc. that are needed to build the scalable applications they are tasked to create. I work on j2ee apps that scale, but badly - poor performance and low availability at high numbers of concurrent users.
RIA with applets is a no-go, and a j2ee programming team capable of RIA without applets in j2ee along the lines of the very impressive thinkfree office will not be easy to assemble. applets in general are a deadend and the incompatibilities are astounding on a WORA-billed platform.
The entire universe of j2ee accoutremont: maven, ant, hibernate, jrun, junit, jmeter, on and on… the xml configuration files, all of this adds complexity, and team members, and increases code and chances for misconfiguration and errors in deployment.
Performance of j2ee is much better in recent years, but in 2008, i still use s-l-o-w j2ee applications every single day. the author of the post is right: ten years with little to show for it.
j2ee means all to frequently: no firefox ’cause we can’t support it, no mac, no linux. so, j2ee in the corp world means windows and IE. Not very hackerish. Or cool. Or fast. And I love windows as much as the others. I’m knocking most corp j2ee app development in the us, certainly 95% of it in boston in 2008.
The j2ee web application servers, and servlet containers frequently have their own problems which delay deployments and crash sites, etc. Things like weblogic, tomcat. Sometime you work in a j2ee shop that has one piece of the j2ee chain that’s a little older and it holds things up during deployment, retards performance of the j2ee application, or causes a recurring availability issue.
Jboss and related and similar j2ee enabling and complementary technologies are developed by toolmakers and when added to all the frameworks out there (ICEfaces, millions more), before you know it you’re using tech from dozens of vendors and keeping track of the lifecycles and updates becomes unmangeable. How about five, ten years from now? Where are the j2ee apps then? Who maintains them?
j2ee programmers need to know so many j2ee technologies that they even the best ones lack experience across the entire spectrum of technologies and so they learn on the job. And that takes time, and makes projects using j2ee later. They have less time to learn about anything but j2ee, and they think (my personal observation of many of them) you don’t know anything about computers if you don’t know java. Many have no experience of anything before java.
I already said above, j2ee apps scale - mostly not that well. Again, in my personal experience.
The JRE is not great. It is the weak link in many j2ee apps. Frequently incompat. between different j2ee apps which need a diff. version.
I have never ever seen a j2ee dev team that did anything more than pay cursory lipservice to agile development methodology.
I have seen during the nineties ecommerce buildout many scaled perl and scripting language LAMP applications and sites that filled millions of orders, charged millions of dollars, served millions of pages. So I know they scaled, because I saw them. J2ee’s scalability, to my mind, is frustratingly unevident when judged against these personal recollections. Most of the j2ee applications i have worked on slow down the more people are using them, etc. This is based on my daily working life in many j2ee-only shops in boston. I work with it for a living, and j2ee has paid my bills and put food on my table. I’m just simply agreeing with the original poster’s comments.
j2ee UI’s and UI development (JSF, java server faces): ack. Swing, struts, AWT: it just never happened correctly. Every j2ee dev team i work on has poor UI. I know, I know, your experience is different. Mine has been - java, j2ee UI is usually bad. I’m working on a VUI dialog designer for work that is an applet that interfaces with a j2ee backend. The UI is good, almost very good. I mentioned thinkfree office above. But almost all j2ee apps have poor UI and interface. In ten years, j2ee UI will be one of the main complaints about j2ee in hindsight, along with bloat, complexity, gross overuse, inappropriateness for a wide variety of programming problems, perfomance. Java is still too slow too often in 2008.
Gotta go work with more j2ee tomorrow at work, so I have to go. Just kidding about java and j2ee. It’s great.
Comments(3) 
