Peter Yared, former CTO for Sun's application server, says that "Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java," in an interview with Integration Developer News. However, his position may be biased, as he's employed by ActiveGrid, which bases solutions on LAMP, and thus is a bit of a J2EE competitor.

Mr. Yared says that ActiveGrid has the same benefits for users that Ruby on Rails does, with "developers can be 10X faster than J2EE, and that means changes and updates they need to do to their code can be done in much less than the year or 2 it can take today. And, we can make updates 10x less expensive than J2EE because integration and deployment costs are reduced."

IDN: How do devs escape from this growing complexity of J2EE and get on the road to composite apps?
Yared: At the end of the day, there is not a single high-level tool for J2EE that is useable or clean. They are all either code generators or generate proprietary metadata, There is nothing that’s clean. So, there is no high level development tool. That means you have people hand coding to these [Java] APIs, and that limits the number of people that can build these kind of new [composite] apps.

Discounting the marketing spin from the fact that this is very much a softball interview, Java and J2EE (in particular) has a huge target painted on it - being used as the comparison point for Ruby, .NET, and now LAMP. In advertising, comparisons mean that there's merit in the competitor's product, so perhaps they're complimenting J2EE more than they expect.

On the other hand, the points they often try to make have a certain validity. Do you think the deployment step in J2EE is invalid? One of Mr. Yared's statements in the interview is that "No one at the design point says they want to run on 4 8-way [CPU] servers anymore. It’s expensive, hard to build applications for, and hard to deploy." Is that the case? Speaking as an developer, I've developed applications to run scalably on single-CPU to multicore machines in J2EE with what I considered to be little or no effort; is that unusual?

(Note: this article was originally pointed out to TSS by V Cekvenich. Thank you, Vic!)

I'm not sure that it will be LAMP that wins, it's a strong contender and I have to agree that JEE is a long way from the front.

I still have faith in Java, more along the lines of Spring with MDA and Grid though.

Even the vendors like BEA are starting to see this, it's time Sun saw the light (no pun (with LAMP) intended).

-John-

I'm not sure that it will be LAMP that wins, it's a strong contender and I have to agree that JEE is a long way from the front.I still have faith in Java, more along the lines of Spring with MDA and Grid though.Even the vendors like BEA are starting to see this, it's time Sun saw the light (no pun (with LAMP) intended).-John-

Agreed. I think its time we had a marketing term that stood not for what J2EE 1.4 is today (with all the old horror stories of EJB 2.x, Entity Beans and such like) - but for the new simple lightweight approach to developing in Java while reusing those JEE services you actually want.

Strong contenders seem to be POJO or Spring? Its easy to show LAMP being more lightweight than a traditional JEE development - its much harder when comparing it to modern POJO approaches with Java IDEs and Spring.

James
LogicBlaze

Agreed. I think its time we had a marketing term that stood not for what J2EE 1.4 is today (with all the old horror stories of EJB 2.x, Entity Beans and such like) - but for the new simple lightweight approach to developing in Java while reusing those JEE services you actually want.Strong contenders seem to be POJO or Spring? Its easy to show LAMP being more lightweight than a traditional JEE development - its much harder when comparing it to modern POJO approaches with Java IDEs and Spring. James

Agreed. But we definitely need the P of LAMP in the Java Space . From my point of view there was and still is a large underadressed requirement space in J2EE, which is being adressed by Groovy and likes and which (--too? ) slowly is beeing picked up and adopted by the J2EE community (JSR 241 and Groovy as RI). There are simply things in the EE requirement space on which you do not want to spend so much time on, simply because the code life-cycle is bound to be short.

Best of both (all) worlds would bring J2EE a competative edge: engineered frameworks, pojo's, light-weight container's, and fancy scripting as glue.

Besides from the fact that Java can be made much more powerful by something like groovy, but that's altogether another story.

Forget about the EJB's... and from my not very representative opion about ORM altogether ....

We need a away to use SQL in very unobstrusive way, something which in the J2EE has'nt been adressed satisfactorly (at all) ... At least we can say that the community doesn't agree here at all...

Groovy is maybe again showing (hinting) the way? In Spring configured containers? Which populates a POJO Domain Layer? And Service Layer, which can be used however?

And then we IDE's which support the mix ;-)

Chris

Ha, ha. What a load of hogwash. I whip out J2EE apps and Web Apps in particular a lot faster than with anything in the LAMP land (including Ruby on Rails). Use the right tools and the supposed complexity is absolutely no issue at all. I switched to JSF and Sun Java Studio Creator as soon as it became availble for web apps -- creating database driven web application has never been easier. Bottom line, use the right tools and you can easily forget all this nonsense with LAMP.

So why is neither amazon nor google coded with J2EE if J2EE is a lot faster than anything in LAMP land?

So why is neither amazon nor google coded with J2EE if J2EE is a lot faster than anything in LAMP land?

Who said they aren't?

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

FYI, Google is neither coded with J2EE nor PHP. They use Python. Donno about amazon.

FYI, Google is neither coded with J2EE nor PHP. They use Python. Donno about amazon.

I responded to this earlier, but the response disappeared.

First, Google certainly does use a ton of Java, and it is involved in every search.

Amazon also uses a ton of Java.

The concept of a simple directory of Python files making up Google or Amazon is laughable. Those are big businesses that have many applications making up what appears to be a simple website. Many of those applications are built in Java.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Hi Cameron.

I may have jumped to conclusions when I read for instance:
http://webservices.sys-con.com/read/49156.htm that google and amazon run the LAMP stack. On rereading the excerpt it only states that they run "XML, open source, and grid computing" ...

Where did you find the information on google and amazon using Java?

Thanks /Dave

Where did you find the information on google and amazon using Java?

You can find some information in articles, but most of it is woefully out of date.

You can talk to the Java developers at JavaOne in the Google booth. (You may have also noticed that Google hired Josh Bloch, Cedric Beust, Bob Lee, Gregor Hohpe, ....)

Most of my knowledge on the subject comes directly from architects and Java developers that work at those companies.

And just to be clear, the fact that companies use Java doesn't imply that they don't use LAMP also.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Hi Cameron.

I may have jumped to conclusions when I read for instance: http://webservices.sys-con.com/read/49156.htm that google and amazon run the LAMP stack. On rereading the excerpt it only states that they run "XML, open source, and grid computing"

And anyone who uses Google as a prima facie "way to do things" for "the enterprise" needs to have their head examined, as the Google Application is pretty far removed from any actual enterprise I've ever worked with.

The Google model works well for Google because Googles parameters are availability and performance, with those little tasty nuts called "accuracy" and "consistency" being shoved in the back. Google does not need to be accurate, nor consistent. If it takes a week for a web page to show up in Googles search, so what. If two different servers in Googles cluster return different results to the same query as change bubbles through the system, no big deal.

As an end user you won't notice.

Apply those same metrics to a stock trading or distribution system, and you WILL be getting phone calls. Loud, angry phone calls from folks wearing pretty clothes and working in fancy offices.

Googles scope and scale means that inaccuracy and unreliablilty are not a detrimant to the entire system, and is therefor a readily scaleable application. When hardware is your primary scaling and growth metric, the individual application components performance then becomes secondary to the overall operation.

So, Google could be writing their front ends in Chipmunk BASIC for all we know, or care. Google will pick the platform(s) that balances development and performance, as a 10% slow down in performance on the front end means 10% more machines and network infrastructure to make up for it.

But Googles infrastructure, operations and design goals are quite contrary to what most conventional Enterprise systems require, and while they are a very successful large scale computer application, they are different enough that they should not be considered a benchmark to judge or model others by.

Google does not need to be accurate, nor consistent.

Sure .. for searches it can miss data etc.

For ads though, there's money attached. In fact, over 98% of their revenue is attached .. which sounds like an enterprise app to me ;-)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

These knids of statements are amusing because it's true that something, some day, will defeat Java EE by being more productive / less costly and eventually eclipse it in market share. And it's highly possible that this will be innovated by the open source community.

What's unlikely, however, is that this killer will only be an open source framework and not have a major commercial vendor throwing its weight behind it, or if it is related to a larger social trend that expands beyond the developer-tools industry, such as the rise of the Internet coincided wtih J2EE.

What's also very unlikely is that the killer will be LAMP, specifically the MySQL and "P" portions of that acronym. PHP just isn't that interesting, it's a useful tool to build web pages, but it doesn't offer tremendous advantages over what Java or .NET has. Python is more interesting, but needs a robust infrastructure behind it before it becomes a language for enterprise systems. (Plus I'm personally rooting for Ruby)

Furthermore, all of this assumes that development paradigms will be the main market determinant in the future. I'm skeptical. There's too much fragmentation to forsee a small number of leaders. And all of these pronouncements of doom and gloom assume that existing companies will stick to their current business models, when it's clear that they probably won't. If big vendors adapt to the proliferation of development paradigms, then the startups will fade pretty quickly -- their "only kid on the block" strategy is not a sustainable advantage.

And let's not forget that "market" implies "money exchanging hands", not "number of downloads / installs". There's a story if something is used widely, but it's not as big a story as something being used widely AND creating jobs, profits, etc. Sure, it's been demonstrated OSS can help suck growth out of a market, but most of those markets were very young at the time (web servers and application servers). It's unclear how long or far that will extend for things like databases (MySQL has a very long climb ahead).

I'm getting more and more tired of comparisons like that. In fact there is no significant comparison between LAMP and Java/J2EE possible, it seems that Mr. Yared not only changed his employer, he also changed his mind (I don't think his new company would like to hear/read him praising competitiors...).

For sure: un-experienced developers MAY be up to 10 times faster raising a web-app in LAMP than in doing the same thing in Java/J2EE. But people always forget about the first "E" in J2EE - "Enterprise" Edition. It's about to support really HUGE distribted systems. I dunno how often people are choosing J2EE for projects that would better be done NOT with J2EE - because they don't need the features of J2EE in their projects - but they buy the overhead J2EE brings with.

I cannot contradict: building up a small and easy web-app goes really fast using LAMP or something similar. As easy as I have been developing Windows apps with Visual Basic for some years. Oh yeah... you got quite fast, quite nice results. But beware of building a system with those "quick-and-easy" development tools that should live longer than 3 years!

As systems evolve, complexity grows. I would like to see Mr. Yared working on a LAMP software that has been evolving for 10 years... *oh my god* currently I have to maintain an application that has been written in VB6 YEARS AGO. meanwhile it's a huge application, nobody wants to change code because its unpredictable what happens after changing a single line. I can imagine that that is similar in LAMP-based systems.

To be true: Java/J2EE has it's complexities. But used at the right place for the right projects - AND WITH THE RIGHT TOOLS - I'd bet you'll be developing as fast as competitors in LAMP with the benefit of producing much more maintainable code!!!

I agree completely. Not everything is a "web app" and not everyone in the Java community or in software development cares about "web apps". Frankly, I'm tired of all the whining about J(2)EE - "Its toooo hard!, wah!". Enterprise development shouldn't be done by novices anyway. There are tools and skill sets appropriate for each of a number of software development purposes. Make sure you own skills are appropriate to the task and pick the tools that fit best. If you pick the wrong tools for the task or you lack needed skills, it does not prove J(2)EE or Spring or LAMP or whatever you tried is bad.

That being said, as someone who works in J2EE/JEE, it has been and still is unnecessarily complicated in some ways and incomplete in others. Entity beans are still a bad idea and there are many bad designs and patterns being recommended to JEE developers. Remember when some "experts" encouraged developers to make numerous fine-grained EJBs? They confused business objects with EJBs. JEE and the advice being given have much improved since then and its getting better all the time.

That being said, as someone who works in J2EE/JEE, it has been and still is unnecessarily complicated in some ways and incomplete in others. Entity beans are still a bad idea and there are many bad designs and patterns being recommended to JEE developers. Remember when some "experts" encouraged developers to make numerous fine-grained EJBs?

You can fool some of the people some of the time, but you can't fool all of the people all of the time.

If it can be proved that vendors were aware of EJB problems internaly, but conspiderd... is it racketering? That would be triple dameages, not just the uniform comercial law damages. (PHB's, please... I am not a lawyer, just pissed when software fails, I am not w/ that group; I make sofware work) Some large projects lost lots of money, due to paid "expert" advice and poorly designed software, I would love for them to get wiped w/ a wet noodle! Tarred and featherd for makeing the rest of us look bad. Adventure Builder, ok.

Now... lets all find some good designs and good advisors. JDNC/Groovy works for my large projects, C/S style.

.V
http://roomity.com as usefull example.

Some large projects lost lots of money, due to paid "expert" advice and poorly designed software,

you exactly hit the point! the projects didn't fail because of J2EE, it failed because of the usage of wrong tools and missing skills. In most cases projects are definitely not failing because of non-adequate technology, projects fail because of wrong skills, wrong tools and the wrong people!

I didn't want to say that groovy,ruby,lamp and what the heck else projects are not working. What I tried to point out is that the "overhead" a J2EE project produces by the regulations of the standard keeps the whole system more maintainable. This is what I can say from my personal experience. And using the right tools on the right places allows a skilled developer to get a grip on the complexities of J2EE.

For sure, in J2EE/JEE there are many things that we are not very happy with. But as you see J2EE is evolving permanently and the upcoming ejb3 is a step into the right direction.

So please don't blame it on EJB/J2EE - try to look honestly for the real reason why a project hits the wall!

- HANS -
http://hanzz.zapto.org

- try to look honestly for the real reason why a project hits the wall!- HANS

Does smokeing lead to cancer?


.V

Does ignorance lead to bliss?

projects fail because of wrong skills, wrong tools and the wrong people!

When there are so many wrong people with wrong skills using wrong tools isn't there something fundamentally wrong? So much effort went into making it possible to write java between jsp code, whereafter the advice is given not to do so??? We have statefull beans , better not use m. There is CMP but don't fine grain , what is this crap leave it out then. I have hope though as long as our spec makers get out of their ivory tower and don't get to democratic.

Every language/technology has its gotchas, it's not Java/J2EE exclusivity. In C you had to watch out for the use of gotos, proper code structure (high coupling/low cohesion, huge LOC functions) and many other problems. In C++ you had template hell, multiple inheritance, bad operator overloading, among others. All built in the language but not reccomended because of maintenance problems they could generate. I am sure other languages/technologies have their "dark side" powers too! So it all boils down to knowing how to use the correct tool with the proper skills on the right problem. There is no perfectly fool-proof tool out there, there will be always someone "smart" enough to mess things up, no matter how simple or complex things are. So just don't blame the gun for the murder.

Regards,
Henrique Steckelberg

J2EE is just not for an web app only. I am the architect for a complex enterprise application, where web interface happens to be only a small part of the big picture. An SOA stack happens to be the main interface for the system.

I am using light weight framework like Spring, but not as a replacement for the core J2EE stack, but more as a complement.
 
Sure tools can help our life easier. But some problems are inherently complex. Friendly tools do not make the complexity go away.

I don't see myself giving up on J2EE in near future.

Pranab

Frankly, I'm tired of all the whining about J(2)EE - "Its toooo hard!, wah!". Enterprise development shouldn't be done by novices anyway.

In my experience it's simply that the benefit/cost ratio is not high enough for what many see as JEE applications. That again depends on what a JEE application means to you: if one develops SevletContainer/TemplateEngine/POJOs applications, is it still JEE?

The answer could be yes and no, depends on whom you ask.

--
Igor Zavialov
Factoreal Financial Data and Technical Analysis solutions.

My point is that JEE really isn't hard once you know what you are doing. Its not hard relative to many of the enterprise-level challenges JEE was designed to address. It is more cumbersome than it needs to be, but its improved alot in that area over the past 5 1/2 years.

I find that the the real difficult challenges are nailing requirements, architecture and design. Most people in IT aren't very good at it from what I've seen. Programming business applications if really not very hard at all if you've done the other things right. Of course it helps if you've designed for reuse and included appropriate frameworks and wrappers so your programmers aren't each solving the same problems. It also helps if you've organized your teams so that no one has to be an expert in everything JEE. People can easily master parts of it and work together with others who have mastered other parts. Enterprise applications aren't supposed to be implemented by one or two people. Compared to what I faced doing things in earlier technologies that are similar to what I do in JEE, we've come a long way.

So many of these complaints remind me of years ago when a VB programmer argued that VB was a good 3 tier development tool because you could run it on the client and the server. If only that was all there was to it. I pretended to agree and added that it was also infinitely scalable because you could run copies on as many PCs as you could afford. ;)

As far as java is concerned I believe that still a lot of enhancement of API’s happens on daily basis. Apart from that J2ee technologies name any (jdbc,ejb, rmi,jass,etc etc ) is used by almost 75% of the Software development organizations.
Even the vendor specific or opensource Content Management and Portal Server are either on J2ee platform or are being migrated to J2ee platform so to make their product a 100% JSR168 compliant.
I think its not the right time to even think about this…

http://lokeshpant.blogspot.com

I know this is a little bit off topic, but one of the things I find interesting about the LAMP vs Java thing is the people behind it.

I know quite a few Java developers and some LAMP developers. When we talk shop with Java developers the conversations are many times about team building, modeling code, design patterns, when to abstract vs. when not to abstract, and new and interesting API's that we have worked with. Talking with the LAMP guys always seems to be more about the new and coolest hack, some app that they were able to whip out in two days, how they implemented their own version of some API that was already out there, etc. One LAMP developer I know works on a team with 20 other people, but when he talks about work, he talks as if it is every man for himself.

From my personal point of view there seems to be a big difference in the mind sets of LAMP and Java developers. Maybe it makes sense that people of different mindsets would be attracted to different langauges?

One more comment. Peterr Yared says:

"Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java,"

From what I have seen IT Manager become far more upset by the time and money it takes to maintain an application, more so then the upfront time and money to create it. I think the LAMP vs. Java conversation change drastically when you talk about it under this context.

Ok Vic, you can flame me now....

You need to do yourself a favor and check the "Worse is Better" philosophy of software development:

http://www.jwz.org/doc/worse-is-better.html

Peter Yared, former CTO for Sun's application server, says that "Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java,"

<pedant>
But, gee JEE is already an OSS technology! (e.g. JBoss, GlassFish, Geronimo, etc. etc. etc.)
</pedant>

Here's the deal.

The thing folks seem to criticize the most about JEE is deployment. The deployment step is JEEs portability mechansim.

None of the other frameworks even address this step, simply because they don't need to play in that game. They are not concerned if the code you write against their container/framework is portable to another version, because there simply isn't another version. Since they don't design to a specification (at least an external specification), there is little chance of a competing container implementing the same functionality.

And one could argue, why should there be another a compatible, yet competing version? With OSS this rarely happens.

In fact, ActiveGrids whole tenet is that portability is a non-issue because you're going to run Linux anyway, on x86 hardware. They've decided that x86 Linux Is It.

But, personally, I like the fact that we have competing containers in the JEE space. There must be a dozen of them, and the competition promotes and improves the art, from management, stability, performance as well as new features outside the of the spec that may one day get rolled in to the spec.

If JEE were simply Suns locked, internal Java ORB/Transaction server, JEE would be nothing but a blip today. But its not, rather its become an industry phenomenon, and the Whipping Boy Du Jour. The 800 lb guerilla that apparently needs to be knocked off its pedestal.

So, yea, things like RoR and "LAMP" solutions may well offer varying paradigms for development. Yea, they may be more productive up front, but you have to ask if whatever upfront productivity they promise outweighs the proven performace, stability, scalability of modern JEE servers, and outweighs the VAST Java knowledge in the industry to back up those servers and produce those apps.

It's not like JEE is static, it's not like its standing still. Going back to the popular "Java is Good Enough" argument, it's true, Java is flexible enough to adopt many paradigms of development, and many of those are the more powerful by leveraging the platform and infrastructure that JEE provides.

While JEE offers a large amount of things, you can make it as lightweight as you want. You want to write a bunch of JSPs in some Model 1 style of mixed code/view logic? Go ahead, any JEE server will happily deploy that. What if your app is a single servlet that calls JDBC directly? Should I run that on a JEE server? Sure, why not. What if your app supports 2 people, surely a JEE server is overkill for 2 people. Why? Cherry pick the pieces that you want out of the stack, just like any other system. You don't have to master the entire stack to get an application working. Idle services consume very little in terms of resources (if any).

Isn't that a "waste" of a JEE server? Running an application that uses so little of its capabilities? Nope. How many folks run a Unix box with simply Oracle on it, despite all of those other Services that Unix provides? Is that a waste of Unix? Certainly not.

Same with JEE, if and when you want those services, they are there available for your application, in a container you already know, in a system you've already deployed, against a specification you're already familiar with. No grand paradigm shift required to use more and more of the JEE stack for your application.

Sure, you can deploy an app solely on Tomcat, but why should I bother when for, perhaps, an extra MB of RAM (if that), I can get JBoss, Sun, or Geronimo? Why limit myself up front? Why not learn one of THOSE servers rather than simply Tomcat, even if to simply deploy a small WAR file?

JEE is productive, today. It is performant, today. It scales, today. It is portable, today. It is cheap, today. And it will be here tomorrow. All of your CMP 2 beans, for example, aren't going to "go away" in EJB 3, when JEE 5 comes out, your code will Still Work. The code you wrote 5 years ago will Still Work.

RoR is buzzy and cool, it's also very young. Where will it be next year? Two years? 5 years? Where will ActiveGrid be in 5 years? I dunno. I can't say where JEE will be in 5 years, but I certainly have more confidence in the longevity of JEE, in its specification, in its implementation, and in its knowledgebase.

If ActiveGrids paradigm is that earthshaking and wonderful, no doubt someone will move it on top of Java and the JEE stack in due time.

JEE is not perfect, none of these techs are, but Java and JEE combined is a flexible, powerful, performant platform.

Given the fact that Mr.Yared was CTO for Sun's Application Server and obviously had some impact and say on all the issues that he's complaining about as far as specs go, why is everyone so forgiving with his new venture.

In fact, I think ActiveGrid might be hampered given the fact that he "failed" in the J2EE space. Now he's found some new snake oil that's "much better" to sell into the marketplace.

Sarcasm aside, J2EE is in trouble because of the J2EE community. Anyone who peruses or participates in supposed industry newsgroups and forums find nothing but trash talking and pontificating. Not a whole helluva lot of constructive input.

The bottom line if JEE is to survive, IT managers are going to have to feel comfortable with allocating financial and human resources to solve a problem. Right now there seems to be utter chaos regarding JEE's direction or focus. The main push with JEE is/was economy of scale where the "Network is the Computer". It's a tough sale in these lean budgetary times. Fast, cheap and it works is the mantra nowadays even though maintenance and TCO is debatably expensive. So I will concede the ROR and LAMP stuff is appealing for some projects.

Why are we discussing scripting Vs Coding again? One is a quick hack the other is implementing a design. It depends on the IT manager what he/she wants to do. One of my managers used to say "Do it slowly, I am in a hurry".

Increasingly, you can get quick...


and clean. That's the difference today. JEE *is* in trouble. This is yet another example of leadership in the Java space seeing the light.

I don't think enterprise development, as in 2-phased commit and hardcore ORM is in trouble. It's going to be the web UI on a RDBMS...the app that 60% of all Java developers write over and over...that's going to be the first hit in the Java space.

We're in dire need of

- A higher abstraction.
- A better community process.
- A clean start.
- Fresh ideas.
- Metaprogramming.

That's why Java's visionaries are leaving.

-bt

We're in dire need of
- A higher abstraction.
- A better community process.
- A clean start.
- Fresh ideas.
- Metaprogramming.

That's why Java's visionaries are leaving. -bt

From my perspective, the Java space addresses at all of your "ideals" with maybe the exception of the phrase "clean start" which really doesn't mean anything tangible anyway.

I think J(2)EE is well and alive. Where are they leaving? Ruby on rails? .Net? LAMP? I think they are just retiring.

That's why Java's visionaries are leaving. -bt

A very broad and generalised statement, surely? We are talking about JEE here. Java is, of course, very much more than just JEE. Perhaps 'some JEE people are disenchanted' would be a more appropriate statement?

J2EE is in dire need of a higher level of abstraction.

I'd also agree with "clean start" and metaprogramming.

I posted this link over on JavaLobby in March, 2005,
and it caused a fuss, but I think it's a valid argument-


http://www.realmeme.com/Main/savingj2ee/index.jsp


What J2EE really needs a development methodology
that focuses on removing complexity from the
design & dev process. We have methodologies that focus
on response time (XP), organizational politics (Waterfall),
risk management (RUP), but none that focus
explicitly on managing complexity in the process
itself.

well, then lets go ahead and code the next enterprise-level project in Perl, and see how well we fare.
This is so ridiculous that every other line of comment would be a comeplete waste.

well, then lets go ahead and code the next enterprise-level project in Perl, and see how well we fare.

Spring home page and the Struts wiki page are writen in Python, that might give you an idea to think.

Anyway, when you are in a hole, and you have seen nothing else, you need to get out the hole and look down at it from above; then you realize that there is more.
Just consider and try write something you need in Groovy and see if you get more millage, YMMV. (We already have to write short bash or cygwin scripts... that is how you can start, and be more dynamic). The code is a lot more readable when you do heavy lifting. It's OK to have more than one lang. on your resume.

.V

http://roomity.com = RiA Community

theres nothing wron with other languages, of course, although I still doubt whether Perl should be on the list of serious contenders for the enterprise space. I used to live off of Smalltalk programming, and still have that warm fuzzy feeling when I look back. I do recognize the merits of python (although..).

I think what matters for large-scale development is to have a language with a good and complete set of object-oriented features. Beyond that, its the infrastructure that matters.

So, if you are looking for an easy-to install CMS for a community site, and dont intend to customize it on the programming level, get one of them PHP CMS's, by all means. If you need to develop, you may be well off with Python. If you need enterprise-strength infrastructure and tools, theres no match for java IMO.

Spring home page and the Struts wiki page are writen in Python

BTW, what makes you think springframework.org was written in python? I can see evidence that it runs on Drupal, which is a nice PHP CMS.

IMHO, J2EE will be just fine. It'll take the best ideas from multiple open source products (i.e. Hibernate --> EJB 3.0) and will serve as a standard way of developing Enterprise Java applications.

People will always complain about some missing features in J2EE, but at least you won't stuck with some great but proprietary product in the middle of the project.

Other people will always praise some great features of a particular Java framework, but when it comes to automating an Enterprise, I'd stick to big guys (read J2EE) adding selected open source products, where it make sense.

Best,
Yakov Fain
http://www.weekendwithexperts.com

Another competitor predicting that Java will fail.

The Sky is Falling!

"Peter Yared" may be right when he is talking about some very small applications/web apps, the scope of which will be really really small and specially you know it in advance about the boundries of your apps, but in reality it is not the same, once you start project most of the people make plans including functional domains and timespans and thought that its correct but in most of the cases thats false.

So if you are talking about Enterprise and are not sure what it will be lead to then choose "JAVA" and even not MS based apps, then you are on safe side as Java platform is there from a while now and have grown with the real time requirments, a Big example of this is "Think what ever you want to search about Java Platform" perform a simple search in Google and you will find something which is not the same with other apps.

J2EE gets used in hundreds and hundreds of circumstances where it's just way too complicated - and Java developers seem to have this mindset that overly complicated code that costs hundreds of thousands of dollars to deploy is a good idea. Yes, there are definitely some cases where it's the best tool for the job. But 95% of the time, the same goal could be accomplished with LAMP for a lot less time and money. NAME FIVE WEB APPLICATIONS THAT COULDN'T BE DONE WITH LAMP. The exception is integration with legacy systems - that you really do need Java for. People shun PHP because they see it as only for kids and as a hackish, amateur language that encourages bad code - and it's not suited to enterprise, blah blah blah. And yes, straight PHP does allow for bad code. But Java developers choose to ignore the fact that there are frameworks (Symfony, Zend Framework, CakePHP) that allow for development just as structured and stable as Struts or Spring. (I speak with functional experience in LAMP/php and having tinkered around with Struts, Struts 2, and Spring MVC. I have a decent understanding of basic Java OO structure - the same as PHP's OO system except on a couple of points.)

Thank You Güzel Sözler