Your article has merit. The problem is not the power of Java or Java Beans however, the problem is never ending changes to the frameworks.

OK we start using Servlets. Servlets are a great advance over CGIs. However, the problem comes in writing all that HTML code by hand and testing the ouput, which requires a recompile every time.

Then we migrate to JSPs. Great idea! Now we can see what our HTML pages will look like at design time. We code scriplets into our JSPs and we are happy.

Oh, no, now we have to separate the HTML from the logic, because we are not going to use Java developers to produce JSPs, we are going to use "Web developers" and graphic artist.

OK, so we go to the Bean model. Java developers write Java beans and the JSP "Web Developers" use them. Great! alot cleaner JSP as well.

But that is not good enough. We need more separation, so we come up with the JSP/Servlet/Bean model. Ok, we learn this paradigm and start coding.

But wait, this is not good. We are still using too many in out code. Now we come up with Taglibs. Now our "Web Developers" do not need to know about Java Beans, they use taglibs (which requires them to know a taglibs methods and the scripting we design for them, so what is the difference here, really? P.S. I actually like Custom Taglibs).

So that is not good enough, we need a better MVC architecture. To the rescue, Struts. Struts looks good, learn it and use it.

Oh wait, we need a more simpler standard taglib scripting set. Here comes JSTL. We need a better struts, here comes Java Server Faces. We need, we need, well, you get the idea.

All of these changes have taken place in the last one to four years and are constantly changing. We haven't even covered the EJB/JMS/Web Services/RMI thingies yet.

I think that this is what the author also has in mind,and so do I. ENOUGH, start standardizing these things, and make changing API sets less of a new learning experience. It is madness!

BTW, I agree with the author about EJBs. Entity beans and Session Beans performance simply SUK. It is however, a great way to sell a $10,000.00 to $30,000.00 a CPU App Server. BEA, IBM, Borland, etc. love EJBs!! Those who seek to deploy a large application with hundreds of users, have found they do not like them too well.

As Ross Perot once said, "There goes that giant sucking sound!"

I think there is a misconception on the use you want to give to components.
Let's think: vehicles have wheels, but not all vehicles have four wheels, not all wheels are the same, different wheels have different scopes as a car wheel won't ever replace an airplane wheel.
As the wheels, software components have also scopes. You may never be able to create the "SUPER-COMPONENT" because there is no such a thing.
Te fact is that on similar problems with similar scopes and similar domains you may take advantage from previously written components and there's no guaranty they will smoothly fit in.

I think the issue with components in Java is that people have spent too much time doing components without thinking about component lifecycle. Strangely, the EJB spec tells Java programmers how to do components, but nobody pays attention.

Very good artcile.

It's funny how developers continue delving into the Java mess, constantly denying the obvious and inevitable.

Java simply does not have a good framework for software development. It's a funny feeling, working with Tapestry, Struts and Velocity and comparing them to ASP.NET - it seems that all of the three aforementioned Java technologies are written by high-school students. EJB, or EJ-what, as my colleagues refer to this technology, is a ridiculously complex and unusable technology, that is by far the only one that beats COM in unusability. Entity beans being my favourite, I'm sure the people who actually know how and why to use entity EJBs is less then 5 worldwide.

Web-services ? Please, try writing them in Java and ASP.NET and compare lines of code and complexity.

It's obvious. You do not need a Caltech degree to see that Java frameworks just do not work. And come on, I have a project to complete, I do not have the time to write a framework with inferior technology myself.

Enter .NET. I have a report stating that 60% of all third-party components and tools will be .NET related by year 2004. You know why ? Because it is easy to write them. It's neat and clean, and fast. And gets the job done, unlike Java's millions open source projects that just do not work.

But then again, keep the Java hype. That leaves more room for me in the only expanding technology market nowadays -- and that is not Java, as you've probably noticed.

You address some important issues. I can understand your perspective. Newcomers to Java will share similar concerns. I do see this evolving with maturing technologies and with emerging developer tools that integrate Struts for example.

Frameworks are maturing so that they do not leave the burden of work up to developers. Have a look at the reseach complied at www.mvc2frameworks.org. In particular have a look at the spreadsheet.

Frameworks for example that extend Struts with various components that applications typically need.

Take the open source Expresso project (www.jcorporate.com) for example which is a Very comprehensive architectural framework. Most popular architectural framework (user community 30,000+ registered users/ 4500 on listserv). Its components work across various dbs, and app servers!

Additional addons are available for WebServices, code generation, and applications such as content management, discusson forums, faq, polling etc.

Alexander,

You are right to question if the MDA gives a more useful abstraction than OO.

The reason I think it does is because most OO models in use are actually Platform Specific.

MDA specifies a Platform Independent Model (PIM) described in a formal language, that can be transformed to a Platform Specific Model (PSM). From the PSM another transformation is made to the Code Model. A standard compiler transforms the Code Model to the hardware binary (or bytecode for a VM).

If you think this cannot be useful in a single development environment then consider my current project:-

I am reverse engineering 22 Domain Classes and 70 associations to create a PIM. From this PIm I generate a set of PSM models (Web Tier, EJB tier, DBMS tier, and even WSDL).

In one day I generated a working J2EE application deployed to Tomcat/Jboss which includes all the Entity, Session EJB's. Value Object pattern, DAO for fast lane reader, page iteration, complete STRUTS front end for CRUD maintenance, Session Facade, DBMS DDL scripts for 7 major DBMS flavours and Deployment descriptors for Weblogic, JBoss, Sunone7, Websphere and Oracle9AS.
The next step is to customise the front end JSP's and add detail business rules.
Changes made to the PIM and PSM will still preserve changes at lower levels - (a common problem with older generators.)

It took the original team of developers about 1 month to get this far. So perhaps MDA and Pattern /framework generation can be productive!

So Phil, I guess anyone who disagrees with your world view is ill read and or a mere hacker? Well, that is a very compelling argument! I'm convinced! LMAO

Take a look at Open Source SOFIA. http://www.salmonllc.com/sofia).

It's a J2EE based toolkit that provides an end to end solution for buiding database driven browser based business applications. It also incorporates best of breed off the shelf tools and full documentation to make you productive right away.

All free and open source.

Those who slam the J2EE architecture are also those who don't bother to do the proper reading (esp. Sun Press) and who have a poor understanding of software design. I am not quite clear why everyone assumes that the J2EE architecture should be constrictive? If you want to know the best way of doing things, read Core J2EE Patterns. But of course, mere hackers wouldn't understand that. As far as the diversity of the platform goes, it is a natural part of this open platform to be evolutionary and open to experimentation. The fact remains that there has been massive beneficial adoption of Java standards. When I look at the alternative options for 3 tier software design, I think it is clear that the best option for scaleability, felxibility, maintainability and availability is J2EE. Period.

I agree that the promises havent been fulfilled, but I don?t think its the vendors' fault. They simply provide frameworks and tools.

It is the responsibility of the developers to actually develop reusable components. And in order to accomplish this we have to look for reuse at the design level, not at the code level. A good first step for this is to understand and properly apply design patterns.

So, in a nutshell ... although the existing frameworks could be better, its still the developers' responsibility to make reusable components.

IBM has not dropped the ball on J2EE components Have a look at http://gwareview.software.ibm.com/software/awdtools/businesscomponents/ for a complete set of cross industry components.

Having been in the J2EE enterprise component business for the past three years providing EJB components suites for a number of business domains such as e-Commerce, CRM, Content Management and Identity Management, I feel compelled to add a vendor?s viewpoint here.

The marketplace that Sun and repositories such as Flashline.com envisioned has not materialized. There are a number of reasons for this. For one, selling business objects to corporations on enterprise class applications is very different then selling component based utilities that are seen in VB market. The evaluation and sales cycle for buying business components is similar to that of buying other software applications that are aimed at enterprise customers. These customers are not going simply order CRM Components from a website. A second could be a lack of market or creating the necessary awareness for such repositories to exist. A third could be a lack of depth in
the market providing suitable components.

I agree that it is challenging writing EJB components and getting things such entity beans to perform well. That does not mean that is not feasible.
It is true that business rules and attributes vary from business to business and in large organizations, they may vary from one business unit to another. When we designed our EJB framework, it was with the intent that attributes and rules would vary from customer to customer. We used a variety of strategies such as O/R mapping, Metadata and pluggable interfaces to allow our customers to do this type of customization.

Our customers have ranged in size from Fortune 100 firms to startups and they varied across a number of industries. In all cases we have been able to deliver on the objective of using our component based framework to rapidly deliver applications in a fraction of the time and cost that it takes to deliver solutions with traditional packaged software. It has allowed developers to focus on implementing business logic that is unique to their organization. By using our framework and large collection of components, we have also been able to shield application developers from some of the complexities for J2EE and deliver performant applications that can easily be adopted to ongoing changes in their business environment.

Over the past three years our products have evolved to include a rich set of applications that run on these components, and thus closing the gap between a pure
component solution and traditional packaged software. We used tools or components such as Struts to achieve this goal. We have also exposed these components as web services, there by allowing simpler integration.

Regards,

Suneet Shah
CTO, Diamelle Technologies
www.diamelle.com

Since right after OO began to offer reuse as a benefit, people have asked why it doesn't work. The answers haven't changed. First, it's diseconomic, in the sense that it costs less time and money to write components than to discover, compare, select, test, and validate others. This diseconomy is proportionate to code and component complexity which are increasing over time. Second, nothing in my technical or business experience makes me tend to try component providers, even the big brand names. The TV and magazine ads are great, but as technical professionals know, the products don't deliver on the promises that the ads imply (but don't actually make in a legally binding sense). If the big, household names can't deliver, it's difficult to build management trust in no-names, however excellent their technologies might be. Finally, is the biggest reason of all. Software has never been reliable. Quality is even harder in software. Six Sigma reliability is not nearly sufficient in software, where size and complexity are orders of magnitude greater than any manufactured item. Six Sigma reliability in code, that is six defects per million lines of code, are grossly unsatisfactory.
Final comment: In its essence, Sun has never been, and I don't think ever will be, anything other than a hardware company. (Don't get me wrong: I have always loved Java and it is my main and preferred professional tool.) We all should, however, understand Java from Sun's point of view: Java is a tool to preserve the market for non-WINTEL computers. Java is not a philanthropic endeavor.
Bottom line: let's get our code trustworthy (and out of the headlines!) and let's find a way to make component reuse compelling in time, money, and reliability terms. We have a long way to go.

I have been working in the J2EE arena for a few years now and after drudging through all the technologies, it seemed like a set of standard component would reduce my development time. This notion was wrong, however. Don't get me wrong, components have there place, in specialized situations, but when you are talking about large scale systems, that change from one project to the next, a framework seems like the likely answer. If developed correctly, it can reduce the amount of code that I have to write, allowing me to focus on the business rules. I should be able to front-end the app in any way I choose. A well written framework should allow all of these things, as well as easy access to datasources of any kind, etc. I believe that this is why frameworks are becoming so popular. Trying to glue together a series of components can become quite bothersome and could lead to many more points of error in your apps. While I do feel that components still serve a useful place in a j2ee app, a solid, flexible framework does allow me to get more done in less time while maintaining robustness and scalability.

Roberto, I see what you mean and that's certainly an improvement. But my problem ( and it is a very real problem in the project I'm working at) is that business abstractions need to be defined at runtime by business people. I cannot use generator based solutions there. Business users need to define classes and properties and so on.

Chris, I think the Assembler comparison isn't suitable here. 3GLs provided abstractions like ifs and loops and so on instead of moving bits to registers. Where is the abstraction of MDA above the level of any object oriented language? UML is just OO in pictures. A picture isn't necessarily a higher abstraction than the same concept expressed texually. Yes MDA promises to abstract from platforms like J2EE or .Net and their respective ideosycracies. That's all well but it doesn't raise productivity for someone who works with only one of these platforms today.

Alexander,
your point is good. Component reuse is not JUST a technical problem, MDA is offering a way to alleviate/solve this complex problem allowing you to work as much as possible at the business model level.

Back to the example I see two scenery for extending "a customer", based on semantic considerations:
1) you want to extend it in all your apps;
2) you want to extend it just for some apps (the customer in a specifc situation needs something more);

MDA can help you in both cases as you can work on the MODEL of the customer you used in your apps (Business NOT Tech model) and then regenerate them.

Scenery 1) you can enrich once your old customer model (adding what you need) and use it to regenerate all your apps, so you can easily keep all of them up_to_date (both for semantics and for tech)

Scenery 2) you can generate an EnhancedCustomer as a specification of the customer (like subclassing) so that you've another component logically (at model and semantic level) inherriting the common part from the generic customer. Then you decide which component to use in your apps.

Roberto

Although I agree with many of your points, I think in the end this is no a Java or J2EE problem but a problem with the whole notion of components as self-contained software modules. The extension mechanisms for business components like your generic customer are not well defined. How would you go about to extend a generic customer EJB to include additional fields and relationships? Do you mess with their storage mechanism? How do you do schema evolution? How would you integrate it into the notion of a "customer" in your CRM?

We have a much more general problem here that has to do with relating concepts to each other based on a sound logical foundation. Only if this has been achieved, do we have any chance of solving the technical infrastructure problems with the likes of EJB or .Net.

The closest to a solution is RDF, OWL and the whole Semantic Web idea. You need to be able to state facts about things without integrating your code physically with any kind of "component". Multiple "component" providers need to define their concepts on the same semantic foundation, not only on the same technical platform. Otherwise it will never work.

Hey,
I don't think Components and Reuse are just an Holy Grail...
...the key is the abstraction level and the environment where we expect Components availability and Reuse.

We must shift from "Universal" components/reuse to "Enterprise" components/reuse.

Why do we have dozens of car producers and hundreds of different models? Because usage and expectations are very different between car users.

This is even worse with software, any SW on any platform.

I think it's not possible to market a "customer handling J2EE component" suitable for everybody (for functionality, cost, HW & SW requirements, performance ...)

BUT I think we can all agree that Reuse could is a reasonable target at least at "Enterprise" level.

This is exactly where MDA, Patterns and tools like OptimalJ helps you: reusing and maintaining MODELS and COMPONENTS that solve YOUR PROBLEMS. Leverage Enterprise investments in building software, avoiding to reinvent solutions and guaranteeing productivity, quality and interoperability.

J2EE is just an instrument to that, a good one IMHO.

Roberto

I think that a lot of the replies to the question of where are the components are on the money. Java (and in fact all language I know) are designed to be flexable and allow innovation. Standards can (when made simple) reduce the learning curve for products (DB access is the perfect place for a standard: JDBC).

I don't believe (and history has so far upheld this belief) that it is technically possible to build a generic write once use everywhere component for most application components.

Infrastructure components are certainly buildable (ie: ORB's, MessageQueues, Collections, etc), but writing a purchasing agent, product bean, or a user class that can be used in most applications creates more work. Now the programmer must figure out how to use this black box implementation, and how to integrate it into the application, and how to optimize it, and how to debug the application when the eventual bug is found.

I have written many User beans before, and ever one is a little bit different. Perhaps what would be more useful to a software engineer would be a set of source examples, documentation, leasons learned, and instructionals along with sample code on how to build common application components such as a purchasing system or a credit card management system. If a company sold a product such as that it would reduce the R&D time and hopefully shorten the debugging process.

This might make a great open source project? Anyone doing this?

Joseph,

first, I regret that you join in spreading that nonsense about EJBs being slow. The problem is that lots of people use EJBs - in particular entity EJBs - for purposes they were never intended for. If you have a project where the J2EE framework fits (and mind, many people use it where it is not appropriate in the first place), i.e. where you need (distributed) transactions, security, distribution in the network. MOM etc., you won't be able to create a better performing solution with acceptable effort with a non-J2EE approach (you can, of course, always get better performance if you have the time and money to build your specific application from scratch - at least if you have real good programers that understand all implications of a large transactional secure system, but don't expect to be able to re-use anything of that beast).

Second, while it is relatively easy to think of components in the GUI (and there are a lot more GUI JavaBeans around than you obviously know about) it is quite difficult to define useful components on the server side. I know a few J2EE component collections for financial applications. This application domain is well understood and you can identify components easily. But in most areas when you try to define a component, you end up with a modulized application with the modules somehow being specific to your application...

Defining components takes time and often requires re-thinking application design. Look at that model driven architecture approach that has come up now. This is an approach that supports the component use much better. Yet, the idea has been around much longer, because what you get is a business process (BPM) based system which is essencially a workflow based system, and, yes now we are getting somewhere, because now you can define an application independent component, the workflow engine. And these engines are currently coming out of development (personally, I'm involved with WfMOpen - http://wfmopen.sourceforge.net - but this is only an example), and J2EE is ideal as a basis for developing such a component.

It is much more difficult and takes a lot more research and resources to develop a good set of components than to simply write the application. And appications are much easier to sell. Ever tried to explain to a manager the beauty of your component framework while the guy at the next table clicks around in the pretty GUI of his application "all here what you will ever need"?

Do not expect components to show up in four color print. They will slowly emerge from developers communities, because they are something developers need (and can define based on their experiences) but something nobody is prepared to finance.

Steve,

Thanks for the feedback.

I think the argument might be becomming circular here. For instance - over the symantics of what is J2EE. For instance STRUTS is not a J2EE standard but it is built fully using J2EE standards.

J2EE is a solution to a set of Enterprise Problems, but does not solve everthing out of the box. Some could say this is a stength rather than a weekness, as it is very extendable and adaptable. J2EE is not perfect, and it's complexity is part of it's prodcutivity problem.

For instance CMP as you mention is often a major performance issue, but if some of the Sun Blue print patterns are used such as Value Object, Session facade and Data Access Objects, and the application server is correctly configured , then this can be very efficient and elegant solution.

On your point about customers of Compuware, MDA and Blueprint patterns are standards available to everybody. We are just one company to put them together into a productivity tool. The ROI has to justify the tool.

Like I said... petstore lol.

Also, last I checked, STRUTS is not a J2EE technology so you're just confirming my point... Thanks!

It's comforting you think the J2EE architecture is sound, by they way, is that with CMP EJBs or JDO? LMAO

Seriously, J2EE will not be a real brand until it means something. Right now it is pretty much meaningless as you admit, you couldn't even build a J2EE application. You built a well understood application using some J2EE branded technologies and some other stuff.

Your tool sounds great and so did the modeling tools of the 90s, but it's interesting to note in this study you cite how often it was said that a big benefit came from 'the tools end-to-end framework' also the 'tools security framework'. Shouldn't this be what J2EE is all about? Should only compuware customers get the benefit of a total solution approach? It sounds like you all are at least trying to build a "nest" for people to feel safe in choosing this approach (even though the study says you better know exactly what the tool is generating or you won't reap the benefits).

How many of you guys use unix or linux or its flavours to do your development ? I am guessing a lot of you .. Now if you have noticed, unix functions do a specific task , but they do it really well and can they can be used with a plethora of optional parameters to make them really flexible. Why am I talking about this ? Well, what I am trying to ellude to is that if components are well written, flexible enough, well documented then developers can reuse those components. There work shifts from developing those components from scratch to actually reading the specifications and tailoring those components for reuse in their applications. What do they gain out of this if they have to put in so much effort going over specifications and customizing components ? Well what they get is a well tested components with far less bugs than what they would develop from scratch. Whoever knows about software engineering, knows that there is much more to software than just the implementation. Software components have been compared to hardware ic's. You can buy a memory chip and plug it into your mother board without having to deal with creating one on your own. So why are our endevours towards creating such plug and play type of components going haywire? One of the reasons is a lack of well tested standards. One of you earlier mentioned that J2EE is a bunch of standards that are at different stages of maturity and this is absolutely right. Java's age today is around 12 yrs and J2EE has been approximately 6 years. We just havent given enough time for the standards to mature enough. I am sure from discussions like these we get valuable feedback which is shaping the standards for the future. hmmm .. and now comes ... whats that called .. .NET ? another? its not about creating yet another one of them , but its about creating one of them that everybody conforms too and bennefits from too. Long back people use to have different systems to buy and sell goods, for ex. the barter system ... slowly these systems evolved and the modern currency system evolved .. lately we have even seen that these currency systems have tended to combine into one eg. Euro .. infact on another level most things can be bought of the www by something like credit cards, digital currency .. slowly with time and learning methods combine into one unique method that has resulted from years of experience. It takes time.

We released the Comet Way Agent Kernel (http://www.agentkernel.com) in 1999 because it provides the component based model that J2EE and JavaBeans doesn't. Ours is the cleanest, simplest model I've ever seen, and we have worked hard to make it better over the years. It requires no special IDE, no third-party web server, no specific operating system, no constructors, no getters and setters, no database, no special build procedure, no wrappers, no RMI, no special administration tools, no special deployment process, no specific JVM, and best of all no special knowledge above and beyond what you'll learn from Java In A Nutshell.

In fact, if you download it right now, and have bothered to learn how to compile a .java file, you too could be running your own secure, distributed, dynamic component-based applications in 10 minutes.

A good development platform makes programming easy for anyone, and that's why Java was so successful in the first place. Although we have not contemplated every nuance to component design or written any multi-vendor endorsed specifications, we have found many many applications that our simpler model supports through the REUSE of agent-based components.

See for yourself. Maybe it's not your cup of tea, but you'll see lots of things done right from the developers perspective. Developers don't need specs and models and new paradigms. They want elegance, simplicity, the ability to focus on the task at hand.

Look at our Agent List for a taste of what you can get when you have a living breathing component architecture. And check out our component based web server. It rules. -- And it's all FREE (god forbid).

Steve,

I can show you J2EE applications which can deploy without code changes on the major platforms BEA, JBOSS, Websphere and Sun. (Deployment descritors need to be different - but we just generate them different).

We commissioned the Middeleware Company to do an indepenent evaluation of MDA against traditional techniques. The Spec was an extended Petstore (much more complex). The traditional team consisting of J2EE code and Pattern gurus (including one of the most famous EJB authors that we all know) took 5 weeks to do the project. An inexperienced MDA team took 4 weeks to produce the same application on the J2EE platform. The code and application which resulted was regarded very highly.
Read about it here:-
http://www.middleware-company.com/casestudy/mda.pdf

I agree too that this is a general industry problem and not one that can seen as just a J2EE issue. The J2EE architecture is very sound, the problem lies with current levels of developer and deployment productivity.

MDA is not our invention it is a standard developed by the OMG (who also own the UML and CORBA standards), it is also being applied to non-J2EE systems.

I think the big problem is with J2EE itself. You can't solve an enterprise problem with "J2EE"... I challenge anyone to present a large scalable solution with only official, standard, portable, J2EE technologies (pet store?? LMAO).

And if you show me one (hehehe), I challenge you to deploy it to any other J2EE certified platform without a code change....

This is our .NET killer? Until seeing the J2EE brand means I will be able to build complete applications, pick a certified vendor, fire that vendor if they don't deliver in reliability, performance, or expense and pick another vendor without breaking my application all without leaving the J2EE "nest" (assuming J2EE ever develops a "nest"), J2EE will be missing the boat and will be/is meaningless as a brand.

And I speak from love and as a success story for "J2EE"... I am like many here, using java, some J2EE branded technologies, and other providers to solve real challenges.

I fear for the inexperienced who chose J2EE or for those unable/unwilling to take the lumps of experimentation with "official" releases, they will probably fail, lose their jobs, and never re-visit java again (another .NET victory...).

I question the ROI of J2EE, how much has been lost to the failures, and have the successes paid back that investment?

And the tool vendors are busy building the 3rd floor of this model driven development, promising "instant" prototype applications, "instantly" tested. Great, followed by man-years of risky toil to try to make it really work...

Chris, you make a very good point about moving on from assembly. The key difference is that assembly worked first, then we wrote compilers that wrote better assembly then we could in virtually all cases. What makes you think we are at a point where anyone would even reconize that the code generated now by this new product of yours is better, or would even work in virtually all cases? And even for those appropriate cases, are you going to fix the JMS bugs? The CMP EJB performance and locking nightmares? Or perhaps your tool doesn't even use those technologies... Who wants to bet their company on this? show of hands???

I agree that a lot of the challenges we face today will probably be abstracted and simplified by the next big thing. We've seen this again and again in sofware's short history.

All that means is that bigger and more complicated problems will be expected to be addressed.

But the next big thing will still need develpers with the same qualities you'd want today.

I also agree with the poster who said something along the lines of "Compents are a sofware industry problem, not just a Java problem". I don't see the component technology the author is lamenting over in other technologies either.

I don't think code re-use is the Holy Grail, it is Productivity! A lot of people have thought that if we could just get better code re-use then we would have better productivity.

Instead we should focus on re-use of Patterns - as many of you have already said.

Trying to build in future re-use to your component at the time of manufacture, means you may not be building what your customer wants RIGHT NOW. Agile techniques rightly point out that this can be a waste of time and delays the current project. (the next project may never happen, or the customer changes their mind while your project is late!)

It is interesting to note that Assembler programers used to think it would be impossible to replace them. 10 years after the introduction of 3gl languages and their compliers the use of assembly language coding was mostly dead for Enterprise applications. What happened? The level of abstraction was raised and so was productivity. Again OO has done the same. The next level of abstraction (away from the hardware and towards the business user) is on the horizon - Model Driven Architecture. (MDA)

UML and further enhancments that need to come will become the new source, it will be compiled into platform code such as java/j2ee or .net. Developers will mostly become Platform Independant Modelers and Platform Specific Modelers.

If you don't believe me - go ask a retired Assembly language coder!

Code reuse is the Holy Grail of software development. At a very low level, you can abstract things, but at a high level, this results in a complexity that isn't worth it. (There are a lot of examples out there.) Writing the code is what it's all about -- it'll be a sad day when folks can just stick components together like tinker toys. (Or WOULD be, as it will never happen -- you can hold me to that.)

I have written various succesful enterprise applications using the J2EE and other Java APIs.

For those of you who complain about complexity, there are many IDEs which will write plenty of code for you (my favorite is Oracle JDeveloper 9.0.3).

Most of the reusable code I have written falls into one of two categories: RDBMs dependent code or vertical market specific abstractions.

I do agree, however that you should probably stay away from CMP and stick with stateless BMP Entity Beans.

I think Java is just great. I love it. It's useful and we reuse a lot of stuff.

But we stick mostly with standard Java and its huge class library, with JSP/servlets and JDBC backends. We use JCE, JavaMail, JSSE, Swing, RMI, XML/SOAP and JMS to great success. Like Wall said, we also use open source stuff from jakarta and others.

We reuse lots, but we don't make any use of EJB. We found EJB just too complicated and too slow, and you are right that often moving from one container brand to anotther caused grief. Maybe it will be better one day, but it's more complex than it's worth. We find JDBC much easier than figuring out to soft config it for CMP.

It just seems that new specs are created well before they are truly ready for the marketplace. Everyone jumps on a "standard" even though the standard was written before there was any real experience using the ideas behind them. It just doesn't pay to be on the bleeding edge.

I agree with the one response that says this newsletter has become a java fud service. Are we really worried about Java going away? If it does it does and we'll all move on to the next thing. It is just a tool with a lifespan anyway.

That said, I think there is a lot of confusion about what a "Component" is. I really doubt the reality of having one Struts or EJB component that takes all the work out of leveraging that framework well. All you do is move the work somewhere else (think tons of config files and work-arounds because you don't have control of the source files).

Even in my 10 years of VB development, most of the wizards and do-it-all components were considered for newbies and demo-projects only.

The more I consult on larger projects the more I see that the reality is that there is no magic bullet for software. The more I've seen tools that hide the complexity; I've seen them limit your flexibility.

The best reuse I've seen so far comes from using common patterns (Gof and Core J2EE), Quality open-source projects (a lot of which I'd consider pluggable components - log4j, taglibs, etc) that have been a productivity saver time and time again, and experienced developers who can see beyond the current task and abstract some higher designs for reuse.

My belief is that software development is more of an art form than paint by numbers. I've seen a small team of artists outperform a large team of plumbers in time and quality.

For my money, there is nothing out there for the many kinds of enterprise development I need to do, that can compete with Java, J2EE, and its open-source community.

When there is, I'll be one of the first to jump ship.

The author is not ignorant, but I'm less sure it's a failing of Java or J2EE than it is of the software development market overall.

For example, there is a lot of reusable Java code, but much less in the J2EE space. The Apache Jakarta project, for one, creates so many useful Java classes that only a fool or someone stuck with legacy code would look elsewhere for the many basics.

But when it comes to Javabeans, EJB, there is much less plug-and-play than has been promised.

But to be fair to Java, this may be more a reality of how hard it is to write anything complicated that is also useful generically. We don't see these components in other languages or other object models to any great extent either.

In fact, just reusing entire applications can be hard enough, even with XML-based (SOAP, et al) APIs since there are really a lot of integration points in any complex applications. For example, how is security, logging, and other framework plugging going to work with disparate systems? We have db access code that will likely be different depending on the db in use (i.e. a blob in Oracle and Postgres are not even inserted the same way, so JDBC's abstraction didn't help there).

Anyway, until I see another programming language that has done it better in terms of components, then we can talk about Java's prohlem. Right now, the promise of components is age old, but delivering it is extremely complex. This is not Java's fault since what the hell is a "generic customer" or a "generic order"? Sure, there could be some simple college-level components made, but what are the odds it would match my needs?

Payment processing is likewise complicated by the myriad ways of paying (credit card, debit card, EFT, check, cash, varying currencies, letters of credit, prepaid systems...). And to which backend payment system are you using? In the end, the idea that there's something so simple as a high quality business object is wrong. There are lots of generic classes that handles lists of items, sorting them, date routines, encryption routines, formatting routines, money routines, error logging, file uploading via HTTP, GUI widgets, etc. But clearly a "car" object to GM would be quite different than a "car" object to Hertz and different again to a "car" object for regular folks (one manufactures them, but also sells them; the other rents them from multiple manufacturers; the last probably only cars about household related functions of car). There's simply no such thing as a "generic car" that's useful to anybody. This is why programmers exist, to give people the functionality that they need.

Lastly, most of the programming of such components is done in a proprietary environment, in which the intellectual property to the code is not shared. There is often quite a bit of sharing WITHIN an organization, but these components are not made generally available. So, the problem may not be just with the component models or J2EE per se, but with the fact that nobody has created anything sophisticated enough to market as a separate item that's not a competitive advantage to keep to oneself. Again, it's not clear this is Java's fault.

AS, I have read the books! I think it is rediculous to think that I need yet another specification to follow. I should probably clarify something - I am a Business Application Developer - I don't write shrink-wrapped for sale code. I work in a small shop and still find Java plenty RAD. I code along developers using foxpro and MS gui tools to build their apps. I make all of my stuff handwritten using a simple text editor and it blows their's away!! I have also written my own custom tag library in less than 2 months that I have been re-using for almost a year now in my web-based stuff with very little modification - in other words, I believe it was well-designed. With that tag library I have written our company's entire intranet site including a home-grown calendar app - completely from those tags - in less than 3 weeks! Please don't assume just because somebody doesn't agree with a technology that they aren't smart, well read, or that they are just ignorant. I am very happy - and so is my employer - with my level of competence and my "bead" on things!!

I wrote an article on this very point back in 1993 (link) in regards to the pioneering NeXTSTEP marketplace, so don't hold your breath.

http://www.simson.net/nextworld/93.6/93.6.Oct.Community6.html

Marcos

I wrote an article on this very point back in 1993 (link) in regards to the pioneering NeXTSTEP marketplace, so don't hold your breath.

Marcos

AS, you should not draw such conclusions based on so little knowledge. You don't know me. For example, I actually co-founded a company which has spent multi-millions on a reasonably large and complex J2EE application (> 140 entity beans for example).

My application is successful. My comments are more a reflection of fact then lack of knowledge. Just because you disagree is no reason to think the other person is stupid or inexperienced...

So let me clue you into a few things. Firstly, all those expensive projects you've worked on with WebLogic, how many are successful (point them out i'd like to see...)?
Secondly, how many of those projects only use J2EE technology and not 3rd party stuff and weblogic proprietary stuff? None? wow what a shocker...
Third, even if you tried, would any of your projects work out of the box against any other J2EE server? again, i would think none...
Fourth, how many used any amount of CMP EJBs... how did that work out?

Any return on investment on the mult-millions of pounds investment in these projects??? huh? (oh wait, maybe you just used JSPs, they work)... LMAO

PS WebLogic is a good product (bloated, but still good). It is not J2EE...

Joseph is absolutely right saying there is little component re-use going on. But should Components be the focus of re-use?

I think we should be looking at a higher level of abstraction to get re-use from one project to the next. Take a look at the OMG specification for Model Driven Architecture http://www.omg.org/mda.

With the combination of MDA and Pattern technology developers get re-use out of the abstracted pattern and Business Users get re-use out of the Business Model captured in the Platform Independent model (PIM).

We have a tool called OptimalJ http://javacentral.compuware.com which implements both the MDA standard 100% and Sun's J2EE blueprint patterns 100%. The result is that we can pump out WORKING 2-tier and 3-tier J2EE applications with a fully Struts front end automatically built for you and instantly tested against the bundled Tomcat and Jboss test environment. Of course you still have to do customisation work but all the basic plumbing is written for you and you get to prototype a working application instantly.

I think good J2EE tools and methodologies are here now - try them!

Steve, get yourself a good book and get your hands dirty then you will see the power of J2EE.
I have been developing multi-million pound prjects using J2EE and weblogic for a couple of years and you what things just work when you use java if you are smart enough to know what you doing.
Oh, by the way dont read Sam's teach yourself in 10 mins then come back and say J2EE doesnt work.

What is J2EE anyway? A loose collection of technologies that are at a random degree of maturity and usefullness relative to each other.

There is not a prescribed way of solving a problem using "J2EE", or even evidence you can solve any generally solvable problem using "J2EE" efficiently. You end up using some of it (JSP) and other technologies that you're lucky enough to stumble across (STRUTS).

If you're really really unlucky, you buy into the idea that you should use EJBs and are then likely to fail way before you even get started...

If you really really lucky, you buy into the idea that you should use EJBs and actually succeed.... mostly by not using CMP EJBs or bypassing most of the EJB services (using MVCSOFT for example)

The bottom line is that java and the whole community is obsessed with "neat" and "bleeding edge" stuff, no one wants to build work-horses. So you get "tools vendors" and a bunch of "1.0" level stuff that may or may not work.

Cedric commented that he has lots of Weblogic users that can attest to the use of EJBs... well, where are they? are they scaling using CMP EJBs? LMAO

You might want to take a look at BEA's Workshop environment with its controls architecture. We believe it is a breakthrough for developers.

I think sys-con newsletter is become a MS tool for slagging off Sun and java. This and many recent articles are nothing but a lot of crap, what strikes me is the lack of knowledge on the authors' part and lack of good material on the editors part.
I think its time to click on the "unsubscribe" link.

Bye bye sys-con

it really does you are right, it will never fly

Hi Joseph,

Good piece. I wrote a few comments on my weblog:

http://beust.com/weblog/archives/000020.html

I am horribly upset about the difficulty of reusing Java components.

For every Java tool that has a clean install, there are fifty that put you through the torture chamber.

CLASSPATHs are a stupid mess and I think they are the total root of the problem. When you want to install a component, how do you resolve its dependencies on other components? For example, suppose you write your JDBC app against a specific DBMS because it has unique features you need. Perhaps you also want to leverage a specific JDBC driver for that DBMS. When you set up your installation, how do you resolve the issue of finding the right driver? Do you use existing installs of the driver? Do you install your own copy into some private area and munge your classpath? Or do you supersede existing driver copies with your own?

But on the other hand, the language syntax is also a big problem. "Write Once, Read Never" was coined for C and what's different about Java? Java is horribly unreadable. How can you reuse what you can't understand? Javadoc and code-completing IDEs are a crutch allowing us to ignore the unsavory effects of the language syntax.

Hi Joseph, I wonder what components do you mean. I'm using EJB's, JavaBeans, Servlets, JSP, JSTL, Swing and I have room enough to create my own components, application components. Do you mean we don't have what we need to start building applications? At least, are you trying it? Or are you waiting for those fantastic MS wizards claiming to build your application at a single mouse click?

Once again I will respond by saying - GET A DIFFERENT JOB!! I'm so sick of developer's crying for someone to write their freaking code! The beauty of the Java language is it's level of abstraction. I can write just about anything I need - very quickly. In my opinion there is no need for purchasing components when I can build one myself - and make it scale! Those of you that don't agree need to learn how to spend time designing before coding! If you would do this, you would maybe finally see how great the Java language is!! Why in the @#$@ do I need someone else to decide the spec for me. The only time I should be following someone else's spec is if I'm sharing data with them - and that is what XML is all about! Quit griping and get back to coding you lazy freaks! Sometimes I think JDJ is just writing these articles just to inject controversy into the Java Community! Will you knock it off!!!!!

>. If I want to build a simple process with
>Struts, I now have what seems like
>dozens of options to help me build that >process, but who's willing to market a >component to handle the process
>itself?

we are here for example: http://www.servletsuite.com/jsp.htm

but in general you are 100% right

There are projects like Tapestry that are trying to take a crack at it. They only end up addressing one aspect, in Tapestry's case UI, not the whole issue. Many times the initial learning curve and all the cobbling required to get the pieces working appears to be more trouble than just "inventing it here".