Digital Edition

Leading Java Developers Refute Meta Group Claim That They're "Not Getting Adequate Performance" from J2EE Pundit clearly lack
Leading Java Developers Refute Meta Group Claim That They're "Not Getting Adequate Performance" from J2EE Pundit clearly lack

(January 18, 2002) - Recent reports that enterprise Java has begun to hit bumps in the e-commerce road have been greatly exaggerated, say the editors of Java Developer's Journal.

Responding to public statements made at the beginning of the month by Will Zachmann, vice president of Meta Group Inc.'s open computing and server strategies practice, editor-in-chief Alan Williamson and JDJ's J2EE and J2ME editors - Ajit Sagar and Jason R. Briggs respectively - refute the claim that the recent spate of proprietary extensions of J2EE (such as BEA's new "Cajun" application framework, Oracle 9IAS, or the proprietary extensions added to WebSphere's 4.0 Java app server) signals profound disillusionment with Java's "write once, run anywhere" promise.

"The editors of JDJ are all Java developers and architects," Williamson points out, "So our experience of Java derives from day-to-day, hands-on development with the entire platform - not just from theoretical knowledge like the industry pundits."

"Java has got a lot of mindshare," Zachmann had claimed, "but it remains to be seen if it's going to keep it. Java has to start delivering on the promises if it wants to succeed."

"They (Java developers) are definitely not getting adequate performance with entity beans," he continued, "nor reusability, rapid development or total platform independence... Anyone that is doing enterprise Java development is learning that you don't pick up an application from one application server and drop it on to another without any pain."

But JDJ editor-in-chief Alan Williamson disagrees vehemently with Zachmann. "It's wild statements like these that enrage Java developers," he thunders. "If you conform to the J2EE specification then you will have no problems. As soon as you start relying on libraries from the application server vendor then you are locked in; and of course you are going to have problems porting. But let's not be naive here and think this is isolated to Java; how many times have you run a Windows program only to find a DLL missing? I cite many of the original VB based programs as a classic example."

JDJ's J2ME Editor Jason R. Briggs is equally dismayed by Zachmann's contention that Java enterprise developers all agree that you don't pick up an application from one app server and drop it on to another "without any pain."

"Right," responds Briggs, "So that's why I've just been involved in developing an application that will drop into JBoss, WebLogic or JRun by tweaking a line in a single configuration file (and to WebSphere, by changing the deployment descriptor slightly)."

"Where's the pain in that I ask you?" Briggs continues, adding: "I've got reusability, rapid development - and platform independence, when and if I need it."

Zachmann had also asked, "How do you distinguish between the notion that Java is completely standardized and the notion that people are going to compete to sell Java platforms at the prices that they've been getting them for? It is unrealistic to expect anything else."

But JDJ's J2EE Editor, Ajit Sagar, takes issue with Zachmann. "I fail to see the connection betwen proprietary extensions, vendor value-added features and the longevity of Java," says Sagar, completely refuting Zachmann's linking of the two.

"A better way to analyze vendors' natural extension to the Java platform," he points out, "is to view it as the next stage in Java's evolution. About four years ago HP had come out with a different implementation of the VM than Sun. Obviously this didn't kill Java. To say that vendors' initiatives to extend Java is shortening its lifecycle is absurd."

Sagar continued, "What this means is that Java is getting commoditized. Vendor lock-in is a relative phenomenon. If application server vendors were not providing value-add on the Java platform, there'd be no need for them to exist. That 's what I would term as the death of Java, because there wouldn't be any market around it. The only Java you would see would be from Sun."

"Granted that the trend in the industry to provide proprietary frameworks increases vendor lock-in," concedes Sagar. "But then, how many times do you change an application server once you have selected one? And there's still the base platform that can be ported to other application servers. It's not as if you have to develop everything from scratch. The wealth of the Java platform's ever-expanding arsenal of standard APIs remains the same across all platforms."

Does Java have to "start" delivering on the promises of WORA if it wants to succeed, as Zachmann contends? No, say the editors of Java Developer's Journal, with one voice...because it already is doing just that.

About Java News Desk
JDJ News Desk monitors the world of Java to present IT professionals with updates on technology advances, business trends, new products and standards in the Java and i-technology space.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 3

1) One thing I can not only assert but prove: I've written applications, using the command-line J2SE SDK on desktop NT 4.0, ftp'ed (as .jar) same to the IBM System 390 and run successfully application same ***without re-compile*** from the Unix System Services command-line. That's portability...PERIOD.

2)It really IS the model, not the language...Java's real power is implementing the OO model. Speaking from experience, Java's reputation will undoubtedly be unfairly tarnished by a spate "Java-BOL" applications as Java is mis-applied to "fit" archaic data models. I suspect a lot of the performance problems quoted in this thread relate to that issue. Currently, in the middle of implementing a multi-year, multi-million dollar so-called "replacement" for a flagship system in the area of criminal corrections, I've come to suspect most tech and non-tech management will never really embrace the underlying examination and work required to properly implement (or re-implement) a truly object-oriented (viz. object-based) system. Commercial system "builders" like IBM don't use the canonical OO development model because they can't keep their people utilized profitably; they put together a project they want the DB2 data modelers working early instead of (properly) waiting until the object model is derived and then mapping this logical model to the physical model. The unfortunate side-effect is your relational model becomes the de factor object model, resulting in brittle, poor-performing design.

Mr Zachman does not know whereof he speaks regarding Java's WORA capabilities.

Granted, WORA does not come "free". You have to architect your code so that it can run anywhere, but with Java this is not a difficult task, as it is with so many other languages.

Java is the first language I have seen that allows portability from embedded devices through to massive servers, without changing a line of code.

For example, I have written an open source GPS (Global Positioning System) access library in Java. It runs unchanged on servers, PC's (both Windows, Mac & Linux), PDA's (Palm, PocketPC) and even on embedded devices (such as those based on aJile's Java chips).

Speaking of embedded Java. Know of any other languages that are implemented in silicon and are commercially available and being used in real-world applications? I thought not....


Hi, Mr Zachmann
You are right about COBOL (which I used so many years!).
Among the many available COBOLs there were some (most notably RM COBOL) that would let you achieve full WORA (unles you did some silly things).
RM COBOL does not compile native code but something called "p-code" or "intermediate". That code is "interpreted" by a program (not called "virtual Machine").
So I was able to develop, test and compile in a PC and distribute the "executables" ("interpretables") to PC networks and UNIX systems.
Programs run very fast. Really fast.
Of course, if you are going to fill screens with fractals then Java or any other interpreted language won't be the right choice.
It would be like trying to run Indianapolis with a Jeep 'cause it can run everywhere: it simply is not the right choice.
Juan Lanus

If you're going to develop with J2EE, you must first understand the architecture specification so that you know how and when a vendor's proprietary extensions will affect portability. We have successfully, on several occasions, deployed an ear file simultaneously on WebSphere and WebLogic while developing using Sun's RI. Not to mention also switching database servers whenever we like.
And EJB performance? Get real. What could you possibly be comparing it to that has remotely comparable scalability?
Mr. Zachmann, if you don't know what you're doing, stop trying to speak for those of us who do. I recommend that you heed Mark Twain: "It is better to keep your mouth shut and appear stupid then to open it and remove all doubt."
Yes, Alan, you are absolutely correct. I am thoroughly enraged by such a blatant abuse of ignorance.

At last, we are in agreement! Yes, I wholeheartedly agree with you that the marketing blitz associated with Java and J2EE has reached ludicrous proportions. To assert that all that J2EE requires programmers to do is focus on business logic and nothing else is an absurd claim. The biggest challenge J2EE faces is the intrinsic complexity of the underlying technologies and the associated steep learning curve, lack of solid tools that can shield the complexity from the developers (it's improving) etc. but with the right background and experience J2EE can indeed produce a powerful and elegant solution. But obviously, there are problem spots and like everything else, it's no holy grail of enterprise computing as it has been made out to be. No technology is.

Best Regards,

>> to expect 'ready portablity' in the sense of 'taking one app from one app server and drop it in another' is a naive interpretation of WORA at best, and at worst, confusing a languaage with a technology. > In any case, to debunk EJB because it does not regularly deliver performance which some of these traditional TP monitors do is ludicrous. <<

It is not my aim, Roy, "to debunk EJB". My aim is to assess it realistically. There is much value in Java, J2EE, and EJB. That is obvious. There are is also widespread, unrealistic, belief in promises made for it that are not, in fact, fulfilled (not yet, anyway). That is also obvious.

That is all.

All the best,


All of us have time constraints, and I too, have no taste for resorting to name-calling, I'd rather address the issues you have raised and keep my response to-the-point.

Point 1 - about the IBM redbook. I won't argue semantical details such as whether you were trying to _prove_ a point or not, I'd merely point out that even citing the IBM redbook as 'an example of some of the real world portablity issues' is misleading and has no basis, simply because, the J2EE technology has changed vastly between the time the book was published and equally importantly, the app server implementations have caught up with the specs rendering the portability issues mentioned in this book totally moot. These so-called real-world issues you are trying to point to(as per the quoted book) are non-existent, and therefore, invalid. Having said that, I should also point out that there are other issues with portablity, issues such as migrating app-server specific deployment descriptors but that's merely a fraction of the entire codebase of any typical J2EE project. You have to recognize that J2EE, apart from being a series of specifications, also lays down extensive APIs which all these app server vendors have to conform to, and implement. If programmers really care about portability then all they need to do is use these APIs and make sure they don't end up using any app server specific APIs or extensions. And even though there are some app-server specific features and extensions that can come in handy (specially in the areas where the specs themselves are evolving) it is entirely possible to avoid them and still deliver a robust, well-performing enterprise scale application. And I speak from real-world experience. It is important to recognize that J2EE does not dictate that administration and deployment of an app be the same across app servers, what Java and J2EE allow us to do is write applications that would run on all platforms and within all J2EE containers without really any significant changes (and virtually no change to code, I emphasize). The language (Java) buys me platform portability and the technology (J2EE) gives me code standardization across containers - the procedure for installing, deploying or administering the app would definitely vary across app servers - to expect 'ready portablity' in the sense of 'taking one app from one app server and drop it in another' is a naive interpretation of WORA at best, and at worst, confusing a languaage with a technology.

Point 2 - I was disappointed that you did not highlight any EJB specifc issues and instead, chose to discuss what essentially amounted to C++, Java performace comparisons. As for the enhancements in the EJB2.0 specs, the ability to 'call by reference' was nothing new, it was already there, albeit as app-server specific extensions in most of the app-servers in the pre EJB2.0 days. That's missing a vital feature of the enhancements - the idea of local interfaces goes far beyond merely enabling call by reference. The design implications are far-reaching which allow a great deal of flexibility in designing the object model which was absent in 1.x days. In any case, to debunk EJB because it does not regularly deliver performance which some of these traditional TP monitors do is ludicrous. There are EJB applications that perform very well in high-availability, fail-over environments (for the sake of fairness, these HA, FA facilities are extensions provided by any self-respecting app server) specially the ones that do not use pre EJB2.0 style entity beans. J2EE containers may have some distance to go before they match the reliability/availability of the traditional TP monitors, you have to keep in mind the technology is maturing - how long has the TP monitor technology been around? And most importantly, from a productivity standpoint, would you want to have your programmers implement an enterprise-scale web-based application in C,C++ and hand-roll the logic of concurrency management, transaction management, secutity management etc and that too, in a non-standard, non-portable way, not to question the reliability and robustness of such home-grown implementations. That's the biggest benefit of using J2EE and understanding that will go a long way in making meaningful comparisons rather than making peripheral comments and getting confused between the capabilities of a language and a technology built on top of that language in the process.

Best regards,


Unfortunately, I really do not have sufficient time to debate all these matters in as much detail as I (and you, apparently) would like. So I will try to reply but succinctly to the key points you raise.

To start, I did not cite the IBM Redbook in order to PROVE a point, merely as an example (which I explicitly noted was rather out of date) of some of the real-world portability issues. I've addressed that topic in my immediately prior reply to Jason as well. I am not trying to prove the point that, in practice, ready portability of non-trivial enterprise applications is proving VERY elusive (depite what amount to repeated claims that WORA virtually comes automatically as a benefit of using a J2EE application server). It does not. If you perfer to believe otherwise, I am content to leave you to your belief.

As to my contention that EJB 2.0 alleviates but does not eliminate EJB preformance issues, that is also true. EJB 2.0 adds what amounts to "call by reference" capabilities for method invocation within a common container, cutting through a lot of the overhead otherwise incurred. That is an improvement over EJB 1.x. In specific instances it is now possible to achieve quite good performance, assuming best practices are used in the impementation. However, on average, a J2EE application server implementation STILL will not deliver the sort of performance for high volume transactional applications that is routinely achieved on more traditional platforms (e.g. CICS, Tuxedo, monolithic applications written in C or C++ on UNIX systems, etc.). That is not to say that there are not other advantages to the Java platform. But it still has some way to go before matching the perfomance of these older platforms.

Finally, though, let me also note that I am generally less inclined to respond to folks who, instead of simply engaging the issues, indulge in what amount to arguments ad hominem, for example, by claiming that the person who does not agree with them must be technlolgically cluesless and then trying to invent little quiz question to try to 'prove' the alleged cluelessness of their opponent. That is a game I do not fell compelled to play.

All the best,


>> I think we'll have to agree to disagree on that one. Because I've ported a non-trivial app from one server to another (a well-designed one, admittedly). But I guess you really have to see it (or do it) yourself before you can believe the hype. ;-) <<


Please do not misunderstand me. I'm not saying that it is impossible to get useful portability across app servers. What I am saying is that, in fact, many corporate developers and ISVs are not getting such portability.

In part, this is a matter of simply not knowing how, but it is not only that. Real-world, non-trivial enterprise applications, for example, do not just involve nice new Java code. They requirce complex interaction and integration with legacy applications. This typically requires making extensive use of functionality that is provided as part of a J2EE application vendor's "enterprise" suite that are a) outside the J2EE spec and b) specific (i.e. proprietary) to that vendor's suite.

So while in theory the nice new Java code can be written to be portable (provided, of course, that one follows appropriate best practices, which many, most even, do not), but the in practice the application as a whole, is anything but "write once run everywhere." In practice, the application ends up deeply embedded in stuff that is specific to a single vendors (J2EE "Enterprise" suite) product.

This is not just a matter of BAD practices however. It is often required in order to get needed integration or to achieve needed levels of quality of service (a.k.a. performance).

All the best,


Still, entity bean performance most definitely has been a problem (a problem that is, by the way, alleviated but not eliminated by EJB 2.0)

Looks like Mr. Zachmann has this habbit of dropping seemingly knowledgable references from time to time - now it's the turn of EJB2.0 :)

Would you please care to elaborate on the point you made above, Mr. Zachmann? Specifically, how performance still remains such a problem with using EJB2.0 style entity beans (strictly speaking CMP entity beans)?

Let me assure you, I'll reply to your post point-by-point. The point you made would have been entirely valid for EJB1.1 CMP/BMP entity beans but doesn't apply any more to EJB2.0 CMP entity beans. However, I'd be the first one to acknowledge that EJB is a challenging subject to grasp, and hence, is subject to abuse in the hands of an inexpereinced programmer and performance usually ends up as one of the biggest casualties. And like everything else, there are places where entity beans should not be used and there are places where they can make your life much easier. Being able to make that judicious design decision is what makes a good designer/programmer, not poring through some online articles and waving hands in the air.

I will look forward to your reply. And btw, I'm still waiting for the reponse I wrote regarding the impressive quote you once made about an IBM redbook, which, according to you, clearly demonstrated how difficult it was to port a J2EE app from one app server to another.

Best Regards,

Hi Will

I think we'll have to agree to disagree on that one. Because I've ported a non-trivial app from one server to another (a well-designed one, admittedly). But I guess you really have to see it (or do it) yourself before you can believe the hype.

Nice talking to you Will.


I can't believe the number of programming noobs out there. EVERY language has its strengths and weaknesses. Java happens to offer a good comprimise between WORA, reusability, maintainability, performance, learning curve, etc.

You'd be hard pressed to find a language that does as well as Java across the board. Java is not perfect, but no language is. I've coded everything from 80486 assembler, C, C++, VB, REXX, PERL, PASCAL, BASIC, and Java. They are all great and they all suck too.

I build web applications for a living, and Java serves me very well. We develop on Win2k boxes, and test on UNIX boxes (our customers typically deploy on UNIX boxes). It's a piece of cake to do this and we crank out complex web apps that satisfy our customers as fast as any Microsoft shop ever could.

I use to be religious about this stuff but now I just view things as tools to help me get a job done. Currently, Java is the best tool for building robust web applications, in my experience. Microsoft has some nice advantages, but they have some seriously bad gotcha's. Play with whatever you like, but I know Java gets the job done.

And yes...EJBs have a ways to go. Please do not lump in your EJB problems with J2EE since J2EE is more than just EJBs.

>> You may very well have been somewhat tarred and feathered with a brush that should've been reserved for the writer of the article, and I use the term 'article' very loosely. But your remarks definitely rankled in a way that some of the other sources quoted didn't. > Case in point: "They are definitely not getting adequate performance with entity beans, nor reusability, rapid development or total platform independence. The actual ability to take a complex application from one J2EE application server vendor's product to another is just not happening." <<


Well, first of all, that particular 'quote' is one where I don't think I've been quoted 100% verbatim and/or somewhat out of context. Still, entity bean performance most definitely has been a problem (a problem that is, by the way, alleviated but not eliminated by EJB 2.0) and there is no uestion but that, in practice, J2EE development is anything but rapid, does not achieve the easy reusability promised, and y does not achieve anything like 100% platform independence for non-trivial applications.

The last sentence attributed to me above overstates the matter somewhat, but the truth is that non-trivial enterprise applications are NOT typically readily portable from one vendor's application server to another.

All the best,


William F. Zachmann


You may very well have been somewhat tarred and feathered with a brush that should've been reserved for the writer of the article, and I use the term 'article' very loosely. But your remarks definitely rankled in a way that some of the other sources quoted didn't.

Case in point: "They are definitely not getting adequate performance with entity beans, nor reusability, rapid development or total platform independence. The actual ability to take a complex application from one J2EE application server vendor's product to another is just not happening."

I'd like to take a moment to address those points one-by-one, in light of my own experience.

I might be inclined to agree regarding entity beans, since I usually tend to use session beans and don't have a lot of experience with the former. But there's the crux -- because I don't have a lot of exp. with entity beans, I can't really comment on their performance. And before you ask, yes, I get excellent performance out of session beans.

In terms of reusability, that's a design and dev. issue for any language, not just a Java issue (as you're no doubt aware). If your architect doesn't have a clue, you're not going to end up with reusable components whether the language is Java or C++ or or VB or anything else.
Just my personal opinion, but if you mean "not reusable" in terms of some kind of EJB component marketplace, then I don't consider that a huge negative. I've never worked for any company where they considered buying in pre-developed business components of this type -- perhaps other companies do, but I don't personally know any.

Rapid development? Don't know what your point is here. Knocking up a home and remote interface for an EJB is hardly a time-consuming process. Perhaps it's slow to get started, but after your team has got over the initial hurdle, development is very quick from my experience.

Total platform independence? I've seen that in action a number of times. If I use proprietary extensions, platform specific code, then of course I won't get that immediate portability -- but I've just finished working on a project (large-scale, e-comm, financial system) where portability won't be a problem simply because we thought about it in the beginning and made the decision not to go down any avenues that tie us in. That hasn't meant limiting the application in any way, mind you.

I apologise on behalf of JDJ if you feel you've been made the villain in this, but as I said your remarks did seem the most cutting, and in our opinion, without good reason (the writer's fault, and not yours I'm starting to think).

Kind regards

Are you aware that .NET server is still at beta 3? I don't believe you when you tell me that your customer is happy that you created an application for them that will run on a beta server.

Feedback Pages:

Subscribe to the World's Most Powerful Newsletters


ChatOps is an emerging topic that has led to the wide availability of integrations between group cha...
As DevOps methodologies expand their reach across the enterprise, organizations face the daunting ch...
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being soft...
You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know ...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every ...
The cloud era has reached the stage where it is no longer a question of whether a company should mig...
The need for greater agility and scalability necessitated the digital transformation in the form of ...
In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an over...
Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection...
In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and ...
While some developers care passionately about how data centers and clouds are architected, for most,...
"Since we launched LinuxONE we learned a lot from our customers. More than anything what they respon...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily ...
"As we've gone out into the public cloud we've seen that over time we may have lost a few things - w...
In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Ser...
Sanjeev Sharma Joins June 5-7, 2018 @DevOpsSummit at @Cloud Expo New York Faculty. Sanjeev Sharma is...
We are given a desktop platform with Java 8 or Java 9 installed and seek to find a way to deploy hig...
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis too...
"Cloud4U builds software services that help people build DevOps platforms for cloud-based software a...
The question before companies today is not whether to become intelligent, it’s a question of how and...