It''s been a while since this article was posted but I''ll add a comment anyway: One of the commenters above said that the value of all these specs is that they let you build your business app on top of existing tools rather than having to start from scratch. Good in principle, but it seems to me that most of these tools are more difficult to use than just doing things from scratch. For example: I just spent a week or so learning EJB. I got far enough that I was able to write a trivial little "hello, world" app with it. And I''m left wondering: What''s it good for? Sure, I can put business logic in an Enterprise Java Bean to separate it from the presentation in a JSP page. But I could do that with an ordinary bean. I could do that just by dropping a stand-alone class on my server and calling it from the JSP. I''ve written apps using those techniques and they work just fine. All I gain by using the EJB is that now I have to write home and remote and maybe a local interface on top of the bean class itself, then I have to set up the JNDI connections, and then I have to create an XML configuration file to describe it all. So I get to create 4 to 6 files instead of 1. I''ve written client-server apps using socket programming, and fat-client apps using http to send data to and from the server. These techniques seemed a whole lot easier than EJB. Ditto on SOAP -- maybe if I had a really complex data structure that would be handy, but I found it a whole lot easier to just wrap my data as comma-separated-values in an HMTL page. I''m coming to the conclusion that most of these new tools and specs are just not worth the trouble. Java is way cool. JSP is way cool. JDBC is pretty good. JavaMail is somewhat easier than hand-coding the protocol. The rest I''m still searching for a use for.

There is a visual IDE already available for Java - inteRAD's build-IT. The existing WYSIWYG features drag and drop Swing interface construction. In the upcoming version 4, inteRAD will deliver direct JSP deployment from the existing WYSIWYG.

Ever heard of "if you can't stand the heat, get out of the kitchen"?

I don't see it: too complex? How? They are just APIs and knowing that you can count on them to be there is fantastic. (I am still pissed off every time I download an RPM for my Linux box and there are 25 dependencies that I have to go off and find...) There may be a little bit of a learning curve, but that only makes sense. Java is pretty powerful as a server language, without the pitfalls of C or C++. I mean, I'd always choose Java on the server over C, C++: talking about complexity, and the effort making sure you allocated memory correctly, didn't leave buffer overflow vulnerabilities, etc. etc.

So Java is not VB or PB. What a surprise. It's for a different public of developers. You don't give a kid a powersaw...

If it is too complex for you, maybe you should look for a different language to develop in. Server applications ARE relatively complex.

20% of developers write 80% of code...

Daniel,

I couldn't agree more with your comments. It has become very apparent that recent JDJ editorials seem wholly geared toward negative coverage and a general denunciation of Java technology.

It is sad to see this happen, and it does make one wonder whether the 'Java Developer's Journal' should now be more aptly named the 'Java Denouncer's Journal', or the 'Java Doom Journal'?

However, I shouldn't be too concerned, it's only sensationalist journalism used to provoke maximum reaction and comment within forums (and hey, it seems to have worked!). The JDJ people who write this stuff need to constantly find something new to comment on in order to keep JDJ 'buzzing'. It's a hard act to keep up, especially with a solid, mature technology...

OK I've changed my mind, maybe 'National Java Enquirer' would be a better title after all... ;)

I think one of the problems is that a lot of us has a neurotic ambition about knowing every aspect of Java tehnology...not only for a common use but also to pass all Certification exams.
There is no impossibles things, but i don't belive that you can give someone an editor and he will be cappable of develop instantly an application, no matter if he needs to use an Swings's HTMLEditorKit, RMI, EJB, JDOM, Java WebStart or the Struts framework from Jakarta.technology. You can read and be an expert in all those aspects if you had time...but then you will not have time to use (and enjoy!) in real work cases.

The outward "complexity" of the set of available Java solutions is nothing but the inevitable consequence of the richness of this set.

In the old days (80s and early 90s), things were "simple". That is to say, you built on platforms with bare-bones capabilities. If you wanted to do anything interesting, you had to spend person-years of effort inventing, building, and iterating (because you never get it right the first time).

Today you have to spend a couple of days doing research on the web and reading specs before you can build on top of a powerful piece of software that you can download (usually for free). This represents a VAST amount of progress for the industry.

Combined with the stardardization of interfaces via the JCP (sorry, another acronym), which makes it easy to port to different vendors, and leverages expertise from the entire tech industry, this represents the single largest contribution of Sun/Java to the software world.

Personally I dont think J2EE is really that complex. You dont have to read all of the specs to start writing code in it. But I like to make it appear as a complex spec. Its after all for the benefit of the developers to side with complexity rather than with simple things. Developing should never ever be made easy or else the marketing guys will take over and start coding. I remember how I was interviewed once in Visual Basic by a marketing guy...

Developing web applications in Java doesn't have to be difficult. Why waste time hacking together a complex mix of Servlets, JSPs, HTML templates and SQL calls when there is clearly a better way? A way that is not only easier, but produces much higher quality web apps to boot. The right application framework can take the complexity out of developing web apps - while simultaneously yielding far superior results.

The Covont Advanced Application Platform is the most advanced web application framework available for Java application servers. If you're developing enterprise-class web applications in Java, the Covont platform can significantly reduce development complexity while producing higher quality results. It will forever change how you view web application development. Learn more at http://www.covont.com

As far as the article goes, I do agree with Weiss that Java & J2EE is complex and it certainly raises the bar on developers joining the band wagon. While we may bask in the fact good J2EE developers are still hard to come by and our skills are valuable, if another vendor comes out with a simpler, more effective mechanism for server side development(as .NET is trying to do, I think), we are screwed!

A lot of people seems to dissing Entity beans on this column. I, for one, must admit that EJB2.0 CMP is a much better step forward. We recently developed a project that uses entity beans to a large extent and we have not had any problems with it. As long as you utilise you container's caching mechanisms for beans that are read only and stick to good design patterns, EJB's can work very well for you. Having said that, I would stay away from BMP entity beans and only use it if a DAO or other Java object will not suffice and you need transactional backing etc in the context of what you are attempting to achieve.

Bottom line - building robust, flexible applications is difficult. Java seems overly complex because it has attempted to address many issues and situations and provide powerful solutions. If you want or need something easy there is always VB or PB - but then you have to live with their limitations. Developers are going to have to devote additional time in coming up to speed when they find a need to move into new areas they have not yet encountered - there will never be any way of escapting that. Invest in some books and stop reading the specs. I've learned a lot in the 5 years I've worked with Java - and as a former MCSD I would never give it up and return to VB land.

I also agree with the author but he's mistaken in attacking the specs from a developers perspective of Java. I've been developing with Java for 4 years and have never had to read a single spec to learn the technology (including EJB). I learned JSP in a day with a getting started tutorial on java.sun.com. Keeping business code out of display was actually mentioned in the discussion of java beans with JSP. Do you get that kind of best practice from the spec? Armed with a one day ramp up I was able to use JSP in a project at my company. Additionally, I'm not the only one at my organization who has had this experience. The specs are speaking to vendors who write things like a servlet or ejb conatiner. Not the developers who use these technologies. The only spec I've read is J2EE deployment and only then to identify bugs in a vendor product, not to learn how to build an ear, war or jar file.

I agree that Java's being seriously hurt by complexity. I have "learned" Java three times so far, and every time my spec-oriented work takes me away from it, I need to restart practically from scratch. By contrast, I can work with SQL or VB in a heartbeat. I have 20 years' experience that also includes a few years' each of Fortran, Ada, PowerBuilder, and C.

The Java spec is remarkable but why is it so difficult to learn and retain? I think someone needs to study how developers master Java and write code in it. I have some suspects as to why it's as hard as it is:

* Classloader -- who really knows or sees what versions of what classes are being loaded? Is it right to allow one zip/jar to add to classes in another jar's packages? And how do you recover when the class that your textbook and all your co-workers are discussing is not in your classpath, and none of the 250 jars on your machine look like they have it?

* Interpreter -- It's theoretically possible to run Java interpretively in many cases, but who does? If we don't, I would submit that it is because the language implementation and the supporting libraries are not robust enough to work that way. It's not the JVM, the JVM can do anything. If anyone wrote an IDE in which Java could really be run interpretively, we'd have the beginning of a usable language environment

* Exceptions used to hide problems. The exception facility in Java is not an excuse for sloppy error handling. I believe that a lot of Java programmers use the neat, powerful exception facility to bail out on really solving problems they can anticipate. If there's one thing the solid Microsoft IDEs and language implementations do, it is to catch and recover errors or rework the environment to help the programmer deal with them effectively.

* Meaningless package structure. There are essentially no semantics to a Java package. (Location in a particular directory is pretty weak). There's a lack of class-closure accessibility, compounded by tools which "helpfully" hide what's going on. Right now the only semantics to a "package" is with regard to protected access. We jar up our classes, but are those jars complete? We use IDEs and Ant and then we're mystified about what actually is in the JARs.

I see Java as a general purpose language. As an OO language it benefits from the inheritance mechanism allowing smooth extension into many problem domains. In that sense it is rather like English, which can be used to describe simple or complex problems over many different areas.
The challenge for Java is to find a way to incorporate these extensions without overloading the language with superfluous detail. Essentially, as with English, it needs to develop some problem-oriented covers under which the commom Java language is used to express the solution.
Problem oriented dialects, with Java glue may be the way, hidden behind a problem-oriented IDE. Java then would effectively become an IL, and about time too.
The noise and complexity of Java right now results from marketing pressures to get public and the thrashing around is aimed at making Java all things to all men, and en route, to cancel out .NET, which is not going to happen.
Summary for me: Java is a nice language, but too noisy. Will be better when it grows up.

I see it all like this:

If JAVA solves problem or it is what you need --- learn/use JAVA else use .NET VB PB PHP ASP etc.

I use JAVA because I like it,and solves problems i need to solve.

Servlets/JDBC/JSP Java XML API's it's all I need.
So if don't like JAVA don't use it period.

If you don't read spec, it only means you're not working on that area. Whether to read spec depends on what task assigned to you - if developing a ejb container, i don't think you can do it without read the spec. read the full spec if you're working on that part! For example, I've read COM specification, CORBA specification together with programmer's guide after I was assigned those tasks. (more specs for other tasks such as RFCs, M and X series). The more you know, the better your code. So the author may be partially right, you do need to know what specs are there and so when needed you know what's needed to read and where to find it.

The one and only think wrong with the whole J2EE mash is that it doesn't address the end-goal of delivering useful applications into the mitts of real users in a direct manner.
Well, that and the introduction of EJBs was misdirected in that they should have been simpler local objects. But I digress.
Twenty years ago one could make a nice living putting apps together with a 4GL. I worked for the original 4GL vendor and did just that. Same with the VB / PowerBuilder era. Same thing: builds apps fast. Same problems: it was really difficult, or impossible, to tear them away from their initial limitations and turn them into something really, really good. Their underlying technology either couldn't do what needed to be done, or you couldn't get at it in an effective way.
Java, J2EE in particular, is at the other end of the spectrum. It can build pretty much any type of app any modern technology platform can build, but up 'till now pretty much everything has beem hand-built. And let's face it, the old canard about OO leading to reuse is balderdash, it ddoesn't happen. In fact, the primary benefit of OO is that is makes it easier to to the right things when building systems.
So, there's a complexity conundrum at play: the ability is there, buried in the details.
I'm hopeful that the frameworks will evolve to the point where constructing apps will become more straightforward, with less attention to the guts required in order to define and cobble the app together, while at the same time producing the Java code that premits one to delve in and do whatever's necessary to customize it in whatever direction is necessary.
I presonally really like Struts for lots of reasons, principally my feeling that it's a well0organized framework that can be the "bed" upon which apps can be built, abstracting the web-app technical issues away until one needs to get at them. I like the earlier post about how .NET could put together something quickly, but then it was hard to deal with while Java took longer initially, but then was easier to manipulate.
So when the higher-level tools and techniques get going, I for one will be happy to have Java - J2EE included, under my apps.
Until then, then.

Complexity is a natural property of any evolutionary process. Java platform has been evolving for years, so the complexity that we are seeing right now makes sense.

Java has been evolving quickly because of the increasing technological demands. Fast growth in software typically means degrading quality. Also, since Sun has made a commitment of perpetual backwards compatibility, they cannot 'Refactor' the Java core properly and always have to come up with workarounds.

People say that J2EE is overwhelming, but how can it not be?! It is covering so many different aspects of technology. Expecting J2EE to be simple is like expecting businesses or life itself to be simple.

But what I think may be happening is that as Java grows, the clarity fades away, its quality degrades. Not all API and specs where done by the original team. Not everything fits together in a nice way. To keep things simple you need to keep them clean. But in our world that

Some developers choose to make applications more complex than they need to be, for the sake of being able to put buzzwords on their resume.

I've seen a single-user application written with EJB and JSP when it could have been a simple desktop Java application or at most a few simple servlets. I've also seen gross overuse of XML. Some developers just want to put buzzwords and acronyms on their resume, instead of focusing on the few that are actually required for the problem at hand.

If Java did not provide so many services and APIs, when we actually need them we'd have to write our own or use a proprietary vendor's libraries. The existence of so many APIs only increases complexity when developers choose to use as many of them as possible just because they are there, instead of ignoring the ones they don't need.

I think Weiss is partly correct, and partly way out!
A specification is a specification, nothing more or less. The implementers must understand the whole spec, and have a good overview of J2EE.
The regular developers, mostly need to know how to use the implementations. There is no need for them to understand all of J2EE. Why bother with JCA when developing JSP pages?
For projects of some size it's totally unacceptable to require all developers to know every detail of the technology they are using. This is the architects role. This has is true for all technologies (but perhaps not mainframes).
The typical roles of a J2EE project is descibed in books and on Suns web pages!

I think Sun and the JCP should consider a developers path to the specs, and just point to the real spec when necessary for further reading.

There isn't really anything wrong with having a large specification, not with Java and all its varied APIs. They are necessary for all of the problems that they try to solve. The real problem is that most of the APIs are simply over-engineered. I most recently noticed this with Sun's implementation of web services. While every piece of Sun's strategy is necessary - the implementation is far far more complicated than it needs to be. WHile I spent a week going through Sun's implementation and generally terrible documentation (a classic problem with many Sun APIs), I actually implemented several webservices using GLUE. Therein is Sun's problem more so than any specification such as J2EE. While all of the architectures they're trying to engineer are quite capable of scalable distributed computing - they generally lack simplicity and hence generation such negative feelings towards J2EE as a whole. While I certainly wouldn't go off the deep end and recommend .NET as a solution - Microsoft has a far more coherent strategy and implementation. Fortunately - so does GLUE (and for the most part Apache's AXIS).

Well Java is sure not for dummies and I dont think we want VB kinda single thread app here with memory leaks playing with us. If you think Specs and API are too complex for you get out of IT and get another Job. I dont feel sorry for people who has no graps for objects thinks VB scripting is so great, then just stay there of look for some thing else. Java fills the the Gap where C++ left off and dont tell you understand .Not even Billy doesnt know what the hell it is.

In contrast to this article, I think the main thing to understand is that no one person can or should be an expert on everything. Obviously, there are too many new technologies out there to keep track of. This just helps emphasize the idea that lone-wolf programming for the most part is dead and "a little help from your friends" is a good thing.

I can not understand how the so called Java developer Journal can publish this unfounded, fickle article. Worst, it is very alarming to see that lately Editorials and in-the-news have a reactive / negative perspective. I wonder if JDJ is willing to promote Java or... JDJ has problems in selecting columnists.

If you want to build a (business) solution you will either reuse an existing one or develop it yourselves or both. But once the "reused solution" had to be developed, too. Thus basically every solution is backed up by development. This is pritty evident, isn't it?

What's next? The original problem itself is a business one meanwhile the solution is a programmatic one. Thus the first thing you would do when developing a solution for a new problem is to modell the problem that is to say express the problem in a formal way that could be solved in a formal (programmatic) way.

Summ it up: in my point of view this is the reason behind the problem discussed by the article. Java/OOP (or UML) is farly ideal for modelling real life or business issues. Put it simply: real life or business is neither an object nor a collection of objects nor an object network, or is it?:) Maybe in the future there will be a strong methodology to fill in the gap between OOP/Java and real life. Maybe the gap is to wide.

Last question: who is responsible for filling in the gap?

As a contract developer for popular J2EE platforms, we never had issues understanding the APIs themselves. Significantly more of our time has been spent setting up and testing individual J2EE platforms.

Having J2EE compliant code ready to test wasn't near as difficult as filling out JavaBean parameters in web-based server configuration interfaces (or worse). Spending two days deploying what should be a simple application is simply laughable.

I'm glad it provides jobs and long projects for so many developers that have been out of work. That's the real point of all this right? Creating an industry that keeps programmers getting paid. If we get too much lazier, we should consider starting a union.

If you are simply trying to setup a java web server that runs simple web services (or god forbid web pages), check out the Comet Way Agent Kernel

It's based completely in Java and you can get it up and running in less than 5 mins. You'll wonder why it takes other products so long just to startup.

Java is simple, J2EE is not. However, like enter. applications are layered, the resource for developing the apps. are layered too. For majority of the programmer/developer, they do not need to know/read the specs. Like normal computer users do not need to know/understand how the computer works, do not even mention to them how CPU, BUS, memory, OS,etc., are coordinating to do the work. Even enter. architects do not need to understand the sepc for designing their system. There are so many good books talking about a specific subject of J2EE, why you bother to read the specs. They are not for developers. If you ask your developer to start a project by reading specs, you really need to give up your position as a manager/architect. Why there are so many specs, ask why there are so many technical articles/books for detailing how a computer works.

Always in a team, some do partial of the whole project, just ask them to focus on their part of the techs needed. I do not think mastering JSP or Servlets, or JDBC, or evne EJB takes long time to get started. Of course, your team should have a highly paid Guru who should understand most of the parts the project are needed. For a small project, download a Tomcat, and you are on the way for one week.

If you do not need it, do not touch it.

I don't think the problem is understanding the spec. The author of the article has worked with Sybase to write their application server.

The problem is that the spec IS too complex. I do understand and embrase OOAD, design patterns etc. But the myriad of detailed specifications to do the simplest thing can be daunting.

The "mentoring" process in J2EE development should be looked at, also. In implementing a new technology, it requires a long time to learn it well enough to be completely effective. The devil is in the details; and the details are what really bites a developer in a new technology.

They used to say that C++ is a language a developer should "ease into" ( a quote from the inventor of the language). J2EE is also something that a developer should ease into.

But a development shop always seems to run on Crisis Management rather than real planning.

Jason is right. It would be wonderful to find a job where they allow you to have the time to read the spec thouroughly, but the reality is that you have "yesterday" deadlines. J2EE is not conducive to that.

I consider myself to be a J2EE programmer. At the time I got into it, 'J2EE' loosely meant servlets, EJB, JDBC, XML and maybe JSP. I'm sticking with that definition. An employer cannot reasonably expect a developer to have every corner of EJB committed to memory.

The problem then becomes, what should you put on your resume? If you just put J2EE, some clueless recruiter doing a keyword search on 'EJB' and 'SOAP' won't pull it up.

My own experience with J2EE was not too bad. I was able to take a team of four programmers, none of us having worked with Java before, and have the team producing reasonable code in about a month. We focused on the three technologies we actually needed (EJB, JSP, Servlets) and didn't learn the others until they became necessary later in the project.

Of course, we were all accomplished C++ client/server programmers when we started, so our experience may not be typical.

Every application is built on layers. You have layers defined by specifications like Java and J2EE. You have layers provided by vendors. You have other layers that may be specific to your company, and still others specific to your project. The more layers you inherit the fewer you have to write, but the complexity of knowing and managing those layers is still there.

Perhaps the alphabet soup of acronyms would be easier to digest if it were more clear which technologies build upon each other. My preference is to learn the core technologies and build up the rest myself. So far I've been quite successful using only the J2EE standards. I would argue that the benefit of importing higher-level technologies into a project is often negated by their overhead, complexity, and lack of fitness for the particular application. Oviously I'm not saying we should go back to writing everything ourselves, but we should carefully consider what we choose to use. Starting a project with one or two core technologies and expanding from there is not going to overwhelm most programmers.

I also think that any technology is easier to understand when you start by knowing what it does and why you need it, as opposed to starting with a list of technologies you think you need to know and somehow figuring out how to fit them into your project. I suspect that a lot of projects go that route. Some manager says "we should use technology X" because he heard it was good, and his programmers are stuck trying to not only learn it but figure out how and why to use it.

What Java needs is a good IDE.

I'm working with Eclipse on Solaris; Dog slow. not sure why.

I love IDEA from intellij.

But neither of them allow WYSIWYG jsp development coupled with Automatic definition of Data bindings.

Maybe Dreamweaver MX will get it right.

These guyz arent the normal M$ biggots. Looks like Personified Technologies [getpersonified.com] is an ISV who actually bets their business on Java. Just very interesting to see some self-criticality and not ranting from the M$ sloths.

js

Overly large, my ass. We're talking about server-side here, not client-side apps (where I'll admit, Java is far too large). Since when has providing a full feature-set been a problem for a server-side app? A development project with an intelligent architect will pick from the best of the J2EE apis (who needs to know about message beans if you're not going to use them?), and ignore the rest. Follow that standard, enforce it amongst the team of developers, and the 'overly large' API isn't going to be a problem.

I'm not a Java Bigot (tm) - I'm not even a Java developer actually, but I am interested in what technologes you (or other /.ers) consider equivalent to J2EE. The only one I know of that offers similar services is MTS err... COM+...sorry Enterprise Services from M$ (when will those marketting guys ever make up their minds).

And you can't forget to mention IBM when you talk about Sun "wanting" to own Java. Just think about the name of IBM's open-source IDE Eclipse. What is eclipsed? The Sun. Jason Weiss Personified Technologies, LLC. http://www.getpersonified.com

The problem with Java specification is the same as with so many other aspects of Java. It's a question of ownership. Sun wants to own Java, period. Their feud with Microsoft is as much about not wanting to accept criticism of AWT as anything. Oh yeah, they have a "community process" that's supposed to make for non-Sun involvement in the product. It even succeeds to some extent. But mostly, the process is dominated by Sun's culture of possesion.

This is not just a matter of corporate policy. When I worked at JavaSoft, I actually met people who would not distribute their specifications in editable format, for fear of losing control of same...

J2EE is vendor slop. Not only is it overly large, but simultaneously incomplete. The abstractions are useles in the real world because they were designed for the very special case of JDBC databases. And when XML or any other du-jour technology came floating by, they were thrown in, too. Not because it necessarily made sense, but because one or more committee members had a vested interest.

The things that J2EE aims to accomplish can be (and have been) done with far less in a more architecturally palatable (read sensible) and scalable way. Please, please. I hope J2EE dies.

With the collaspe of the tech bubble over the last couple of years Sun Microsystem has finally realized that it's future isn't Operating systems or big servers. Solaris and its UltraSparc, will not be able to compet down the line with Linux or Intel 64 bit chips. Sun has to become a services company like IBM and in order to do that they need to gather as many developers to Java and develop software tools that become the next PB or VB for the 21st century. Sun can develop tools to open new markets that their tools and services dominate. Solving problem as all the specs of Java seem to do creates opportunity for tools vendors. I hope Sun in listen.

Those specs arent supposed to be read by developers !

I think that the author (and possibly the community) has confused the roles of different kinds of documentation.

In projects like those that developed VB and PowerBuilder and the environments that were built around them (e.g. OLE automation), I am certain that there were reams of specifications written just as complex as the J2EE specifications. However, you and I have never seen those documents and will never see them, because those developments were proprietary and those documents were and are considered confidential.

Also, because those developments were proprietary, they did not need to include in those designs all the details required for independent implementations to interoperate. Many small but critical design decisions took place as a side-effect of implementation because it was the only implementation that the authors cared to see actually function properly.

What we do see from those projects is user documentation explicitly written to guide the user in how to think about what was done in order to use it. The documentation describes the behavior and limitations of the (single) implementation. The trade press also fills in the gaps.

In an open community process, where it is assumed that people will develop and use implementations other than the reference implementation, you need to do all of your architecture and design work in plain view and that design needs to contain more detail than is necessary for a proprietary solution. The W3C and JCP documents aren't written to bring the developer up to speed but to guide the implementor and provide a reference to the developer of which features of the architecture are guaranteed to be provided by all conformant implementations.

Unfortunately, many of the implementors of these standards, even the reference implementations, don't go far beyond that in what they provide with the kit. Sun does provide examples, like the Pet Store sample, that show you how you might use the technology. These are descriptive and useful, but don't lend the sense of global conceptual integrity for which I suspect the author is groping. Instead, the onus of providing conceptual user documentation has fallen almost entirely to the trade press.

I also wonder if the nature of the problem hasn't changed. Web services involve the reliable distribution of information to many unknown programs over unsafe and unreliable networks. Writing performant modern web applications forces us all to become what, in the 80's, would have been regarded as "systems programmers".

The tools hide a few issues; for most issues, they just give us the controls to manage the issues ourselves. As a result, where before we might have had to interact with three or four third-party components and would implement a few underlying non-business-logic items ourselves, now we are interacting with perhaps ten or twenty third-party components, and the main distraction from our business logic is learning how to interface with the components that already do the things we need.

All of this requires us to learn more sophisticated ways of thinking about programming and to learn many more interface details of what others have written. Unfortunately, there is only one thing for it. We need to spend half of our design time reading. It's our job.

I remember when one of the bugbears of development was a management attitude of WISCA - "Why isn't Sammy coding anything". We eventually managed to convince management that design was important. By and large we've been successful. Now we have to do the same thing for research. The better development organizations already have.

Ralph

I agree with the author that J2EE could be made easier. I have been working on J2EE for a while now. When I developed my first application in Servlet & JSP - I loved Java (compared to ASP / cgi-bin). I Recently for my Sun Certification (Ent. Architect), I tried my hands at Entity Bean - CMP - 2.0. When I compare that J2EE application with a similar application I developed in .Net, I start doubting - is Java (/ J2EE) "still" the Best?

Using .net, in a week I got my basic application done. But to add the belles & whistles it took a week more. Compared that to J2EE it just took 2 weeks to develop the same base app. But It was really powerful. I had to build a lot of 'infrastructure' but then extending & modifying it was easy.

At the end I wish: Only if .Net was more flexible (read open) and J2EE was more simple !!!

But my honest hope is one day IBM / BEA & SUN will wake up (or they already have ) and develop a lot of tools around J2EE. (JCP guys: PLEASE do not force the "Entity Beans" on us) !

Till that happens I'll continue to try out .Net , even though it is frustrating sometimes to be unable to do very simple things that are easily possible in J2EE. And may be , I'll even recommend / use .Net for some internal project to start with ...

Java as a language is great. I think the problem a lot of people run into is expecting it to be more than a really good 3GL. It's not. It's a langauge, and it has *lots* of low level libraries. This is a good thing, if used for the right purpose.

Where people/companies get into trouble is expecting it to be something different than it is. Lots of companies are developing enterprise applications by programming directly to these low level APIs. This, frankly, is stupid in 9/10 cases.

Would you write a typical corporate application (aka a "power builder" type app) using C and just the stdlib? Not if you wanted to keep your job! But people do the equilivent of this in Java all the time!!!

I don't know if companies are just stupid, or if they're *trying* to screw themselves under. Wake up! A typical corporate app shouldn't be coded to low level APIs. Get yourself a higher-level framework that fits the job, and code to that. Can you say 1/10th the code?

And its not like there isn't a ton of frameworks out there to choose from. (Everyone has their favorites, but since I mainly build web apps on top of databases, I use the Covont framework.)

if it cannot solve a specific problem. many can understand the spec, few can create viable working applications, and that involves more than just so called computer science

If you can't understand the Spec, then perhaps Computer Science isn't for you?

Sorry--take three:-) Unlike VB productivity, which is achieved through proprietary wizards and dated table/form metaphors--the insulting for dummies approach, VE keeps the developer focused on the business logic (objects, processes, and rules), while taking care of the database and interface layer (which supports both desktop and handheld browsers, along with full support for Web services), all running on an n-tier J2EE implementation of your choice. After all we learned, we sure can do much better than VB--on a fairly complex application, VE showed a 6-to-1 productivity advantage over VB. Combining VE with J2EE far better achieves Microsoft .NET

The current problem is the complexity of the frameworks that Java uses. From Swing to Servlets there is too much overhead in getting started.

Its an unnecessary burdent that Swing applicataions do not know how to close themselves and servlets cannot be accessed until a web.xml file is edited.

Also there are times when you need to Java libraries, but Java itself if too complex. I use Jython to write clean python code that runs in a JVM.

When I need the elegance of servlets w/o the complexity I use Webware (webware.sourceforge.net) as a Servlet runner. (Python code and does not run in a JVM)

As I was saying, unlike VB productivity, which is achieved through proprietary wizards and dated table/form metaphors

Regardless of the page or acronym count, or even the JCP process, the complexity in J2EE is real! Great separation between middleware implementations (containers) vs. application logic, however, none of it is intended for human consumption. Just like 3GLs in general are not suitable for building business applications. Instead, a thin layer on top of the middleware to capture logic with very easy and familiar artifacts, yet masking all of these specs, is the natural evolution in the Java camp. Intelliun delivers this technology (VE) by taking only two models from UML and combining them with simple formula syntax to express rules and constraints. The result is a mathematically complete visual development environment that you can build any business application with, at a small fraction of the effort. And, the training curve is absolutely minimal. Better yet, if you want to really learn OO without letting languages and specs get in the way, you need to take a look at VE--checkout the white papers (link below). And, unlike VB productivity, which is achieved through proprietary wizards and dated table/form metaphors

I think two-tier and three-tier architecture have their own places.

I have seen couple of PB projects that lack scalability and performance. For instance, employees are lazy, and when everybody tries to submit monthly paperworks at the end of month, no one can log on to the system. (You know why.) The system crashes, and failover is horrible. Three tier architecture can solve these types of problems.

You don't want to use EJB with intranet and for only 10 users, do you? Then, PB maybe the way to go. (Or, even VB.)

After a year working on Java, I really miss PowerBuilder. There are some applications for Java such as stock transactions and ordering prescription drugs. We can develop quite a good PowerBuilder application in a week. The same application would take a long while to implement and the screen GUI is less than what we had on the early version of #3 for PowerBuilder. I do not know why we need a middle tier server. It slows down the application and creates many problems. Nobody in the right mind would share EJB from different applications. Entity bean is a joke to me. I believe all the managers read the same magazine and most Java developers are the nerds from the ivory towers (please no hate mails). Magazines try to sell new stuffs and Java and the supporting products are new. I hope the corporations will wake up one day and go back to PowerBuilder and VB.

This is a bunch of bologna.

Every specification named solves a specific problem. All that would be accomplished by eliminating the specifications is that the same problems would be solved, but in completely different ways by different people. You'd be back the vendor lockin nightmare that you had in C++ when you wanted to do something that wasn't part of the core language (i.e. anything remotely advanced or interesting). You want threads? Email capability? Database access? Messaging? Pick your vendor well, 'cause you're stuck once you do.

And the other guys comment about learning curves and specs NOT being related is dead on. I am a senior developer and technical trainer, and I've never read a single specification (nor do I plan to, unless I start writing compilers or servers).