Article:
  Cat Fight in a Pet Store: J2EE vs. .NET
Subject:   Comparison should have stopped on Page 1.
Date:   2001-12-21 15:15:06
From:   calvida
You had me up to the point beyond the assertion that the "experimental flaws" which invalidated the performance claims of Microsoft were grounded in the failure to replicate the Oracle optimized implementation in the Wintel envirnoment. This seems a valid claim (Although, as you seem to imply, by no means does it bias the results in .Net's favor over J2EE. "The differences might be real, but we just can't tell." Performance differences may well be exacerbated in the Wintel incarnation of Oracle/J2EE).


Your further claims are more problematic. You make much of the fact that the implementations support different sets of "nonfunctional" requirements, especially the J2EE emphasis of portability over performance. By spinning the question this way, you have set up criteria that effectively does away with the significance of performance measurements entirely. As you say "if approach X satisfies my higher-priority criteria, will it be fast enough?"


Apparently your higher-priority criteria is mostly subsumed in the ideal of portability, not the "best practices, design patterns, and architectural ideas" that were the stated goal of the Pet Store Exemplar.


Framed in this way .Net is the loser always because of its very nature, not because of any particular or general implementation. Why talk specifics at all? .Net is a creation of Microsoft and therefore ineluctably tainted by association with a single OS? What about the ECMA adoption of C# and the .Net framework? Do other ISVs have to build their own CLR implementations in order for .Net to be perceived as open and portable?


You imply that J2EE is inherently superior because it's implementation is not database nor OS specific. And that .Net is somehow corrupted because its implementation is specific to SQL server on Intel.


Unfortunately platform portablity is more often a specification overkill, as you rightly point out. All the performance optimizations you suggest (in your "springboard" project and in the links in the reference Sun pages, all depend on eliminating the generic implementation of the Data Access Objects, and therefore, of the portablility of the application.


Just as the performance of the J2EE implementation can be modified at the expense of portablity, the .Net implementation can be made more portable at the expense of performance. Doubtless Data Objects can be forged in .Net that are at least as abstract as those in J2EE. Stored procedures can be done away with, similar results can be forged in a more generic implementation of SQL (although the use of store procedures may be an interesting question with regard to design patterns and best practices, which goes unexamined). With objects/components, much is possible.


Your real theme here is the inverse relationship between portability and performance, a relationship that is independent of the existence or "inherent" superiority of J2EE or .Net.


I think you make an unclear distiction between the fact that Oracle addressed "performance bugs" that is, somehow, not the same thing as "tuning" the application.

Full Threads Newest First

Showing messages 1 through 1 of 1.

  • Comparison should have stopped on Page 1.
    2001-12-21 22:14:01  deanwampler [View]

    I think you misunderstood my intentions on a few points. By raising the issue of "non-funcational" requirements, I was trying to emphasize the point that both implementations make or don't-make optimizations based on different choices about portability, etc. My point wasn't to create an excuse for rejecting any and all claims of .NET superiority, but rather to emphasize the point that a valid comparison must compare two things that address the same objectives, as much as possible. Otherwise, the possible conclusions from the comparison get muddled by the many differences. A good experiment always eliminates as many differences as possible.

    If the same sets of compromises/design choices are made in a .NET and a J2EE implementation, then the comparison is much more meaningful. If .NET wins, then fine with me; I want the best technology available and I'm not so anti-Microsoft that I can't acknowledge things they do right. I'm really not a big J2EE partisan, especially if I perceive that the Java community is growing smug. I consider it more important to be objective when making technical comparisons. I thought I complemented Microsoft when I discussed their front-end architecture, although I'll admit that my wording was perhaps a little tentative, more out of a lack of thorough familiarity with .NET than for any other reason.

    I don't consider a portable, platform-neutral system inherently superior, because there are situations where it is overkill and therefore "bad". How many projects have collapsed under the weight of such good intentions? However, a good system should give me the option, should I need it. (As an aside, in my experience, designing for portability tends to create better software anyway, even if you don't need the portability. I did perhaps hint that Microsoft's historic indifference to portability has lead to excessive coupling between components, which in turn has lead to more fragile systems.)

    So, I regret that you read too much bias in the article. If I was biased, it was against misleading comparisons. Of course, Microsoft is by no means alone in doing this sort of thing.

    I'm still hoping someone with the time and resources will do a .NET vs. J2EE comparison that will really give people the information they need to make informed choices, both between .NET and J2EE, and in the subsequent architecture and design activities.