Related link: http://java.oreilly.com

Here are some new O’Reilly Java books to consider in your Holiday shopping plans:

NetBeans: The Definitive Guide

As the Java programming language has increased in both functionality and complexity, developers have demanded more of their program editors. Gone are the days when a simple visual editor is sufficient for even small programming projects. While there are numerous IDEs available today for use by Java developers, one stands above the rest, not only for its functionality, but for its extensibility: NetBeans.

In NetBeans: The Definitive Guide, you’ll find out how to use this IDE to its fullest, making your Java programming more efficient and productive than ever before. You’ll understand the basics of the IDE, and quickly be utilizing the various editor and explorer windows. You’ll also master many of NetBeans advanced features, and be working with XML documents, CVS repositories, Javadoc trees, and web applications, all within the NetBeans framework.

In addition to teaching you how to use the existing features of NetBeans, this work goes on to cover developing additional modules for NetBeans. Through this instructional portion of the book, you will master the NetBeans APIs, and learn how to enhance NetBeans for your own specific needs. Whether you need to add customized behavior to handle your proprietary file formats, or want to redistribute NetBeans as a proprietary product, NetBeans: The Definitive Guide will allow you to master this open source IDE and all of its advanced features. Whether you are an enterprise developer looking for an IDE that can handle your complex program tasks, an open source developer looking to integrate NetBeans into your own visual projects, or a manager trying to maximize your team’s development potential,NetBeans: The Definitive Guide is the book for you.

Return to NetBeans: The Definitive Guide

Programming Jakarta Struts

Web tier frameworks have really taken off in the past year or so. Developers who used to spend hours and hours writing low-level features have realized the enormous benefits of using well-written frameworks to build the presentation tier so they can get to coding the “good stuff”, the business logic at the core of the program.

The Struts Framework, originally created by Craig R. McClanahan and donated to the Apache Software Foundation’s Jakarta project in 2000, has become one of the most popular presentation frameworks for building web applications with Java Servlet and JavaServer Pages (JSP) technology. It encourages application architecture based on the Model-View-Controller (MVC) design paradigm, colloquially known as the Model 2 approach.

As popular as Struts is becoming, the online documentation is inadequate, focusing on the most basic functionality and leaving out information crucial to developers writing today’s complex web applications. O’Reilly’s Programming Jakarta Struts was written by Chuck Cavaness after his internet company decided to adopt the framework, then spent months really figuring out how to use it to its fullest potential. He calls the books, “the culmination of lessons learned (the hard way) during the building of our application.”

Readers will benefit from the real-world, “this is how to do it” approach Cavaness takes to developing complex enterprise applications using Struts, and his focus on the 1.1 version of the Framework makes this the most up-to-date book available.

Programming Jakarta Struts covers:

• An overview of the concepts involved in writing web applications
• Detailed installation and configuration instructions to get Struts up and running quickly
• A thorough discussion of how Struts implements the Model-View-Controller pattern, and how to interface with that pattern in your own applications
• JSP and Jakarta Tag Libraries for authoring complex web pages
• Logging, Validation, and Exception Handling with Struts
• Using the new Struts template framework, Tiles.
• Writing internationalization and localization code using Struts
• Practical, real-world best practices for web applications

Craig McClanahan, originator of Struts, says of the book, “One thing a lot of open source packages lack is a comprehensive guide to all of the features — something that goes far enough past “hello, world” to get you into solving real application design problems, and it looks like you’ve hit just the right level for a lot of people.”

Return to Programming Jakarta Struts

Java Swing, 2nd Edition

Swing is a fully-featured user interface development kit for Java applications. Building on the foundations of the Abstract Window Toolkit (AWT), Swing enables cross-platform applications to use any of several pluggable look-and-feels. Swing developers can take advantage of its rich, flexible features and modular components, building elegant user interfaces with very little code.

This second edition of Java Swing thoroughly covers all the features available in Java 2 SDK 1.3 and 1.4. More than simply a reference, this new edition takes a practical approach. It is a book by developers for developers, with hundreds of useful examples, from beginning level to advanced, covering every component available in Swing.

All these features mean that there’s a lot to learn. Even setting aside its platform flexibility, Swing compares favorably with any widely available user interface toolkit–it has great depth. Swing makes it easy to do simple things but is powerful enough to create complex, intricate interfaces.

Java Swing, 2nd edition includes :

• A new chapter on Drag and Drop
• Accessibility features for creating a user interface meeting the needs of all users
• Coverage of the improved key binding infrastructure introduced in SDK 1.3
• A new chapter on JFormattedTextField and input validation
• Mac OS X coverage and examples
• Coverage of the improved focus system introduced in SDK 1.4
• Pluggable Look-and-Feel coverage
• Coverage of the new layout manager, SpringLayout, from SDK 1.4
• Properties tables that summarize important features of each component
• Coverage of the 1.4 Spinner component
• Details about using HTML in components
• A new appendix listing bound actions for each component
• A supporting web site with utilities, examples, and supplemental materials

Whether you’re a seasoned Java developer or just trying to find out what Java can do, you’ll find Java Swing, 2nd edition an indispensable guide.

Return to Java Swing, 2nd Edition

Related link: http://www2.theserverside.com/home/thread.jsp?thread_id=16689&article_count=6

Posted by Jordan Zimmerman on TheServerSide.com:

“A recent research note from two analysts at the Aberdeen Group calls open-source software and Linux distributions the ‘2002 poster children for security problems.’ Of the 29 advisories issued through October by the CERT Coordination Center at Carnegie Mellon University in Pittsburgh, 16 of them addressed vulnerabilities in open-source or Linux products.”

What’s your experience with open source software and security issues? What do you think of these findings?

Related link: http://www2.theserverside.com/home/thread.jsp?thread_id=16653&article_count=1

Posted by TheServerSide.com’s Floyd Marinescu:

“An interview with Marc Fleury, founder of JBoss, has been posted on theopenenterprise.com. In the interview, Fleury talks about the history and value of JBoss, claims that vendors are focusing on integrated software stacks because JBoss crippled their ability to make money on appservers, and discusses JBoss’ goal to become a monopolistic but responsible provider of Web infrastructure.”

Related link: http://www2.theserverside.com/home/thread.jsp?thread_id=16656&article_count=1

Posted by TheServerSide.com’s Floyd Marinescu:

“‘J2EE has it all over .NET,’ said James Gosling at a panel yesterday at the SD East 2002 conference. ‘It’s more feature-complete, more mature, and what .NET has going for it is a marketing budget only God can dream of. .Net is a product from a company. J2EE is a market.’ .NET platform support and the ‘embrace and extend’ strategy were also debated in a panel at Comdex 2002.”

What do you think of James Gosling’s charge?

In his article on the JDJ website, Alan Williamson talks about his recent run-in with a potential author and his reaction to the author’s attempt to “show off their superior knowledge by dazzling our editors with fancy acronyms and big words.”

I’m not going to stand here and try to defend this nameless would-be author. Instead, I want to try and raise an issue that’s been bugging me for a number of years now, pretty much ever since the canonical patterns book, “Design Patterns” (also referred to by us design patterns snobs as the “GOF”, or “Gang of Four” book–referring to the four authors that contributed to it) shipped back in 1995. Specifically, I want to address the huge misunderstanding that emerged through the industry about what design patterns are, what they were intended to do, and why they’re still important, all hopefully without any trace of snobbery.

Design Patterns

All references to Christopher Alexander and his work within architecture aside, a pattern is essentially a tuple of four things:

• A Problem This is intuitively one of the easiest parts to understand: what obstacle is in the way of producing an efficient/elegant/powerful/whatever design?
• Forces or Context surrounding the Problem No Problem exists in a vacuum, however–there is always a surrounding context or set of constraints that make Problems different within different environments. For example, a problem might be to “construct an object without directly invoking its constructor”. However, the context varies wildly–who should be driving the construction, the user of the object, or the framework surrounding the object itself? Are there constraints on invocation (such as memory or time)? Is there a particular need (such as runtime compositionability, also common referred to as “plugins”)? This is quite possibly the most important part of the pattern definition, even more so than the problem itself.
• A Solution Simply defining a problem without a proposed solution is called “whining”, and isn’t very useful in the long run, except as an immediate transitory state to creating a Solution. :-)
• Consequences yielding from that Solution Again, this is critical to understanding the patterns community’s goals for patterns. We don’t want to pretend that a given solution will be a one-size-fits-all solution. “Every action yields an equal and opposite reaction”–this is true for programming as well as physics. Optimize for speed? Take a hit in memory footprint. Optimize for space? Take a hit in speed. Trying to optimze for both? Take a HUGE hit in maintainability. Understanding the consequences of a particular pattern, both positive AND negative, is key to understanding of the pattern in question helps solve your particular problem.

Nothing more, nothing less. But, as with many things simple, the result is quite powerful.

This isn’t to say that patterns are set in stone, however–far from it. A given pattern can (and should!) always be tailored to take into account the context in which the problem shows up. For example, the classic Factory Method (ask a method to build an object for you so you remain entirely decoupled from the actual object type constructed) shows up in a couple of varieties, one of which has the caller pass an argument in to help identify criteria or an opaque identifier to help the Factory Method determine which type of object to build. For those who did COM, this was most easily seen with CoCreateInstance(): pass the CLSID of the kind of object you wanted, and the appropriate type (of the appropriate version of that type) would be constructed and handed back. The Factory Method as displayed in the GOF book doesn’t use this–but it doesn’t change the pattern, whether the parameter is there or not.

In of itself, so far, patterns don’t sound particularly useful–there’s no mention of “reusability” or “reusable code”, there’s nothing tangible I can put my hands on and use immediately, and it’s a fair criticism of the patterns community that we could never quite figure out what to DO with all these patterns we’d cataloged. It’s not like I could put the GOF book into the hands of junior programmer and suddenly make them a better programmer. Instead, the GOF book seemed (at least in my experience) to resonate most deeply with those programmers who’d “been there” once or twice before, found a few patterns they recognized, and
were able to even refine their code based on some of the consequences they hadn’t realized they’d accepted when building it. Once they’d done that, they were hooked–they suddenly started devouring the book and seeing patterns show up everywhere. They could recognize when they’d seen this problem/context before, and could evaluate which pattern to apply to the situation. On top of this, we now had a language, a lexicon, of new terms to help us describe systems at a higher level (which Williamson points out in his article).

What happened, however, was that many newcomers to the concept of patterns saw only code listings and assumed that patterns were just objects writ large. They started looking for “reusability” at a code level, rather than at a design level. Alan falls prey to this somewhat himself, likening “patterns” to “data structures”. On one level, he’s right–a pattern typically isn’t something we “invent”, but “mine” or “discover” lurking in the code. It’s an attempt to codify something so that by giving it a name, we can define it and get to understand it better. (If this sounds very Zen-like, it is–several noted patterns gurus started getting into a very abstract and philosophical space that tended to lose any but the most dedicated patterns enthusiast. Personally, while I applaud their willingness to try and understand all this at a deeper level, I try to keep my patterns usage more concrete.)

But where Alan falls short is to recognize that it’s not the *code* that’s important, but the understanding of the context and consequences of using that code. He cites the Singleton as an example of a pattern that we’ve all probably used numerous times. But what’s the difference between a Singleton object and static methods on a class? Why use the Singleton? Or, in other words, what are the consequences, positive and negative, of using the Singleton as opposed to “regular” static methods on the class? That’s where the power of the pattern comes in.

Coupled with that, tremendous amounts of information can now be carried intuitively with a single word. I can tell you, “Oh, we wanted our thread pool manager to be a Singleton”, and you can immediately infer some knowledge of our design goals, constraints, and the design itself based on knowledge of that pattern, and can in turn suggest or question the design, not the code. We’re communicating at a higher level of abstraction, not reusing code.

Alan goes on to point out that “They’re just repackaging the stuff you’ve been doing for years in a format that can be openly discussed…. I would guess that 9 times out of 10 you’ve used [a pattern] many times and didn’t even realize you were a design pattern follower!” Yes! Precisely! He’s absolutely right. Having said that, though, it feels like this misses the point again–by giving the thing a name, we can describe it and discuss it and codify it. It’s not just a way of pointing out the code–it’s a way of allowing us to see past the code to see the higher-level abstractions within the design.

“Patterns” Everywhere

I don’t want to seem like I’m bashing Alan or his level of expertise or experience. It’s an absolute truth that some have held the idea of patterns as a hatchet over people’s heads for some time now, leading many to believe that patterns are this mystical cult or exclusive club that only those born with the right birthmark can get into. I’ve met several of those design patterns snobs, and he’s right: they just make your skin crawl with their condescending attitudes and lip-curling sneers of disdain. When I find one, I usually take great delight in drilling him on the excrutiating details of pattern after pattern after pattern. :-) Of course, I’ve also met my share of EJB snobs, COM+ snobs, and even container-classes snobs (”We wrote our own, HIGHLY-tuned, HIGHLY-efficient set of collection classes, and it only took us two years to do it…..”). Snobs in general suck.

What truly makes this story worse, however, was that just as the patterns world was starting to build some critical mass, the marketing folks got hold of the name, and diluted the idea of what a pattern was back into “code reusability”. Worse yet, patterns began to be misused and misinterpreted–quite probably the worst offender here was Sun, with their “design patterns” in JavaBeans (sorry, guys, using get/set method names to define a property isn’t a pattern) and their “Model-View-Controller” pattern in JSP/servlets[1].

As a result, expectations that patterns would cut development time by outrageous percentages were set, and since patterns really had little to do with development time (patterns influence design time, not development/implementation), the expectations weren’t met and yet another interesting thing in Computer Science fell by the wayside. Today, patterns are relegated to the dustbin of “passe technologies”. Mention that you’re interested in using patterns or use a pattern by name as part of your discussion, and suddenly you’re a “design pattern snob”.

Patterns Redux

Patterns are still important, because all marketing hype and failed expectations aside, they’re still useful as a means of communicating design elements between software architects and developers. The JavaBean event notification system is one giant exercise in the Observer pattern. EJB uses Interception[2] to provide its runtime services. The Comparable and Comparator classes are two variants of Strategy. And so on. As is typical in this industry, it’s easy to dismiss something after it’s been “passed by” in the media. Doing so here would be a mistake.

I heartily invite ANYONE, regardless of language or environment, to go pick up the GOF book. In particular, however, I’m going to point people the first 50 pages of the book, not the catalog of patterns that form the rest of the material. That first 50 pages explains the “Zen” of what patterns were trying to accomplish, and how knowledge of patterns can be used on a real-world project. The catalog of patterns is interesting, certainly, but numerous catalogs have sprung up since. Understanding the how and what of patterns is far more fundamental.

(And Alan, if you’re reading this, next time somebody tries to play the design patterns snob, ask them to describe the intent of the Folded Pizza pattern.)

[1] Certainly, the formerly-named “Model 2″ design described by the old JSP spec is a pattern–it’s just not MVC. In fact, the GOF book broke MVC down into a simpler pattern, the Observer pattern, based on the idea that MVC provided updates to the Views whenever an update was made to the Model. Making a change to the Model in turn told the Controller to update the View. In the world of HTTP, changes to the Model (the JavaBean) aren’t seen in the View (the rendered JSP output) until it’s explicitly requested. Model 2 is more accurately analogous to the “Presentation/Abstraction/Controller” pattern from “Pattern Oriented Software Architecture, Volume 1″.

[2] Interception is described in “Pattern Oriented Software Architecture, Volume 2″.

Let the flaming begin!

Related link: http://labs.google.com

Peter Norvig, Director of Search Quality for Google, stopped by the Emerging Technology Group in November. He gave a talk that rambled a little bit, but could fairly be described as “Google’s point of view on various programming language related things.”

Good talk. He said a lot of interesting things.

One of the things he talked about was Google sets. From his point of view, the important thing was was this:

• Every now and then someone will stand up and say “We need to have large scale, established and standardized ontologies in order to make sense of the information on the web.”
• But such a categorization is already encoded in the structure of the web, and Google is already using it.
• In fact, the added benefit from such resource-intensive ontology development and characerization is not readily apparent.

Which leads us to Google sets. Google sets is a way to browse the web’s implicit ontology. What you do is simple: you enter some terms which you already think of as instances of some class. Google then returns you what it thinks are the other instances of that class.

Keep in mind that some of the instances it returns are, well, bizarre. Enter the terms “narwhale” and “rhino” and the response list includes, in addition to animals and record companies, the entry “Mailing Lists” (no doubt there’s a reason for this. I just don’t know what it is).

Playing around with google sets is inherently fun. But it’s also a great way to mine the web. For example, here’s a great use. Enter the name of the company you work for. Enter the name of one of its main competitors. Click “small set.”

Voila! There’s how the web classifies your company.

Tell me another great use for google sets.

Related link: http://industry.java.sun.com/javanews/stories/story2/0,1072,48977,00.html

EJB Solutions, Inc. announces the immediate availability of Out-of-the-Box™ 1.0, a fully integrated, documented, and tested distribution of over 50 Open Source projects targeted at Java™ developers. As companies deal with the current economy, IT departments are looking to Open Source solutions as a way to cut costs.

What do you think of open source Java in-a-box? Would you use it?

Related link: http://thesaurus.plumbdesign.com/index.jsp

What can I say. It’s just stunningly cool. Run it. My favorite applet of all time, I think.

Right now, I’m trying to figure out: if every person is separated by at most 6 degrees from everyone else, and if every film start is separated by at most 6 “film degrees” from Kevin Bacon, is there a similar thing for words in a thesaurus?

For example: Can I reach any word in the dictionary in 12 or fewer steps from “egg” (I got from “egg” to “unimpaired” in only 5 steps. And from “egg” to “uncastrated” in only 6)?

What’s your candidate for the “Kevin Bacon” of the dictionary?

So I migrated home machines the other day. From an antique P-II to a much more modern Athlon. Suddenly, all sorts of programs (like Eclipse– it rocks when it has enough memory and CPU) became much more usable.

As part of the migration, I decided to clean up a few things.
For one, I switched to using Mozilla full-time. It’s vastly better than Internet Explorer at this point (the privacy controls, and the ability to turn off pop-up windows, are marvelous).

For another, I didn’t install Flash.

Am I missing anything? Curiously enough, I don’t think I am. Flash is, apparently, mostly used for advertisements and (to be blunt) crap that has to be animated because that’s the only way you’d pay attention to it.

Maybe that’ll change in the future. But, right now, I’m living life flash-free and loving it.

I did install quicktime, though. Gotta have my move trailers.

Let me know. Is there a reason to have flash installed on my machine?

Related link: http://www.oopsla.org

I just got back from Seattle, where I was at the 17th Annual OOPSLA conference. OOPSLA is one of those hybrid events, where the academic computer scientists and the practioners who actually build this stuff can get together and swap stories about past projects and speculate on future directions in object oriented computing, software design and web services. The proverbial brick hurled into the crowd would bounce off two software architects, somebody from IBM Global Services, and hit a tenured computer science professor. Not that I advised anyone to do this, particularly as I’m a software architect. In general, the ratio of content to product flackage was agreeably low.

So what did I learn? One of the things about writing computer books is that, if you’re a perfectionist like myself, it becomes increasingly hard to let anybody else look at your code. This seems a little bit backward, but the expectation tends to be that you’ll always get it right the first time. I’ve gotten this occasionally in my career, so you can only imagine how Kent Beck must feel. He’s credited with inventing eXtreme Programming and Agile, as well as being one of the major proponents of Test Driven Development. I just write Java books. His point, which I will now twist, was that it’s fine to just make it work, provided that the intent is to make it work better in the next round: one data manipulation doesn’t require an abstraction, but if you need to do it again, refactor. As in sin, intent matters.

Actually, you don’t need to imagine because he mentioned it in the keynote: Kent Beck leaves To-Do comments in his code. Of course, this is a natural part of XP development, not to mention most other kinds. I, and I suspect most architects, believe that good software develops out of both design and experience. Up front planning will help you get much closer to where you want to go, but iterative development, prototypes and a willingness to chop down trees (code) will get you to the best system in the most reasonable amount of time.

This issue was the subject of a panel discussion between a group of “Up Front” architects, advocating covering the walls with UML, and “Extreme Refactoring” programmers, advocating a sit-down-and-code approach. The gimmick was that panelists kept switching sides, sometimes addressing their own points. While it was fun to watch Noted Figures in Software Architecture dart across stage donning and doffing paper neckties, the point, that architecture and refactoring go hand in hand, was obvious to most of the audience in the first five minutes or so, and the panel format perhaps wasn’t the best way to address the real issues, which are the tradeoffs between design and refactoring.

A year or so ago I got the refactoring religion in a big way, and I’ve been periodically tearing through my company’s codebase dealing with the issues that had been put off for another day. It’s an interesting activity the first couple of times, because, by definition, a refactoring means that the system works the same way when you’re done as it did in the beginning. Of course, I usually cheat: I refactor when I suspect I might want to make changes in the future, and where the refactoring will make it easier for me to do that. I’ve even been known to break the cardinal rule of Doing It Right and refactor as I add new functionality, rather than before.

The interesting thing about refactoring in this case is that it’s led the product in question towards a more self-consistent architecture than it would otherwise have had, even though I did a large amount of up-front design work on the current release, which is itself the fourth major iteration of the package (and presumably I’d learned a few things on Iterations 1-3). Of course, if I hadn’t done the up-front design I wouldn’t have had a stable framework to refactor in. If I’d built the system up function by function, I suspect the overall result might have been the same, but it would have taken longer to get the initial code working, and the refactoring process would not have been trivial (although one might say the whole fourth version was just a big refactoring of the third).

So what were the big lessons? Design up front as best you can, but don’t be afraid to switch later. In addition: Don’t cling to particular technologies or languages just because, but don’t switch to the Next Big Thing either. Java and .NET are good for different things, and some of the same things. Don’t fear the TODO comment. Eclipse is cool. Web Services are almost there, but maybe not quite this minute. If you want to get a major standard adopted for billions of dollars a year worth of commerce, keep it as simple as possible. Starbucks in Seattle really is better than Starbucks back east.

I know, I know - a whole week for that? No, I also got to see Bill Gates showing off a Tablet PC and terrifying the program manager running a demo of Microsoft’s testing environment. Worth the trip right there. In all seriousness, there were some interesting presentations, and the papers behind them are available at the event web site. Next year is in Anaheim.

Anybody else go? Anybody learn anything?

Here in northern California and Tysons Corner, VA last year, the well-regarded Computer Literacy Bookstores closed. What does that leave? Well, for those who are looking for techical bookstores that they can actually visit by foot, here are some remaining options:

1. DigitalGuru is a technical bookstore that’s both virtual and real. DigitalGuru has an excellent selection of computer programming trade books for all skill levels. Moreover, they have a good selection of engineering, math and graphics books. To visit by foot or by car, go to 546-3 Lawrence Expressway, Sunnyvale, CA in the heart of Silicon Valley. If you are unable to visit in person, you can go online or likely find them at a major conference near you. That’s because they’re the offical bookstore at several major conferences including JavaOne.

2. nerdbooks.com is, of course, online, but also has a store full of computer programming trade books as well as other books on desktop publishing, engineering, mathematics, networking, gaming and much more. To visit offline, go to 911 Washington Boulevard, Suite # 201, Roseville, CA, east of Sacramento. This and DigitalGuru are the only bookstores focused on just the technical — the guru, nerd and the like.

3. Stacey’s Bookstore is not just a technical bookstore, but a general one as well. However, their technical focus is quite good, especially at their San Francisco store. They also have a store in Cupertino, CA, again in the heart of Silicon Valley.

4. Also, try visiting university bookstores such as the ones at Stanford, U.C. Berkeley, Santa Clara University, San Jose State/Robert’s Bookstore, and more. These stores usually have an excellent selection of computer and technical books.

Well, I think these cover most of the technical bookstores in northern California. Of course, there are excellent technical bookstores elsewhere in California and the U.S. So, if you’re looking for technical bookstores to actually visit by foot (or by car), check out these or others that readers will put forth, below in the Talk Back.

Of these, what is your favorite? You can also nominate a favorite that’s not listed above.

Related link: http://www.jboss.org/talks.jsp

Marc Fleury, is the founder and leader of JBoss. He spoke at the SDForum Java SIG and it was a great talk. Marc’s a very good speaker, he’s got a vision to share, and he has a habit of speaking his mind occasionally.

Why am I mentioning a talk that already happened? Because he’s on tour! Check his speaking schedule. If he’s coming to a town near you, and you’re a Java programmer, you should definitely stop on by and hear what he has to say.

What do you think? Is JBoss headed for world domination?

Related link: http://www.sdforum.org/p/calEvent.asp?CID=950

What with all the fuss over the recent J2EE

“benchmark”
(and, if you don’t know why I put benchmark in quotes,
check out Rickard
Oberg’s Review), it seems an appropriate time to put
a link to
SDForum’s J2EE versus .NET debate, coming on
November 18.

The particulars? Three guys from SUN, three guys from
Microsoft, discussing (errrr…. mock-debating) the relative
merits of the platforms.

Should be informative, should be a good time. And, best of all, the format is modeled after professional wrestling!

Related link: http://www2.theserverside.com/home/thread.jsp?thread_id=16374&article_count=1

Posted on TheServerSide.com by Floyd Marinescu: “A beta release of the J2EE 1.4 SDK/documentation is now available for Linux, Solaris and Windows. Highlights of the J2EE 1.4 release include web services support integrated with Servlets and EJBs, an enhanced Connector architecture with bidirectional integration; standards for J2EE management and deployment; JSP fragments and an expression language; and, a new standard for extending J2EE containers with a pluggable authorization facility… A FCS [First Customer Ship] is expected for Q1 next year, with a final release in Q2/Q3 2003.”

Sun released another early-access version of the JSR 14 “Generics for Java” implementation recently, and can be found at http://developer.java.sun.com/developer/earlyAccess/adding_generics/. (The main JDC page claims that the last release was 1.2, on March 21; that’s incorrect. If you click through the link to the URL above, it reads as 1.3, released on October 30.)

Using the 1.3 release is a bit awkward, since the release itself ships as two .jar files, one for the compiler and another for the java.util Collection classes (properly genericized). This means, unfortunately, that you’ll need to put the javac.jar compiler code somewhere in the bootclasspath of the javac.exe tool when you run it, and reference the collect.jar as part of the bootclasspath when you compile and run the resulting code. The 1.3 release ships with some UNIX and Win32 script/batch files to help ease this pain, but if you’re planning to do any serious work with the release, I’d suggest just writing your own quick-and-dirty JNI Invocation launcher to get all the options in the right place; details on how to do so can be found in a variety of different JNI books, as well as my own (now horribly outdated) Server-Based Java Programming. If I get around to it, I’ll write one myself and post it here.

One nice thing about the JSR EA implementation is that once you get past the compilation phase (and if you don’t use any of the generic collection classes in collect.jar), you can run the compiled code on preexisting VMs–there’s no structural changes to the code made when compiling generics into standard Java classes. So, for example, taking this code:

class Generic
{
  T data;

  public Generic(T d) { data = d; }
}

public class GenTest
{
  public static void main(String[] args)
  {
    Generic gs = new Generic("Hello, world");
    System.out.println(gs.data);
  }
}

and compiling it in the genericized Javac (which I’ll call gjavac from here on out) yields “Generic.class” and “GenTest.class”.

One of the goals for the JSR 14 was “designed to be fully backwards compatible with the current language, making the transition from non-generic to generic programming very easy.” Part of this means that there can be no structural changes to the underlying JVM that will be used to execute the code. (This is in direct contrast to the Gyro release from Microsoft–it patches the CLR to recognize generic types within the runtime. This pretty accurately reflects the differences in philosophy between Sun and Microsoft–Sun believes in “one language”, and Microsoft believes in “multiple languages”.) Sure enough, if we disassemble the compiled Generic class, we see

Compiled from GenTest.java
class Generic extends java.lang.Object {
    java.lang.Object data;
    public Generic(java.lang.Object);
}

Method Generic(java.lang.Object)
   0 aload_0
   1 invokespecial #1 <Method java.lang.Object()>
   4 aload_0
   5 aload_1
   6 putfield #2 <Field java.lang.Object data>
   9 return

As you can see, the underlying data type for “data”, which was represented in the source as the type variable “T”, is a java.lang.Object reference. Similarly, using the parameterized Generic behaves much as you’d expect (once again, consulting javap for a bytecode disassembly):

Compiled from GenTest.java
public class GenTest extends java.lang.Object {
    public GenTest();
    public static void main(java.lang.String[]);
}

Method GenTest()
   0 aload_0
   1 invokespecial #1 <Method java.lang.Object()>
   4 return

Method void main(java.lang.String[])
   0 new #2 <Class Generic>
   3 dup
   4 ldc #3 <String "Hello, world">
   6 invokespecial #4 <Method Generic(java.lang.Object)>
   9 astore_1
  10 getstatic #5 <Field java.io.PrintStream out>
  13 aload_1
  14 getfield #6 <Field java.lang.Object data>
  17 checkcast #7 <Class java.lang.String>
  20 invokevirtual #8 <Method void println(java.lang.String)>
  23 return

The “smoking gun”, as it were, is on disassembly lines 14 and 17: the runtime will retrieve the data as an Object, then cast it down to a String (the parameterized type) at runtime. In short, the code is no different than if you’d written it “the long way” yourself–all the type-safety is being checked at compile-time, much as C++ does.

The key thing is to realize that, despite what my earlier post about JSR 14 may have implied, the generics-in-Java effort is not stalled or dead, and with any luck we’ll see a release before JDK 1.5 goes out the door. In the meantime, I encourage you to play with the early access release, and offer feedback to the JSR 14 team about what you think of it.

And so now the race continues. Which environment will be the first with generics, Java or .NET?

That’s right–I think the Internet has achieved true omnisicience, and its name is Google. Google sees all. Google knows all. If there’s a computer nearby, Google knows about it and can report on it.

The Catalyst

What’s triggered this sudden burst of enlightenment? A recent email thread between two DevelopMentor peers. One wrote

I seem to remember hearing somewhere that MS owns a significant part of Verisign. I’m curious to what *significant* means. Does anyone know how I’d go about figuring this out? I’m not much of a businessman myself…

The response that came in shortly thereafter completely blew me away:

http://www.verisign.com/corporate/news/1996/finance.html.

MS was one of 10 strategic investors, not listed near the top, of a $30M round. Doesn’t necessarily mean that’s all they’ve done, but that’s what comes up with a Google search of “Microsoft”, “Verisign”, “investment” limited to the two company sites.

The amazing part about this lies not in Microsoft’s funding of Verisign (Microsoft is getting around to funding everybody–before long, we’ll hear about Microsoft making a sizable investment in Sun just to p*ss Scott McNealy off), but in the fact that this information was available through Google.

Think about what’s going on here. You have a question. A petition for knowledge. You want to know something about the world–nothing at all to do with the Internet, even–and you ask Google. If it’s somewhere up on the Web (and what piece of information today isn’t up somewhere on the Web?), Google will tell you in rapid order.

For example, I want to know how many men Saddam Hussein can throw at us in the event of a war. I type “Iraq” “military” and “men” into my Google toolbar in the browser, and get pointed to a number of news sites with mainstream media articles, but then, down near the middle of the top 10 results, I see this link, http://www.csis.org/pubs/2002_iraq.pdf, which turns out to be an online paper, “Iraq’s Military Capabilities in 2002″.

Another example: I’m serving spaghetti and meatballs to my kids for dinner. I want a nice wine to go with my Chef Boy-ar-dee. Google gives me, in response to “spaghetti” “dinner” “wine”, a link to Smart-n-Final (a discount grocery chain) Spaghetti Dinner Fund Raiser Shopping List, in which one of the ingredients is listed “Dry White Wine - 750ml bottle - 1″. (I am definitely bookmarking this page, by the way–I get involved in volunteer dinners all the time for various organizations.) I’m still not quite sure which wine to open with my microwaved pasta, however, so I’ll refine my search somewhat: I add “serving” to the list. (There’s probably much better keywords to use here, but I’m still new at this yet.) Sure enough, in the second page of links returned, I get a link to http://www.foodstyles.com/Menus/big_spaghetti.htm, on which is a complete menu for a spaghetti dinner, at the bottom of which I see “Recommended Beverages: We recommend a Salice Salentino, a Red Wine from the Southern Region of Italy or a Chianti from Tuscany.”

There is nothing Google doesn’t know. Or rather, there is nothing the Internet doesn’t know, and Google is the High Priest. Join the new religion. Seeking enlightenment? Ask Google.

Anybody want to form a Google cult?

I live in two worlds.

I’ve been writing Java code for over 6 years now, specifically in the back-end server space. (I was using the NetDynamics product as far back as late 1996, when JDK 1.0 as the norm.) I’ve been writing about Java since 1998, and teaching about Java since 1999. I’ve also been writing .NET code for over 2 years now, specifically in the back-end server space. I’ve been writing about .NET since 2001, and teaching about .NET for about the same amount of time. Living in both worlds gives me a really interesting perspective, both politically and technologically; I’m a member of the JSR-175 Expert Group, to bring metadata annotations into Java, and I’m writing a book on Rotor, the Shared Source .NET runtime implementation. I love Java, I love .NET. I want both to thrive, because the innovations produced as a result of competition between the two benefit us all.

Normally, I really really try to avoid the whole benchmarking thing–it’s a black hole that ultimately does nobody any good. People ask me in my classes (J2EE or .NET, doesn’t matter) which technology is faster, Java or .NET. I tell them that I’ve never run a benchmark, because I believe the variables between the two camps are too many and too diverse to accurately benchmark, and that ultimately it doesn’t matter because the choice of which technology to use is usually made on a golf course or over a fancy dinner, not in a benchmarking lab. DevelopMentor, the company I teach for, went through this “should we do a benchmark to compare the two” discussion about two years ago, and we all almost unanimously voted against it, for many of the same reasons.

When Microsoft released their version of the Pet Store a year or so ago, I was moderately amused–they’d rewritten the sample to use what they believe to be .NET best practices (which at this point is realistically anybody’s guess), and behold! Massive performance improvements. The Java community as a whole ridiculed the effort, and several J2EE app server vendors responded by writing their own versions of the Pet Store demo, and behold! Massive performance improvements. Nothing new here.

But now, The Middleware Company, a reputable Java and J2EE training and consulting company (and, I must, in the interests of full disclosure, point out, a rival to DevelopMentor) has taken the plunge and attempted to produce a benchmark that seriously compares J2EE and .NET on the subject of the Pet Store once again. They published their results last week, and, to put it politely, all Hell broke loose.

First and foremost, I want to point out that I deeply respect the pure cojones of The Middleware Company (TMC) in producing this–they knew, when they saw the results, what the reaction within the industry would be, and they published the results anyway. I have to believe that this was in the honest interests of trying to toe the careful line of honest reporting–either that, or TMC has decided to force themselves into bankruptcy. It simply makes no sense for them to do anything otherwise (unless they’ve suddenly decided to become a .NET training company, which I doubt). So I think it’s important to give TMC some props on that score. I believe they did try to make it as fair of a benchmark as they could, and they did achieve a serious performance improvement (17 times better than Sun’s original implementation, according to the report (p. 7). Whether they did everything they possibly could have done is another issue, addressed later.

In the meantime, however, it seems as if everybody within the industry, particularly the Java guys, have been leaping to their feet to decry the results of the benchmarks. In basketball, we’d be seeing a bench-clearing brawl right about now. More vitriolic poison has been slung between posters on message forums over this benchmark than in the last U.S. Presidential election–it’s amazing.

As someone who lives and breathes in both camps, I feel compelled to offer my own spin on things, to anybody who’s still listening. In particular, I want to address some comments made by Dion Almaer, in his
OReilly weblog, and Rickard Oberg,
in his online website review of the benchmark. I’ve never met either personally, but I have exchanged email with Rickard (a number of years ago). I deeply respect both.

Comments

Without further ado, let’s get into this. As always, I welcome comments and criticisms of my criticism.

• Dion points out that “What was the point of this report/benchmark? It seems unclear to me. Was it just about
  performance? Was it about ease of development (LOC)? It blurs.” Absolutely. The LOC measurement in this benchmark definitely dilutes the results of a performance-oriented benchmark, and vice versa. More importantly, I’d like to see a benchmark that drills down even further–how would you optimize the J2EE/.NET application to optimize for performance as opposed to scalability? Or even the numbers when “optimizing” for design purity (which Dion touches on later)? The benchmark doesn’t state clearly what it’s trying to measure, and as such, leaves us with a sense of confusion regarding what we’re trying to measure here.
• Dion writes that “M$ could even tweak their .NET core! Do you think you can download that .NET runtime right now?” Dion, I hate to say this, but that’s a spurious argument and a foolish one to rely on. Do you honestly believe that Microsoft wrote a specialized version of the runtime just for this benchmark? I can honestly say that I’ve met a number of the guys on the CLR team in Redmond, and let me reassure you, they have MUCH bigger things to deal with than this benchmark. More importantly, I challenge anybody out there to download the Rotor source and point out what optimizations could be made to the .NET runtime (or to the JVM, for that matter) that would seriously impact the performance of this benchmark. This is zealotry talking, and we don’t need that here.
• Dion says that the report “does not fully disclose who did the report, who was involved in the benchmarking, why certain “rules” were chosen, and who paid for it.” This is a fair criticism; in addition, both Dion and Rickard point out that the way this thing played out, it *really* looks like it was skewed from the beginning to favor the Microsoft guys. I would think that, given the leak of the email from Microsoft showign that they knew about the benchmark results before it was posted, TMC at least owes an apology the community at large, *ASSUMING* they presented it to Microsoft before the results. In fairness to TMC, however, we must consider the possibility that they never actually presented the results to Microsoft–just as Rickard got the internal Microsoft email, it’s fair to consider the possibility that somebody within TMC leaked the benchmark results to Microsoft, meaning TMC wasn’t giving Microsoft a heads-up after all. Check out the exact verbase of the email: “The week of Monday Oct 21, a draft of the Middleware report was distributed to analsysts during private 1:1 analyst pre-brief meetings with….” NOWHERE does it say that TMC gave the report to Microsoft, or was even present at these meetings.
• A number of people have criticized that the benchmark wasn’t run on Solaris or Linux. The benchmark report states, quite clearly, that “Both application servers were tested on both RedHat Linux 7.2 and on Windows 2000 Advanced Server (SP2)”, and that TMC “used the operating system that provided the best performance with that application server for the final, published test runs.” Should the tests run on Solaris, as a comparison? Absolutely. Will it be hard to find “comparable” hardware to run the tests on? Not at all–just buy whatever equivalent hardware I can get for the same price as the Compaq hardware used to run the tests, at list prices.
• Dion writes that certain optimizations weren’t part of the app, and lists Local Interfaces and other JVMs as examples of what wasn’t used. Again, however, TMC states that these were considered, and that Local Interfaces turned out to be no faster than remote ones, since any sane App Server would optimize the Remote Interface under the hood anyway, and that JRockit was, in fact, used, or at least attempted to: AppServer B couldn’t support anything beyond JDK 1.3. This in turn makes me question whether AppServer B should even have been used, but that’s another story for another day. (See the FAQ.) Honestly, the fact that AppServer B doesn’t support 1.4 tells me that the major App Server vendors aren’t all that concerned with the performance of their products, either. (And what the heck are they doing internally that prevents the app from running on 1.4, anyway?)
• A number of people have criticized the J2EE PetStore implementation for being unoptimized. First of all, let’s not forget that this served as Sun’s “Blueprints” document for a number of years, offering advice on how to build scalable systems using EJB. If it’s not optimized for performance, then Sun’s been leading all of us down a dark and unoptimized path for four years now. Shame on them.

  However, I am really getting sick and tired of Java developers trying to justify EJB as being the way to
  scale up and perform well, then claiming that the PetStore, which uses EJB, isn’t optimized to support scalability and
  performance. Folks, it’s high time we took the blinders off, stopped drinking the Kool-Ade, and realize that EJB doesn’t magically give you performance and scalability–it’s your application implementation and design that gives you that.

  So, then, would somebody *PLEASE* step up, write the PetStore the way the community thinks it should be written (using stored procs, no EJB, whatever), so we can kill that original implementation and be done with it? If it’s not written the way it should be, then Sun should remove all traces of the Pet Store from their site and release one that does. If they don’t, then they’re implicitly still backing the idea that the Pet Store is the blueprint to building EJB applications, and they deserve what they get when they get crucified in benchmarks.

• Rickard writes that the .NET implementation is “seriously flawed”, in that the .NET implementation mixes SQL logic into the middleware componentry to do the actual data-access layer. “Look at, for example, Product.cs which contains both object definition of the Product class as well as the SQL/code to access it as static methods. That is not very “object oriented”, now is it?” Frankly, as I’ve been trying to say for years, EJB and other distributed technologies aren’t about building distributed objects, but about building distributed components, also known as services. So the argument that this approach isn’t very object-oriented is, to me, a red herring.

  I think it’s also worth pointing out that having the SQL in the Product class really isn’t much different from having the SQL hard-coded in the ProductEntity bean (if it’s a BMP bean) or in the deployment descriptor (if it’s a CMP bean, thinking specifically of finders and/or selectors). I will point out that layering business rules in a SessionBean and data-access code in an EntityBean yields better segregation of code, at the expense of violating good O-O encapsulation between the two objects–so which do we want? Segregation of business rules from data access, or good encapsulation boundaries?

• Much of the rest of Rickard’s assessment of the benchmark, particularly his dissection of the J2EE implementation, sheds some serious question on how the J2EE implementation was optimized. Rickard comments that Ed Roman has been calling various people, “trying to convince them that [Rickard’s] review is basically written because [Rickard] is out to ‘get’ [TMC].” If this is true, then I’m seriously disappointed in TMC’s response. I grant you, TMC is definitely in the hot seat, but I would hope that they would welcome an opportunity to retest the benchmark with some of the optimizations that the Java community is calling for. What I would *really* love to see, as I said before, though, is somebody to write a version of the Pet Store that we can all agree is the “right” one to use, and put this question of Pet Store’s implementation to bed forever.

Summary

At the end of the day, however, I hope that this benchmark does a couple of things:

1. Java developers, .NET is a serious contender and is here to stay. Simply calling Microsoft names and writing the derogatory “M$” everywhere doesn’t erase the fact that Microsoft has produced a viable alternative to Java, particularly on the Win32 platform. Stop being silly and closing your eyes to this. Instead, do what Microsoft does so well, and steal from them: steal ideas, steal concepts, steal designs, then twist them around to make your Java apps faster. .NET doesn’t provide any kind of support for
   entity beans? Ask yourself why that is. .NET doesn’t provide any kind of support for object pooling? Ask yourself why that is. I’m not saying that everything Microsoft does is perfect–Windows DNA is a prime example of that–but don’t lull yourself into complacency by simply chanting “Microsoft sucks” to yourself and ignoring what’s going on over there. There’s a lot of bright people there in Redmond, and they’ve been thinking about this problem a long time.
2. .NET developers, don’t be lulled into complacency, either. The various Java vendors are *not* going to take this benchmark laying down, and you can bet that the Java guys are going to come after it with both barrels blazing. In particular, there is a tremendous amount of good ideas that the J2EE world embraces that are somewhat awkward to do in .NET; one such case in point is the whole Model-View-Controller paradigm for building webapps. Pick up a Servlets/JSP book, and figure out how to bring that over to ASP.NET. Don’t start thinking that you can just dribble SQL all over your .aspx pages and expect that the .NET runtime will somehow make your application “just run faster”–it isn’t going to work.
3. Java developers, this benchmark is essentially an indictment of EJB, not of Java. Demand to see a benchmark that doesn’t use EJB in the middle, using stored procedures against the Oracle database, built in an intelligent fashion that doesn’t include dead code or redundant transactional boundaries. Think you need EJB to work against simultaneous distributed databases? Think again–most servlet containers (the principal one I’m thinking of is Tomcat) support JTA, which means you can do distributed transactions against multiple databases directly from the servlet container. Think this means you’re losing the benefits of connection pooling? Not at all–the servlet container naturally acts as a connection-pooling funnel, particularly when coupled with connection-pooling JDBC drivers. (The same, remarkably enough, can be said for .NET and COM+.)
4. .NET developers, this benchmark is essentially an indictment of EJB, not of Java. Demand to see a benchmark that doesn’t use EJB in the middle, so you can get a fair and unbiased comparison of how the Java bits work against the .NET bits. Be prepared to admit that there’s really not a whole lot of difference between the two once we get down to that level.
5. Everybody, step back for a second and realize that at the end of the day, IT DOESN’T MATTER. This benchmark only proves that .NET turned out to be faster for this application in this environment for this particular test. Is your application precisely similar, in both architecture and implementation, to the Pet Store? It’s a hideous leap of logic to assume that “because the .NET implementation of the Pet Store runs faster in the lab, my online human resources system will run faster in our data center”; once the code diverges at all from the benchmark, entirely new variables come into question that can seriously affect the results.

To me, the verdict is clear: run your own benchmarks, form your own conclusions. It would be nice if we could find somebody who’s completely neutral to run a benchmark, but what company exists today, working in both spaces (so as to provide equal degrees of expertise) that doesn’t have ties to Microsoft or Sun/IBM/Oracle/etc? Let’s forget the benchmarks, analyze the code to find out why they each performed the way they did, and apply the lessons to our own systems.

How could the J2EE implementation be better designed? How many of you in one camp have looked at what’s recommended as best practices in the other?

Tuesday is election day. Mentata’s Jon Roberts developed a web application to perhaps help you make more educated voting decisions. Follow the links below, and you can say “Yea” or “Nay” on some of the same issues your
congressmen voted on in their most recent session. You don’t need to make a decision on every issue (you “Abstain” by default), but you need to vote on at least one to get results. Upon submission of your votes,
his application will evaluate how often your congressmen agreed with your calls (by %).

• For issues regarding the U.S. Senate
• For issues regarding the U.S. House of Representatives

Feel free to try it as much as you want, and please forward this message
to anyone you can before Election Day. If you have trouble, contact problems@mentata.com.

This example application is built entirely on open standards and
delivered using mostly open source software. In particular, it uses Java
servlets and an LDAP compliant directory database. The resulting
application is comprised of about 200 lines of Java code with a deployed
footprint of 10K. All work, including building the database, documenting
the project plan/requirements/design, writing the code, testing the app,
and delivering the system took under 40 hours. All software products
from Mentata Systems (www.mentata.com) are free and open source.

Thanks for any interest, and don’t forget to vote for real on Tuesday.

What do you think of this open source Java-based Web application; and did it make your voting decision more informed?

I tried out Trove, an open source collection of collections :)

I wrote an article here on ONJava.Com, which showed the performance of Trove compared to java.util.* collections.

I have had various people email with their findings, when running the benchmarks in various VM’s, and on different hardware. The results have been all over the map.

This shows the need to run YOUR OWN benchmarks, on your own system. As new JVM’s come out, you need to check again, as 1.4 is very different to 1.3 for example.

Don’t trust anything but your own numbers ;)

I subscribe to quite a few mailing lists. Most are low-traffic mailing lists that announce events of interest. Here’s a typical subject header from one of those: CSLI Calendar, Wednesday, 2 October 2002, vol. 18:4.

That’s a great subject header. I can read the subject and immediately know what the letter contains and when I should read it by (and, more importantly, when reading it would become pointless).

Then there are the technical mailing lists. Where, to be honest, the subject lines are often vague in ways that surpass my comprehension. Why is it that people on distributed computing mailing lists often think “Client Problem” is a good enough subject line?

We all get way too many e-mails a day. And we all need to filter somehow. My new resolution is: if it’s a friend, I’ll read it. If I know it’s important I’ll read it. If it’s a total stranger discussing “Client Problem”, I probably won’t.

Forget spam killers. The real killer app is something that will summarize an e-mail (and replace a bad subject line with something meaningful).

When I woke up at the beginning of the week, and saw the report that The Middleware Company
came out with, I just couldn’t believe it. I didn’t understand what they had done this,
and *I work* for this company! I was as clueless as you.

There has been a lot of responses to the report.
A lot of people are on the warpath… holding their axes up high as they charge
at TMC and TSS.

As I have read the report, peoples comments, and other posts on the subject, I see key issues
that upset me:

• Lack of Full Disclosure
• Unfair Benchmark

Lack of Full Disclosure

Let’s face it, the report does not fully disclose who did the report, who was involved in
the benchmarking, why certains “rules” were chosen, and who paid for it (directly or indirectly).
When you don’t have full disclosure, you don’t show the whole picture. We are getting information
out of TMC now, but it should have been there from the beginning, and they need to come out with
all of the information.

Unfair Benchmark

Benchmarks suck. Lets face it. Even the most well designed benchmark only does a performance comparison
within strict bounds. In a running race this is fine, as there are not that many variables.
In the enterprise computing world, benchmarks mean next to nothing. It is very easy to come up with
a set of rules, where you come top in a benchmark. This happens all the time. I think this happened here.

What was the point of this report/benchmark? It seems unclear to me. Was it just about performance?
Was it about ease of development (LOC)? It blurs.

Performance:

If it was for performance, then the vendors of Server A & B should have been able to come in and tweak
the code, deployment descriptors, OS settings, hardware, and whatever they needed, to get the highest numbers
for this particular test. Microsoft were the only company that was allowed to do this. That isn’t fair at all.
We have seen that an older version of PetStore was used, and certain optimizations were not part of the app:

• EJB 2.0 Local Interfaces
• EJB 2.0 CMP
• How about taking out EJB as an example?
• It would be nice to try JDO
• Try other JVMs (e.g 1.4, JRockIt)

If this would have been done, not only could we have seen more results, but THESE ARE THE THINGS THAT MATTER!
I don’t get about bbops as numbers on their own. I want to see the effects of CMP 2.0, Local interfaces,
straight servlet frameworks, other persistent mechanisms. This is knowledge that I can use in my projects.
I will not be able to tweak the system like the vendors can, so give me what I care about.
The TMC guys spent a lot of time tweaking this and that, so there is a LOT of good information in their brains.
What did they change and why? How did it help performance?

We also learn that the benchmark used XA transactions, and other “rules” like this. I want to know
how tweaking these “rules” affects the results. I try very hard to stay way away from distributed transactions
unless I *really* need them. The TMC engineers have stated that they did try some optimizations that have
been stated, and that .NET still would have “won”, but again, lets move away from this winning and losing talk.

Ease of Development:

LOC? Who gives a damn. “This app has 10,000 lines of code”. What does that mean to me?
How much of it was generated with tools (XDoclet, IDEs, etc)? I don’t write an application and say
to myself “Oh, I will take out this cool class that helps out, as it is another 500 lines of code to worry
about”. Are we also counting framework code that we use? How would things be affected if we used
Struts/WebWork, and OSCore/OSCache, OJB, and the list goes on. LOC itself means nothing. I want
to see how the architecture looks, how it feels, and that will give me info that I want to know.
NOTE: Rickard comments on the LOC discussion in his commentary

So what does this report mean?

Ok, so after all of this, what did the report mean? That .NET is better than J2EE?
Not at all. It didn’t show anything like that. It just showed that for one PARTICULAR set of rules,
Microsoft managed to get better numbers than a couple of TMC employees who used a couple of J2EE app servers,
trying to optimize old code, with non-bleeding edge servers (whereas MS could even tweak their .NET core! Do
you think you could download the .NET runtime they were using at the time?)
[CLARIFICATION: I am not saying that the CLR team were there tweaking their VM to get better results on this benchmark. I know they have better things to be doing…. I am just trying to make a point about the access.]

Well, when I look at that, all the report has taught me is that I would love to see more information from people
trying out different architectures, and how performance and ease of development is really affected.
I am a firm believer of KISS and “Fast Enough” principles, but this stuff is just interesting to read about.

Lets try to get some real information on this topic shall we?

There are a huge set of reasons why someone would choose J2EE over .NET, and I am looking forward to
seeing the community, and the J2EE vendors hit back at this.

Also, maybe something will come of the Rematch.
Again though, I don’t want this rematch to just be about numbers, lets change the objectives here, and just learn about
the technology.

DISCLAIMER:

These are my thoughts, and have nothing to do with my employers.
I work for TSS, and all of this came to me as a huge surprise. As big a shock
for us, as for you guys.

LINKS:

Here are links to all of the information regarding the report, and feedback:


The Petstore Revisited: J2EE vs .NET Application Server Performance Benchmark: http://www.middleware-company.com/j2eedotnetbench
Discussion on TheServerSide.Com: http://www.theserverside.com/home/thread.jsp?thread_id=16149

Rickards Review: http://www.dreambean.com/petstore.html

Cedrics Comments: http://freeroller.net/page/cbeust

Slashdot’s Posting: http://developers.slashdot.org/developers/02/10/30/1345214.shtml?tid=156