As far as comments about out sourcing Sun''s application server, perhaps they might try contacting Geronimo, the Apache project that is getting started. That''s the one chance I see for them getting a developer following. Even then it might not happen since many of those people were from Jboss.

Hello,
Java web service stacks are a joke. Why is it still so hard to deploy a rich web service with complex types? Having to write serializers, mapping files, and WSDLs is offensive once you have used ASP.NET Web Services. This is a fact.

The technical reason is the lack of custom attributes in Java. 1.5 has got to get out ASAP and vendors must begin to replace mapping files with attributes ASAP.

The web design story is also a fiasco. I hope Rave 1.0 is at least half as good as VS.NET 1.0.

I''ve been doing .Net for a year. See my resume at http://ralkire.home.comcast.net/resume.html if you have questions about my background. Don''t get me wrong, it has some nifty features, but just as many flaws. Try using it''s Web Services to pass objects with circular references. Try adding dynamic controls to the pages, and be sure to add them in the same order on each request you re-add them (since .NET) doesn''t save them and the web controls can''t be serialized. Try invoking commands on an OCX on a web page. Note that ViewState sends everything every time even on heavily data bound pages whether you like it or not. It makes it easier to create custom controls, but NS7 and Mozilla support is weak. Most of .Net/C# technology is taken directly from JAVA, not some brainchild of MS. One touch deployment is what I call JAVA Activation Frameowork. The fact is much of the problems JAVA has had is due to Application Server vendors trying to differentiate themselves by providing unique features that are not portable. I beleive JAVA is far from finished, and should learn from the good aspects of .Net the way .Net learned from JAVA.

While integrating systems into JBoss adds value to JBoss, it does ruin the systems for those who are not interesting in using JBoss together with them.

Having just migrated off of WebLogic, and onto Sun''s AppServer7, let me tell you, I saved a *ton* of money - and got a faster app server as a result. BEA''s on the wrong side of a commoditizing market - and they''re smoking something if they don''t see Sun starting to chew up their marketplace.

The problem is that when we compare EJB/J2EE with .NET people have some entirely different visions in mind.

J2EE has its strength in EJBs and usually brings EJB to mind.

.NET has its strength in the User Interface and brings that to mind.

Sun has a technology called Java Server Faces that they have been building for two years now which will compete with .NET

EJBs are complex and unrequired for most projects. Simple Java Beans are good enough for medium sized web applications.

Hi Robert, how experienced are you in .Net to get that conclusion?

I doubt the people who say .Net is easier, faster, or better have ever used it. It takes far longer to develop a Web application that doesn''t fit within the IDE drag drop framework MS provides. And figuring out how to do something in Java is simple, not convoluted with the same problems that made the developers leave C++ in the first place. Aspect Oriented does not fit within UML well, so those developers that don''t do design should love it. Just try searching the MS docs for how to make NS7 work, or for the correct attribute modifier to use. Or use their version of reflection (trial and error) to determine what are the correct combination of flags to access a field.

People (who probably haven''t coded an Enterprise application) talk about how great .Net is, but I have used it and can''t wait to get back to Java. I could spend a week telling you what is wrong with C# and .Net.

BTW I hope all you .Net lovers out there like they way they did session state, and also how your locked into IIS. Why not save some time and have payroll deduction send a part of your paycheck directly to MS.

The biggest problem is that J2EE was marketed to every web developer as the ''industry standard'' solution. Its simple too much overhead for most sites out there. So .NET is winning on the low end, but the current J2EE solutions should not play in the low end, it just frustrates developers.

I would rather code in Java then PHP for the sake of maintainability, but would I rather edit 5 xml files, 4 .java files and a .jsp for a simple guestbook app or a single .php?

I prototyped a J2EE app in Python Webware - a servlet like system where you just create a servlet class and drop it in the filesystem. It just worked, and was never upgraded to Java.

Now I''m playing with Webwork2 and for the first time I am seeing the payoff of all of these files. A complete, well documented web application where a ''scripter'' level administrator can just setup some XML files and write a few .jsps may be able to compete with .NET, but I have not seen that yet.

My experience with Java and Microsoft tells me that I ''want'' to develop in J2EE, but .NET looks easy. PHP gets the job done with job security of mangling unmaintainable code for years, and Python is a nice compromise without much industry support.

So what are industry leaders doing to address the solo/small developers that is competent enough for Java, but happy with Python/PHP/Cold Fusion? These are the guys that love MS solutions, since that make life easier for them.

If you have no intentions of addressing this market, then make that clear. Java is presented as pervasive and the solution for everything from cell phones to demanding financial apps, and the developer is left to figure out why and how.

Are we waiting for ''project Rave'' to solve this?

Much like the way this post started out with a firm statement and then just rambled on all over the place, while hinting at a real solution or something useful the J2EE converstation starts out strong and then loses the user when they first try to understand. The myriad of framworks and technology are boggling when the user just needs to wire up an internal database to the web.

Honestly wouldn''t your time have been better spent developing rather then reading this post? With .NET there would have been no debate, no choices, just a single ''way to do it'' from a single vendor. We may feel thats bad but its a quicker road from download to Hello World.

So maybe its not J2EE vs .NET, but rather J2EE vs CRL and (insert J2EE framework here) vs. .NET

Maybe we are all trying to answer the wrong question.

I would like to elaborate a bit on what "JBoss Group brings to the table". Besides 24/7 support, J2EE certification, and partnership programs, JBoss.org is also growing beyond the app server to be a home for other prominent open source projects. The difference from Apache.org or ObjectWeb being that projects joining JBoss.org get a commercial spin.

As Linux has proven, you do not get widespread adoption of an open source project until there is commercial enterprise support behind the product. Companies just need and demand somebody to call and point fingers at when problems happen in production. JBoss Group provides the infrastructure for open source projects that join our community. Professional PR, marketing, sales, support infrastructure, accounting, and finally legal are just some of the examples of the structure that JBoss Group can provide.

JBoss.org has recently grown beyond the application server.
The widely popular Hibernate (www.hibernate.org) and JGroups (www.javagroups.com) open source projects have come under the JBoss.org umbrella with the hirings of the leaders of these projects Gavin King and Bela Ban. JBoss Group will help speed the adoption of these projects by, 1) funding development, 2) providing support/consulting, and 3) developing training courses. Gavin and Bela were attracted to joining JBoss Group because they wanted to stop working nights and weekends on their software babies and make a living out of it. JBoss Group provides the haven for this.

I think our motto "Professional Open Source" sums it up best. We can provide the industry with cheap open source solutions that cut costs and improve overall software quality, yet provide the support infrastructure that companies are used to with proprietary software.

Best regards,

Bill Burke
Chief Architect
JBoss Group

Mr Ottinger,
For user driven web applications I would agree performance is usually adequate. However, for autonomous high throughput transactions the server side has challenges. Compare the speed of BEA Tuxedo applications with BEA WebLogic applications. We are talking orders of magnitude difference. Not always so easy to justify in my experience. Don''t get me wrong, I love J2EE and Jave...just have a hard time selling it when asked...so how much hardware and memory will we need? In a price pressured industry your hardware requirements can be more important than licence cost. I would like to see vendors doing everything they can to improve performance and reduce hardware requirements.

Cheers,
Simon

David, I don''t want to impugn your feelings about EJBs, but I can''t help thinking that you''re being constrained by a misunderstanding somewhere. The technology for EJBs, for the client, is not especially complex. What''s more, I''m not sure that you''re not looking at EJBs as a magic bullet; they''re simply components, and solutions involving EJBs still involve working knowledge of how to write good components. AOP simply moves much of the work into your hands, as you''ve stated, and between you and me, I''d rather someone else write the "hard parts." (This isn''t to say that sometimes the spec is insufficient, as I said in my own responses. It certainly is insufficient, but again: thinking of EJBs as components, with component-oriented limitations and strengths, helps a lot here.) As far as your "real problem," well... I''d be interested in your server choices, since I''ve had no problems doing queries to get lists of objects rather than all the objects. Most application servers will do this "properly," as it turns out, and I''ve seen a number of people making incorrect assumptions as to how the "plumbing" of their application server works when that''s exactly what they shouldn''t bother thinking about.

Speed has never really been a problem for our Java apps on the server. The client is still too sluggish and typically takes too long to startup. Eclipse''s SWT seems faster, but it also can bog down and be very slow to swap back in after minimizing it for a few hours.

EJBs have been a big disappointment to me. The technology is too complex and too slow and doesn''t solve enough real problems with the ease you''d expect. I think AOP may indeed be a good way to think about this so that we can better tag components. In the end, we found it much easier to write the code we need than to try to make the tags work for us, especially considering the harder time debugging code that is auto-generated versus debugging your own code. The number of EJB "data" objects necessary to handle the various queries people do is a real problem (i.e. when loading objects partially, like doing queries to get lists of objects rather than all of the objects).

Also, getting databases to process only a few rows at a time (a la cursors) is just too hard to do in a portable way. JDBC''s BLOB APIs are also bogus and don''t port well.

Mr. Reavely, it could also be because on the server side, performance is very much sufficient. Even the slower servers are "fast enough" for enterprise components, and on the client side, Java''s speed has been sufficient as well. In what areas are you not seeing acceptable performance, and why? (Note my use of the word "acceptable" and not "optimal.")

Hi,

Nobody mentioned performance as an issue. Could that be because all the participants don''t want to bring this up?

Personally, I think performance is the number one issue.

Cheers,
Simon