Discussions

News: The Middleware Company Asks for Input on J2EE vs. .NET Rematch

Bookmark and Share Get thread feed

  1. The Middleware Company Asks for Input on J2EE vs. .NET Rematch (377 messages)

    The Middleware Company (TMC) has published a letter in which they admit many of the problems raised with the Petstore benchmark and suggesting that people not draw conclusions about how J2EE verses .NET compares yet. TMC is requesting community feedback about whether a second test should be performed, and how it should be performed.

    Read A message to the J2EE and .NET Communities on middleware-company.com.

    Read Rematch plans and process.

    Check out the original benchmark report, and the original discussion thread about it.

    The Middleware Company will be monitoring this thread on TheServerSide for feedback that will used in a potential second benchmark.

    Note: TheServerSide.com (although owned by The Middleware Company) has not and is not playing a role in this benchmark beyond the functions of news reporting and providing a forum for feedback.
    Reply to this

    Threaded Messages (377)

  2. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    If TMC says that they want a FAIR retest doesn't that implicate that the first one was UNFAIR???

    And if so, why are they doing the retest? Wouldn't it be better to get a neutral company make the retest?

    And Floyd, I still have confidence in TSS and I think you are making a great job. Wouldn't know what to do with a morning without TSS. :-)

    Mirko
    :wq
    Reply to this Reply to original

  3. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I saw the article - linked from msoft, but I missed the debate. Which is a great great pity. Bet it was robust!

    Let me guess about the rematch:
    a) Ditch EJB's
    b) Use objects which map to tables BUT do not let the objects manage their own persistance
    c) Have a marshalling layer which is focused on the web page, these select all data in the minimum number of selects possible and load only the columns needed. The selects then populate the objects.
    d) There is no business layer as such. But there are a set of objects focused on servicing the GUI, and these use a 'utility' layer for common functionality and services.
    e) field validation is delegated to the data objects where possible to encourage code reuse, and javascript and validation tag libs/utilities are used where it is not possible.

    So you have object reuse - in terms of data objects.
    You have a system optimised for speed through use of custom SQL: both in terms of select/insert and update.
    Your transactions are optimised as well: but not using fancy tech, simply optimised for the applictation in question.
    JNDI is not used.
    Connection pools are used.
    A static loaded is used for read mostly type stuff :- which polls a single timestamp field to work out when to reload.
    You are future proofed against database feeds from a legacy system :- ie no presumtion that your code will be the only stuff updating the db.

    You then precompile your JSP's - if you use them.

    The system is now fast. Blistering in fact.

    But, what about struts? What about velocity? What about tapestry? What about XSLT/XML? What about a logging infrastructrure (log4j)? What about cross database support (JDO/CMP/bespoke)? and so on....

    The thing is, in any given situation all of the above may be appropriate. In fact the exact model used in the paper may be appropriate because speed is not the primary concern. By the time your project ends in 12 months the specs will have doubled anyway.

    So yet again, while fun, speed is not the way to judge J2EE v's .Net!

    Java's only selling point against .Net is that it lets you roll out to Unix/Linux/wintel. And with msoft licensing, venture capital death, downsizing and smart sourcing this could become the most important thing.

    Jonathan
    ps just found the original thread....I'll have a read, should be fun.
    Reply to this Reply to original

  4. The original debate can be found....[ Go to top ]

    ...here.
    Reply to this Reply to original

  5. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    This is called architecture!

    Paul
    Reply to this Reply to original

  6. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I have seen a lot of comments in the style of "let us
    get rid of EJB" and "use stored procedures" etc..

    By doing so, then J2EE may get close to .NET in
    performance (I still think the nativeness will
    give MS a sligth advantage).

    But what have we proven by that ?

    Is it how will recommend J2EE applications being
    developed ?

    No !
    Reply to this Reply to original

  7. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    <quote>
     I have seen a lot of comments in the style of "let us
    get rid of EJB" and "use stored procedures" etc..
    By doing so, then J2EE may get close to .NET in
    performance (I still think the nativeness will
    give MS a sligth advantage).
    But what have we proven by that ?
    Is it how will recommend J2EE applications being
    developed ?
    </quote>

    Why not? Or.. why? The point of the J2EE environment is that you have a great deal of flexability when building your applications. So, if you were just going to build a small store front application, would you *need* to use EJB? No.. you can do straight JDBC coding (hopefully in a good pattern/style), use JDO, use OR-Mapping tools.. you have lots of options.

    This really does complicate the comparison between the two technology camps. So, EJB is certainly a way to look at things, but then you really should be building multi-tier distributed appliactions on both sides. If you are building a store front, pick the technologies that best meets your needs. For .NET, that may be easy... for J2EE, you have a lot of options to choose from, and you may well need to build multiple versions of your application in a benchmark scenario.

    (Think of this another way.. if you have a speedboat and a large ship, the speedboat will be good for quick things, while the ship is good for living on, working on, moving around in. Yes, the speedboat can speed up more quickly, but its less flexable but you probably wouldn't want to cross the ocean in it.)
    Reply to this Reply to original

  8. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Why are stored procedures necessarily evil? And why are EJBs necessarily good? The fact is that if the "classic" J2EE approach doesn't deliver adequate performance in this application, it needs to be challenged. Or are we content to say to managers "J2EE has a pure architecture but it will always be slow." Performance is an important business requirement, and can't be ignored.

    What's so wrong with stored procedures? Used appropriately they can cut the total amount of code in some cases, and be highly performant.

    In my new book, Expert One-On-One J2EE Design and Development, I look at how to use relational databases efficiently (including the use of stored procedures where necessary) without moving business logic into the database. If we make a distinction between business logic (in the J2EE server) and persistence logic (which can often be done more efficiently in the database) there is no problem with using stored procedures if it improves speed. Note that I don't advocate putting business logic in the database.

    As someone pointed out, a great strength of J2EE is that it lets us choose from a variety of approaches. It's up to us to choose one that's efficient. Otherwise .NET will kill J2EE.

    Rod Johnson
    Reply to this Reply to original

  9. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    ROd, "Or are we content to say to managers "J2EE has a pure architecture but it will always be slow." Performance is an important business requirement, and can't be ignored. "

    Of course performance is important, but the problem is, this test was testing J2EE on wintel which no one in their right mind would do for any decent-sized project. SOmething that runs native will always run faster. We couldhave easily compared J2EE on wintel but interfacing with tons of assembly code, and it would have outperformend .Not for sure. That isn't the point, everone is msising the point. I just can't believe it. People need a wake-up call here, they aren't seeing the forrest for the trees.

    "What's so wrong with stored procedures? Used appropriately they can cut the total amount of code in some cases, and be highly performant. "

    You have to ask? Is there a standard language for stored procs&triggers? AS IF! Who wants to re-write thousands of lines of db code and hire a new expert to do itwhen it's time to upscale to a different db? Try and tell your manager about THAT one!
    Reply to this Reply to original

  10. Great idea for the rematch[ Go to top ]

    This thread is 'should we do it again, and how should we do it again'.

    The anger is that TSS/TMC stuck to EJB and it turned out to be rubbish. No one is terribly suprised.

    But the selling point of TMC is that they know how to do it right... OK, so the next benchmark uses no vendors. You already have 'best of breed' from msoft and Sun - ie the EJB mantra was followed.

    So move on, do what you do best. This time ditch all the industry mantra and do it as you know it should be done. Ditch app servers, ditch complexity. Make it simple, make it quick. It is only a sodding pet shop.

    Given this spec:
    Write a pet shop web site for 2000 page serves a second on hardware X using Java, because we may need to sell it to a linux house. Don't worry about a portable database layer, we want it done fast and dirty for SQLServer, if we need to port for Linux we can rework it.

    Now I know this is a pretty shoddy spec, but that is what msoft are working to, so lets work to it too.

    Once we have the results we end up with:

    TMC have 2000 pages per second
    .Net have 1400 pages per second
    EJB has 600 pages per second.

    Result: if speed is important ditch EJB. If speed is important go with java (yeah, I know).

    This is a very credible argument, I long to see EJB die and be consigned to the fiery pit. It has polluted java and should be expelled.

    If Clinton can provide 2000 pages a sec already lets promote him to java God :- I'll give you one of the original Java Jackets circa 1996 (pristine, unworn...when you see it you will know why).

    Jonathan
    Reply to this Reply to original

  11. Great idea for the rematch[ Go to top ]

    Jonathon,

    <quote>
    The anger is that TSS/TMC stuck to EJB and it turned out to be rubbish. No one is terribly suprised.
    </quote>

    The anger is more that an older spec of EJBs was used, and in an ineffective manner, at that. Also, while I use them quite often and quite well in what I do (I do not write client/server or web applications), most people probably don't use them for writing petstore sorts of apps, despite what you might think of as the mantra from Sun (again, I am not speaking from experience about writing petstore type apps, I don't have any, really).

    Your lack of understanding of EJBs leads you to make the comments that you make - keep in mind that they have their place (yes, including entity beans). Should they be used for a petstore? I'll leave that up to others who understand that sort of application design better.

    Keep in mind that if you don't like EJBs, don't use them. Simple as that. Even if you think Sun or the major vendors are telling you to use them. If you buy into what any vendor says, Microsoft, Sun, BEA or any other, and don't understand what you are actually buying into, it's your fault. No need to consign anything to any fiery pits. Improve EJBs absolutely, but there's no reason to get rid of them.

    Cheers
    Ray
    Reply to this Reply to original

  12. Great idea for the rematch[ Go to top ]

    Ray

    "Your lack of understanding of EJBs leads you to make the comments that you make"

    Sadly I understand EJB perfectly. I enven have a code generation product for EJB. Loads of folks seem to think that data persistance and caching is done well in EJB. The fact is that it is always over kill. I think you are right that EJB will evolve. It will evolve to become something far simpler and lightwieght. In fact it will have no common ground with the original EJB spec, because that spec is/was rubbish. Look at local interfaces...the spec changes beyond all measure to increase performance, because remote EJB's are rubbish. But for some reason we are left with a massively huge spec for an 'object factory'. That is all that local EJB's have become. Anyone of us can write an object factory with caching in about 5 minutes without reading 400 pages of spec and buying an app server for £60000.

    There are also dd files, app server dd, no, lets go for XDoclet and inline non-compiled tags. Cricky what about primary keys with distributed objects caches, lets make something up for that too. etc.

    The databases already do all this. It appears EJB's only performance gain is in creating a java cache, as opposed to a database cache. But the specs layer in so much useless, un-needed rubbish that any tiny benefit is lost.

    Believe it or not, Ray, my comments come from studying EJB and the alternatives. Basically EJB is a money engine for sun via licensing and certification. Thats all. Otherwise there would not have been all those problems about certifying JBoss. EJB is not a good architecture, nor even a suitable architecture. It is rubbish that is befouling java.

    Thankfully most folks know this, use it sparingly and wait longingly for JDO/whatever to become the defacto standard in it's place.

    But to counter you before you start. Yes I use EJB as required by client architectural standards. Yes they work. Yes we all made loads of money during the boom. Tomcat remains the most popular server side 'app server'.

    I quite like MDB though.

    Jonathan
    Reply to this Reply to original

  13. Great idea for the rematch[ Go to top ]

    <quote>
    ...data persistance and caching is done well in EJB. The fact is that it is always over kill. I think you are right that EJB will evolve. It will evolve to become something far simpler and lightwieght...
    </quote>

    Yes, and at the end:
    - we only have to write *1* Java class and *1* XML descriptor. Not more than that! The Java compiler should take care about the rest.
    - we get location transparancy (no need for Remote or Local). The JVM should take care about this.

    For this purpose we have to extend the Java specification language instead of building another frameworks (EJB, JDO or whatever).
    We have to go one abstraction layer higher. Java itself was successful by offering garbage collector (no need to free the memory by yourself). So it's time to extend the JVM for at least for the two points above.

    LoDe.
    http://openuss.sourceforge.net
    Reply to this Reply to original

  14. Great idea for the rematch[ Go to top ]

    Jonathon,

    While I too have long studied EJBs, I also actually use them on a dailey basis. I agree that if you are looking strictly for persistence and cacheing, then you probably won't be getting the bang for your buck (while an app server on one of our projects is Oracle 9iAS and is quite expensive, we also use EA Server on another, which isn't).

    For what we do (EAI/Warehousing), we used to have to go down the CORBA route - ugly! Now we have those primary services - transactions, concurrency, transactions, persistence, naming, asynch. messaging,security, and distributed objects all in one nice EJB spec. There is a whole world of enterprise class applications that goes beyond web and client/server based applications into which EJBs fit nicely. Quite nicely, actually. And done correctly, the performance is outstanding - far better quality, easier to develop and maintain, and faster performing than you could write yourself.

    Even though you may have your opinions on EJBs, and many people do (obviously), there are whole classes of enterpise applications that can use the technology. Perhaps in the realm in which you work, you don't find them to be useful - great! That's the nice thing about J2EE - you don't have to use all the components of the architecture! And like you say - you can roll your code in 5 minutes - I say brilliant! And if you don't need a full J2EE server, don't buy one. And obviously, there are plenty of servers that don't cost 60k. (EA Server, for instance).

    Again, EJBs aren't perfect - in fact, I've often thought that EJB and JDO folks should get together re: the persistence aspect of EJBs. But to say EJBs are rubbish is to lose sight of where they work well.



    Cheers
    Ray
    Reply to this Reply to original

  15. Use of Stored Procedures[ Go to top ]

    Tracy, I was replying to the previous post regarding stored procedures, not talking about the overall methodology of the benchmark. I agree that was flawed, although I don't see why "no one in their right mind" would run J2EE on Wintel. Intel boxes are cheap, and a Pet Store isn't exactly the Apollo Project. Isn't Java meant to be portable? Or is it just meant to run on *nix?

    I gather you think that stored procedures are always inadmissable, but your arguments don't convince me.
    - "Is there a standard language for stored procs&triggers". They're nearly all based on SQL, which everyone (should) know. A stored procedure can be viewed as the RDBMS-specific implementation of a simple interface. It's not difficult to reimplement simple stored procedures on different databases. Anyway, why is database portability always essential? This is basically an unusual business requirement, not a given. The last client I worked for spent about $1 million in a huge Oracle installation. Did they care if their applications required a few stored procedures reimplemented if they ever decided to go to DB2? No: they wanted that investment leveraged. There's a saying that "data tends to stick where it lands." In practice it's more likely that a J2EE application will be reimplemented than that a database will be uprooted.
    - Who said anything about writing thousands of lines of DB code? I said I advocated considering putting *persistence logic*, never *business logic*, in the RDBMS. If thousands of lines are required in the database, it's definitely more than persistence logic and the database isn't the place to put the functionality. Used appropriately, stored procedures are likely to result in a lot less code. The only reason I would choose, say, to use PL/SQL as opposed to Java to do something is if (a) it was persistence logic, not business logic; (b) it was a lot easier to do in the stored procedure than in Java. For example, it took 10 lines of simple PL/SQL to do as opposed to 200 of Java.

    By definition, enterprise systems use a mix of technologies. Java isn't the best solution to all problems.

    Rod
    Reply to this Reply to original

  16. Use of Stored Procedures[ Go to top ]

    Rod, "I gather you think that stored procedures are always inadmissable, but your arguments don't convince me.
    - "Is there a standard language for stored procs&triggers". They're nearly all based on SQL, which everyone (should) know. A stored procedure can be viewed as the RDBMS-specific implementation of a simple interface. It's not difficult to reimplement simple stored procedures on different databases. "

    Lol!
    Reply to this Reply to original

  17. Use of Stored Procedures[ Go to top ]

    Tracy, I'm still waiting for your argument :-)

    Rod
    Reply to this Reply to original

  18. Use of Stored Procedures[ Go to top ]

    <Rod>
    Tracy, I'm still waiting for your argument :-)
    </Rod>

    You'll be waiting for a long time - he never has one!

    As for stored procedures...I (like most Java developers I know) are against them for several reasons:

    - Most stored procedure code is not very clean/elegant
    - It is placing logic (even if it is data logic) in two seperate places (app and database)
    - In my experience, that code tends to be forgotten/neglected more than the rest of the application code. Your mileage may vary, however.

    Stored procedures are even less attractive for product developers who create a product that needs to be deployed on multiple database vendors/versions.

    If you are developing in-house apps, the "proprietary code" arguments holds less water, as it is unlikely that you will change database vendors often.

    All that said, if you have a problem where a stored procedure solution is an order of magnitude faster than a Java solution (and this performance is critical), I can see using a stored procedure in this circumstance.

    So, as a rule - no. I special circumstances - yes.

    My $.02.

    Ryan
    Reply to this Reply to original

  19. Use of Stored Procedures[ Go to top ]

    If you are clever then you code your vanilla app using ANSI SQL, but provide 'performance packs' for particular DBMS's which may use stored procedures.

    Many DBMS's allow you to write stored procs in java nowdays, so it's not like there even a context switch required between languages.
    Reply to this Reply to original

  20. Use of Stored Procedures[ Go to top ]

    What Ryan said, except for me not having an argument ;) I just didn't want to waste the time.
    Reply to this Reply to original

  21. Use of Stored Procedures[ Go to top ]

    Ryan,

    You do realize that a PreparedStatement in most JDBC drivers creates a Stored Procedure right?
    Reply to this Reply to original

  22. Use of Stored Procedures[ Go to top ]

    He probably won't care because that's not visible to the developer and doesn't incur database dependency...
    Reply to this Reply to original

  23. Use of Stored Procedures[ Go to top ]

    <Lasse>
    He probably won't care because that's not visible to the developer and doesn't incur database dependency...
    </Lasse>

    You are correct. I don't care what goes on behind the scenes in the database. That is the responsibility of the driver/database provider, not mine. Isn't that the whole idea of abstraction?

    Ryan
    Reply to this Reply to original

  24. Use of Stored Procedures[ Go to top ]

    Dave: "You do realize that a PreparedStatement in most JDBC drivers creates a Stored Procedure right?"

    That's a Sybase (aka Microsoft SQL Server) optimization. Sybase only supports dynamic SQL (so embedded and prepared SQL all stored procedure calls etc. are all actually accomplished by using the dynamic SQL API.) I've never seen an Oracle driver do that, because Oracle actually has a prepare concept that returns a handle through the API to an object inside the Oracle server that is a "prepared statement."

    The supposed benefits of a prepared statement are that the SQL is pre-parsed, security checked, etc. only once, and subsequent calls to the prepared statement can "just do it." One of the expensive things is designing an execution plan and optimizing it; a prepared statement does that up front. That said, depending on which options you use with Oracle, those options can actually reduce the benefits of prepared statements. I think the cost-based query optimizer is one of those options, but this is already well beyond my technical understanding.

    On the Sybase (Microsoft SQL Server) side, the benefits of the stored procedure are similar to prepared statements in Oracle: the big chunk of SQL is pre-parsed and an execution plan is pre-designed and kept with the stored procedure. There are downsides to this too: The execution plan is static and so cannot be optimal over time by definition (if database characteristics are changing, like table and index sizes.) There is some special "please recompile the stored procedure" command or option in Sybase (MS SQL Server) to address this weakness.

    FWIW.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  25. Use of Stored Procedures[ Go to top ]

    <Cameron>
    The supposed benefits of a prepared statement are that the SQL is pre-parsed, security checked.
    </Cameron>

    Those are the database-side benefits. PreparedStatements provide several benefits at the application level, too:

    - they properly quote database Strings for you, so you don't have to muck with appending these manually (e.g. "'" + myValue + "'" + ... YUCK!)

    - they allow you to create one statement statically and bind the dynamic elements, rather than building entire paramaterized query strings on the fly (and wasting time/memory)

    - they handle several object types transparently (Dates, primitive wrappers, binary data, etc). Something not so elegantly handled (or impossible) using Statement

    I'm sure you know this already - just wanted to make sure other PreparedStatement benefits aren't overlooked.

    Ryan
    Reply to this Reply to original

  26. Use of Stored Procedures[ Go to top ]

    Hi, Cameron is right, as (almost) always :

    "There's a popular belief that using a PreparedStatement object is faster than using a Statement object. After all, a prepared statement has to verify its metadata against the database only once, while a statement has to do it every time. So how could it be any other way? Well, the truth of the matter is that it takes about 65 iterations of a prepared statement before its total time for execution catches up with a statement. This has performance implications for your application, and exploring these issues is what this section is all about.
    When it comes to which SQL statement object performs better under typical use, a Statement or a PreparedStatement, the truth is that the Statement object yields the best performance. When you consider how SQL statements are typically used in an application--1 or 2 here, maybe 10-20 (rarely more) per transaction--you realize that a Statement object will perform them in less time than a PreparedStatement object."

    From Java Programming with Oracle JDBC by D. Baes (Excellent book, btw)
    Reply to this Reply to original

  27. Use of Stored Procedures[ Go to top ]

    <q>
    When you consider how SQL statements are typically used in an application--1 or 2 here, maybe 10-20 (rarely more) per transaction--you realize that a Statement object will perform them in less time than a PreparedStatement object."
    </q>

    PrepareStatement creates object in Oracle's "shared area" so request from other connection (at least from the same user/connection pool) can reusen it (within several minutes from last use, depends on load and SA size). My guess is that end of transaction will NOT kill this object.

    AlexV.
    Reply to this Reply to original

  28. Use of Stored Procedures[ Go to top ]

    Cameron,

    Can you tell from my posts that I spent way too much time working for Sybase? <wink>
    Reply to this Reply to original

  29. Use of Stored Procedures[ Go to top ]

    this whole thing looks more like a EGO problm for java coomunity. Why do we really want to compare things. No comparision will be fair enough and people will still cribb after the 10th such attempt.
      We all know java is slow in performance, requires hell lot of time for configuration. But its robust, scalable, more modular and very easy to maintain the application.
     .Net sucks in terms of scalability- need to restart machine 100 times for a damn COM to work, maintaining the code sucks . its like a script language ..
      so jst LEAVE it now.
    Reply to this Reply to original

  30. Use of Stored Procedures[ Go to top ]

    Cameron,

    >>>>
    On the Sybase (Microsoft SQL Server) side, the benefits of the stored procedure are similar to prepared statements in
    Oracle: the big chunk of SQL is pre-parsed and an execution plan is pre-designed and kept with the stored procedure. There are downsides to this too: The execution plan is static and so cannot be optimal over time by definition (if database characteristics are changing, like table and index sizes.) There is some special "please recompile the stored procedure" command or option in Sybase (MS SQL Server) to address this weakness.
    <
    Not totally correct. In Sybase this is not a weakness but a feature. If you want to have the stored procedure recompiled every time it is executed just create it with the recompile option and that will happen. No need to do that manually. Even if you use this all SQL will stay where it is supposed to be, in the RDBMS, embedded SQL is very very hard to debug. And it will save a lot of network traffic.

    In most situations the query plan will not change though. The database content is not static but in most production systems I have seen big tables will become only bigger tables which means no change in query plan.

    We have built some big systems with Websphere and Sybase stored procedures and it works fine.

    Another two Eurocents...
    Reply to this Reply to original

  31. Use of Stored Procedures[ Go to top ]

    Let's clarify our positions here. I believe that stored procedures are appropriate when certain conditions are met:
    * they involve persistence logic, not business logic
    * database portability isn't a business requirement
    * using stored procedures improves performance and/or results in a simpler overall solution
    * the stored procedures are simple.
    I argue for a project-by-project, case-by-case decision. In many J2EE projects I would not recommend use of stored procedures, as this conditions aren't met.

    Tracy believes that we should never use stored procedures, and we should ignore any potential benefits, because stored procedures are always bad. So in his view if using J2EE with a relational database, we can never use a key part of the capabilities of modern RDBMSs.

    Ryan argues that stored procedures are a special case, justifiable only when they deliver real performance benefit, for example. Basically Ryan and I agree, except that I tend to think this "special case" comes up more often.

    Further comments inline:

    >As for stored procedures...I (like most Java developers I >know) are against them for several reasons:
    >- Most stored procedure code is not very clean/elegant
    SQL is often a lot better at manipulating relational data than Java. Simpler code, less code can be a benefit. I only advocate using stored procedures if they deliver a dividend of simplicity. Are entity beans elegant? The O/R impedance mismatch means that if we use RDBMSs, Java data access code is often inelegant. We only get to choose the lesser evil, as we often can't write true OO code.

    >- It is placing logic (even if it is data logic) in two seperate places (app and database)
    But the data's in the database. So in some circumstances, it makes sense for persistence logic operations to be where the data is if it's more convenient and minimizes round trips.

    >- In my experience, that code tends to be forgotten/neglected more than the rest of the application code. Your mileage may vary, however.
    This calls for good project management. Enterprise apps are about a range of technologies. And if the stored procs are simpler than the Java equivalent (one of my preconditions) maintainability won't be impacted.

    >Stored procedures are even less attractive for product >developers who create a product that needs to be deployed >on multiple database vendors/versions.
    I agree. In this case I don't advocate using stored procedures. But this requirements is rarer than many people think. Ryan makes a correct distinction between types of apps here.

    Attitudes like Tracy's go a long way to explaining why we have this thread (because the Java Pet Store performs so badly). It shows:
    * Inflexible technical bias ("stored procedures always bad") leading to unwillingness to modify this approach on a case-by-case basis. No interest in performance implications, because it's more important to use J2EE the "right" way, regardless of the evidence or actual requirements.
    * So convinced of his position that he feels there's no need to argue it. Thank you Ryan for stepping in.

    The whole Pet Store debacle shows that we need a more pragmatic approach to J2EE architecture. I am deeply committed to OO principles, so I don't just want to cut corners. But the fact is that, in a particular case, if BMP entity beans don't perform and stored procedures may, *and we have accepted a performance challenge*, we need an open mind. The strength of J2EE is that it allows so many options. It's important not to be too bigoted to consider them.

    Rod Expert One-On-One J2EE Design and Development
    Reply to this Reply to original

  32. Use of Stored Procedures[ Go to top ]

    <Rod>
    The strength of J2EE is that it allows so many options. It's important not to be too bigoted to consider them.
    </Rod>

    Amen, brotha!
    Reply to this Reply to original

  33. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Cool...they changed the subject. The first was that they wanted a "FAIR" rematch...which implicated that the first one was UNFAIR.

    It seems that TSS is not only a publisher of news if it changes the message titles for some companies...

    Mirko
    :wq
    Reply to this Reply to original

  34. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    TSS and TMC please DON'T change the content of the news bulletins once they have been posted. If you did so, please duely note it. Mr. Mirko noted "UNFAIR" was within the original heading - what happened to it ? Don't tell me this time Ed Roman removed it.

    It seems the server side has learned a great deal from Microsoft: slight of hand. What a shame.
    Reply to this Reply to original

  35. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    After reading all the 100s of posts on the benchmark(s), I think the benchmarked applications should be implemented twice (well, I really don't believe TMC has the resources...)

    1st setup - Strict rules. enforce as homogeneous environment as possible, including a 3rd party database (i.e. Oracle), enforcing identical division into physical layers, etc.

    2nd setup - Loose rules. Allow the use of any design on any platform within a certain investment. Special care should be given to balancing licensing fees so that the effect of either party's first-year-for-free type of promos are eliminated.
    Reply to this Reply to original

  36. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    As an outside observer I'd say that TMC is responding to a general kicking from a user base that didn't like the result. Ok, there is certainly a case that Sun and others may have wanted to re-write the app from scratch, but basically TMC did a lot of work setting up a fair comparison without the bull* that starts to creep in. I think then that their response addresses their biggest mistake - publishing something that shows Java in such a bad light when that is their base audience and techonology. I applaud their attempt at independence, but commercial reality is that TMC will now be forced to re-work until the 'right' result is obtained.
    Reply to this Reply to original

  37. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Only thing that would be fair would be to give BEA and IBM the same privilages that you gave Microsoft.
    The best you can do now is to take the results the vendors give and post them.

    I dont think the BEA application should look exactly like the IBM application. They implement different specs. The application should be what the vendor feels fit.

    Use the same database.

    Please also publish the cost of the hardware used to test.
    Reply to this Reply to original

  38. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Nobody will ever be happy with this benchmark regardless of the rules and players. Let me guess down the road, once this 2nd benchmark takes place and J2EE is declared the winner, the J2EE implementations themselves will become the next target of discussion. Oh gee, ibm, bea, oracle, and the open source community arguing over who's implementation is better? Will it ever end? It doesn't matter, build a good solution based upon good programming principles. I'm surprised no has said "how about a php or phython petstore?", that's more crap I have to deal with when less than knowledgable developers think they have all the answers.

    I think it's interesting to see the difference of amateur solutions vs. professional solutions being presented but in the end it all comes down to $$$, not just speed, people, or infrastructure. If people want Java to be better then start complaining to Sun and have them use their marketing powers and $$$ with all their partners to paint a better picture than .net. Sun has more to lose with their bread and butter selling hardware.

    I found these discussions more valuable from the perspective of how people would apply technology towards the problem. thanx.
    Reply to this Reply to original

  39. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    TMC can save itself a lot of time & money by hiring Clinton Begin to do the J2EE implementation for them.

    http://www.ibatis.com/jpetstore/jpetstore.html

    It took him only days (instead of months) to do this on the first PetStore comparison, and the outcome came incredibly close to that of DOT NET implementation.
    Reply to this Reply to original

  40. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Hey all.

    I never coded with C#, I'm a great fan of Java and love to code with it but strangly enough I've always tought, without really knowing, that a full MS stack would "perform" better than a stack built with java in it.
    As far as comparing .Net to Java is concerned, my reasoning is that we, as software developer/consultant/architect/engineer, should remember who we're doing our job for. The end users and the Businesses that are employing/contracting us. We shouldn't declare that a language and/or a platform is better just because we like it and spent a lot of time developing expertise in it. (Most of the time we don't even try other platforms)

    My idea would be to have a .Net Team and a Java Team to develop the best application they can on the same hardware and based on the same precise business/user requirements.
    Each team would be compose of top coders/architects from both schools.
    The application would have to be able to scale to a certain number of users and would be develop in consecutive versions to reflect the changes/evolutions in the business requirements. Those requirements changes would be made available after each version.

    Users (which would certainly be developers from both schools )would be able to check the usability of application A and B anytime from the web and rate each versions.
    Benchmarkers would have the opportunity to measure whatever they measure in terms of transactions, scallability ..
    Decision makers would have real time access to the details about the cost of the platform, the development etc. (without knowing which one is app A or B)

    At the end we reveal which one is the Java App and which one the .Net App.

    This way we would be able to compare the
    - cost of design/development
    - time spent on design/development
    - evolutivness of the application on each platform
    - raw performance
    - overall performance from an end user perspective.

    Let have the big guns(DELL,IBM,MSFT,BEA ..) sponsor this and than release the source codes on sourceForge so everybody would benefit from it.

    That'd be usefull I think...
    I even have an idea for the application...

    Cheers,
    Dominique.

    p.s.
    No Flame please. I really don't like flame session. really! :-/
    Reply to this Reply to original

  41. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    One suggestion for 2nd retest : Remove all the code written as stored procedures from Microsoft version of Petstore and reimplement it as middle tier functionality, as is the case with SUN's implememntation.

    Other suggestion, please compare the 2 versions on Unix boxes ;-) ...Any realistic enterprise application would be deployed on Unix boxes. If you can not do this, this comparison is useless.

    Also, in your report, please include the number of platforms you could deploy one version of petstore as against the other version of petstore.

    If the report does not include these points, the comparison is useless
    Reply to this Reply to original

  42. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    One suggestion for 2nd retest : Remove all the code

    > written as stored procedures from Microsoft version of
    > Petstore and reimplement it as middle tier functionality,
    > as is the case with SUN's implememntation.

    Why not rewrite the "middle tier functionality" in stored procedures in the J2EE version instead?

    > Other suggestion, please compare the 2 versions on Unix
    > boxes ;-) ...Any realistic enterprise application would
    > be deployed on Unix boxes. If you can not do this, this
    > comparison is useless.

    Right, I´ll be sure to spread the word of this to all the companies currently deploying their enterprise apps on zOS, iSeries, and Himalaya servers.

    > Also, in your report, please include the number of
    > platforms you could deploy one version of petstore as
    > against the other version of petstore.

    And this is relevant because? Most companies tend to deploy their systems on one hardware platform.
    Reply to this Reply to original

  43. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Let's take the database out of the contention by using the same SQL Server 2000 database for both Petstore and Petshop, and do the data access right using T-SQL stored procedures, not dynamic queries. For JDBC, use the best Type 4 drivers out there, and for ADO.NET, use M$FT's SQL provider.

    Ditch WebSphere if it doesn't support EJB 2.0 CMP. Use WebLogic's proprietary ReadOnly and Optimistic caching strategy as much as possible. Use WebLogic 7.0, and the JRockit JVM for the Ontel platform.
    Reply to this Reply to original

  44. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Wintel that is.
    Reply to this Reply to original

  45. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    For Round 2, why not produce a 'pluggable tier' benchmark application with full source code? How would this work?

    1. Middleware Company (MC) produces a minimal benchmarking application publishing full source code.
    2. MC will publicly certify all cooperating software and hardware.
    3. Public contributors produce pluggable implementations of the 'pluggable tier' interfaces (persistence, for instance) specified by MC.
    4. MC will run this benchmark software against plugged implementations provided by the contributors and publish the results.

    I'm not going to list all the advantages or disadvantages of such an approach but it seems to me that instead of merely indulging in some kind of shallow gladiatorial contest, we might actually discover what the best ways to produce network software architectures are. If administered properly, it could also keep costs down and attract rather more welcome publicity for the MC too.
    Reply to this Reply to original

  46. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    If you want to take the database out of it, go with Oracle or DB2. Both have *excellent* Java support. Oracle might be more fair of a comparison, because .net has a native driver for that.


    -----
    Let's take the database out of the contention by using the same SQL Server 2000 database for both Petstore and Petshop, and do the data access right using T-SQL stored procedures, not dynamic queries. For JDBC, use the best Type 4 drivers out there, and for ADO.NET, use M$FT's SQL provider.
    Reply to this Reply to original

  47. Lets keep it very simple![ Go to top ]

    Lets keep it very simple!

    Keep the hardware the SAME, but have each side CHOOSE whatever OS and Database that will give the best performance that they see fit (Obviously, hardware platforms are limited because of .NET. However, this limit may be short lived sometime in the distant future).

    Each hardware platform equivalent should have whatever software they need to run at their best. For example:

    .NET will probably use the following, although not limited by:
         Windows Server 2003 running .NET 1.1, IIS 6. 0
         MS SQL 2000
         Etc…

    J2EE will probably use the following, although not limited by:
         Linux, Solaris or whatever
         WebSphere, WebLogic or whatever
         Oracle, MySQL or whatever,
         Etc…

    METRICS that should be measured are as follows:

    Performance
    Scalability
    Ease of Maintainability
    Ease of Extensibility
    Development Cost
    Software Cost
    Cost of ownership
    Maintainability Costs
    Following at best, a true n-tier architecture

    If J2EE vendors are not willing to fork out the money for this test, and I know that MS will, why not have MS pay for the J2EE vendors’ best players to come and participate? Wouldn't that show good faith on their part?

    Ross Pellegrino
    Reply to this Reply to original

  48. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Why not beginning by opening a Sourceforge project with the source code so that the community may be able to work on various optimizations...

    BTW: As the low-level functions are clearly platform optimized in .Net, keeping the tests under a Windows platform means certainly loosing the competition even with a lot of - all the possible - optimisations (just test for example the performance of a simple string concatenation loop under C# and Java).
    I'm quite sure M$ has already internally done such tests, that's why they are so confident about winning this 2nd round. But perhaps it would be finally a good think for the Java community. Perhaps it will lead to some kind of Java/J2EE open sourcing so that the community may be finally able to perform more code optimizations to keep a competitive and open platform during the next years.

    My 2cts

    Stéphane
    Reply to this Reply to original

  49. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    First and fair thing to do is to get the message of TMC to the J2EE and .NET communities should be posted on Microsoft site also because they have the old bench mark document posted. Looks like TMC has allowed them to do so.
    We wish, The Microsoft's false campaine should be stopped and also Publicly Nutralized.
    Reply to this Reply to original

  50. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    No one believes you anymore.

    How did you compare 2 different technologies? .Net hasn't any persistent tech. which you can compare with EJB. Beside if you say so that you choose the ultimate technology in both platforms, how come you used BMP ?

    And one more thing. If your developers, consultans and whatever from Middleware can't implement a simple J2EE application open a new project at Sourceforge, I'll be glad to help them.
    For the community...

    Regards,
    Matyi.
    Reply to this Reply to original

  51. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    No, TMC should NOT do a 2nd round of the benchmark. You have already lost your reputation and nobody will believe you in future, regardless which party wins the benchmark.

    Your excuse is ok so far. Everybody understands that you can't tell the whole story, otherwise you certainly could close your shop.

    Take a back seat and check for some new business opportunities in future, other than 'J2EE experts'.
    Reply to this Reply to original

  52. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I have never seen a bunch of sore losers as you guys have demonstrated. If the results were is java's favour, you guys would applauding the bench mark. When the truth is that java/JVM is just a hacked up piece of software.
    Reply to this Reply to original

  53. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    One more thing. When the 2.0 version of .net comes out some time next year , we may have to ditch java and jump on the mono open source implementation for .net.
    Reply to this Reply to original

  54. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Mackie,

    Get real. If someone stands up in court and says blah, blah and that goes against you, you have every right to look into the truth of what was said, and the persons credibility. If found to be untruthful or the person lacks credibility, then good for you. If not, then your stuck with it.

    Same situation here.
    Reply to this Reply to original

  55. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I have never seen a bunch of sore losers as you guys have

    > demonstrated.

    I think your slick remarks would carry more weight if written in understandable english. I´ll try to help you here:

    "I have never seen such a bunch of sore losers as you guys have demonstrated that you are."

    Well, I am not a native speaker, but it is still an improvement.
    Reply to this Reply to original

  56. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I must agree with Andreas, the TMC has lost credibility.
    First of all, the petstore was not designed for speed or benchmarking J2EE but to elaborate the J2EE features.

    Therefore benchmarking does not make sense on Petstore. TMC should not do a rematch.
    Reply to this Reply to original

  57. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I Think TMC is running out of money. Dude, as being a company of Java and J2EE technologies how dare you are to compare Standard J2EE frame work with some idiotic .NET . Instead of conducting a benchmark, you should ask your online readers about how many enterprise applications they have moved out of Microsoft technology into J2EE. The main reason developers all over the world loved and put a lot of effort to develop and deploy their applications using Java, J2EE and open source technologies cuz of its beauty as an open framework.
       I think, if you are influenced by big boss Bill and his junk Windows only frame work and you are getting some money from them to compare J2EE with .NET that is your business and you don't have to show that to the publics. By comparing J2EE with .NET you are going to loss your company dignity as a supporter of open source.
       Until and unless Microsoft open their junk approach and monopoly of using only one operating system, as a software engineer of a bachelor degree in Electronics and Communication Engineering, who know the basics of bites and bytes in Silicon technology, I NEVER GONNA WORK IN .NET, I am sure this will be the opinion of most of the Java engineers opinion all over the world. SO PLEASE STOP YOUR STUPIDITY AND GET THE HECK OUT OF YOUR COMPARISION BUSINESS
    Reply to this Reply to original

  58. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    * We ask that you give us the benefit of the doubt here. >Judge us based on the work we have done for the J2EE >community over the past few years, building TheServerSide.com >community, writing the leading books on the technology, and >much more. We have not worked this hard only to sell >ourselves.



    There is absolutely NO reason whatsoever anyone (including Microsoft) should trust you again. Your engineers are at best incompetent. You've deceived the community and the vendors by unfairly trashing what you claim to stand for. Whether this was intentional on your part remains to be seen but ask yourself why anyone would want trust you again. You, the stewards of J2EE, the offical host of ecperf results you've betrayed those you claim to serve, you've sold our trust to Microsoft. But why, why, is the question on everyone's mind would you go out of your way to humiliate J2EE? For decency's sake, I urge you to hand over this website and your bestowed responsibilities to the JavaLobby, for they have remained true through thick and thin.
    Reply to this Reply to original

  59. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    You, the stewards of J2EE, the offical host of ecperf

    >results you've betrayed those you claim to serve, you've
    >sold our trust to Microsoft.

    Yep!
    Reply to this Reply to original

  60. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    <quote>
    You've deceived the community and the vendors by unfairly trashing what you claim to stand for. Whether this was intentional on your part remains to be seen but ask yourself why anyone would want trust you again.
    [...]
    For decency's sake, I urge you to hand over this website and your bestowed responsibilities to the JavaLobby, for they have remained true through thick and thin.
    </quote>

    There is little doubt in my mind that it was intentional.
    Javalobby, at the very least, has good forums and several free books (PDFs).
    Reply to this Reply to original

  61. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    A) Do you think we should conduct a 2nd benchmark?


    Yes.

    > B) How do you think that benchmark should differ from the current benchmark?

    Invite each vendor - Microsoft, BEA, IBM, and Oracle (and why not the JBoss Group) - to build there own implementation based on a normal specification. Do not require any specific architecture - EJB´s,JMS whatever - let each vendor decide how to get the best performance.

    Let the vendor choose to deploy on Unix or Windows - I have no idea how to match the hardware specs though =)

    Theres no guarantee that the J2EE vendors are interested in participating though, what if .NET really is faster... =)
    Reply to this Reply to original

  62. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Perfect suggestion!
    I would add next :
    It seems to me that all this "religious war" has a central GOD as is normal for a "religious war"
    "My GOD is much faster than yours ... " and that's ALL what can be seen here, nothing else, only the approach of low level knowledge engineers who are able to catch only "how fast opens this windows, how fast goes to taskbar this window ... " bla bla used usually only by M$ windows experienced developers and not enterprise architects. So the solution to fight this situation is to use his own strengths and strategies ... (read Machiavelli you will be surprised to see how valid is for our scenario ... )
    So give to BEA, IBM, ORACLE the freedom to present their own Petstore implementation designed and focused ONLY for speed, not thinking at all about real enterprise designed application ... and see what happens ... Another tragic point which seems that was lost again : PEOPLE, PETSTORE IS A TUTORIAL FOR BEGINNERS IN JEE WHAT THE F..K YOU ENTERPRISE EXPERIENCED ARCHITECT ARE LOOSING
    TIME WITH DISCUSSIONS FOR BEGINNERS ?!?!?!?! It's about marketing ? It's about "how many developers we will convince that is better for their career in this bad times for IT to choose this and that because this will decide who will lead the market, the one who has the majority of developers knowledge ?"
    Wars( benchmarks you can say ... ) are always about power not about truth and good and bad ...
    Shame ...
    Reply to this Reply to original

  63. Ground rules[ Go to top ]

    Well, let's take a step back and examine the original purpose of this benchmark. Exactly what is to be benchmarked? If pure performance is to be benchmarked, then neither technology should be limited in any way to squeeze the best performance out of the respective platforms. However, all decisions or strategies used to accomplish this goal should be disclosed to "a candid world" so that individuals can weigh the value of the benchmark. In the end, the goals of the benchmark should be clearly enunciated.

    Also, some ground rules should be established. If Microsoft staff are to be involved, then Sun/BEA/IBM/Oracle/Sybase/etc staff be included as well. If staff of both vendor groups cannot be obtained, then neither vendor staff should be utilized. If any assistance is rendered by any vendor, the nature of the assistance and who rendered the assistance should be disclosed. In fact, any communication with a vendor regarding the benchmark, whether it be with vendor technical, marketing, sales or management staff, should be disclosed in the final report.

    A truly fair benchmark would have separate teams of developers for each platform. These teams should have similar and equivalent skills and competencies. Each team should then be turned loose to do the best they can with their assigned platform, rather than potentially sabotage the competing platform. And, each team should be free to utilize anything they wish to accomplish their goal. No conditions should be placed on either team since this would taint the benchmark from the get-go.

    In my mind, the credibility of TMC and TSS is on the line here. The original "benchmark" damaged that credibility by at the very least presenting the appearance of, if not actual, favoratism. This is THE chance to mend that damage.
    Reply to this Reply to original

  64. More ground rules[ Go to top ]

    Oh, one other thing. Throw out the work done for previous "benchmark" and change the business problem domain. This whole thing sprung from Microsoft's FUD report about their own version of the PetStore application. Sun's PetStore was an architectural prototype, a reference implementation, an academic exercise, not a highly tuned, production ready application. If you're trying to distance this benchmark from the FUD, create a new problem domain and let each platform have at it.

    Finally, release the complete source of both the tainted benchmark and the new benchmark. It's not that I don't trust you, but...well, it's that I don't trust you.
    Reply to this Reply to original

  65. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    1. Performance does not always mean speed. An application doing fair job on varios platform and DBMS is not meant to be faster than one made for specific platform and specific DBMS. Maximum achievable speed of SUV on flat road is not its performance benchmark. If still .Net is slower than J2EE, it's a weakness of .Net, not a strength of J2EE.

    2. More abstraction means more flaxibility and parheps less speed. By following good design, we try to build loosely coupled system able to withstand future changes, speed is not our main goal. How easy it is in .Net to adapt changes compare to J2EE?

    3. J2EE offers switchability of most of the components, means more freedom of choice. Remember Apple's problem?
    Reply to this Reply to original

  66. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    OK, counter rant:

    "No, TMC should NOT do a 2nd round of the benchmark. You have already lost your reputation and nobody will believe you in future, regardless which party wins the benchmark."

    "There is absolutely NO reason whatsoever anyone (including Microsoft) should trust you again. Your engineers are at best incompetent. You've deceived the community and the vendors by unfairly trashing what you claim to stand for."

    I believe you folks should consider what architectural experts are for. J2EE is tied to EJB no matter what us techies know. The big app server vendors rely on the EJB complexity to provide the bases for their price tag. And sun/javasoft promote it as something that is in someway useful. Even TSS and all java consultancies rely on it - without the complexity they have a far lower value.

    So, when looking at J2EE v's .Net the comparison has to be between .Net and EJB (as part of J2EE).

    For a speed comparison it should be C# in the .Net framework against Java in the J2EE framework. Both solutions selecting appropriate technologies focusing on speed only. This will result in systems which will ONLY run on their target system (for C# this will be .net runtime and SqlServer, and for Java this will be the JVM and SqlServer). To make it even fairer you could run against SqlServer and then against Oracle. I realise java would port to unix/linux (which is the main win with java).

    No stored procedures would be executed within the database.

    This is now a level playing field. But note we are now basically testing the JIT within both runtimes (simplification...but what the heck). We are no longer testing 'architectures'.

    So the fact remains, TSS comparison WAS an entirely valid and truthful comparison of ARCHITECTURES. It will remain valid until sun drop the EJB specs, writing them off as over sexed, over paid and over here.

    Any comparison of languages is a pretty stupid thing to do anyway, because we can open it up to C, C++, fortran, assembler.....

    Jonathan
    Reply to this Reply to original

  67. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Jonathon -

    <quote>
    I believe you folks should consider what architectural experts are for. J2EE is tied to EJB no matter what us techies know.
    </quote>

    I am one of the few on this list who seems to like EJBs (including entity beans) but I disagree with your statement above. J2EE is a set of tools, regardless of how the big app server vendors choose to emphasize the value. In other words, J2EE has EJBs as part of its toolset, but you don't have to use them. And architectural experts should know when to use the various components and when not to. The value from consultants/employees, etc doesn't come from promoting EJBs but from knowing when to use them or any other component.

    Now, while I would like to see a comparison of J2EE/with EJBs as compared to .NET, it isn't a requirement.

    <quote>
    So the fact remains, TSS comparison WAS an entirely valid and truthful comparison of ARCHITECTURES. It will remain valid until sun drop the EJB specs, writing them off as over sexed, over paid and over here.
    </quote>

    Yes and no. Yes in that the components used were valid J2EE components, no in that they weren't the best suited for the test. Now as to your assumption about EJBs, I can only assume that you have used them sparingly in your application development experiences - I won't go into their actual uses, go through the thread that was sparked from the original tests. They have very valid uses and there is no need to get rid of them. Improve them yes, which they are doing. However, if it isn't appropriate to use them, you don't have to. J2EE isn't tied to EJBs as you suppose above.

    As for a retest, I wouldn't worry so much about trying to find a .NET equivalent piece of architecture in J2EE, I would spend my time based on the functional requirements of the application itself - don't lose transactions, etc and build based on that. Use whatever .NET methods deemed neccessary, whatever J2EE components deemed neccessary. Because when I build J2EE apps, I am not at all concerned with what .NET can and can't do, what it's platform might be and what the database might be. Each side should be able to use whatever hardware and OS they choose. Again, as in the real world. Build a J2EE app using the most appropriate components from the J2EE infrastructure that best fit the requirements, as would be done in the real world. Run it against Oracle, SQL Server or combination, or against open source databases like SAP DB, which works great in high transaction environments. Build the .NET app the same way.

    For results, look at what it costs to get the transaction rate achieved - including development time, hardware, software, maintenance, etc. People can look at LOC if they want, though personally I give that less importance than others in the original thread. In a way, this might be similar to the ECPerf tests though with the inclusion of .NET.

    Cheers
    Ray
    Reply to this Reply to original

  68. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    The problem with the TMC results were the slanderous statements against the J2EE appservers, particularly Websphere. The brunt of the "comparison" was complaining how difficult they were to configure and tune, and the real killer was the added functionality for web services which exposed a limitation in WS and the attempt to trumpet that as a flaw in all things java.

    Of course EJBs are slower than COM+ objects that don't do as much. Especially with 1.1 BMP.

    And then there was the LOC comparison. They refused to use any tag libraries or tools or frameworks and counted their custom solutions in the lines of code count.

    Not to mention that the custom COM+ executables that provided the "glue" that an appserver gives were specific to the Petshop, and completely unusable for any other project. And were not counted in the lines of code. At the very least, they should count against all the boilerplate code that goes into EJBs.
    Reply to this Reply to original

  69. Essential part of a rematch[ Go to top ]

    Unfortunately I don't think that a single retest is possible since there are so many disagreements about what was wrong with the tests.

    However, I do see that it may be possible to have *two* possible tests: one with CMP2 and one with JSP/Struts. I personally think that the JSP/Struts implementation matches the Microsoft implementation more closely (after all, .NET has no concept of EJB), however, EJBs are useful and the previous benchmark gave them a bloody nose. We need to set the record straight on what the *real* performance penalty of CMP2 EJBs are and what scalability gains we can really expect.

    So here are the guidelines I'd propose. I believe that it will ensure
    the results will be valid, that people believe in the results, and
    that it would get rid of the damage caused to TheMiddleWare's
    reputation.

    For the implementations
    ***********************
    For Java Petstore:
    > Test 1) Use CMP2. Use JDK 1.4. Use an app server that supports the
    > latest spec. Use local interfaces (even if remote interfaces
    > optimized to local, it's best to remove all doubt). Ensure that the
    > caching is the same as the .NET implementation.
    > (An essential starting point is *the current* Sun Petstore)
    >
    > Test 2) Use JSP. Use struts. Use JDK 1.4.
    > (A good starting point is www.ibatis.com)

    For .NET Petstore:
    > Use the newly released .NET from Microsoft and modify that to become
    > DB independent. If that is too much work, use your current
    > implementation.

    For the test environment
    ************************
    You have two choices:
    1) Use the same hardware, software, operating system, service pack level (no special "hotfixes" on one but not the other), and database.
    2) Use the same amount of money for both and choose the best architecture for both systems.

    Point 2 is more realistic in the business world, but point 1 is likely all you can afford to do for this test. Make sure to put this in the disclaimer.

    In both cases, the latest and greatest *non-beta* software should be used.

    So assuming you go with test 1, I suggest that you use Oracle on Windows 2000 Advanced Server as the common environment. Using Oracle ensures that J2EE and .NET are equally supported by the database vendor. Using Windows 2000 Advanced Server ensures that both implementations can run on the same OS and hardware environment.

    Optimize both .NET and J2EE appservers and operating systems, but
    do *not* aggressively optimize the environments. Realistically,
    most companies cannot afford to spend 6 months optimizing their
    hardware configuration. Optimizations should go into the design.


    Pre-validation of the validity tests of the tests
    *************************************************
    Before performing the tests, give a copy to Microsoft,
    Oracle, and the app vendor you use to ensure that they
    feel the test is fair. Give them a limited time (say
    30 days) to ensure that they don't have enough time to
    put together a comparable hardware system. If you need
    to run tests to ensure that your implementation, you're
    not using best practises, you're using a workarounds.
    Best practises should be obvious to anyone with a
    reasonable amount of experience with the need to run
    tests.

    Once they have approved the tests, I would post a
    preliminary copy of both tests here and on a .NET
    weblog and invite comments for 7 days.

    These steps ensure that everyone agrees that the tests
    are fair. No-one can claim that the Middleware company
    is anything but above board.

    Determine what you want to measure
    **********************************
    Ask the community what needs to be measured. Here are a
    few common ones:
    >* LOC is only remotely valid if you're using
    > the same formatting style. For instance, getters and
    > setters in .NET are traditionally formatted like this:
    > get { return position; }
    > set { position = value; }
    > while in Java, they are formatted as:
    > int getPosition() {
    > return position;
    > }
    >
    > void setPosition(int pos) {
    > position = pos ;
    > }
    > It's basically the same code and *could* be formatted the
    > same, but the J2EE formatting takes 7 lines of code while
    > .NET formatting takes 2 lines. Since getters and setters
    > are used extensively, this really ads up.
    > * Performance. By which metrics? Throughput? Raw performance?
    > Average time for page requests?
    > * Uptime -- Scheduled uptime (reboot or shut down server to
    > apply service packs) versus Unschedule uptime
    > * Number of denial of service request
    > * Maintainability -- how easy is it to add a specific
    > enhancement to both

    No matter what you use, ensure that you put disclaimers on
    what is not being measured.
    Reply to this Reply to original

  70. Essential part of a rematch[ Go to top ]

    Wow.. Awesome post.

    >> 2) Use the same amount of money for both and choose the best architecture for both systems.

    This is the best ever quote i have seen. This helps me choose JBoss with X-tra hardware to beef it up and stand against the other competitors !!!!
    Reply to this Reply to original

  71. Essential part of a rematch[ Go to top ]

    Wow.. Awesome post.

    >
    > >> 2) Use the same amount of money for both and choose the best architecture for both systems.
    >
    > This is the best ever quote i have seen. This helps me choose JBoss with X-tra hardware to beef it up and stand against the other competitors !!!!


    LOL, Why???? Your just saying that if one company has any money to spend on the development of their product they can't if the other company has the money? Haha that is dumn. Use what you have to make your product better. If ya sit back and do know forward development of your product your company will go under. Sun and Microsoft knows that and trust me Sun is $spending$ alot of money in Java. So quit talking about who sends more and talk more about the product. If you keep going towards the money is not fair then your just saying that Microsoft can produce a better product then Sun due to they have more money. And, if that is what your saying the Congrats!!! you just took your first step to the light. You just stated that mictosoft is better at "Product Development" then Sun.


    Here is some good reading. http://www.fawcette.com/javapro/2003_03/online/j2ee_bkurniawan_03_11_03/

    Dane-
    Reply to this Reply to original

  72. Essential part of a rematch[ Go to top ]

    The problem is that if the test is for performance, than one of the tests should be for scalability. I'd recommend a small system and a L-A-R-G-E system (like an IBM xSeries 4xx).

    The worst result (for those biased towards Java or against Microsoft or .Net) is that its direct effect on J2EE is irrelevent -- if .Net wins, it validates .Net as an enterprise platform.



    Original Message:
    You have two choices:
    1) Use the same hardware, software, operating system, service pack level (no special "hotfixes" on one but not the other), and database.
    2) Use the same amount of money for both and choose the best architecture for both systems.
    Reply to this Reply to original

  73. Essential part of a rematch[ Go to top ]

    Robert: "The worst result (for those biased towards Java or against Microsoft or .Net) is that its direct effect on J2EE is irrelevent -- if .Net wins, it validates .Net as an enterprise platform."

    It is extremely relevant. If Microsoft can produce a third party (preferable Java-centric) report that shows that .NET wins (and does so with no admitted link to Microsoft), then it provides a huge marketing win for Microsoft. That is exactly what happened. Almost. Except that several days after the report was published, after Microsoft met with a half dozen Gartners, after Microsoft marketing and sales people had emailed thousands of copies to CTOs, CIOs and project leads, then (when half the damage was already done) it was exposed that the tests were conducted by Microsoft at Microsoft for Microsoft. Apologies to Abe.

    One other thing to consider: Had J2EE edged .NET (as it could have by a few percent with the original PetStore requirements) then Microsoft would have still gained credibility, because the $/tx would have still gone to Microsoft (because Windows including the IIS/ASP/.NET tax was included for all tests.) The only way that it could have been otherwise would have been to run open source on Windows _and_ still beat the performance of .NET, in which case Microsoft _still_ would have gained credibility, because it would have been very close, so no one would be out-right stupid for using .NET.

    The problem is, they aren't comparables. Every time J2EE is compared to .NET, it lowers the value of the open J2EE standard and raises the value of the proprietary .NET product, until the proprietary .NET product gains the value that open J2EE standard has today, (which of course it cannot without Sun and IBM and BEA and Oracle going out of business,) which means that .NET has nothing to lose from any comparison, and J2EE (as the market leader) definitely has everything to lose.

    Why not benchmark the old ColdFusion or the Lotus Notes Domino server against J2EE? It makes just as much sense. They both server HTML too.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  74. Essential part of a rematch[ Go to top ]

    Cameron makes a great point alot of people are forgetting. In any competitive benchmark, when you are the underdog, you don't even need to win to win. Had MS even only come close they would have scored major points with the analyst firms who were professing that MS was never going to have the performance or scalability of J2EE.

    The Java community should understand, that just performing the re-match is a marketing win for MS. And if MS is even close to Java in performance its a win for MS. IMHO, just the rematch will be a win for MS.

    I would personally lick your wounds and try to let this debacle fall into the realm of a bad memory.

    Dave Wolf
    Personified Technologies LLC

    [in the spirit of full disclosure I am a FORMER employee of MS]
    Reply to this Reply to original

  75. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I am hoping we are getting BEA and IBM folks involved in this test. I donot trust ServerSide or Middleware or TMC for running the test and implementing the code . They have compelety lost our faith. Please use Linux or SUN Solaris for the test I dont thinks windows is a valid OS for test since .Net runs native in it.

    Also please use servlets and Database pooling using factory methods for datasource connection.

    thanks
    Sarwar
    Reply to this Reply to original

  76. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    .net runs native to wintel.

    Java runs native to.... err. So why choose a different OS and muddy the waters? We want a simple comparison surely.
    Reply to this Reply to original

  77. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Jonathon,

    <quote>
    Java runs native to.... err. So why choose a different OS and muddy the waters? We want a simple comparison surely.
    </quote>

    We want a comparison such that, given a set of parameters for an application, produce it on .NET and on J2EE and measure performance, cost, etc. .NET is pretty tightly married to Windows. In its current form, one might conclude that the OS is part of .NET.

    Why should J2EE limit itself to Windows when it doesn't need to? .NET should be able to take advantage of what it can - i.e. the native MS stack, and J2EE should be able to take advantage of what it can - i.e. choosing the hardware,OS, and database(s), application server, etc. It may be that the J2EE app servers tested run best on Windows, or not. It shouldn't be limited to what .NET can or can't do.

    Cheers
    Ray
    Reply to this Reply to original

  78. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Ray,

    true, but I guess at the heart of it is the apples and oranges. Basically this debate will run and run. And the reason is that there is no 'fair' comparison. And frankly who wants one, we all have axes to grind.

    I like the architectural blueprints idea. This is the 'java ' rightsizing mentioned in the summer here. The idea is that given a set of requirements and a set of restriction you come up with the simplest, best architecture: both in terms of meeting business requirements, legacy requirements and training requirements.

    requirement inputs:
    size of data set
    availabilty
    failover
    audit
    multi render/single render
    in-house system/product offering
    known infrastructure
    open to any infrastructure
    use cases
    business blah blah
    etc

    Restrictions:
    money
    existing hardware
    existing OS
    current architecture standards
    existing team skills
    future direction of corp architectures
    direction of the industry in general
    training requirements/budget
    etc

    From this should come the selection of:
    single cpu/multi cpu wintel/linux
    unix hardware vendor : scale
    OS
    Database
    Programming technology
    Architecture for rendering to web
    Gui presentation tech
    Selection of IDE/test/docn/collobaration tools
    messaging middle ware
    replication architecture
    failover strategy
    security solution
    etc

    Previously I was thinking of this in terms of Java only. ie to help new java developers work out what to learn. Maybe .net should be in one of the 'right sized' solutions as well.

    BUT, the risk here is that we put ourselves out of work! So maybe FUD is good. :)

    Jonathan
    Reply to this Reply to original

  79. Official Response from iBATIS.com[ Go to top ]

    Should this benchmark proceed? We all know how impractical and unrealistic benchmarks are, but they are still one of the most important marketing tools around. There is not a single facet of the IT industry that does not at least advertise using benchmarks. If Microsoft succeeds in winning the benchmarks, the perception in the industry will be that .Net is better, faster and cheaper than J2EE. Perception is reality. If Microsoft wins this competition (as silly as it may be), then I guarantee that this time next year my boss will drop a .Net book on my desk and tell me to get ready for the "upcoming migration".

    So what do we need? Here is my opinion, but I also support many of the other ideas that have already been discussed.

    ************************************************
    1) Application Specification

    We need an official specification for the Pet Store application. Let's create one.

    ************************************************
    2) Rules

    A set of rules and the environment in which we will compete must be clearly defined, but must also allow J2EE to work within an ideal environment. The current environment (Wintel) is not a fair one, as we all know.

    I believe the only benchmark by which we will be able to fairly compare J2EE vs. .Net is

        1) price/performance and
        2) developer productivity (e.g. lines of code and time to implement).

    These benchmarks are not dependent on having the same hardware or operating system. The input is investment (money) and the output is value (performance).

    For example: give each team a set of defined budgets: $5000, $10000, $50000, $100000 (or whatever). Then measure the TPS for each complete solution under each budget. The resulting price/performance will be the only comparison made. This is the only fair way to compare such different platforms that have been developed using such different design principles.

    Why? This is a more realistic way to make the comparison. Companies only care about one thing: money. They don't care if the hardware is the Wintel or Sparc/Solaris, they only care how much it costs. In a sense, they ask "how many customers can I serve with an investment of $50,000?". Obviously total cost of ownership topic will be raised, but unfortunately only time will tell that.

    ************************************************
    3) Platform

    We can compete with any J2EE platform, or combination of platforms. But in order to WIN, we need THE best J2EE platform. If it's IBM on AIX, or BEA on HP, or SunOne on Sun --whatever the case may be, we need to know what the best one is and we need to compete using it. In addition, we can use different J2EE platforms under each of the different budgets. For example: to get the best price/performance in the $5000 category, we may use JBoss on Intel and Linux. Then in the $25000 category we may use SunOne on Solaris and Sparc. Then in the $50000 category we could use Oracle 9i on HPUX (or whatever, these are just examples). I really like this idea because it shows off the flexibility of the J2EE platform.

    ************************************************
    4) Experts

    We need the appropriate experts for the platforms that we choose. The vendors should be very excited to help us out here. If they are not, then they will need to understand that they could be missing a very important opportunity to protect their investment in J2EE. We need the experts and we need them to work together. We need to fight the common battle against the threat of the .Net marketing campaign (because that's all .Net is --a marketing campaign).

    ************************************************
    5) Open Source/Community development

    I think the Middleware company has the right idea here, but unfortunately I think we might be opening up a potential hole for Microsoft to poke at. It took Vertigo Software 5 weeks with 2 developers to write the original Pet Store. If we use thousands of "community resources" and take months to develop The New Pet Store, we will not prove anything except that J2EE is so complex that it takes the entire community to write a simple online shopping cart.

    My recommendation is that TMC act as a host to a number of Pet Store submissions that community teams develop under the rules that we define (as above). Although there's no way to know for sure how long it takes each team, there's a very good chance it will be reasonably accurate.

    ************************************************
    6) Support for The Middleware Company and TheServerSide

    We need to let go of the most recent benchmark conducted by TMC. More importantly, let's not lose sight of the fact that, no matter how unfair it may have been, WE HAD ALREADY LOST in the eyes of the industry (by Microsoft's rules). I fully support TMC and believe that they are interested in making J2EE a winning platform. If we don't support them and just continue with childish conspiracy theories, then I would not blame them for backing out to save their name. I wouldn't even blame them for switching to .Net if their own community and peers in the industry lost all faith in them. Let's work together and back them up. Let's keep TheServerSide a J2EE community.

    Just my opinion.

    Best regards,

    Clinton Begin
    Creator of JPetStore
    www.ibatis.com

    ------------------------------------
    For anyone wondering, JPetStore 2.0 should be out around the middle of next week. I'm at 2246 lines of code, including the distributed transaction.
    Reply to this Reply to original

  80. Small correction to above (iBATIS.com)[ Go to top ]

    Vertigo Software implemented the original .Net Pet *Shop* for Microsoft. It took 2 developers 5 weeks.

    Cheers,

    Clinton
    Reply to this Reply to original

  81. Official Response from iBATIS.com[ Go to top ]

    Who really cares?
    Reply to this Reply to original

  82. Der Rockstar is wondering: "Who really cares?"[ Go to top ]

    Great question! I really don't like wasting my time, so let me know if what I'm doing is pointless. I have about six new games sitting on my shelf that need to be played, and a pile of .Net books to read. Each of them is more interesting than tweaking Pet Store code.

    Cheers, ;-)

    Clinton
    www.ibatis.com
    Reply to this Reply to original

  83. Der Rockstar is wondering: "Who really cares?"[ Go to top ]

    Clinton,

    I'm about 1/2 way through book 6 and still haven't had the time to produce a suitable complex .Net example from scratch. Don't read the books, start coding and refer to the books.

    Or give up for a while and play some games....it's what I've done.

    Jonathan
    Reply to this Reply to original

  84. Actually I've found this little pissing match quite useful[ Go to top ]

    Despite futility of this pissing match as a objective benchmard, I've found this and Clinton's Petstore version in particular quite useful. As part of my contract is to make a web application interface, I've learned a lot studying the various implementations. It seems Java has a plethora of frameworks and design patterns, but few practical, robust examples of their use.

    Clinton's app in particular has been quite helpful for me. His object-relational mapping framework proved very useful and the app in general was a great example of a small, efficient web app.

    I look forward to the next round not because I think J2EE will finally have a fair benchmark against .NET (that will probably never happen), but there should be some good code to scavenge. :)

    Don

    BTW, Clinton, I'll send you the code for that xml mod I made as soon as I can get it off the classified box.
    Reply to this Reply to original

  85. re: Official Response from iBATIS.com[ Go to top ]

    <quote>
    I believe the only benchmark by which we will be able to fairly compare J2EE vs. .Net is

        1) price/performance and
        2) developer productivity (e.g. lines of code and time to implement).
    </quote>

    I would add to this that I think it is also useful to see a comparison of performance on fixed hardware, even knowing the limits of such a picture. What I would like to see is something like this:

    Wintel blah blah with J2ee = 200 blips/sec
    Wintel blah blah with .Net = 300 blips/sec
    Lintel blah blah with J2ee = 400 blips/sec
    Lintel blah blah with .Net = 0 blips/sec

    I really appreciate TSS. And, the only real monster to deal with is that both M$ and Sun (and the big J2ee vendors)--and maybe a lot of us ourselves, are more dedicated to hyping crap to get people dependent on their companies than to building and understanding useful platforms and tools.

    j f
    Reply to this Reply to original

  86. Official Response from iBATIS.com[ Go to top ]

    <quote>
    A set of rules and the environment in which we will compete must be clearly defined, but must also allow J2EE to work within an ideal environment. The current environment (Wintel) is not a fair one, as we all know.
    </quote>
    Let me get this straight.
    Everyone here is saying that .NET has no equal if the platform is Wintel?
    You people have just declared a winner without even having a benchmark.
    Also, PetShop was design to be a blue print or have you losers forgotten?. It's time to give it up and quit being such Microsoft haters. It's pointless talking about this since none of you will ever open your eyes and see the thruth. The thruth is that Microsoft has done such great job to surpass it's competitors and none of you want to accept that. You haven't seen anything yet. Next year will be even greater. You say that Unix should be used. The company I work for right now is on a Microsoft platform. Since you said that J2EE sucks on Wintel, then all I can say is thank God, they didn't choose and chose .NET instead.
    Reply to this Reply to original

  87. Petshop[ Go to top ]

    did everyone forget this site is all about non-Microsoft products? The PetShop applications were designed to be the architecture to choose to implement Java applications. Many people bought into it. Despite of what all of you liars are saying about PetShop was meant to be a learning application. That's such crap. I can learn Java by buying a Learn Java for dummies or Learn Java in 21 days. After that I will need to implement a real world application and that's where PetShop comes along. You people got suckers into thinking J2EE was the best now that you've seen thruth you can't accept it. Why would anyone use Websphere I don't know. IBM suckers so many of these small brain developers into thinking they're working with the best.

    I don't care for non-Microsoft products, just like you guys don't care for Microsoft products. Let's leave it at that. Quit being such a Microsoft haters. I've never seen any Microsoft developers putting down J2EE or any java technology. For some reason or another these java guys have it in for Microsoft products. They want to see the end of Microsoft.
    Microsoft is keeping everyone on their toes you people should be glad, at least now you might get a better version of Java or even a standard.
    Reply to this Reply to original

  88. Petshop[ Go to top ]

    <Q>Despite of what all of you liars are saying about PetShop was meant to be a learning application. That's such crap. I can learn Java by buying a Learn Java for dummies or Learn Java in 21 days.
    </Q>

    Basic Java you can learn in that kind of book. Petshop is a demo of the advanced stuff. No one really is saying learn Java by looking at Petshop.

    <Q>
    After that I will need to implement a real world application and that's where PetShop comes along.
    </Q>
    See, you sort of get it.

    <Q>
    You people got suckers into thinking J2EE was the best now that you've seen thruth you can't accept it.
    </Q>


    <Q> Why would anyone use Websphere I don't know.
    </Q>
    Works for us. If the company likes IBM and wants to pay for it... .

    <Q>
     IBM suckers so many of these small brain developers into thinking they're working with the best.
    </Q>
    I thought that was the other platform's [single] vendor's job/ :)

    <Q>
    I don't care for non-Microsoft products, just like you guys don't care for Microsoft products. Let's leave it at that.
    </Q>
    Ok.

    <Q>
     Quit being such a Microsoft haters.
    </Q>
    So you couldn't just leave it at that. How about you stop being such a Java hater or IBM hater?

    <Q>
    I've never seen any Microsoft developers putting down J2EE or any java technology.
    </Q>
    Look at your previous comments. Look at a lot of the comments in this and other threads. Look at other discussion groups and web sites. I see it ALL the time.

    <Q>
    For some reason or another these java guys have it in for Microsoft products. They want to see the end of Microsoft.
    </Q>
    "Turnabout is fair play."

    <Q>
    Microsoft is keeping everyone on their toes you people should be glad, at least now you might get a better version of Java or even a standard.
    </Q>
    Keeping someone on their toes is good. Doing it by lying, cheating, stealing and misdirection is not.
    Reply to this Reply to original

  89. My Advice[ Go to top ]

    Don't do any benchmarking! These benchmarks seems to be only marketing for some particular product, whether it's good or not or whatever. This NET vs. Java debate sucks! These benchmarks tend to be very outdated as soon as they are published. Sometimes the code sucks, sometimes wrong hardware was chosen and sometimes there had been some UFO observation.

    Look at SPECjAppServer results! They don't tell anything. Then again look at TCP-C benchmarks. They don't tell anything. It's just benchmarking setup that settles the matter of which app-server is better than the other one - What is the better app-server? What is the application? - How does the benchmark reflect to real world application (that you are currently writing)?

    If I need to scale my .NET or Java-application, I sure know that I can do that. They both scale. That's proven, so let's stop this shit and concentrate on doing. The app-server or platform is very good if you can make your job done. There is no silver bullet and there never will be.

    If you still plan to do a benchmark, then be ready to accept the bullshit again. There is almost as many opinions (that say what could be done better) as there is developers who look at the benchmark (some even argue without looking at it). And then we have this debate again (Rickard Öberg will write a report and so on...).
    Reply to this Reply to original

  90. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Our livelyhoods depend on this.

    IMO TMC, TSS, and Precise should not conduct any benchmarks in regards to J2EE. TSS "Your J2EE community" can't be trusted. They prepared a slanted "performance report" for Bill Gates to present at COMDEX. What's to stop them from doing this again?

    There will be much "lip service" from TSS but I believe action speak louder than words. They have demonstrated lack of integrity. ORACLE, BEA, SUN, IBM, etc. should create a JOINT community to spearhead java initiatives.

    The pattern is emerging: TSS is a parasite that will eat away at our flesh. Let's get TSS out of the picture.

    btw, it is a conspiracy. You only need to read upto 3rd grade level to figure this one out.
    Reply to this Reply to original

  91. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Hi and have a good time
    Please read my ideas entirely

    1 - as someone from .NET world i say .NET Petshop is not blueprint - best practice or reference implementation for .NET
    Microsoft has other samples like Duwamish, Fitch & Meyer .Their architecture are more powerful than .NET Petshop.
    Petshop does not use any design or architecture pattern.

    J2EE Patterns discussion group
    .NET Patterns discussion group

    2- All of us know that remote calls are extremely heavy
    .NET Petshop is 3-tier application but Petshop tiers are not physically independent.
    you cannot place its presentation layer in one machine and biz layer on another unless Petshop uses .NET Remoting.
    it's really easy but with lost of performance penalty.
    form this view until Petshop uses remoting comparing Petshop and Petstore is like comparing apples and oranges

    3-EJB is heart of Enterprise Java. something different.
    i see lots of comments in J2EE community these days about disadvantages of using EJBs:
    - LOC: lots of code (remote,local,home,...) for solving on problem but i believe code-generators,IDEs and tools like XDoclet can solve this problem completely but not for novices (and EJB is not for novices)
    form different view i suggest J2EE community to compare development time cost of implementing EJBs and using .NET Component services (COM+) that is extremely different (in .NET you can make your class serviced component with object pooling, transactions,... in few minutes)
    - Entity beans: one of the benefits of EJB that show it's strengths with caching and CMP 2.0 in near future.

    4-Use of local interfaces (introduced in EJB 2.0) should increase EJB performance revolutionary because of 2 (see above) but we see in TMC benchmark that one of application servers does not support EJB 2.0 and another server does not perform better with local interfaces
    I think it must be changed in future. It’s about J2EE vendors.

    5-as someone read lots of .NET CLR shared source implementation i believe:
    - .NET CLR shared source is different form commercially released .NET runtime but lots of them are the same.
    - .NET runtime *is not* native not Windows - see Portable Application Layer (PAL) in .NET CLR implementation and also porting that to FreeBSD
    - .NET runtime use lots of Intel CPU architectures benefits.

    6-we see lots of ideas about changing Petstore to compete with Petshop. This thread also.
    (throwing EJB, tuning application servers,using another OS-DBMS)

    i think for fair compare we must change Petshop instead of Petstore


    Thanks
    Edris
    Reply to this Reply to original

  92. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    <quote>
    A) Do you think we should conduct a 2nd benchmark?
    </quote>

    Absolutely not. No matter how objective you think the comparison is, others will always find fault with your work and make some other accusations. You can't satisfy everyone, and while a number of the comments regarding the original benchmark were negative (and even personal), there were also a number of positive comments.

    High performance is not the only desirable architectural quality, but given the widespread and heated discussions regarding J2EE vs. .NET, you might certainly believe it is. Technology needs to be evaluated within the context of the architectural qualities demanded by the system's stakeholders. While performance is certainly a key objective, the fact that .NET outperforms J2EE does not, in and of itself, warrant a technology shift. What if all of your developers already have experience with J2EE? What if J2EE meets the performance requirements of the system? What are the interoperability requirements? What are the requirements with respect to scalability? Is platform-independence (operating system, application server, etc.) a concern? Is the solution constrained by a business decision to be aligned with a particular vendor? What are the requirements with respect to maintainability? What are the uptime and failover requirements? Is the sponsoring organization averse to open source solutions?

    There are certainly countless other considerations when architecting a solution, and the key point is that these decisions should be made within the context of the system's requirements -- and there are trade-offs to be made. You can't optimize all of these qualities. For example, performance usually implies more complexity and therefore is evaluated counter to maintainability. If performance is the absolute most important goal that must be optimized at all costs, then neither .NET nor J2EE is the right solution.

    I am quite certain that I don't stand alone in stating that I have had my fill of the ".NET vs. J2EE performance" nonsense. Evaluate all of the desired system qualities, make the appropriate trade-offs and apply the technology that best meets all of your needs. Whether it leads to J2EE, .NET or something else -- one of your goals as an architect should be to apply the technology that is most likely to result in a successful system that satisifes the needs of the stakeholders of that system -- regardless of your personal feelings regarding a particular vendor.
    Reply to this Reply to original

  93. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    This rematch is funded by Microsoft. TMC claims that it will be fair and the community should trust TMC's integrity.

    Let's put TMC's integriy aside, why would Microsoft fund this project? Why would Microsoft publish a performance comparsion between .NET and J2EE in the first place? Microsoft did not honestly believe that its own benchmark result would convince developers. It's objective is to bring fear, uncertainty and doubt (FUD) to the marketplace, and hopefully, there will be guys like TMC would actually go ahead and do further "third party" benchmark. --->TMC might have integrity, but it is clearly falling into a Microsoft trap of creating further FUD.
    Reply to this Reply to original

  94. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    You have to use exactly the same hardware and operating system . Because .NET runs only on this Windows crap (which doesn't make it a real opponent - there are many countries outside the US moving to Linux) you shouldn't let them use MS SQL.
    If you're going to use different operating systems (which does't make any sense for comparing) test the two systems under a heavy load over a long time - it will be fun hearing about the M$ people restarting their servers all the time.
    I don't think it's worth investing more money in this whole thing. The M$ stuff is for quick and dirty small solutions where uptime and reliability is no criteria.
    The typical M$ developer will never get into J2EE - it's to complicated for them.
    Reply to this Reply to original

  95. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Lars,

    <Q>Because .NET runs only on this Windows crap</Q>

    Do you mean:

    This Windows crap that produces code that is 8 times faster, 4 times more maintainable and with twice the productivity? That is a free ISO standard with an open source implementation that doesn't cost anything to use and redistribute?

    <Q>The typical M$ developer will never get into J2EE - it's to complicated for them</Q>

    Do you mean:

    The typical J2EE developer who use a tool to generate tons of code of which he absolutely understands nothing?

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  96. Yes! We want KNOWLEDGE!!![ Go to top ]

    Yes, absolutely yes and here's why:

    Everyone's got their own set of design patterns and reference architectures they use for their own systems and their own understanding of the theoretical underpinnings of those architectures. However, how many have acutally had the benefit of implementing the same functionality in several different ways and then benchmark them to learn about their behavior? Probably very few. To really understand the palette of options we have with J2EE architecture and their behavior, we'd have to apply the scientific method to perform truly scientific analyses of our options. This involves forming a hypothesis, developing a test, performing the test, publish results, peer review, and then doing it again and again for other hypotheses until we have a strong theory.

    This is tremendously time consuming. Since we all work for companies and not for research labs, we rarely if ever have the opportunity to do this in our jobs.

    Here now, is a chance to have somebody else do all the "grunt work" of testing while all we need to do is provide hypotheses and review the results and discuss our analyses. Wash-rinse-repeat, ad infinitum.

    Yes, head-to-head type benchmarks are fundamentally bogus, because the "winner" hasn't really proved anything in the general case, only for the particular case of the "competition". But what we get out of the exercise, is tremendously increased KNOWELEDGE about techniques that we can apply in our everyday work and RIGOROUS theories that can guide that application. This is of tremendous benefit to the J2EE world in general, since it boosts the amount of knowledge that's in the common and open view and not locked up inside the heads of a few "experts". As we've already seen on these threads there are a number of ideas people have proposed. Here's out opportunity to codify them, document them, and disseminate this information in an easily digestable format.

    What about Microsoft then? In my humble option, Microsoft can er... "do their own thing"...:) Only complete fools would look at the "winner" of a head-to-head "competition" and think that those results would somehow be automagically applicable to their problem. If we wanted to write the "fastest" enterprise applications, we'd all learn the details of SPARC/x86/PA-RISC/ALPHA/etc... architecture and write everythign in a combination of platform-customized C and hand-tuned assembly code. People still do this for games and visualization apps which need to drain every last ounce of performance from their hardware platform. Nobody does this for enterprise apps. It's not becuase they're "not interested in performance", it's because this approach is a waste of human resources, the most expensive component of any software project.

    If your non-technical manager/director/CxO is swayed by a head-to-head benchmark to go to Microsoft because "it's so much faster than J2EE", you need to enlighten them. Java kicks ass because of the powerful architectures we can create to leverage not only the strengths of the technology, but also the strengths and weaknesses of our development teams. We have "more than one way to do it" (borrowing the quote from the perl guys) and have the power of a well-documented set of patterns, architectures, and best practices that we can mix and match to fit our particular development team AND business problem. Plus, do you think you're actually going to get Microsoft enginners to come over and spend boatloads of time to optimize their code to fit your app for any reasonable amount of money? Unless your app happens to be the .NET PetShop (in which case your local SPCA may be intersted in paying you a visit), you're still on your own.

    If Microsoft and other vendors want to pay money for dedicated engineers, equipment, lab time so that the J2EE community can discover, refine, and document even more powerful optimization patterns and architecture design strategies, I say take full advantage of it. All that they'll be doing is giving us more knoweldge and more ammo. The more tested and proven development strategies we have, the more attractive the J2EE platform will be. Remember, knowledge is power.

    It's all about the architecture, stupid!! :)

    [And to make things totally clear, I am an employee of The Middleware Company, but the opinions contained in this post are entirely my own. I was and am not involved in any of this benchmarking stuff. Flames and the like should be addressed to me, personally...:)]
    Reply to this Reply to original

  97. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    I'd like to see a situation where an application is deployed as follows:

    1. Single machine with application server and code talking
    to database on separate machine.

    Now, using exactly the same code:

    2. Single machine doing load balancing handing requests to
    n-machines that talk to the database.

    Version 1 requires 2 machines, version 2 requires minimum of 4 machines (load balancing, worker 1, worker 2 and db)

    Why ?

    Well, this is exactly the behaviour of all the enterprise projects that I have been involved in. Development is done on limited resources (ie one box) and then deployment is done on large scale multi-machine environments. We do this without changing a line of code.

    All this carrying on about lines of code, productivity and scalability, lets at least put forward a test that looks at those sorts of things. I know J2EE can do this, I've been doing exactly this for years. I'm very interested to see what needs to be done with .NET to do the same thing.

    Cheers,
        -- jon
    Reply to this Reply to original

  98. The Middleware Company Announces Fair Benchmark Rematch[ Go to top ]

    Doing another benchmark with TMC involved is like M$ doing another benchmark. If J2EE needs to win, we need to tip TMC for that. Anybody wants to contribute?


    Some funny thoughts from Rick Oberg:

    http://roller.anthonyeden.com/page/rickard
    Reply to this Reply to original

  99. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Calm.

    There is no need for worry.

    Listen. The joy of programming in Java/J2EE is KNOWING that your system will be compatible and adaptable in the ENTERPISE. This is incredibly important. The wealth of J2EE, J2SE, and J2ME APIs, and JVMs running on damn near every platform assures this. (Bless the JCP)

    Of course .NET is faster. It&#8217;s not fair. They&#8217;re doing native calls. A closer comparison would be Java with JNI calls, but this is still not the same. The version of .NET MS releases with Windows is not the same one that they give the ECMA. The ECMA &#8220;Open Source&#8221; Version is the one that will eventually (MS hopes) let .NET leave the Windows nest and become a real prime time ENTERPRISE player (http://www.go-mono.com/). If you&#8217;re going to benchmark a version of .NET use the ECMA version (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/mssharsourcecli2.asp).

    Or, if this benchmark really gets to you - switch all your servers to WinTel boxes and SQL Server, and quit your bickering. You&#8217;re only hurting the J2EE cause and fueling the Microsoft Marketing Machine. A healthy debate is one thing, but a house divided is another. I can&#8217;t believe the TSS actually let MS have a link to such an obviously flawed benchmark (all benchmarks are flawed).

    Shame I felt compelled to write this on a Saturday night.

    Everyone drink a beer with me.
    Reply to this Reply to original

  100. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    J2EE Developers wake up and out of your dreams,
    Java can never come close to .NET in terms of performance, scalability, productivity.

    The only thing java can offer you is portability, but ask yourselves some questions :

    1. Do you allways create applications for customers who use varied operating systems ?
    2. Have you found any customer who want to run an application on more than one operating system ?
    3. Have you ever created a truely portable database centric application ?
    4. Which operating system you are working on for development (95% will say, of course windows) ?
    5. What do you and your customers like, a fast performing vendor specific application or a slow
      protable application ?

    I dont want to comment on the above questions , I want your comments.


    I visit many sites and I see more .asp and .aspx extensions rather than .jsp or .shtml

    Think of developer productivity. Something which you can do with java in one week can be done in

    one day with visual basic.

    Oracle choose java to create the best java IDE (one of the biggest mistakes that oracle did)
    Jdeveloper takes around 80MB of memory and when you start OC4J it goes to around 140 - 160 MB.
    And moreover it got hosed many times on my 256MB P4 PC.
    Java is so powerful that it can be used for many other purposes, not just creating an Memory

    hungry IDE.

    Oracle customers say that they reduced the development time by 20% by using jDeveloper, on the
    other hand MS (M$) customers have bring down development time from 6 months to 6 days with VisualStudio.NET ..............?

    I dont think that I am getting out of topic here, the above comment which I made is also about

    performance of java applications.


    .NET is not something which people created while researching on television sets,
    .NET is the outcome of 3 1/2 years of effort by MS (M$) out of which around 2 years where just

    brainstorming as to what developers need and how to increase productivity.

    http://msdn.microsoft.com/theshow/Episode009/default.asp



    My friends it took me 6 months to learn java/jsp/servlet/ejb stuff and just 15 days for ASP,
    and without any training I started creating applications with VisualBasic 6.0. Only the IDE and MSDN help was with me.

    Now you will tell me to use frameworks, I will say yes I can but what about the steep learning
    curve of the frameworks (struts,bc4j etc.,) accompanied with lots of patterns.

    I am totally satisfied with MC about the benchmark, and they dont need to do another one, as again .NET will win (beleive me, scold me if that does'nt happen).

    Regards Rasin
    Sun Certified Java Programmer.
    Reply to this Reply to original

  101. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Java can never come close to .NET in terms of

    >>performance, scalability, productivity.

    THAT, has yet to be proven. Except to those who are weak to the suggestions of the World's most powerful marketing team.

    >The only thing java can offer you is portability, but
    >ask yourselves some questions :

    Portability is not about targeting multiple platforms, but rather having the choice of any platform that I choose. It's true, if you ask a single person here which OS, hardware and database they use and you'll get one or two answers for each. But if you ask the Java COMMUNITY which operating systems, hardware and databases they use, you'll get thousands of combinations. I can tell you what every single .Net developer uses right now: Windows, VS.Net, Intel, SQL Server (possibly Oracle).

    The power of portability is CHOICE.

    >>3. Have you ever created a truely portable database
    >>centric application ?

    Yes. JPetStore 1.2.0 comes with DDL for 7 databases, and runs flawlessly on each of them without changes to application code.

    It also runs on at least 4 operating systems and 5 app servers without even a configuration change.

    >>4. Which operating system you are working on for
    >>development (95% will say, of course windows) ?

    Yes. And with Java I can develop on Windows and deploy on any operating system I want. Neat eh?

    >>5. What do you and your customers like, a fast
    >>performing vendor specific application or a slow
    >>protable application ?

    This is an interesting question indeed. Let's see, in my place of work 99% of our hundreds of in house web applications do not have scalability requirements beyond a few thousand users. So there has never been a problem on the small scale end.

    Our one or two major "Enterprise Applications" were written in Java because there are currently no other alternatives for running on enterprise infrastructure (64 way unix servers w/terrabyte storage).

    >>I visit many sites and I see more .asp and .aspx
    >>extensions rather than .jsp or .shtml

    I know a lot of web developers using ASP as a toy, but I know very few Enterprise Java developers who allow JSP pages to be exposed directly to the browser (ever hear of MVC?).

    >>Think of developer productivity. Something which
    >>you can do with java in one week can be done in
    >>one day with visual basic.

    Name the server side application specification. I'll race you.

    >>other hand MS (M$) customers have bring down
    >>development time from 6 months to 6 days with >>VisualStudio.NET ..............?

    Then why did it take 2 of their developers 5 weeks to develop the .Net Pet Shop?

    >>.NET is the outcome of 3 1/2 years of effort by
    >>MS (M$) out of which around 2 years where just
    >>brainstorming as to what developers need and how to >>increase productivity.

    2 years and they not once did they ever hear of eXtreme Programming? So where is the refactoring support anyway?

    >>My friends it took me 6 months to learn >>java/jsp/servlet/ejb stuff

    Only 6 months??? You are talented indeed!

    >>and just 15 days for ASP,
    >>and without any training I started creating applications
    >>with VisualBasic 6.0. Only the IDE and MSDN help was with
    >>me.

    Why don't you learn C#, MFC, COM/DCOM and get back to us on that 15 days....

    My apologies for the sarcasm. I just got my but kicked in Tribes and I'm bitter.

    Cheers, ;-)

    Clinton
    Reply to this Reply to original

  102. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I know a lot of web developers using ASP as a toy, but I know very few Enterprise Java >developers who allow JSP pages to be exposed directly to the browser (ever hear of MVC?)


    Do you mean to say that .NET does'nt support MVC.
    What is MVC in true sense according to you ? Hiding page extensions ?

    >Then why did it take 2 of their developers 5 weeks to develop the .Net Pet Shop?
    I would say it took 10 weeks for MC developers just to optimize the java pet shop.

    >2 years and they not once did they ever hear of eXtreme Programming? So where is the refactoring support anyway?

    Well they dont find any need for it.

    >Only 6 months??? You are talented indeed!

    Yes indeed, thanks.

    >Why don't you learn C#, MFC, COM/DCOM and get back to us on that 15 days....

    I'm on my way learning C#, MFC is a different concept.
    and Web Services is a better choice than COM/DCOM

    Rasin
    Reply to this Reply to original

  103. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Do you mean to say that .NET does'nt support MVC.


    I said no such thing.

    >What is MVC in true sense according to you ? Hiding page
    >extensions ?

    No, but it does mean that the view is never accessed directly. In this case the JSP is the view, so one of the end results is that the JSP extension is never displayed in the address bar. I can't believe I just had to explain that to YOU (the talented developer)! ;-)

    > I would say it took 10 weeks for MC developers just to
    > optimize the java pet shop

    I wasn't there, so I cannot attest to the quality of the application code or the application servers. Furthermore there were no J2EE vendors on-site.

    The fair comparison would be: how long would it have taken a non-Microsoft engineer to optimize the .Net Pet Shop to reduce the line counts by 1800 and increase performance further?

    You would be better off not using the example of a flawed study in your arguments.

    Cheers,

    Clinton
    Reply to this Reply to original

  104. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Hi Clinton,

    Should TMC use JPetStore instead of the original Sun's implementation.

    Your app rocks and with few optimizations, it can surely kick .Net ..........
    Reply to this Reply to original

  105. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Rolf,

    <quote>
    This Windows crap that produces code that is 8 times faster, 4 times more maintainable and with twice the productivity? That is a free ISO standard with an open source implementation that doesn't cost anything to use and redistribute?
    </quote>
    I mean the operating system (I never heard that Windows is OSS). This comes from my experience with Microsoft. I've been working many years with Microsoft "technology" and this is my conclusion about it's quality.

    <quote>
    The typical J2EE developer who use a tool to generate tons of code of which he absolutely understands nothing?
    </quote>
    If you mean (a fantastic) tool like XDoclet - you have to tell it what to generate, it's no magic thing that knows what application you want to generate.

    Cheers,

    Lars Fischer
    Microsoft Certified Systems Engineer (NT-Track)
    Reply to this Reply to original

  106. What????[ Go to top ]

    I would say it took 10 weeks for MC developers just to

    > > optimize the java pet shop
    >
    > I wasn't there, so I cannot attest to the quality of the application code or the application servers. Furthermore there were no J2EE vendors on-site.
    >
    > The fair comparison would be: how long would it have taken a non-Microsoft engineer to optimize the .Net Pet Shop to reduce the line counts by 1800 and increase performance further?
    >
    > You would be better off not using the example of a flawed study in your arguments.
    >
    > Cheers,
    >
    > Clinton


    Hmmmmmm......

    "In May of 2001 Sun Microsystems® introduced the Java® Pet Store as a demonstration implementation for J2EETM-based Web applications. According to Sun, the Java Pet Store application illustrates some of the best practices for J2EE development, and is provided as a design pattern for customers to follow when building their own enterprise Web applications. Sun maintains a blueprint series Web site on the Java Pet Store at http://java.sun.com/blueprints/. The Java Pet Store also ships as a primary example application in many leading J2EE application servers. "

    - Key words(best practices, design pattern, follow when building their own enterprise Web applications, primary example)

    When you say " The fair comparison would be: how long would it have taken a non-Microsoft engineer to optimize the .Net Pet Shop to reduce the line counts by 1800 and increase performance further? "

    That is just to funny. The Java Pet Store was designed by the "Java Gods" Sun Microsystems® right? So, why not have the ".Net Gods" write the Pet Store in their code just as Sun did the first one. It seems to me the the "fair comparison" did happen. The people the "made" Java wrote a application using "their Java code" and called it Pet Store and crowned it as "their best practices for enterprise web applications". Sun the developers of "Java" also before November of 2001 was pushing Java developers to follow their Pet Store as their primary example of "how to do it right".

    Recap*** Sun Microsystems® developed "Java", Put out an web application using their version of Java and tells you the programer to follow their way of developing enterprise web applications. Microsoft in turn took the same look, feel, and function of Sun Microsystems®'s best practices for enterprise web applications example and re-did it in .NET and came out with benchmarks then the Java version. **** - Why on gods green earth would you state "The fair comparison would be: how long would it have taken a non-Microsoft engineer to optimize the .Net Pet Shop" When the Java version was done by the "Java Gods" themselfs?

    oh, when you said " The fair comparison would be: how long would it have taken a non-Microsoft engineer to optimize the .Net Pet Shop to reduce the line counts by 1800 and increase performance further? " What you really mean is "Dude, It's like Microsoft came out with this new way of programming and man did it rocked all over my way of developing. Ya, so dudes they like cheated or something. Dudes, to make it easier for ya to understand the fair test should be do something like this.... I will like use cars in my example so we all can understand. OK, take "Ford" ya know the truck maker and have them make a truck. Then take some kids that work on cars in their back yard and have them make the same truck as Ford did but not able to use the super computers that Ford used when making their truck. Ya, Dudes!!! That's the way we can win And make it "Fair" Take my example and plug Sun Microsystems® as Ford, Java as the Ford truck, .Net as the Kids version of the truck, Kids that work on trucks and the Kids. But remember don't let Microsoft be apart of the test how cares the they developed .Net. Ya, This would be "fair".


    Now, is that what you where trying to say???

    Everyone Java is good and .net is good program in what you like to program in. Just have fun doing it.

    Dane Jurkovic-
    Reply to this Reply to original

  107. What????[ Go to top ]

    I would say it took 10 weeks for MC developers just to

    > > > optimize the java pet shop
    > >
    > > I wasn't there, so I cannot attest to the quality of the application code or the application servers. Furthermore there were no J2EE vendors on-site.
    > >
    > > The fair comparison would be: how long would it have taken a non-Microsoft engineer to optimize the .Net Pet Shop to reduce the line counts by 1800 and increase performance further?
    > >
    > > You would be better off not using the example of a flawed study in your arguments.
    > >
    > > Cheers,
    > >
    > > Clinton
    >
     
    Hmmmmmm......
    Ya also said "You would be better off not using the example of a flawed study in your arguments. " - Hell the example that "you" are calling "flawed" is Sun Microsystems® introduced the Java® Pet Store as a demonstration implementation for J2EETM-based Web applications. Not Microsoft's. I could not agree with ya anymore Clinton It is "flawed" Sun Microsystems® the developers of Java® did a really bad job putting it out there. But what else could they have put out there? Sad that the "top dogs" put the best example based on their (Sun Microsystems®) Java code and you (Clinton) think that it is "flawed". Maybe Sun Microsystems® should have had you develop their standards for them and put out one of your applications as the example. Haha


    Dane-

    Dane Jurkovic-
    Reply to this Reply to original

  108. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    J2EE Developers wake up and out of your dreams,

    >Java can never come close to .NET in terms of performance, >scalability, productivity.

    I have to agree...

    For an evaluation of J2EE for a life science project I decided using the following tools/techs: JBOSS (JSPs /w Tomcat), Netbeans IDE, Ant, XDoclet. The basic idea was to have a server-side platform built with open source tools. As a C++ Developer for 12 Years I knew Java isn't the fastest language on earth, but who cares if you can *scale*?

    - First of all, to my surprise, the average Java Developer didn't knew most of them. Most of them do some kind of build process, some kind of IDE, Tomcat is fairly popular though. So you have to sell all these things to your developers. And they have to be trained.
    - And, you have to sell all of these things to your boss.
    - Some of these things are voluntary efforts. If they fail, your whole build process fails (in this case). If XDoclet doesnt support another Appserver, then you can't use it (JonAS at that time, has changed by now)
    - In the end I had a quite nice build process (start ant which starts xdoclet then does compile, then build, then deploy. then startup of JPDA for debugging). Still quite complicated - now go ahead and sell that to your developers and then to your boss.
    - JSP as a presentation layer needs careful planning (taglibs, no code in jsp): sell that to your developers. Other presentation layers (Looked at Turbine, Struts, Tapestry) are really good, still require additional training; Tapestry seems to be really really good, but it is a one-man effort (quite an excellent effort!), which in the end is a risk.
    - EJBs: Lots of Issues: Portability between vendors (apart from XDoclet approach), Performance of Entity Beans (see http://www.cs.rice.edu/CS/Systems/DynaServer/perf_scalability_ejb.pdf), Inheritance for EJBs, Code reuse in general.
    - In the end a not very friendly development environment (netbeans, ant, xdoclet, jboss) even though its probably one of the most flexible.
    - *Scalability* on i386 : See petstore revisited.
    - clients for state-of-the-art interactive apps with java (swing).. Forget it. Which means use a native whatever app and interoperate with the Appserver by some other means. CORBA? seems natural. Now lets check out the jboss homepage: "JBoss/IIOP is currently in alpha state.". Just another RISK.

    Now compare this with a VS.NET thing. You pay the licences for that VS.NET thing, then go to your team and tell them to eat it: learn the IDE, learn ADO.NET, ASP.NET., WinForms, Webforms AND FINITO:

    Fixed Costs and Fixed Risks.

    There are certainly a lot of high-end apps that require hardware thats currently only supported by J2EE. Ok, I guess people have no choice there. But definitely a lot of CPU cycles get burnt there for nothing... which sometimes doesnt matter but still leaves a bad taste.

    After some testing and evaluation we pulled the plug: J2EE with EJBs is too complex (productivity and programming skills) and did not scale in our environment.

    Perhaps Plain Javabeans with Struts and a some kind of JDO would have been perfect.
    Reply to this Reply to original

  109. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I can't believe this discusson is still going on.

    M$ only runs on wintel, and isn't portable. End of discussion, end of story, no need to debate ANY more guys. It's over! You start out with a KNOWN ceiling, and you know from day one you will NEVER be able to scale your app past a certain point. WHO would do such a thing? We've all seen the projects that "will always be small, and never grow." Ya right! As if. Those don't EXIST. So you're looking at an eventual REWRITE anyway, so why bother? Just start out with the right technology to begin with.

    Let's see the test re-run with the J2EE app running in a clustered DB2/OS390 mainframe environment or may on a Cray supercomputer, that's a more accurate demonstration of what J2EE is capable of, NO ONE would ever DREAM of running a good J2EE app in a winbloze environment. Get real, and wake up and smell the Java people.
    Reply to this Reply to original

  110. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    We've all seen the application that scales well from the first version without a complete rewrite. Yeah, right. Those don't exist
    Reply to this Reply to original

  111. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    <quote>
    First of all, to my surprise, the average Java Developer didn't knew most of them. Most of them do some kind of build process, some kind of IDE, Tomcat is fairly popular though. So you have to sell all these things to your developers. And they have to be trained.
    </quote>
    This is sadly true. It is really hard to find average Java developers, who have the capability to understand those tools directly from beginning. Many average developers never work without IDE. This means they never get in touch with the build process itself. What they know is just using "drag&drop" and "wizards" (typical Microsoft environment).
    They just don't understand the process behind those wizards. I think, there are a lot of works to do in this area and the answer is surely *not* to build more and more wizards for every stuffs ;-)

    <quote>
    *Scalability* on i386 : See petstore revisited.
    </quote>
    This is not quite true. You can always add your cluster with some new i386 hardware. If you think your application does not perform well, you can add a new hardware and this is very easy to do with J2EE and also with Open Source products. I agree that it's not easy to tune up a JVM with its many parameters but it's very interesting to see, what those
    parameters can do for you (heap memory, garbage collector, etc.).

    <quote>
    JSP as a presentation layer needs careful planning (taglibs, no code in jsp): sell that to your developers. Other presentation layers (Looked at Turbine, Struts, Tapestry) are really good, still require additional training; Tapestry seems to be really really good, but it is a one-man effort (quite an excellent effort!), which in the end is a risk.
    </quote>
    Yes, this is true. That's why I'm using XMLC for my project. Because XMLC is based on XML and if your developers can work with XML DOM parser, they surely can work with XMLC.

    <quote>
    EJBs: Lots of Issues: Portability between vendors (apart from XDoclet approach), Performance of Entity Beans (see
    http://www.cs.rice.edu/CS/Systems/DynaServer/perf_scalability_ejb.pdf),
    Inheritance for EJBs, Code reuse in general.
    </quote>
    Yes. It's not easy to write the vendor specific deployment descriptors, I have to admit this. I'm just amazed to see in many discussions that many Java developers hate EJBs. I like them a lot ;-) They are very easy to write (also without xDoclet). They have a good mix between Java (bean implementation) and XML code (deployment descriptors). They are easy to extend. They make it easier to write a real component (Differentiation between *Session/Workflow
    Object/Module/Architecture* and *Entity/Business Object /Type/Data*).

    LoDe
    http://openuss.sourceforge.net
    Reply to this Reply to original

  112. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Amanjit,

    <quote>
    Now compare this with a VS.NET thing. You pay the licences for that VS.NET thing, then go to your team and tell them to eat it: learn the IDE, learn ADO.NET, ASP.NET., WinForms, Webforms AND FINITO:

    Fixed Costs and Fixed Risks.
    </quote>


    It gives you

    * Limited hardware/os architecture
    * Limited scope/scale of projects you can work with
    * Limited developer skillset, I find that Java developers work nicely in a windows environment, but I don't find a lot of MS developers who can work in a unix environment when called to do so (I find some, but not a lot). These sorts of occassions happen quite a bit, actually.
    * One vendor only. Now some would argue this is a good thing. However, you are at their mercy. After all, what are you going to do, switch to another if there is a problem? (The answer in the MS/.NET world is no). Now granted most companies don't switch vendors mid project, but being at the mercy of one vendor and limiting yourself to one vendor's strategy and ideas is not a good idea. In the J2EE world, you have one specification, and many vendors. Each with a somewhat different approach. Choice.

    It's kind of funny though what you say about the Java developers you ran into. I personally don't know any Java developers who DON'T know at least one J2EE app server (JBOSS is the most popular), one IDE (Netbeans and JBuilder are the ones I see quite often), Ant and XDoclet.

    And training developers is easy, if you have the right developers. Granted, if you have an entirely green set of developers to work with, J2EE might seem somewhat foreign, but you get what you pay for. If you are building entperise apps, you may want to hire at least a few people with that experience.

    Cheers
    Ray
    Reply to this Reply to original

  113. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Can't let this one go unanswered..

    >Tapestry seems to be really really good, but it is a one->man effort (quite an excellent effort!), which in the end >is a risk.

    Tapestry has evolved. The project has adopted Apache voting, identified 5 committers, and has voted to change licenses (Apache)!

    Geoff
    Reply to this Reply to original

  114. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I suggest to use open-source and famouse frameworks (like struts ,hibernate ,xdoclet ) and then analysis of the line numbers.
    Beacuse almost all projects in j2ee, use these frameworks.
    And no one has time to reinvent the wheel (at least in j2ee community)
    Reply to this Reply to original

  115. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Why don't you try to make a set or real benchmarks that will produce useful results, starting from C# vs. Java.

    I don't think this "Misuse Pet Store more then Microsoft did" game will give us true answers.
    Reply to this Reply to original

  116. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I have been following this whole debacle from the moment it was released and i am amazed at the discontinuity within the TMC organization.

    I see Floyd attempting desparately to distance himself and TSS from the very hand that feeds it. Whatever way they work internally, as far as the outside world is concerned TSS = TMC. Hell, even as you create an account on TSS you are given lots of TMC messages regarding how TMC sponsors, owns, maintains TSS. So lets not start pretending you are two separate entities. We ain't buying it!

    So the question is, should they retest? I don't think so. The best thing TMC/TSS could do, is to return to J2EE and forget about .NET for the time being. Leave the benchmarking to the experts. There are a number of bodies that specialise in these sort of results, and TMC isn't one of them; as they have now proven.

    I think the TSS do a great service for the J2EE Community, and it only saddens me to think that the other Java editions don't have such organizations helping them out. To this end, TSS are in a rather unique and special position. This excercise, while i am sure was well intended, has blown up in their faces big time, with many of the J2EE vendors now disillusioned with TMC and TSS. A dangerous situation to be in.

    I will be interviewing Ed Roman tomorrow afternoon at OracleWorld, and i am very interested in hearing his personal thoughts on the whole issue now that some time has elapsed.

    One thing i will say though. Ed Roman and his team, in the last week has now had a taste of what it must be like to be Microsoft; with consipiracy and accusations running like wild-fire through the news community.
    Reply to this Reply to original

  117. Apples for Apples[ Go to top ]

    I must confess that I have not read the report in the amount of detail that perhaps I should have. However, there are some glaring points that I think need to be addressed in order to balance the bendmark figures in a round 2.

    1. Exercise skillful use of EJBs. For example, if servlets are access EJBs running on the same host, then the access should be via Local versus Remote interfaces to factor out the networking overhead. Also, utilize the session facade pattern to reduce round-trips to entity beans from servlets.

    2. Use the exact same database that the .NET solution used. Don't use a different vendor's implementation as that taints the equality of the test. In order for the test to have merit, it must use as many similar hardware/software components as possible.

    3. As suggested in the response letter, get some of the vendor's involved. IBM, Bea come to mind.

    Better luck next time.
    Reply to this Reply to original

  118. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    The purpose of the tests is to show performance and scalability differences between J2EE and .NET platforms, right? If you're interested in the performance of that *one* *layer* of a distributed system, it makes sense to keep all else as constant as you can (for at least part of the tests), and vary *only* the app server in your testing.

    This wasn't done in your first set of tests, so we have no way of knowing if the differences in performance were due to more tuned/optimized database performance or in the (J2EE or .NET) application server tier (which was supposedly the focus). Please run at least one set of tests to help us separate out these affects...

    You also didn't show the Error rates or effects of more recent JVMs very clearly.

    Suggestions:

    First and foremost...
    1) KEEP THE DATABASE TIER AS CONSTANT AS POSSIBLE FOR AT LEAST ONE SET OF TESTS.
      a) USE THE *SAME* DATABASE FOR the .NET and J2EE tests.
      b) USE THE *SAME* STORED PROCEDURES.
      c) USE THE *SAME* OR *VERY* SIMILAR DATABASE DRIVERS.

    2) If at all possible, separate out the time spent in the database per page request from the total time serving the page.
       -Instrument the database calls to get metrics of how much of the page response times are spent in the database (vs. the app tier).
       -Putting this (performance recording) instrumentation in the database tier would ensure that you weren't measuring differences between (JDBC/ODBC) drivers and could separate out database time...
       -Have these datapoints available so that we plot our own load curves, as you did for the first tests.

    3) Have your graphs show other metrics of machine resource usage on both the app-tier and database servers as load and # of clients increase. At a minimum, show total CPU usage (per processor, and average), and maybe memory/disk/io as well.
       -Very likely, strong increases in CPU usage should correspond to strong increases in page response times. [It would be good to confirm this by seeing it...]
       -Have these datapoints available so that we plot our own load curves, as you did for the first tests.

    4) CHECK FOR ERRORS in the returned (HTML) page requests, and report this as the load and # of clients increases.
       -This is always something to weigh in when scalability is evaluated.

    5) Use JDK 1.4.1, and also JRocket for at least one set of tests. Show how performance varies from JDK 1.3.1 (which is probably the only JDK you can use for the IBM Websphere tests) to 1.4.1 to JRocket. Even if this can only be done using WebLogic, it should also show roughly how much faster the Websphere solution will be as WebSphere can take advantage of those JVMs...

    6) Include JBOSS into your testing. There is no reason not to, and many of us would be interested in seeing the results.

    7) Make the coding enhancements mentioned by Rickard Oberg, et al. Ask for expert help in writing the J2EE code and feedback on comparisons with the .NET code...
      -Publish all code for both .NET and J2EE prior to testing.
        -Allow some time (2-3 weeks?) for community/industry feedback prior to testing.

    Glad you're going to try this again (at least once).
    Reply to this Reply to original

  119. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Just study at the end of the day the code from MS.
    They won the first benchmark due massive (and absolutely correct by my mind in this case) usage
    ASP.NET tag OutputCache. The whole page is cached. So it was extremely good for used test scripts.
    Now (in the latest PetShop) the same cache has been used through Cache call in the middle tier. But practically it is the same. ASP pages are very small and just use this cache through custom tags (controls in ASP.NET terms)

    This decision causes a very low overhead. Of course, it lacks many of EJB&#8217;s features, you can not split it between different boxes etc. but who will care. It means, that there are no reasons to use EJB against that (and especially without local interfaces). Just a plain JDBC with some cache support is a right choice. Simply check out existing solutions for J2EE.

    Dmitry Namiot
    Coldbeans

    P.S. Just a remark:

    >but I know very few Enterprise Java developers who allow
    >JSP pages to be exposed directly to the browser (ever hear
    >of MVC?).

    a never say a never again. Such extreme approach is (by my mind of course) a direct way for J2EE to nowhere. I think we have a too long history of stories like J2EE = = EJB, MVC is the only choice, a long hand written XML configuration file is a right stuff to deal with, while IDE is for VB idiots only etc. You have to use what do you need for your task under the given terms/conditions. Yes, you should know about MVC, but do not think that it is a panacea. Again, all this is IMHO only. Let we discuss technical things here.
    Reply to this Reply to original

  120. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    The answer to the question if you should do a second benchmark is: DEFINITELY YES. You should do it both to rehabilitate your image/credibility and to porvide the J2EE community with a benchmark widely accepted WITHIN the community. Such a benchmark would be really useful, helping developers create a fair (not cluttered with marketing and hype) image about both technologies in the REAL WORLD.
    Reply to this Reply to original

  121. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Q#1
    Being a dedicated Java developer, I was initially disturbed by your benchmarks, but a little reflection convinced me that this is actually a great opportunity in disguise. Open competition motivates innovation. With all these application server providers, hiding behind their licensing agreements, it was also refreshing to see some real data. It is not in the best interests of developers, much less businesses, not to have this basic information. I commend TSS for all your hard work and encourage you to rise to the occasion and go on to become the primer source for objective server data, performance and otherwise. As for me, it would be invaluable information in choosing venders for both my clients and my own company.

    Q#2
    I don’t feel the tests gave Java a fair shake, but nonetheless provided a good base to start from. One thing that might give a broader perspective and emphasize the reason for Java’s success would be to publish a table of platforms supported by each camp.

    I don’t expect Java to ever beat Microsoft on their own platform, but I’d like to see the benchmarks rerun using Java’s latest technology (i.e. JDK 1.4). We need to make sure we’re in the running, and if not why, so it can be addressed.

    A really cool idea would be to have Petstore benchmark runoffs on standardized Windows and Linux platforms open to all (sponsors and prizes?).

    Another headline grabber would be to have an open class where anything goes :).

    I think better ways of measuring source code size, which eliminate style and formatting preferences, should be sought.

    Your challenge is find a way to be objective, open, and inclusive. Recognition and respect will naturally follow…

    Richard Easterling
    Reply to this Reply to original

  122. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Considering that serverside.com is run by the middleware company, and the middleware company is owned by precise software solutions inc., and precise software solutions is a strategic partner of Microsoft, the comparison will NEVER be fair.
    The serverside is effectively OWNED by microsoft.
    Don't you get it yet????
    Who do you think is pulling the high level strings here?
    It's a shame since I really respect Floyd and others and find their books and advice some of the real bibles of the trade.
    But this is what Microsoft do - shouldn't we have learnt that by now?
    Open your eyes!! MS has succeeded in it's normal slimy way to infiltrate the J2EE community and spread FUD.
    That's what they're trying to do: divide and conquer.
    What really gets me is we have been STUPID another to not notice the transition. I'm really ashamed of that.
    Time to start up a new J2EE community guys.
    And I really hope the great architects here like Floyd and co., will stick their morals and join us too.

    Oh by the way, this is the evidence for my "conspiracy theory"
    http://www.tamirfishman.com/download/precise_18082002.pdf
    http://www.precisesoft.com/Partners/Strategic/
    Reply to this Reply to original

  123. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Tim,

    > The serverside is effectively OWNED by microsoft.
    > http://www.tamirfishman.com/download/precise_18082002.pdf
    > http://www.precisesoft.com/Partners/Strategic/

    I read both articles and I found your theory to be far fetched.

    Precise is a Microsoft partner, that is true. But this is what they write about the nature of their partnership:

    >>>> start quote from site >>>>

    Precise enjoys an OEM relationship with Microsoft, which has licensed Precise/StorageCentral SRM technology for use as an optional add-on with Microsoft's Windows-Powered Server Appliance Kit (SAK). The SAK is the foundation software for server appliances currently sold by Microsoft's OEM partners such as Dell, HP, Compaq, IBM, NEC, and Maxtor.

    "Precise/StorageCentral SRM complements the proven reliability, manageability and availability of Windows 2000 technologies and enables OEMs using the Windows-Powered Server Appliance Kit to deliver a richer NAS solution to their customers and to get that solution to market quickly." -Keith White, Senior Director of Marketing for the Embedded and Appliance Platforms Group

    >>>> end quote from site >>>>

    To me it seems this doesn´t have anything to do with Java or .Net.

    Also Precise did indeed buy The Middleware Company, again you are right there. But since this was quite a small acquisition for Precise and since Precise has large investments in non-Microsoft technology I think this does not impact the way The Serverside itself feels about J2EE versus .Net.

    Just my two Eurocents...

    Hans
    Reply to this Reply to original

  124. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Hans - do you really think Precise will describe it's relationship with Microsoft truthfully if there was some underhand motive?
    I can just see it now:

    "Precise is a strategic business partner of Microsoft. In return for giving MS access to our J2EE community, we get lots of nice sales leads from MS etc. etc."

    [My note- above is an example of what MIGHT have happened, I am not alleging the above case is true]

    Of course they're not going to say something like that - what did you expect?

    Microsoft need to infiltrate the linux/java/oss community in order to survive - and that is exactly what they are doing.

    And us suckers are falling for it.

    ( BTW Really I am not really this paranoid in normal life ;) )
    Reply to this Reply to original

  125. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Strategic partnerships are rarely exclusive... I know for sure a handful of companies with strategic partnerships with Microsoft AND some J2EE vendors. Guess what? They're doing more J2EE projects than Microsoft tech.
    Reply to this Reply to original

  126. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Tim,

    The more I read about it the more I start feeling your way. You are right! Some good articles have been published on other sites as well, most of them referenced in one or more posts here. For me these articles already make up for any lost faith in J2EE and as so they also do for all other managers in my business as they did not even read the original benchmark (they have me for that).

    Now I wonder how we are going onwards from here. A retest by TSS will not be believed by anyone.

    Hans
    Reply to this Reply to original

  127. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Precise has no J2EE strategic partners...You missed the most important point. No BEA, SUN, ORACLE, IBM , ETC.
    Reply to this Reply to original

  128. Microsoftie speaks out on FUD[ Go to top ]

    Since I work at Microsoft I should disclose that anything to follow is a personal opinion and not that of my employer, etc., etc., blah, blah.

    That said, there is an unbelievable amount of FUD flying around. Let me help clarify with a few things I know from personal experience.

    Microsoft and TSS were both surprised at the results. Our contract required that *any* results be published. We hoped our assumptions about .NET being faster would be validated but the outcome was way better than we thought it would be. Isn't that nice?!

    Now as a J2EE architect for the last five years and an app server implementer (I wrote containers the TX manager, and a security framework) I believe I can speak with some authority when I say J2EE is a great design that very few people on the planet can use well. J2EE is a great tool for solving some very complex systems development problems. However, it is way beyond the grasp of mere mortals. Most "J2EE" projects use JSP and/or Servlets. Very few use EJBs or MDBs because the developers don't know how. Hell, half the architects aren't making the best choices either.

    While I have been able to put together some J2EE-based systems I'm proud of, my personal feeling is that if I had the opportunity to do it over today with .NET 1.1 I would use the MSFT technologies because the project would get done faster with less-skilled developers (i.e. less $$!). Despite five years to educate developers on J2EE, I see few enterprises able to maximize their investment in the model.

    Because I'm focused on delivering the best bang for the buck and the most functionality in the least time for my customers (e.g. LOB managers) I've cared less about the "elegance" of the solution and a lot more about manageability and price/performance. With good interfaces I can replace the implementation behind them later.

    It would be great to see the discussion start focusing on what works in each model and how each platform could be improved to maximize the benefits for all. Web Services is obviously going to help us interoperate so let's just use the right tools for the job, ok?

    Let me conclude with one final thought. Before joining Microsoft I was out of work for nine months. That's a long time to live on your savings folks. One thing I learned is that right now cash is king and that's the position your CIO/CTO are in. If you're not leveraging the route of least expense (please, please compare J2EE and .NET TCO for your own benefit) you are contributing to the problem in his/her mind and more likely to be cut in the next round of layoffs. That's harsh, but also the stone cold truth. Consider how much value your "elegant" designs add from the perspective of a cash-strapped business and you will quickly realize that your best shot at continuance and promotion rest on saving money for your cost center. Now take a hard look at J2EE and .NET and find your own strategy to survive and thrive. What is your bottom line impact going to be in 2003? Positive or negative?
    Reply to this Reply to original

  129. Microsoftie speaks out on FUD[ Go to top ]

    Adam said: "(please, please compare J2EE and .NET TCO for your own benefit)"

    J2EE, being a specification, costs nothing. ;-)

    Seriously, I can get J2EE tools (NetBeans, Sun ONE Studio, Eclipse) and servers (Tomcat, JBoss, Sun ONE AS7 PE) for no cost. What do I need for .NET and how much does it cost?

    Are you saying that it will cost me more to operate my free software than to buy and operate .NET products?
    Reply to this Reply to original

  130. Microsoftie speaks out on FUD[ Go to top ]

    The biggest chunk of the cost of devloping a system is the salary of the developers. Effective J2EE developers tend to come from Unix/C/C++ and early version VB (I am talking about v4 and earlier) background who have a minimal of 5-7 years of experience. In contrast, your average .NET developer most likely came from the VB/ASP world, who probably learned VB from v5 and later and has less exposure to OOD/OOP (personal observation, so no flame please). So the total cost of devloping a .NET application is typically less than that of a J2EE app.

    IMHO CIO's and project managers today as always face the touch decision: do you hire less experienced developers and adopt the easier to use technology to lower TCO? This is not necessarily a right/wrong answer to this question. I guess this is not such a huge issue today as the number experienced developers who are willing to work for food is a dime a dozen.
    Reply to this Reply to original

  131. Microsoftie speaks out on FUD[ Go to top ]

    Professional software developers, project managers and CIO's should also understand that there is the potential for an overwhelming proportion of the cost of a system to be incurred after development has been finished, during its maintenance phase. The additional cost of hiring experienced developers can be recouped by the resultant lowering of ongoing costs and the ability for a system to be easily adapted to meet changes in business conditions or new market opportunities.

    Of course its easy to say that, but quite another to get people to adopt a strategy to spend additional money now to save money later, particularly these days.

    (I actually find it amusing that so many people spend countless hours arguing about performance and the cost of tools. Sure they are important, but in most cases they don't make that much of a difference in the big picture.)
    Reply to this Reply to original

  132. Amen to Business Value[ Go to top ]

    I've read this entire, exhausting thread. I've also followed many of the

    links provided. (Link to the Mono project, ZD article on benefits of .NET,

    many others).

    I've enjoyed the interchange between Cameron and Jim. Their initial posts

    included instructive code examples and rational, gentlemanly discussion. (The

    thread degenerated at one point, and reminded me of two theologians debating

    about how many angels can fit on the head of a pin. Thread returned to sanity

    later).

    I am the type of programmer characterized in an earlier post as an "average

    shmoo". I'm not, however, a complacent "average shmoo".

    I spend a lot of time trying to learn new things. The hardest thing to do is

    not learning new things, but trying to figure out which new things to which

    to apply that effort.

    From a purely economic standpoint, I see that adding the keyword "Java" to a

    resume is worth about a $20,000 salary boost, while adding "VB", "COM",

    "N-Tier" to a resume opens up thousands more employment opportunities.

    For me, the single, most rational post has come from Adam McClure. Adam

    elegantly states my perspective on the purpose of my job:

    <quote>
    Because I'm focused on delivering the best bang for the buck and the most

    functionality in the least time for my customers (e.g. LOB managers) I've

    cared less about the "elegance" of the solution and a lot more about

    manageability and price/performance. With good interfaces I can replace the

    implementation behind them later.
    </quote>

    This quote -- for me -- was like finding a pearl in the dogsh**. My CEO and

    CFO don't care what platform/language/tools I use, so long as the

    applications I deliver:

    o Solve a real-world business problem
    o Incorporate all (or most) of the requested features
    o Are delivered at the lowest possible cost...
    o ...in the shortest possible time

    While I love the tools Microsoft have provided for RAD development, I resent

    the fact that it's technology is churned so often that by the time I have

    become decently proficent in the last OS/Programming Tool, I am "frogmarched"

    into the new via the planned obsolence strategy that has proved so successful

    in other consumer products.

    I also resent the fact that MS locks me into MS everything. I have 5 years

    experience administering NT/2000 domains, gang, and I have to tell you that,

    in my opinion, they're flaky. I'm not opposed to Microsoft, I just hate being trapped.

    I resent being lied to by MS. How long do they think they can get away with:
    "Don't buy competitor A's product that works today. Wait until you see what

    this vaporware demo version of our new stuff will let you do!" (Apparently

    forever).

    While Mono holds the promise of being able to apply my hard-earned knowledge

    to more than one platform, I'm deeply suspicious that Microsoft will somehow

    subvert it to lock in the Microsoft-everywhere business model. (Remember

    J++?)

    After following this thread, I'm sorely tempted to check out of the entire

    Java vs. .NET debate and go with Delphi/Kylix for cross-platform and compatibility and Web development. (Can't seem to find anywhere near the number of resources -- books, usenet, etc for Delphi, though. :-( )

    <rant>
    I've always detested zealotry in any form. I call zealots "bug-eyed true

    believers". ("Soon, Dr. Jones, you vill become a TRUE believer".) You cannot

    dissuade a "bug-eyed true believer" from his/her point of view, because -- at

    bottom -- you always arrive at some dogmatic article of faith. You see this

    in BSD Klingons, MS "smart guys", Macintosh fanatics, DB gurus -- pick a

    type. Why does our profession attract so many snotty, arrogant people?
    </rant>
    Reply to this Reply to original

  133. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    tim fox,

    "
    The serverside is effectively OWNED by microsoft.
    Don't you get it yet????
    Who do you think is pulling the high level strings here?
    "

    This is simply not true. I've addressed this issue at length here:
    http://www.theserverside.com/discussion/thread.jsp?thread_id=16316.
    Reply to this Reply to original

  134. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    The test performed by TMC proved to be very interesting (if slightly alarming), but two main points come to mind when assessing the fairness of the test.

    1)Are the architectures of the .Net and J2EE applications comparable ?

    2)When comparing J2EE vs .Net in terms of productivity, LOC etc, what should we be comparing?
    After all the .Net comprises of the platform + tools + frameworks, which is obviously geared to fast turnaround. But in the test, I believe the J2EE application did't use any frameworks or specialised tools hence the high LOC count.

    To overcome the above problems, I believe that a new benchmark test should be approached like this :

    1) Define the petstore application in terms of functional requirements (i.e the aplication has to do this, that, has this transactional behaviour etc, etc), but do not stipulate any particular architecture or technology to be used.

    2) Invite developers/companies from either side of the J2EE .Net divide to use any platform, tools, frameworks of thier choice in order implement the application specification in any way they see fit. The only rule being that the implemented application comforms to the functional requirements specified.

    3)Test the various applications on the same hardware and O/S, and for J2EE apps test on any other supported hardware and O/S's.

    This should give a more realistic indication of how much performance is possible with either platform and also the relative performance of any given architecture.

    Secondly, the comparison of productivity will be more realisitic as the use of tools and frameworks will be closer to a real development situation.

    Keith
    Reply to this Reply to original

  135. Please! If you want J2EE to win ...[ Go to top ]

    If you want J2EE to win, please let me contribute a PetStore that is going to be much faster, less code and cheaper than .NET.

    I have 14 years experience in SW and am certified P&T, SUN Java Certified, OO Certified, J2EE instructor, etc.
    I am sure that I could get other OpenSource people to work together.

    Most of the benefit is going to be that I will use J2EE w/o the EJB. (no one ever uses full API). Also Static Data Source, Struts, Turbine Cache, Cached RowSet, etc.

    OT: Mono .NET runs on Linux, and you can have ODBC to MySQL/pgSQL. There is .NET version of MVC called NETMav, similar to Struts.
    OT2: Java Servers can run on Windows, such as Tomcat or Resin, and they can talk to MS SQL via JDBC.
    OT3: There is nothing in it for MidleWare to do another test, since no mater what, there will be complaints. Complaints should be to BEA and IBM that sucker some to buy expensive SW that is slow and complex. Since the nice BMW that your sales guy is driving?
    OT4: If MS wins, most high load applications should move to C# which is a ECMA standard lang. Who care Sun on MS, or OpenSource.
    If you do rowset, .NET won't win.

    .V
    vic@baseBeans.com
    Reply to this Reply to original

  136. Please! If you want J2EE to win ...[ Go to top ]

    Some other ideas if you REALLY want to retry AND use entity beans are:
    1. Caching at business delegate level
    2. Caching of home interfaces
    3. Use mvcsoft ejb2 persistence engine plugin which allows your entity beans to avoid the J2EE stack altogether when calling each other with just a simple configuration change (most entity beans don't need to call through the stack specially if used with session facade.
    4. Use local interfaces (this is obvious)
    5. Cache at html page level for catalogue stuff which doesn't change much.
    Reply to this Reply to original

  137. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Apart from the Technical questions, just let us think logically.

    I dont say, you sold our opinions to Microsoft(As it was found in The Middleware Company) or any thing like that,But, if you run the second test, what would be the outcome??

    There would be 3 outcomes, possibly.

    1. .NET is still faster,etc... than J2EE. In which case, still many people can argue that u r defensive.

    2. J2EE is faster,etc... than .NET. ha, now, it is very much possible that you are trying to satisfy the J2EE community now.

    3. Both J2EE & .NET are equal, and is superior in some circumstances to other, etc... .But this result is not going to be useful.

    But, if you argue, the real reason to do a BenchMark is tomake a comparison, not to satisfy anybody, well, you know the truth.After all these long years of seeing the Bench mark results, do you really belive somebody will spend their 2 pence on a bench mark result?? Even if a Bench mark is very fair, definitely the next day, the otherside will publish another result.

    So,its better for the TSS ,J2EE, and .NET to concentrate on our applications, rather spending time on Benchmarks.

    Bravo,
    Nat
    Reply to this Reply to original

  138. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Cats out of the bag already. If you request the help of Rickard Oberg (and take your public beating) that may help close the credibility gap. It's not about the best technology. It's about people, process, and honesty.
    Reply to this Reply to original

  139. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    It's not about the best technology. It's about people,

    > process, and honesty.

    How do we benchmark that?
    Reply to this Reply to original

  140. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    This whole benchmark and the new call for feedback is a complete nonsense and waste of time, as long as TMC dont specify WHAT they want to benchmark.

    Or does the consultants of TMC believe, that they can benchmark all important aspects of a development framework with this petshop application benchmark ?
    Reply to this Reply to original

  141. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    And something else to TMC, please stop to lament, how unfair you would be treated.
    This whiny "message to the J2EE and .NET Communities" makes me more angry than the posting of the benchmark.
    Reply to this Reply to original

  142. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Hi All,

    It seems to me that the only realistic test would be one that doesn't strive to test like for like.

    What you should do is spell out the requirements and set a budget and time frame. This is what happens in the real world isn’t it!

    So the requirements may be to replicate the functionality of the original pet store and the budget may be £40,000 (to include hardware, licenses and development costs).

    This way you could have a cluster of Linux boxes running JBoss (or what ever) and see if the whole stack gives more value for money. Clearly .NET on Windows is going to out perform Java on Windows, so all previous tests have just been stating the bleeding obvious!

    Try a real would scenario!
    Reply to this Reply to original

  143. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Hi All,

    OK humble pie time; my collegue tells me that TMC test was on Linux for the Java petstore. But I think my point about a real world scenario based on a budget holds true. Doesn't it?
    Reply to this Reply to original

  144. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    In my opinon you should invite BEA/IBM to implement the version of petstore and then do a comaprison. I will not be surprised if they don't want to participate. Also why not go for JBoss??

    Cheers
    Zulfi
    Reply to this Reply to original

  145. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Syed,

    I think it would be better that the project be open-sourced for the programmatic part because the community will easier accept the results and I'm sure tough J2EE guys will take it personally and accept the challenge. Apart from the web services part, I'm pretty certain performance can be improved two or three times just by abandoning the BMP approach or the entity bean layer alltogether.

    However, the tuning part should be done on the testing platform and should be done by experts, ideally from BEA and IBM (or Oracle, they had the best performance results on ECPerf 1.0 and 1.1 whatever it may be called now).

    I really think TMC deserves a second chance. With the help of the J2EE community, they should do fine. I could help there if need be (I work on a similar benchmark in my organisation).

    OT: Syed, I just sent you an email at your Yahoo address. I'm so glad to find you here! Serendipity... :)

                    Yann
    Reply to this Reply to original

  146. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I agree with Yann:

    IF you do a rematch
    1 involve the developer community in making the coding as good as possible. Maybe even an open race of several parallel implementations. If people would be willing to help implement it ofcourse.
    2 involve the vendors in tuning.

    IMO
    But regardless of what you do your integrity will seem suspect, rightly so or not, due to the great interests that are at stake and the great (financial) power of MS. So you can't be a judge in this benchmark since you influence the market by making the benchmark and are consequently automatically a player.
    The only way for TMC & TSS to have an impartial stance is to concede that the benchmark was flawed and let it rest at that.

    I'll keep following TSS regardless of the reactions of rabid dotNet- and Java followers who hardly can express themselves clearly because of the froth at their mouths.

    groeten,
    Joost
    Reply to this Reply to original

  147. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I subscribe to the above mail (Mirko's and Yann's).

    There are a lot of ways to do this (right).
    See Richard Fanta's remarks and other cache remarks.
    Similar approaches should be compared.

    Also, there should be some kind of voting, for statistical purposes, if you want more results out of this thread.
    Regards,
    JN
    Reply to this Reply to original

  148. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    <Q>Java followers who hardly can express themselves clearly because of the froth at their mouths</Q>

    People who shout and scream with paranoid talk of conspiracies and overreact in various extreme ways are seldom right. Just normal everyday behavior of people which have their privileges taken away from them.

    J2EE has been working in an area protected from competition. Java/J2EE had a little monopoly of their own. This was not because they had beaten the competition but because there was no competition: no other system worked on those expensive boxes.

    Now when the Intel processors begin to nib away from the underside and Microsoft have presented their own system for "heavy duty web projects" it shortly will not be possible anymore for Java application server vendors to charge $50.000+ for an "app server" + 20% yearly license + consulting. Bad for vendors - good for the business world.

    The will also be a more difficult world for impractical theorist with pet ideas.

    The 400 pages of EJB spec reminds me of something which happened to me when I was a little boy.
    One day I shot a series of photos on my neighbor’s dog. They were delighted and I was amply rewarded. Of course I went on and bought two more rolls of film which I used up on more pictures of the dog. Imagine my disappointment when the neighbors didn't want more pictures!

    Enough is enough (that goes for W3C too..)

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  149. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    TMC can kiss my roayal ass..

    You cannot be loyal to two differnt groups when bench testing two competing technologies..you either are loyal to the devloepr swho depend on accurate bench test info or to the vendors.. you cannot have it both ways..

    TMC you have made your choise of who to be loayl to, now we independent developers make outs..

    I vote we have Apache Software Foundation do the test rather than TMC..
    Reply to this Reply to original

  150. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    The central problem with the original test was that there was not a level playing field. Microsoft was allowed to write its own benchmark (apparently optimized for speed at the expense of all other considerations) and to provide its own optimized test server. The other vendors apparently had no input at all.

    Any fair test must subject all vendors to the same rules. If one vendor writes its own benchmark or configures its own server, then all the other vendors should do the same.

    Of course this is not what is usually meant by the term "benchmark". This usually implies an independent test, run by a neutral third party, in which the exact same code is run on identical hardware, changing only the software being compared (in this case the app server). This is impractical in this case since .Net and J2EE require different source code.

    I'm not sure what could be done about this. Once you have two different versions of the benchmark code the test becomes largely a test of the relative skills of the developers. One possibility would be to have the same developers write both benchmarks, if you could find developers who are equally skilled in both platforms.
    Reply to this Reply to original

  151. TMC and TSS have sold out to MSFT[ Go to top ]

    What a bunch of croc re: seeking inputs for a fair rematch.

    Floyd desperately trying to distance tss.com from TMC and NOT succeeding at all! You have lost all credibility with your report. Just why weren't the J2EE vendors given a chance to optimize their scores?

    For a company like TMC that touts it's best practices teaching course, how many of these were actually applied in the benchmark? I'll wager none!

    It is a well known fact that TMC isn't raking in a whole lot of $$$ (that explains why you sold out to Precise in the first place) and how you arm twist the vendors into coughing up more $$$ for the privilege of running tss.com on their app servers. It is no surprise that when MSFT came by with a fat wad of $$$, you promptly grabbed it and went on to publish a fatally flawed report.

    It is about time you dropped the "your j2ee community" from your tag line. It just ain't true anymore!

    Sayanora Floyd!
    Reply to this Reply to original

  152. TMC and TSS have sold out to MSFT[ Go to top ]

    Nosille and 'n n', the fact that you continue to bring my personal name and TheServerSide's name under fire for this is very dissapointing.

    I think the content on this site and the dedication of my and the TSS team's dedication over the years to bring the J2EE community together and provide valuable information (like J2EE spec lead tech talks, free books, etc) speaks loudly to our integrity, much louder than your rants. I never censor anything on TSS, and I won't censor your comments now. I'd rather let every one read them and reflect to themselves on how immature you guys are being.

    And BTW, TSS did not twist any vendors arm to join the cluster. They wanted to join and the motivation for the cluster launch was very pro-j2ee and documented in the article/press release. I don't have the ability to twist peoples arms magically, if I did, I'd be twisting yours right now.

    Floyd
    Reply to this Reply to original

  153. TMC and TSS have sold out to MSFT[ Go to top ]

    floyd, well actually you did sensor some posts a while back when some people started making fun of a certain mister bar(f)cia :) , i thought it was quite hilarious and was sad to see it removed, even though it was incredibly immature etc..
    Reply to this Reply to original

  154. TMC and TSS have sold out to MSFT[ Go to top ]

    Floyd,

    I think you deserve loads of respect and gratitude for running the site. For those just getting into EJB it is a huge resource. Some of the regular contributors are very bright guys and it is the only forum I have found where you can learn things through debate without too many idiots trying to get flames going.

    Possibly it's time to assert executive power and simply delete the original benchmark and this thread as well. Folks are only debating it because it's here.

    You may lose those who are disencharnted with you, but you have probably lost those no matter what. The wider community will stay with you. TMC may be tied to the benchmark but TSS does not have to be.

    I don't believe this debate is going anyplace useful.

    Jonathan
    Reply to this Reply to original

  155. TMC and TSS have sold out to MSFT[ Go to top ]

    Floyd,

    as I said in the beginning, I wouldn't say that you personally or TSS have any guilt concerning the J2EE vs .NET comparison.
    Please tell me why the title of this thread has changed? Is this because of preasure of TMC? In my point of view the first title which was like "TMC want a fair rematch for J2EE vs .NET" was quite well verbalized. And it put out what many of us think: It was an unfair, marketing driven and unintelligent (excuse me for that) comparison from TMC.
    Because Microsoft influenced and knew the results (at least a week) before the community (see Rickard's review dreambean.com). I think TMC is disqualified to do the retest. And if it was not marketing driven and Microsoft influenced, then they shouldn't do the retest either, because then the people who did the test are quite incompetent in the J2EE area and maybe they should implement the .NET opponent.

    I hope that the discussion will end and we can concentrate on other things here on TSS.

    Grüße,
    Mirko Novakovic
    :wq
    Reply to this Reply to original

  156. why title was changed[ Go to top ]

    Mirko, the title of the thread was changed to be closer to the truth. I initially worded it as 'annouces fair rematch' and was informed by my TMC co-workers that the title was innacurrate. TMC is not announcing the new benchmark, they are seeking input as to whether one should be run at all and if so, how.

    It is a normal thing for a publication to change their article/writing after the fact in the interests of accuracy.

    Floyd
    Reply to this Reply to original

  157. why title was changed[ Go to top ]

    Floyd,
          Personally I have no issue with a post being revised. What I have an issue with is that it was done at the behest of TMC.

    I think it would be good if you could post procedures online under which __anyone__ can edit a prior post. Better yet, let us do it ourselves rather than having to mail someone.

    Right now, you happen to be able to do this because you can go tweak the database. If you are going to support the notion of revising posts (as you seem to do) then you ought to make this functionality available to all.

    Alternatively, you could just have posted a note with a different title and explained why you wanted to change it. Either way would have been better than the "quiet" way it actually took place.

    For the record, I think this thread is a huge waste of time. TMC made a mistake, a big one. And they're paying for it. But I respect that they stood up, admitted it, and at least want to make things right. There are precious few companies out there that would do that so my hat is off to them. However, at this stage, any move they make on a benchmark is bad for them and good for Microsoft, so if they have any sense they'll let this one drop now.

    Anyway, just my 2c. If you're gonna support the principle of revising posts, then support it for everyone!

    Chz

    Tony
    Reply to this Reply to original

  158. why title was changed[ Go to top ]

    Tony, I am very impressed - what a brilliant idea! The ability to revise posts would make a big difference in quality of area such as the patterns area. I'll take this recommendation to TSS team to discuss implementation. Thanks!

    Floyd
    Reply to this Reply to original

  159. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    First, I appreciate TMC saying they erred (think how few companies do that!).
    As for the benchmark, I would say that the approach to be taken is:
    We have a business problem, that is to build a web site for a petstore. That's what we need to achieve. Full stop.
    Do not look at all at Sun's implementation, just go and implement the equivalent business functionality best you know. Use what _you_, not Sun, think are the best practices, to come up with a real solution. In other words, do it as if you were asked by real customer to do it (in a sense you are...).
    Whether you decide to use CMP, DAO, JDO, EJBs, Struts, XDoclet etc.. is up to you, just as it would be in a real project.
    If it means you have to rewrite it from scratch, well so what? If I have a bad code, it can be easier to throw it all away.
    Just my $0.02.
    Regards,
    Vlad
    Reply to this Reply to original

  160. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    First, ... if we are to have a "fair" performance rematch, TheServerSide should have absolutely nothing to do with it. TheServerSide has no credibility left in this space to be doing anyting like this ever again. This excerpt from JDJ's article on this fiasco is on target ...

    ******** JDJ Excerpt ***************

    "Seriously Let Down the Java Community

    A startling fact, that both JDJ's editor-in-chief Alan Williamson and Glen Martin from Sun find hard to believe, is that "AppServer #B" failed to respond to any further requests after just 4 hours. Alan Williamson comments, "For this very reason alone, TMC had a duty to call in that particular J2EE vendor to make sure they exhausted all configuration options. This was a negligent error on a massive scale. TMC have seriously let down the Java community." Such issues wouldn't have affected the .NET implementation, as Microsoft had their own highly skilled .NET engineers poring over every single line and configuration option to ensure the best possible performance was squeezed out of it.

    The question remains: why? Why would a highly respected J2EE authority be so careless? Rickard Öberg believes there is more politics to this debacle, "TMC really disqualified itself as they were recently bought by a company who has Microsoft as a strategic partner," he says - a reference to Precise Software Solutions, Inc. "

    ************ End Excerpt ***************

    To have TMC and TheServerSide conduct a rematch would be a continuation of this fiasco. Let this rematch be hosted by a true J2EE authority (eg: BEA, IBM, Sun, Oracle). Let Microsoft have the same hands on opportunities to tune its system that they had here. Only this time, let the J2EE architecture, code and system tuning be handled by BEA or IBM. Then we'll have a fair test. And, I believe, we'll see the performance margins close dramatically.
    Reply to this Reply to original

  161. Get the Vendors Involved[ Go to top ]

    Ted, I agree. The vendors should be involved in this. And it's vital that the comparison is made against a Pet Store that isn't lowest common denominator (old spec levels). After all, .NET is a product, not just a specification, so it's impossible to make a fair comparison of .NET against multiple J2EE app servers.

    I don't believe that .NET is necessarily more performant than J2EE. But I do think that J2EE developers need to learn from this debacle. There are sound theoretical reasons why BMP entity beans don't perform adequately. We've seen that the Pet Store version implemented using them doesn't perform adequately. It's time for a rethink.

    I would hate to see the following outcomes from this:
    1. Non-technical decision makers convinced ".NET fast, J2EE slow." Microsoft have done their utmost to publicize the whole thing, so this is a real danger.
    2. J2EE community dismisses the whole thing, and learns nothing from it. OK, the comparison wasn't fair, but the performance difference clearly shows that the Java Pet Store as it stands is poorly designed. It's time everyone realised that this is a poor sample app and that the underlying architecture isn't appropriate for this kind of application.

    Unfortunately, the second outcome is suggested by the posts arguing that any such comparison is unreasonable. Many managers are going to choose between J2EE and .NET in the next couple of years. They don't care too much about the niceties of open platforms (although there is genuine business value in the openness of J2EE): they will listen when Microsoft tells them about any flattering performance comparisons. J2EE must be able to do battle in the performance area or Microsoft will make enormous gains.

    Rod Johnson, author of Expert One-On-One J2EE Design and Development
    Reply to this Reply to original

  162. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    1. The test should include results for .net with MS-SQL server and Oracle and J2EE with MS-SQL server and Oracle. Use the best vendor provided drivers for .net and J2EE(jdbc).

    2. The databases should be benchmarked for basic statements that goes against them. Do the same transactions from SQL clients command line agaist both databases and see what the differences are. Let microsoft and oracle tune the databases to their heart's content. Benchmark that first and then the J2EE vs .net stuff.

    3. How many network connections per machine? Are you sure that .net didn't used separate network connections for web traffic and database traffic on the middleware boxes?
    Reply to this Reply to original

  163. Tough conitions demanded???[ Go to top ]

    We are interested in finding out which middleware has the best performance on the same budget - not the same hardware.

    "Thus the only way we can fairly compare J2EE and .NET is in an apples-to-apples comparison of identical hardware and move to the lowest common denominator."

    But then-did'nt you think that your first benchmark was fair?
    Using identical hardware is not the only way to fairly compare J2EE and .NET. It is also fair to use price as the lowest common denominator - price/performance was used in TMC original benchmark.
    Your conition eleminates a major advantage of J2EE (choice):
    jboss/Solaris/SPARC or Sun ONE:
    http://www.sun.com/2002-1028/feature/


    "We realize that we will not make everyone happy with this controversial decision but sometimes tough decisions need to be made and we believe this is the fairest approach."

    Two Questions:
    1) Is this tough decision a conition demanded by Microsoft?
    2) What were the conitions demanded by Microsoft for their
      first benchmark? Would you (or could you) post a copy?
    Reply to this Reply to original

  164. Recommended design pattern for building scalable Web application[ Go to top ]

    What does it means ?
    Do we have the same understanding ?
    Before starting the seconde round, we must
    build a specification for this benchmark.
    Reply to this Reply to original

  165. LAMP[ Go to top ]

    Is it possible to include LAMP (Linux, Apache, Mysql, PHP)
    in the benchmark ?
    Reply to this Reply to original

  166. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I think the test should be more fine grained

    Servlet Response Vs .NET equivalent response
    JSP response Vs ASP response
    JDBC Vs ADO.NET (same database)
    EJB Vs ?
    JAX-RPC Vs .NET Web Services
    JMS Vs .NET equivalent
    2 Phase Commit Vs .NET equivalent
    # of J2EE Vendors Vs # of .NET Vendors
    # of Java IDE's Vs # of .NET IDE's
    etc.
    Java Applet Vs ActiveX Controls

    Breakdown the measurement into the following categories

    1. Performance (e.g. JDBC query time vs ADO query time)
    2. Ease of development
    3. Vendor Lock in
    4. Learning Curve
    5. Cost (with options- Open Source etc.)
    6. Platform independence
    7. Clustering and Performance

    I just think that we should be looking to solve real world problems than just a pet store one.
    Reply to this Reply to original

  167. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Before rematch, at least one question must be answered: what do we want to compare between the two parties?

    If we make a rule the match must be run on non-windows machines, can we do the test again? Why is microsoft who posts questions and we have to answer?

    Having read nearly all posts here, I find something really needs to be clarified before we do the rematch:

    What EJB can do while a plain servlet plus other data access and persistence techniques can NOT do? What's the purpose to invent EJB?

    If we go JPetStore way, are we missing something that's extremely important from the view of enterprise computing?

    If throw out EJB, can J2EE answer all the questions it already answered today with EJB, though not satisfied?

    What EJB can do that microsoft solution can't? If COM+ is a similiar stuff to EJB, what EJB can but COM+ can't, or COM+ can but EJB can't?

    If EJB really has something important that's missing from microsoft, why not adds them to the rule of the match?

    If J2EE can live well without EJB, why not throw it out? If we indeed need EJB, that must be something very important. If this very important thing is missing from microsoft, then J2EE wins. If microsoft also has such thing and is superior to EJB in this respect, then it's just EJB's problem, not necessarilly denying whole J2EE.

    When you make any match with anybody, the important is you must join to make the rule. Either party has right to display their advantages and hide their weaks. In this respect, microsoft is always wiser than us. They can even make a new game. When they lost the field of application server market, they tout web services, then every body thinks java community has to catch up.

    Any expert's ideas?

    Thanks,

    Bo
    Reply to this Reply to original

  168. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    This thread is already very long, and I don't have time to review every comment to see if this has already been suggested. If it has, apologies for the repeat.

    WRT a rematch, I think TSS, in combination with volunteers from the J2EE community, should arrange for a rematch, yes. And, yes, I think it should involve vendors and the community.

    In order to do this, I recommend that teams of people be able to register themselves for the rematch, submit an implementation, running on specific database and application servers. A target machine specification should be determined in advance.

    Each team would register with a central committee, staffed by vendors, the community and the Server Side. These teams would then go off, create an implementation, and submit it. These submissions would be tested, both for benchmark performance and functional criteria. Any implementation that meets the benchmarks will have its numbers posted, unless requested to be removed by the implementation team.

    The process would be quite similar to, say, ECPerf, for instance. It would ensure that everyone can contribute, that no candidate architecture will go unturned save for those architectures that no-one actually bothers to implement.

    Want to see PetStore on Hibernate? Go ahead, implement it. BMP? Sure. On Pramati and MySQL? Feel free.

    The vendors and community would have their chance to contribute, and TSS could also field a team. All resulting implementations would be made available to the community, which would be an amaznig resource in and of itself, to have the same functionaliy implemented in a number of candidate architectures that can then be explored by interested parties.

    Thoughts? I don't know if the community is up to the effort this would entail, but it seems like a great way to handle a rematch, if one has to be done. (And, yes, I think one /does/ have to be done.)

    Personally, I want to see this running on a relatively lightweight persistence layer like JDO, OJB or Hibernate.
    Reply to this Reply to original

  169. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    And, yes, I'm all for having teams submit LAMP and alternate Microsoft PetStore implementations, too.
    Reply to this Reply to original

  170. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    1. in all fairness one should use a framework such as webwork or struts and not have this count as lines of code as this reflects how people are using j2ee today.

    2. include oracle in the test.

    3. deploy on solaris if microsoft gets to play on its hometurf why shouldnt j2ee be.

    4. rewrite form scratch for performance dont rewrite a 2 year old piece of software that wasn't written for it in the firstplace and exepect it to perform as well as microsoft code that has been written just for performance

    5. have the vendors get involved, this may also make 4 financially more feasable

    6. have brainiacs such as rickard oberg and Cameron Purdy look it over just in case
    Reply to this Reply to original

  171. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    How about this for an idea

    www.petstorebenchmark.org

    ANYONE is free to contribute an implimentation of PS, using any technology they desire.

    Along with the code the developers supply a rationale as to why they made their design decisions and product choices.

    A discussion area is associated with each submission, allowing criticism and suggestions for improvements.

    The actual benchmark is trickier, perhaps people could supply metrics from different environments? More absolute than comparative.
    Reply to this Reply to original

  172. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I have to say that stuff like this isn't really comparing technologies, but comparing who has more brainy people.
    If I was a manager, I wouldn't care that much to know that Rickard can optimize J2EE petstore to run like lightning and that Anders Hejlsberg can do the same for .NET with c# (substitute your two favourite names here if you don't like these two). What are the chances I can hire either of them? Nil or close to.
    What I'm interested in is how good a product my "normal" team of developers can turn out in some reasonable time with reasonable amount of money. So, take two teams of normal developers, give them a deadline, and let them slug at it. Requirements are pretty clear - exact duplication of Suns petstore functionality. Unambiguous, fully defined. Ideally repeat with 10 or so other teams on each side.
    That would give me some real input into how productive/good an environment is.
    Or said differently - extremes of bell curve aren't interesting, because most of the stuff is in the middle.
    Regards,
    Vlad
    Reply to this Reply to original

  173. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    FWIW in this typically noisy forum:

    If TMC are bent on a rematch, there are six main points:

    1) Implement a J2EE Petstore *identical* to the .net petstore implementation in every way (even if it is thought that parts of the .netstore design is pants).

    2) Implement another J2EE Petstore, using the full (even if thought to be overcomplicated) J2EE stack: Struts, EJB, CMP2.0. The LOC count should be much lower than previously reported - and leveraging more of the appserver benefit.

    3) Profile the damn thing! TMC should be able to display profiling reports. Not only will it make TMC's job much easier of defending their results, it will also be 10,000% more useful than an "x is faster than y" conclusion. (Also removes any doubt on database performance)

    4) Run both J2EE Petstores with SQL Server (JSQLConnect drivers?).

    5) OBVIOUSLY, get the vendors to tune their own appservers. While it might be fun messing about with WLS tuning, I am sure that someone from BEA will get it done somewhat quicker than the 5 weeks it took TMC.

    6) Post the code for review before benchmarking anything.


    Regards,
    Nick
    Reply to this Reply to original

  174. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I dont think if I can trust any test and coding from Middleware or TMC when they are nothing but Microsoft's puppets. This is alarming to me that during DOJ ruling MS has been warned to change its monopolistics attitude but it still shows it. Java is way superior than .Not and in real world .Not is a failur so Microsoft is buying its vote, rigging tests. C# is a shameless, poor copy cat of Java and MS has repeatedly copied another compaies innovation and later went against them ..this story repeats over and over. This tuely a sad world we live in.
    Reply to this Reply to original

  175. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I would like some answers to the following questions:
    * What were the reasons for doing this benchmark? Include both major and minor reasons.

    * Some people have commented that benchmarks are a bad way to compare .NET and J2EE. What's your comment on that?

    * Why weren't utility methods (such as getConnection()) placed in base classes, or utility classes?

    * Why were classes included that weren't used?

    * Why were methods included that weren't used?

    * Did TMC perform a code-audit of the .NET code?

    * Who performed this audit?

    * The .NET code does not comply with basic test rule nr 3. Any comments on that?

    * Why was the TMC PetStore based on Sun PetStore 1.1.2 instead of Sun PetStore 1.3.1?

    * Why was BMP EntityBeans used instead of CMP EntityBeans?

    * The JDK documentation states that concurrent garbage collection will provide lower throughput than normal GC. Why was concurrent garbage collection used?

    * Why did the .NET PetShop and the TMC PetStore use radically different caching strategies? (app level caching vs user level caching)

    * Multi-database apps using XA is not very common in real-life systems. Why was XA added to the test?

    * Whose idea was it to add XA testing?

    * The caching rules could be much stricter for J2EE where distributed caching solutions could be employed. Why were the caching rules formulated to allow .NET to get away with a very simple caching solution?

    * Why were some read-only methods using a TX_REQUIRED setting?

    * Why were EJB homes looked up but not used in some places?

    * Why didn't the TMC PetStore use PreparedStatements in all places?

    * When were the report results given to Microsoft?

    * Why were the report results given to Microsoft prior to the official release?

    * Were the report results given to any of Sun,BEA or IBM prior to the official release?

    * If the report results were not given to any of Sun,BEA or IBM, why is this?

    * Who within TMC approached Microsoft with the proposal to create this report?

    * Who within Microsoft was contacted?

    * Microsoft reimbursed TMC for travel expenses and similar. What was the total amount of money paid by Microsoft to TMC related to the production of this report?

    * When server B crashed after four hours of testing, why was that vendor not contacted?

    * During the production of this report TMC was purchased by a company that has Microsoft as strategic partner. This make TMC a bad candidate for conducting such a report, due to the possibility of bias. Why was the testing continued and the report published in spite of this?

    * What method and/or tool was used to compute the LOC count?

    * Were the unused classes included in the LOC count stated in the report?

    * The report refers to the server vendors as A and B in order to keep them anonymous. The TMC PetStore code included a WebLogic deployment descriptor. Why was it included?

    * Was the work on this benchmark performed by the developers full-time, or did they have other assignments during this period?

    * How many MS engineers were involved in the creation and update of the .NET PetShop?

    Any insights on these questions from Ed Roman and/or the TMC developers (Will Edwards and David Harrell) would be appreciated.
    Reply to this Reply to original

  176. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Hi

    Regarding the Petsoar project u started at sourceforge.

    http://sourceforge.net/projects/petsoar/

    Do u have any idea when we'll have something there to download and test.

    Thank you
    Reply to this Reply to original

  177. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    What I would like to see is Rikard's list of questions (msg#64774) formally submitted to the appropriate powers at TMC by TSS for an official/public response.

    Anthony
    Reply to this Reply to original

  178. E_X_C_E_L_L_E_N_T Questions.[ Go to top ]

    TMC, "THE J2EE EXPERTS (My Ass)" MUST ANSWER ALL THESE QUESTIONS.

    MOREOVER, THEY MUST ADMIT THAT THE FIRST BENCHMARK WAS NOT APPLES-TO-APPLES COMPARISON TO (MAYBE) GET BACK 10 PERCENT OF THEIR PRIOR TRUSTABILITY.

    I hope that what TMC did was originated from their being "the J2EE stupids" rather than earning money from MS.
    Reply to this Reply to original

  179. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Please respond to Rickard Oberg QUESTIONS in this thread before even thinking of next comparison test.
    Reply to this Reply to original

  180. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    We don't want any comparison. J2EE is far better than .Net. We are the inovaters and market leader.<Period>
    Reply to this Reply to original

  181. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Floyd, I appreciate the work you and TMC have put into TSS and I do believe it has helped the J2EE community tremendously.

    However, I just read Rickard Obergs post and am appalled. I hope you will read his post and strongly consider an appropriate, and speedy reply.

    Thanks to you as well for doing the homework once again Rickard.

    Sincerly, K
    Reply to this Reply to original

  182. Simple, make the comparison Realistic .. !![ Go to top ]

    Simple Solution.. Just make this whole Petshop thing more realistic..

    So, Hi to All commercial PetShops all over the world.. The ServerSide.com has come out with a free offer. This is what it says:

    -------------------------------

    "If you own a Petshop and you make decent business and you want to bring your business online.. then this is for you. We're giving away a free web-based Petshop application for free. And what more.. we are providing you the hardware as well. And what more.. we are giving away not one .. but TWO versions of it. All you have to do is run your business on these softwares. Try it out for a period of 1 year. We will be coming down every month and collect some statistics from the servers for our Research purpose.
    We're sure your business will go good for the one year (because you'll be using the BEST two software applications to run your business !) and your profits will grow.
    The Serverside.com will be maintaining the application for you for the 1 year... guaranteed!

    And its all FREE. Any Petshop wanna give this a go.. hmm?"

    -------------------------------

    So, how does this sound.. realistic? Changes are bound to come in their business.. those will be implemented on both the versions.. Technical suggestions will be given my the community on implementing the changes.. Let's see which of the two.. the .NET or the J2EE one fairs better.

    Of course, the only condition should be: somebody in the world has to buy the pets.. for real.

    The comparison should be apples vs. apples..

    1. Both the applications should be made from the same Analysis and Design models.
    2. Of course, the applications must perform decent enough.. It gonna run on real world.
    3. Both the applications will access the same database.. use stored procedures or don't use stored procedures.
    4. Both the applications will get Turn-by-Turn on every user logging on to the website. If first user logs in J2EE app will get the turn to serve him.. when the second user logs in .NET will get the turn.. You choose the best hardware to run the .NET and the best hardware to run the J2EE... but the database server will be different and commont to both.
    5. Put up both the projects on sourceforge.net for developing the code.. Anybody can refer it and there will be healthy competition among the both sets of developers.

    Give it a try man.. be more realistic.

    The Petshop company will benefit from it.. but the J2EE developers and the .NET developers lose nothing either. Its a simple humanitarian task for helping a Petshop to get their business online. There are so many things being done for free for the AIDS people, the Earthquake victims, so on.. you can consider this one also in the same category.

    Or may be.. you can consider making a totally different real-world application for some good company in the world.. free of cost..! what say? Win-Win situation. Think over.. this fight is not going to end by taking into consideration some unrealistic scenario and testing some stupid performance factors. This fight will end only if we, the developers, do the job that we're supposed to do.. the job of writing software for real businesses.

    Anyway, Good luck and happy fighting.. Of course, don't forget to make preparations for the Christmas and Newyear !!

    From just-another member of the Computing world who is sick with all this .NET vs. J2EE fights.. !!


    [C Programmer never die.. they are just cast into void]
    Reply to this Reply to original

  183. Tell me one thing..[ Go to top ]

    Suppose, if Microsoft had not done that initial benchmark testing of the Pet(store/shop).. would all this discusion had really happened..hmm ?

    I don't even think people would've have visited the Petstore of j2ee.. if at all they had visited... then only for reference may be.. just like the vb developers refer the filtch and mather example..

    come on.. stop comparing..

    world is breaking.. just because of this comparison thing.

    Powerful nation vs. Weaker nation
    Religion1 vs. Religion2
    Color1 vs. Color2

    Enough of all this.. you like j2ee.. use j2ee.. you like .NET .. use .NET.
    You wanna buy this detergent.. buy this.. if you are really going by the advertisements and banners on TVs and Roads.. then.. its your mistake to have chosen the wrong product.

    think.. analyse for yourself.. ur company wants u to develop something.. gather up a few people from your workplace and discuss.. what would be the best for my company.. will my boss sanction a jboss or a Oracle9iAS or a Websphere or a .NET box ? don't u all think its so simple that way.. mm?

    what will these performance results show at the end of the day.. and.. can u really invest the kind of hardware that is used for these benchmarks.. to the true perfection?

    And.. all this for what?.. what finally?

    if the benchmark shows that the h/w reqd for j2ee is costlier than the .net and ur company can fund only the cost reqd for .net.. u would be definitely going to go for a cheaper one.. right ? u wouldn't go arguiing with the mgmt for a more money..mm?

    its all getting sick.. stick to ur job people.. be good people.. stop comparing for the sake of thse:
    1) "I'm Best"
    2) "You're not the Best"

    Say.. "i'm good".. u don't need to say "You are also good".

    if microsoft markets their tech.. let them do so..
    if j2ee developers wanna show off their ideas.. let them do so..

    don't stop one from doing something.. nobody is going to destroy the world with a j2ee app or a .net app.. :-)

    too bad to see so many people (incl. me) wasting time on such comparisons.. which is finally going to fetch nothing.. nothing at all. :-(

    just think.. suppose PersonA is a j2ee freak.. he sees that .Net fares better in the benchmark.. what do u think he'll do..? stop working on j2ee and jump to .Net ..?
    or suppose PersonB is a .NET guru.. he sees that j2ee fares better in the benchmark.. what do u think he'll do.. ? stop working on .NET and start loving j2ee.. hmm?

    its all technology that matters.. suppose a guy loves to have a Mercedes Benz.. but his company gives him a Ford.. u think he will not use it ?
    come on.. tomorrow my boss says..."u r now put in a new j2ee project.. u'll have to work on it.. " .. what will I do.. i'll defintely work on it.. but.. day-after I might need to work on .NET?

    if a technology solves my purpose of developing an app.. i'll use it..
    its scalable.. not scalable... costlier... cheaper.. less time-consuming.. more time-consuming.. all these will be analysed based on the kind of project.. all these things will happen.. the pros.. and cons.. all will pop-up during discussions..

    so sad to see People fight on selecting one of two.. bad.. very bad.

    stop all this..
    and may Peace Prevail in the world.

    kinda boring stuf.. in a technical forum.. right?

    hope people understand..its all a pack of cards.. one falls.. all others fall behind it..
    Reply to this Reply to original

  184. Tell me one thing..[ Go to top ]

    Suppose, if Microsoft had not done that initial benchmark testing of the Pet(store/shop).. would all this discusion had really happened..hmm ?

    I don't even think people would've have visited the Petstore of j2ee.. if at all they had visited... then only for reference may be.. just like the vb developers refer the filtch and mather example..

    come on.. stop comparing..

    world is breaking.. just because of this comparison thing.

    Powerful nation vs. Weaker nation
    Religion1 vs. Religion2
    Color1 vs. Color2

    Enough of all this.. you like j2ee.. use j2ee.. you like .NET .. use .NET.
    You wanna buy this detergent.. buy this.. if you are really going by the advertisements and banners on TVs and Roads.. then.. its your mistake to have chosen the wrong product.

    think.. analyse for yourself.. ur company wants u to develop something.. gather up a few people from your workplace and discuss.. what would be the best for my company.. will my boss sanction a jboss or a Oracle9iAS or a Websphere or a .NET box ? don't u all think its so simple that way.. mm?

    what will these performance results show at the end of the day.. and.. can u really invest the kind of hardware that is used for these benchmarks.. to the true perfection?

    And.. all this for what?.. what finally?

    if the benchmark shows that the h/w reqd for j2ee is costlier than the .net and ur company can fund only the cost reqd for .net.. u would be definitely going to go for a cheaper one.. right ? u wouldn't go arguiing with the mgmt for a more money..mm?

    its all getting sick.. stick to ur job people.. be good people.. stop comparing for the sake of thse:
    1) "I'm Best"
    2) "You're not the Best"

    Say.. "i'm good".. u don't need to say "You are also good".

    if microsoft markets their tech.. let them do so..
    if j2ee developers wanna show off their ideas.. let them do so..

    don't stop one from doing something.. nobody is going to destroy the world with a j2ee app or a .net app.. :-)

    too bad to see so many people (incl. me) wasting time on such comparisons.. which is finally going to fetch nothing.. nothing at all. :-(

    just think.. suppose PersonA is a j2ee freak.. he sees that .Net fares better in the benchmark.. what do u think he'll do..? stop working on j2ee and jump to .Net ..?
    or suppose PersonB is a .NET guru.. he sees that j2ee fares better in the benchmark.. what do u think he'll do.. ? stop working on .NET and start loving j2ee.. hmm?

    its all technology that matters.. suppose a guy loves to have a Mercedes Benz.. but his company gives him a Ford.. u think he will not use it ?
    come on.. tomorrow my boss says..."u r now put in a new j2ee project.. u'll have to work on it.. " .. what will I do.. i'll defintely work on it.. but.. day-after I might need to work on .NET?

    if a technology solves my purpose of developing an app.. i'll use it..
    its scalable.. not scalable... costlier... cheaper.. less time-consuming.. more time-consuming.. all these will be analysed based on the kind of project.. all these things will happen.. the pros.. and cons.. all will pop-up during discussions..

    so sad to see People fight on selecting one of two.. bad.. very bad.

    stop all this..
    and may Peace Prevail in the world.

    kinda boring stuf.. in a technical forum.. right?

    hope people understand..its all a pack of cards.. one falls.. all others fall behind it..
    Reply to this Reply to original

  185. Tell me one thing..[ Go to top ]

    Suppose, if Microsoft had not done that initial benchmark testing of the Pet(store/shop).. would all this discusion had really happened..hmm ?

    I don't even think people would've have visited the Petstore of j2ee.. if at all they had visited... then only for reference may be.. just like the vb developers refer the filtch and mather example..

    come on.. stop comparing..

    world is breaking.. just because of this comparison thing.

    Powerful nation vs. Weaker nation
    Religion1 vs. Religion2
    Color1 vs. Color2

    Enough of all this.. you like j2ee.. use j2ee.. you like .NET .. use .NET.
    You wanna buy this detergent.. buy this.. if you are really going by the advertisements and banners on TVs and Roads.. then.. its your mistake to have chosen the wrong product.

    think.. analyse for yourself.. ur company wants u to develop something.. gather up a few people from your workplace and discuss.. what would be the best for my company.. will my boss sanction a jboss or a Oracle9iAS or a Websphere or a .NET box ? don't u all think its so simple that way.. mm?

    what will these performance results show at the end of the day.. and.. can u really invest the kind of hardware that is used for these benchmarks.. to the true perfection?

    And.. all this for what?.. what finally?

    if the benchmark shows that the h/w reqd for j2ee is costlier than the .net and ur company can fund only the cost reqd for .net.. u would be definitely going to go for a cheaper one.. right ? u wouldn't go arguiing with the mgmt for a more money..mm?

    its all getting sick.. stick to ur job people.. be good people.. stop comparing for the sake of thse:
    1) "I'm Best"
    2) "You're not the Best"

    Say.. "i'm good".. u don't need to say "You are also good".

    if microsoft markets their tech.. let them do so..
    if j2ee developers wanna show off their ideas.. let them do so..

    don't stop one from doing something.. nobody is going to destroy the world with a j2ee app or a .net app.. :-)

    too bad to see so many people (incl. me) wasting time on such comparisons.. which is finally going to fetch nothing.. nothing at all. :-(

    just think.. suppose PersonA is a j2ee freak.. he sees that .Net fares better in the benchmark.. what do u think he'll do..? stop working on j2ee and jump to .Net ..?
    or suppose PersonB is a .NET guru.. he sees that j2ee fares better in the benchmark.. what do u think he'll do.. ? stop working on .NET and start loving j2ee.. hmm?

    its all technology that matters.. suppose a guy loves to have a Mercedes Benz.. but his company gives him a Ford.. u think he will not use it ?
    come on.. tomorrow my boss says..."u r now put in a new j2ee project.. u'll have to work on it.. " .. what will I do.. i'll defintely work on it.. but.. day-after I might need to work on .NET?

    if a technology solves my purpose of developing an app.. i'll use it..
    its scalable.. not scalable... costlier... cheaper.. less time-consuming.. more time-consuming.. all these will be analysed based on the kind of project.. all these things will happen.. the pros.. and cons.. all will pop-up during discussions..

    so sad to see People fight on selecting one of two.. bad.. very bad.

    stop all this..
    and may Peace Prevail in the world.

    kinda boring stuf.. in a technical forum.. right?

    hope people understand..its all a pack of cards.. one falls.. all others fall behind it..
    Reply to this Reply to original

  186. Tell me one thing..[ Go to top ]

    Praveen,

    Perhaps if you posted your message one more time, we would get the point :-)

    I don't think this discussion is so lively because of "religious" technical views. Nor is it a "my dad can kick your dad's ass" kind of thing.

    The point is that an "independent" software company presented an "unbiased" comparison of two technologies. This comparison clearly favored Microsoft. This comparison is actively being publisized by Microsoft. The problem is this - there is clear evidence that this comparison was not fair. Is Microsoft disclosing this? No. Do companies who read this report know that this was a skewed comparison? No. Is that right? No.

    The problem is that Microsoft is using misinformation (lies, mistakes, half-truths, whatever) published by a third party to position themself "better than J2EE". I think the J2EE community is justified in being pissed off by this. Maybe .Net is faster, but that is not the point.

    Personally, I don't see a point to another benchmark. You can never have a perfect apples-to-apples benchmark (especially when one of the technologies is confined to one platform). The question a company should ask itself (in regards to performance) should be - "Is J2EE fast enough for *my* needs" or "Will .Net scale to meet *my* growth".

    Ryan
    Reply to this Reply to original

  187. Tell me one thing..[ Go to top ]

    Suppose, if Microsoft had not done that initial benchmark

    > testing of the Pet(store/shop).. would all this discusion
    > had really happened..hmm ?

    IIRC, all this nonsense started when Oracle published performance results of running the petstore on 9i. Using the petstore as a benchmark was their bright idea, which kind of blew up in their face. How could MS resist trouncing the Oracle benchmark with a shiny new .NET PetShop?
    Reply to this Reply to original

  188. Same Database(s)[ Go to top ]

    Hi all,

    Something that might be neat to try (stop me if you've heard this one) would be to use two different databases in the benchmark at the same time. The Pet Store application specification states that 2 databases need to be used anyway (one for the catalogue and another for orders).

    I think it would be neat to have 2 configurations and test both:

      Configuration A
         Catalogue on Oracle
         Orders on MS SQL Server

      Configuration B
         Catalogue on MS SQL Server
         Orders on Oracle

    Furthermore, no application code would be allowed to change. All code used would have to be part of the application and all of the lines counted. Only configuration would be allowed to change.

    This would be interesting because it would introduce the challenge of a heterogeneous environment (which is much more realistic). It will also flex the XA muscle of each platform when dealing with databases from different vendors.

    Cheers,

    Clinton
    www.ibatis.com
    Reply to this Reply to original

  189. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Interesting link (sorry if duplicated)

    http://www.ejbsig.de/docs/PetShopArchitecture.html

    DotNetGuru about the bad design of the Microsoft's version of PetStore
    Reply to this Reply to original

  190. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Thanks for your link to the translation of DotNetGuru.org's criticism of the architecture of Microsoft's PetShop. (http://www.ejbsig.de/docs/PetShopArchitecture.html) Although this debate has been mostly ignored on .net sites, the French site from which that article is taken has devoted considerable energy to comparisons.

    Having given up on Petshop as a valid basis of comparison for all the reasons stated in the article, DotnetGuru conducted some of their own tests. The results are here:
    "NET on average 2 to 3 times faster than J2EE"
    http://www.dotnetguru.org/articles/Comparatifs/benchJ2EEDotNET/J2EEvsNETBench.html

    (Google's translater will convert half of the page for those of us who are language impaired. The last half of the article would have to be done one 'graph at a time.)

    The tests might be helpful in considering what to avoid in comparisons between the two platforms. Here's their conclusion (courtesy of Google's translater:)

    "...It is undeniable that NET is more effective than J2EE for the majority of the aspects that we tested here, by a total factor of 2.5.

    "...Java proponants have cause for concern if pure performance is regarded as a major criterion in the choice of environment by decision makers and private individuals.

    "Lastly, we invite our readers to supplement this test by small personal experiments, and to feed the debate over performance of the two platforms. For our part, we will try to continue this effort of objective comparison on other subjects in the future, such as the components trade, Web sites, access to data bases, and XML tools. That promises beautiful surprises in prospect."
    Reply to this Reply to original

  191. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    The .NET Version MS releases with Windows uses Native Interface calls (It will only work on Windows, would you call this Enterprise worthy? Imagine all your production critical servers and databases running Windows and SQL Server respectively). A fairer benchmark comparison would be to pit Java/J2EE against the version of .NET MS gives to the ECMA...

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/mssharsourcecli2.asp
    Reply to this Reply to original

  192. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    <quote>
    The .NET Version MS releases with Windows uses Native Interface calls...
    </quote>

    I've seen statements like that repeated almost as a mantra here, but I'm not sure I understand why the statement is considered so significant.

    It could mean a couple of things: That the ugly code for the Petshop application uses "unsafe" code to make MFC or other native calls? I've only glanced through it, but if that's the case then it is kind of cheating. (Which wouldn't surprise me all that much, however.)

    But if you mean that the CLR that runs on Windows makes native calls to the OS, I fear I don't see the significance. I'm not a systems programmer so I must be missing something here, but doesn't a Java JVM make native calls to its host OS? If so, how is that different than what .Net's virtual machine (CLR) does?

    I understand the argument that Java is available on multiple platforms while the CLR and the .Net Framework libraries currently work only on variants of Windows. That's a huge advantage for Java. But I don't understand why that advantage needs to be hidden under this mantra about "native calls".
    Reply to this Reply to original

  193. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    TEE-RUE. I understand your comments and acknowledge I probaby misused some terms. My underlying knowledge of the complexity of such systems is limited at best. However, I do contend Microsoft "cheats", although I'm not entirely sure in the science of the how...

    Here is a quote from Microsoft describing the Shared Source version of the CLI given to ECMA:

    "There ARE significant differences in implementation between this code and the code for Microsoft's commercial CLR implementation, both to facilitate portability and to make the codebase more approachable"

    you can find it here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/mssharsourcecli2.asp

    It is also my contention that C# and the CLR are nothing new, but more the evolution of J++ and the MS VM. I could be wrong? In either event, here is a link to a Sun doc in response to some perversions of Java Microsoft started making years ago:
    http://java.sun.com/docs/white/delegates.html

    Here is an intersesting quote from above article discussing why Bound Delegates are not desireable:
    "In the most extreme case, a compiler and VM might avoid reflection altogether in favor of special native methods. While a highly efficient implementation is achievable in this way, such a strategy immediately precludes portability to compliant implementations of the Java platform. This is a serious objection, as it abandons the core value proposition of the Java platform: 'Write once, run anywhere.'"

    Don't get me wrong, they (Sun) don't soundly defend the practice of Bound Delegates. Please read for your own opinion. Mine, simply put, Bound Delegates speed up the entropy process, but this may be what speeds .Net up?

    Incidentally, this topic was covered somewhat in the Sun vs. MS court battle. Some intersting reading:
    http://java.sun.com/lawsuit/hearing.091098.html
    What's funny is how any judge could understand this?

    Bottom line is - I don't think the Intermediary code you compile on a Windows box today with .NET will run on any other platform VM in the future ever. I think this due to the "special native methods" mentioned above. Perhaps the Windows intermediary code and the Windows VM (oops, I mean CLR) work in concert, I don't know? I'm ignorant in that area. However this quotes rings on in my head:

    "There ARE significant differences in implementation between this code and the code for Microsoft's commercial CLR implementation, both to facilitate portability and to make the codebase more approachable"
    Reply to this Reply to original

  194. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Is performance really the most important thing to measure? I haven't seen many performance issues that couldn't be solved by adding more hardware. And performance is constantly improving so what is slow today could be highly optimized tomorrow.

    For me the most important is the cost in developing on the platform and the quality of the result. If one technology is twice as fast but takes twice as long to develop then is it really a good deal? How many developers are available for each technology? What do developers enjoy more? (Remember happy developers are productive developers.) In my opinion there are many issues much more important than simply which one is faster.

    Michael
    Reply to this Reply to original

  195. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Guys, first of all, I will talk you not about technology but about public authority. I think no one could contest TSS & TMC knowledge and importance in th J2EE community, so you are something what I named a public authority in J2EE world. Th obvious consequence is that all IT community (not just J2EE community) is expecting whatever you say or do (about technology of course). So like public authority you must be careful on methodolgy when you do something like this benchmark, and if you really want to make a benchmark not a marketing gimmik you have to proceed by a way your procedure could not be in doubt. You don't have to forget that the java community aversion to Microsoft is not about they like to be in everywhere in the information technologys market but how they did it and their strong dislike to competition.

    So I think, you have to do a second round, and do it the way I and community expected from a public authority.

    Like a developer, I think a benchmark like these have to be done on other platforms to be conclusive, I mean do the benchmark on equivalent hardware running different OS, like Linux, Solaris, HP-UX,... This really would be useful because a benchmark give us information about really a platform is better than other for my purposes.

    Regards,

    Pablo Antonioletti
    Reply to this Reply to original

  196. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Forget you guys, you have become next to useless when it comes to comparing products. Stick to news reporting. Please drop "Your J2EE Community" from your header. You should be ashamed to have done this to the cummunity that put you on the map.
    Reply to this Reply to original

  197. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I think it is a good idea to have round 2 comparison, so that this time both parties will be much better prepared. i.e. preferred hardware platform.
    Reply to this Reply to original

  198. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Why bother? Who cares which one is faster?
    Reply to this Reply to original

  199. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    "Nine man-months of 100-hour weeks were spent performing this work"

    Come on, Seriously? If that is the best TMC came up with in that much time they better just put this rematch stuff to rest. Based on that timeframe, we shouldn't be seeing a rematch until at least 1Q 2004?
    Reply to this Reply to original

  200. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Is Microsoft releasing RC2 of its software/tools so it wants another benchmark?

    TSS/TMC is misusing Java community yet again ... they will come with another benchmark that will say "we've included the suggestions from java community and here are the results ... " Any complains at that time would have no ground/base... nice game, eh?

    Who gives you guys the right to represent Java/J2EE community and not one but (all) J2EE servers? Where did you earn that???
    Reply to this Reply to original

  201. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    The Big Picture:

    Every project has limited resources - time, money, programmers, hardware, software, etc.

    Every project also has specific goals. These goals dictate which metrics are important. Performance is only one measure of an application. As many have mentioned, scalability, extensibility, portability, etc. are also important measurements.

    For an application that will run on a Wintel box and where performance is paramount and your engineers are skilled and experience with .NET, I have no doubt that .NET is a better choice.


    The choice of technology must fit the goals of the application and the resources available.

    The first test was absurd and a retest would be equally as ridiculous.
    Reply to this Reply to original

  202. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Your denial is starting to smell a lot like Arthur Anderson. Make a better than half-hearted attempt to answer Rickard's questions. Then move on. Everyone wants to get back to the game. Let's not kill the messenger just yet. .Net could very well be faster - hard-wired and unmaintainable as it may be. Let's code.

    Microsoft is a marketing company and you gave them what they wanted. You don't have the money or visability to do spin control. You do have the voices on this board which is what you need to dig yourself out. My feeling is that if you bleed a little more and bleed fast - and then open this up to all vendors or other groups you can recover.

    The performance data and techniques would be invaluable to shops using J2EE.
    Reply to this Reply to original

  203. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Floyd, I've recently read your book. Very good I might add. I'm curious, have the two experts who worked on the benchmark Petstore read it?
    Reply to this Reply to original

  204. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Don't loose time anymore ... M$ "general" BG is building is mercenary army after seeing that he can't buy honest soldiers ...
    Strength and honour ...
    http://www.cnn.com/2002/WORLD/asiapcf/south/11/12/india.gates.invest.ap/index.html
    Reply to this Reply to original

  205. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    NEW DELHI, India (AP) -- Microsoft Chairman Bill Gates

    >> announced that his company would invest $400 million to
    >> improve computer literacy and expand his company's
    >> activities in India.

    >> The announcement came a day after he pledged $100 million
    >> to fight AIDS in India.

    > Don't loose time anymore ... M$ "general" BG is building
    > is mercenary army after seeing that he can't buy honest
    > soldiers ...
    > Strength and honour ...
    > http://www.cnn.com/2002/WORLD/asiapcf/south/11/12/india.gates.invest.ap/index.html

    What is wrong with giving money to fight AIDS and enhance education in India? If you suspect BG has some alternative motive, then why not? If it saves lifes and improves education levels....then let him...
    Reply to this Reply to original

  206. Go for it![ Go to top ]

    First of all I aplologize for my language, my first language is not English.

    I still have confidence in TheServerSide and The Middleware Company. You did a good job considering the budget you had. Perhaps the information in the FAQ could have been published when you published the report. Perhaps you could have rewritten the MS PetShop to use proper component technology. The report was quite open about what you had done and not done. You didn't advocate MS technology, but simply stated the facts. Anyone could figure out that you were comparing apples to pears.

    I really appreciate the debate following the Microsoft PetShop marketing coup. MS PetShop puts the light on some very murky aspects of EJB. Competition is really important for development, as Darwin discovered. When perfoming the benchmark you actually improved performance of the Java implementation an order of magnitude without doing much about the architecture.

    I believe the MS PetShop is a marketing ploy since is doesn't use Microsoft component technology, i.e. COM+. The Java PetStore uses EJB component technology and can therfore be distributed. The Java PetStore is built as an enterprise architecture, allowing the possible use of the deployed beans from other applications. The MS PetShop is a stand alone application, no distribution at all.

    If you perform a rematch I would really like to see a properly distributed MS PetShop, using COM+ for at least two tiers below the GUI stuff. The components should also display generic interfaces, to allow other possible uses, not just the functionality needed for the PetShop application.

    The current situation is a very good opportunity for evaluation of both architectures and technology. Much is at stake and the companies involved should be prepared to invest a lot of money in evaluation of their products. The PetStore/PetShop applicaion is small enough to be used as a guinea pig. I believe that there are a lot of people an businesses prepared to contribute by building alternate solutions as well as porting existing ones to other servers. All it takes is someone to organise this effort, and I believe that TheServerSide could do this. Are there any other organisations to do it? Your role would then be to define the ground rules and evaluate the contributions. The contributions and standardized testing tools should be downloadable from your site. I guess I am hoping for too much though :-).

    I am myself working on a solution using MSMQ for all distributed communication, XML for message formatting, and C# for implementation. The goal is to show that asynchronous messaging could be used for a typical web application. The reason for doing it in MS technology is to learn (you have to stand close to your enemy to know him :-). In order to evaluate my application I could use a PetShop properly deployed using COM+. Is there anyone planning to do this? Please contact me at reklam at holisticode dot se.

    I also believe that the different solutions should be compared using also other qualities than perfomance, like robustness, flexibility, integrity, reuse.

    I suggest that there should be two different classes in the world championship in petshopping. One "Enterprise Architecture" class and one "Stand Alone Design" class. The Java PetStore will compete in the Enterprise Architecture class and the MS PetStore in the "Stand Alone Design".

    Thanks

    Mårten Gustafsson
    Reply to this Reply to original

  207. Go for it![ Go to top ]

    <Gustafsson>
    MS PetShop ... doesn't use Microsoft component technology, i.e. COM+.
    </Gustafsson>
    MS Petshop uses .Net, .Net uses COM+:
       COM = components
       DCOM = distributed COM
       MTS = transactions
       COM+ = DCOM + MTS + messaging + pooling + security
       .Net = COM+ + common runtime + easier deployment

    <Gustafsson>
    The MS PetShop is a stand alone application, no distribution at all.
    </Gustafsson>
    The MS PetShop components could be deployed across machines with zero code changes.

    <Gustafsson>
    I am myself working on a solution using MSMQ for all distributed communication
    </Gustafsson>
    May I suggest queued components? They require zero extra code (just configuation changes) and do exactly what you describe.
    Reply to this Reply to original

  208. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    PetShop.NET is purely optimized for speed. Bad design, which completely ridicules the statement of MS, that it is supposed as Best Practices for .NET developers.

    Note: Even .NET users are hammering on Petshop.NET as absolutely terrible design, an "anti-pattern" to be torn apart and used an an example of bad architecture. Gotta love it:
    PetShop.NET: An Anti-Pattern Architecture
    (see also .NET vs J2EE benchmark: Interviews, a Rematch and a Live Debate).
    Reply to this Reply to original

  209. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    <martin>
    PetShop.NET is purely optimized for speed. Bad design, which completely ridicules the statement of MS, that it is supposed as Best Practices for .NET developers.
    </martin>

    Less lines of code, runs faster, for less money. Not sure why that isn't a best practice. Ask your CEO if he wants you writing code for less money in less time that runs faster.

    Why are we all so damned enamored with design patterns.

    This thread reads like a Microsoft ad. Everyone here arguing about which design patterns to use, which persistance patterns, etc. In the meantime the MS trolls are laughing their asses off while they click wizards.
    Reply to this Reply to original

  210. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    <Maggie>
    Less lines of code, runs faster, for less money. Not sure why that isn't a best practice. Ask your CEO if he wants you writing code for less money in less time that runs faster.
    </Maggie>

    How about when your customer comes to you and says, "OK. I liked that app you wrote really quickly that was really fast with not much code. Now I want you to add another supplier, switch out the order tracking system you wrote with another product we just bought. Also, we want this to be able to exposed as a web service to some of our bigger clients. Oh, and can you integrate this with our new accounting system?" And you say, "Sorry, no can do. That really fast app we wrote really isn't extensible because we didn't use any best practices or design patterns. The code is full of assumptions and dependencies. We can re-write the whole thing..."

    How's your CEO gonna like that one? *That's* why we have design patterns and best practices. Software doesn't end at version 1.0. Have you ever been involved in the full lifecycle of a product?

    Ryan
    Reply to this Reply to original

  211. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    Yeah, I agree. In my experience, using design patterns acutally results in lesser code (written/updated) over time for large projects.

    Of course, if you have just a silly little website to develop (silly only in terms of magnitude of complexity), then design patterns are probably overkill.

    Sandeep.
    Reply to this Reply to original

  212. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    Maggie: "Less lines of code, runs faster, for less money. Not sure why that isn't a best practice. Ask your CEO if he wants you writing code for less money in less time that runs faster."

    Repeating things does not make them true. It is true that, in a small percentage of tests, the latest version of .NET can be shown to be faster than the latest version of Java, but that is the exception not the rule, and certainly the Microsoft-altered PetStore test (designed to show the only area that Microsoft thought that it could get an edge in) is not indicative of anything that I've seen in the real world. Again, why did the .NET PetStore 2 require XA on the Java side but used proprietary SQL Server extensions on the Microsoft side?

    Furthermore, even in the small percentage of tests that show areas in which .NET can edge Java by up to 10% or even 20% in performance, does that imply that we should dump an industry standard to re-invest in a proprietary standard? If so, why would we even consider web services for example? Why not do some proprietary precursor to EDI, which is probably faster?

    Microsoft chose a proprietary model and a proprietary strategy. They will get people to invest in and build for the .NET product, but so what? There are still people building for VB (pre .NET versions) too.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  213. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    Introspection by Sami JABER:-
    "The implementation of PetShop.NET 2.0 reference application suggested by Microsoft as challenger of Java PetStore approaches more the Anti-Pattern Architecture than a true reference implementation."

    Find out :
    http://www.ejbsig.de/docs/PetShopArchitecture.html
    Reply to this Reply to original

  214. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    "does that imply that we should dump an industry standard to re-invest in a proprietary standard"

    "Standard" in this case is really a marketing gimmick. MS technologies (.NET and otherwise) are quite pervasive...in a way a semi-quasi-standard in its own right. Java/J2EE is not standardized in the same sense that XML, C++, etc are.

    It is true that Java/J2EE will run on many platforms while MS technologies will not; and that can be an important thing. But your use of the term "industry standard" is a stretch.

    (Peace back at you :-))
    Reply to this Reply to original

  215. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    "It is true that, in a small percentage of tests, the latest version of .NET can be shown to be faster than the latest version of Java"

    A small percentage? I haven't seen *any* published test in which Java is faster than .NET. Except the one published by Oracle a few months ago, but it seems not even Oracle is backing it now.

    "Furthermore, even in the small percentage of tests that show areas in which .NET can edge Java by up to 10% or even 20% in performance"

    10% or 20%? We are talking twice as fast in many test here. But let's not discuss details what I really don't like is the way this community is behaving:

    T1. "Microsoft will never create something as good as Java"
    T2. A benchmark proves the previous statement may be wrong
    T3. "The benchmarks is flawed, TMC was sold, MS is evil."
    T4. "Benchmarks really don't say a thing. Even if they would, we are not going to switch because it took a lot to learn it."

    This is so sad. Java has proved to be a viable platform on its own technological merits, this was obvious years ago. It was just a question of time for something better to appear. This is called progress. That next big thing could have come from Sun, IBM or any other Java party, instead most of them preferred to look themselves in the mirror and keep saying how great they were, and how nice and good, especially compared to the "evil monopolist". Time to wake up: Microsoft, "evil monopolist" or not, created the next big thing in programming. Denying it is the obvious first phase but the sooner you get over it and start working in the next Java the better. The clock is ticking, accept the facts and start working in Java++++ (or whatever).
    Reply to this Reply to original

  216. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    Time to wake up: Microsoft, "evil monopolist" or not, created the next big thing in programming.


    I am not sure what M$ has ever created all see is copy cat of Java which still has buffer over flow snd security issue. Scalability is still a issue of .Not and all it runs is in windozes forget Linux.. .

     If you call this .Not good then Java must the greatest thing ever as programming language and platform.


     Get real MS is releasing patch for .Not almost everyday ...the .Not server has nothing but full of problems. Remember Long Horn that has be scrapped.

    I know your a MS troll. All the time MS trolls is in denial of how good Java snd Linux

    Since .Not and Windoze is not winning from technical merit MS trolls and marketing tactics is to create false doucments to show Java and Linux is bad.
    Reply to this Reply to original

  217. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    Time to wake up: Microsoft, "evil monopolist" or not,

    >> created the next big thing in programming

    The next big thing??

    What does "big" mean for you?

    Are there huge differences in the languages? Not at all.
    Certainly nowhere NEAR the difference between Java/C# and C++ !

    Are there huge differences in the serverside runtime environments? Yes and no. There are positives and negatives both ways. They are similar - except that one is platform and vendor neutral - and the other is tightly integrated with one platform.

    Are there huge differences in the development environments? Again, yes and no. VS.net is a good tool - but doesnt hold a candle to some of the admittedly narrower focused tools like Eclipse, Together and IntelliJ.

    What are the key value propositions for you that make .net the next big thing?

    -Nick
    Reply to this Reply to original

  218. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    Nick:

    "What are the key value propositions for you that make .net the next big thing? "

    Point taken. Drop the "big". .NET is the next thing. Evolutionary not revolutionary.
    Reply to this Reply to original

  219. PetShop.NET analysis reveals its Anti-Pattern Architecture[ Go to top ]

    Edgar,

    Cameron: "It is true that, in a small percentage of tests, the latest version of .NET can be shown to be faster than the latest version of Java"

    Edgar: "A small percentage? I haven't seen *any* published test in which Java is faster than .NET. Except the one published by Oracle a few months ago, but it seems not even Oracle is backing it now."

    I haven't seen *any* published tests that showed that .NET is faster than Microsoft except those done by Microsoft. (I thought I'd point out how silly your comment was.)

    I have .NET 1.02 on my machine. I also have various JVMs from 1.1.8 up to 1.4.1_01. When I was benchmarking earlier version of .NET, they couldn't even complete some of the benchmarks (you can see some posts on the Microsoft news groups about problems with array allocation.) Furthermore, there are many tests where .NET and Java are roughly even, and a good number where Java edges or even trounces .NET.


    Cameron: "Furthermore, even in the small percentage of tests that show areas in which .NET can edge Java by up to 10% or even 20% in performance"

    Edgar: "10% or 20%? We are talking twice as fast in many test here. But let's not discuss details what I really don't like is the way this community is behaving"

    Again, I have Java and .NET both. Please send me the code that shows .NET is so much faster. Or better yet, post it here. (I'll be sure to forward it to the appropriate JVM vendors if you can find an example that is significantly faster.) Thanks!

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  220. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron:

    "Please send me the code that shows .NET is so much faster. Or better yet, post it here. (I'll be sure to forward it to the appropriate JVM vendors if you can find an example that is significantly faster.) Thanks!"


    Just a humble example: adding a cent 10 million times. Java first:

    import java.math.BigDecimal;
    import java.util.Date;

    public class DecimalAdd {
      public static void main(String[] args) {
        BigDecimal oneCent = new BigDecimal("0.01");

        Date start = new Date();
        BigDecimal total = new BigDecimal(0);
        for (int i = 0; i < 10000000; i++)
          total = total.add(oneCent);
        Date finish = new Date();

        System.out.println("Total: " + total);
        System.out.println("Time: " + (finish.getTime() - start.getTime()));
      }
    }

    Now C#:

    using System;

    public class DecimalAdd
    {
      public static void Main()
      {
        decimal oneCent = 0.01m;

        DateTime start = DateTime.Now;
        decimal total = 0m;
        for (int i = 0; i < 10000000; i++)
          total += oneCent;
        DateTime finish = DateTime.Now;

        Console.WriteLine("Total: " + total);
        Console.WriteLine("Time: " + (finish - start));
      }
    }

    In this very machine, Java takes from 15.3 to 22.4 seconds, C# takes from 1.2 to 1.4 seconds, that doesn't look like 10 to 20% faster to me...
    Reply to this Reply to original

  221. Please send me the code that shows .NET is so much faster[ Go to top ]

    Yes, but the java

    total = total.add(oneCent);

    construct is not exactly the same as the C#

    total += oneCent;

    now, is it?

    What is the time for
    total += oneCent;
    in Java
    Reply to this Reply to original

  222. Please send me the code that shows .NET is so much faster[ Go to top ]

    <What is the time for total += oneCent; in Java>

    replacing the java code with the proper equivalent to the C# code:

    import java.util.Date;

    public class DecimalAdd {
      public static void main(String[] args) {
    double oneCent = 0.01;
    double total = 0.0;
        Date start = new Date();
        for (int i = 0; i < 10000000; i++)
          total += oneCent;
        Date finish = new Date();

        System.out.println("Total: " + total);
        System.out.println("Time: " + (finish.getTime() - start.getTime()));
      }
    }

    total time is .16 sec on my machine
    Reply to this Reply to original

  223. Please send me the code that shows .NET is so much faster[ Go to top ]

    yes, but you don't have the same machine and you didn't run the C# code
    Reply to this Reply to original

  224. Please send me the code that shows .NET is so much faster[ Go to top ]

    Dan:
    "replacing the java code with the proper equivalent to the C# code"

    No Dan, double is not the "proper equivalent" of decimal. If you check the result (at least with 1.4.1-b21) it is 99999.999986... not plain 100000 as it should be.
    Reply to this Reply to original

  225. Please send me the code that shows .NET is so much faster[ Go to top ]

    is += a valid syntax for BigDemical and is there any perforance advantage?
    Reply to this Reply to original

  226. Please send me the code that shows .NET is so much faster[ Go to top ]

    This is the VC++ code

    #include <windows.h>
    #include <iostream.h>

    int main(int argc, char* argv[])
    {

        double OneCent = 0.01;
        double Total = 0.0;

        DWORD dwStart = ::GetTickCount();

        for( int i = 1; i<= 10000000; i++ )
        {
            Total += OneCent;
        }

        DWORD dwFinish = ::GetTickCount();

        cout<    return 0;
    }

      It took 47 MilliSeconds. i.e., .047 seconds on my machine.

     My machine :
      Processor speed : Pentium 598 MHz
      RAM : 256 MB
      OS : Windows 2000
     
     What would you java guys do if MS pitted VC++ against java?
     b'cos if you ask me VC++ is a pretty good tool for developing truly distributed apps. And that's what I do in my everyday work. We have 3 high end servers (conceptually )that handle various aspects of day trading such as consolidating various real-time market datafeeds from ECNs ( ISLD, REDI, ARCA, INCA etc ), NYSE, NASDAQ, market makers, etc , taking care of order executions on all these sources and handling real-time risk management. We wrote the entire software using VB, VC++, COM+, DCOM, ADO, SQL Server 2000. The highest CPU utilization ( on a high volume day ) I have seen till date is no more than 30% on any one of the machines.
    Reply to this Reply to original

  227. Please send me the code that shows .NET is so much faster[ Go to top ]

    OOPS !!! typo errors ..
     
     replace the last line with
     
     cout< cout<
     I built the "Release version" of the executable and ran it. The Output is :
     
     Total time taken : 47
     Total Value : 100000

     PS: GetTickCount() function gives the time stamp in milli seconds
    Reply to this Reply to original

  228. Please send me the code that shows .NET is so much faster[ Go to top ]

    Ok I hope that I get this thing right in my third attempt. Looks like the copy & paste process doesn't work properly in this text box so I am typing the last two lines myself.
    cout<cout<
     by the way, you can run the same code in Visual Studio .NET also. Just "cut & paste " .
    Reply to this Reply to original

  229. Please send me the code that shows .NET is so much faster[ Go to top ]

    Ok i finally figured out the problem with this text box. On any particular line, It truncates the portion of the text that comes after a pattern such as " <text< ". Therefore, I have modified my code as :

         cout<        <        <
        cout<        <        <
     replace the last line of code in my original posting with this code and run it either in your VS .NET or VC++ editor.
     
     hope this works.
    Reply to this Reply to original

  230. Please send me the code that shows .NET is so much faster[ Go to top ]

    <quote>
    What would you java guys do if MS pitted VC++ against java?
    </quote>

    Isn't that what they've been doing for the past seven years?

    <quote>
     b'cos if you ask me VC++ is a pretty good tool for developing truly distributed apps. And that's what I do in my everyday work. We have 3 high end servers (conceptually )that handle various aspects of day trading such as consolidating various real-time market datafeeds from ECNs ( ISLD, REDI, ARCA, INCA etc ), NYSE, NASDAQ, market makers, etc , taking care of order executions on all these sources and handling real-time risk management. We wrote the entire software using VB, VC++, COM+, DCOM, ADO, SQL Server 2000. The highest CPU utilization ( on a high volume day ) I have seen till date is no more than 30% on any one of the machines.
    </quote>

    That's nice. Tell you what. Add a line to your code that prints the result of:

    Total - 100000

    Get back to me after you've finished rewriting the VB, VC++, COM+, DCOM, ADO, and SQL Server 2000 code so that it either does the math 'properly' or doesn't hide the 'bad' math.
    Reply to this Reply to original

  231. Please send me the code that shows .NET is so much faster[ Go to top ]

    What would you java guys do if MS pitted VC++ against java?

    >> b'cos if you ask me VC++ is a pretty good tool for
    >> developing truly distributed apps.

    Is this some kind of joke? :-)
    It is no contest.
    Java is a much better language than C++ on almost all counts.


    Let me enumerate just some of the reasons why I think C++ is a BAD language for distributed apps.

    1) No checked exceptions.
    2) No tue base-class exception catch(...) means no info on exception type.
    3) 8+ different string types - and not even built-in conversions between std::string and std::wstring !
    4) Missing huge amounts of functionality (compared to the java libraries). std::string doesnt even have something as simple as a trim() method. 100's more examples of this.
    5) Memory leaks
    6) Dangling pointers
    7) Memory corruption
    8) Debugging multi-threaded C++ apps is next to impossible
    9) STL is a nightmare to debug (and you need STL if you want any collections)
    10) If you use a DLL that is built with a different build of the runtime dll (e.g. debug version) then your app will blow up - and you wont know why
    11) There is no way to step through the runtime in a debugger (whereas you can with the Java libraries because you have all the source)
    12) ...
    There are just too many to list.

    In summary:
    1) its 10x slower to develop stuff
    2) its 10x less reliable
    3) its not 10x faster

    -Nick
    Reply to this Reply to original

  232. Please send me the code that shows .NET is so much faster[ Go to top ]

    "Java is a much better language than C++ on almost all counts.

    Let me enumerate just some of the reasons why I think C++ is a BAD language for distributed apps.

    "1) No checked exceptions. "
    Big deal.

    "2) No tue base-class exception catch(...) means no info on exception type. "
    Takes 5 minutes to write one.

    "3) 8+ different string types - and not even built-in conversions between std::string and std::wstring !

    4) Missing huge amounts of functionality (compared to the java libraries). std::string doesnt even have something as simple as a trim() method. 100's more examples of this.
    "

    The STL's string family does leave a lot to be desired. But much of that has to do with the fact that it is really a facade over char/wchar pointers.
    Java's lack of templates hurts the language.

    "5) Memory leaks
    6) Dangling pointers
    7) Memory corruption
    "
    None of these is part of the C++ language. They are the result of bad code. Memory leaks and dangling pointers are possible in Java. In fact, Java makes it harder to manage resources because of non-deterministic object destruction.

    "8) Debugging multi-threaded C++ apps is next to impossible "
    That's false.

    "9) STL is a nightmare to debug (and you need STL if you want any collections)."
    Why are you debugging the STL?

    "10) If you use a DLL that is built with a different build of the runtime dll (e.g. debug version) then your app will blow up - and you wont know why "

    DLLs have nothing to do with C++.

    "11) There is no way to step through the runtime in a debugger (whereas you can with the Java libraries because you have all the source) "
    What runtime? You can step through anything that you have the source to....

    C++ is a much more expressive language than Java. Java is VB with OO plus a nice library set that runs on many platforms. It has a nice use now. But it is not a great language by any stretch.
    Reply to this Reply to original

  233. Please send me the code that shows .NET is so much faster[ Go to top ]

    "C++ is a much more expressive language than Java. Java is VB with OO plus a nice library set that runs on many platforms. "

    LOL! You IDIOT!
    Reply to this Reply to original

  234. Please send me the code that shows .NET is so much faster[ Go to top ]

    You have a clear and simple business requirement "add a cent 10 million times", the result should be US$ 100,000. The way to do it in Java is using BigDecimal, the way to do it in C# is using decimal. Of course, both languages have double and we could've use it but we would've got the wrong result in both platforms. So, from a business point of view, I gave you the closest possible code in both platforms.
    Reply to this Reply to original

  235. Please send me the code that shows .NET is so much faster[ Go to top ]

    <quote>
     You have a clear and simple business requirement "add a cent 10 million times",
    </quote>

    OK.

    <quote>
    the result should be US$ 100,000.</quote>
    </quote>

    OK.

    <quote>
    The way to do it in Java is using BigDecimal
    </quote>

    Not OK.

    <quote>
    the way to do it in C# is using decimal
    </quote>

    Probably.

    <quote>
    Of course, both languages have double and we could've use it but we would've got the wrong result in both platforms. So, from a business point of view, I gave you the closest possible code in both platforms.
    </quote>

    Nope. BigDecimal and decimal are not analagous types. BigDecimal is an *arbitrary* precision type, wheres decimal has a specified precision. For financial calculations, working in cents directly is far more efficient, in both langauges:

    ==================
    public class DecimalAdd {
        public static void main(String[] args) {
            long oneCent = 1L;
            long start = System.currentTimeMillis();
            long total = 0L;
            for (int i = 0; i < 100000000; i++) {
                total += oneCent;
            }
            long end = System.currentTimeMillis();

            System.out.println("Total cents: " + total);
            System.out.println("Total dollars: " + total/100);
            System.out.println("Time: " + (end - start)/1000.0);
        }
    }

    *That* is much closer to running the same code in both platforms.
    Reply to this Reply to original

  236. Over-engineering and right-engineering[ Go to top ]

    "BigDecimal and decimal are not analagous types. BigDecimal is an *arbitrary* precision type, wheres decimal has a specified precision."

    Technically you are totally right. BigDecimal can hold and arbitrary number of digits whereas .NET decimal can hold only 28 digits. No doubt you can mention an app that needs any number of decimal digits but 9x% of the time you will do just right with 28 digits. It's nice that Java engineers created something as appealing as arbitrary precision decimals but most of us just pay the overhead of such academic exercise without getting any real benefit. It's right-engineering vs. over-engineering.

    "For financial calculations, working in cents directly is far more efficient, in both langauges: "

    May be so, but then you have a decimals problem solved with longs, next thing you will have to deal with scales and conversions, and you end up writing infraestructure instead of business solutions. Intellectually attractive, but unfortunately we are not paid for such chores.

    By the way, I love academic exercises and I hold the greatest respect for computer science theorist. It's only that we are talking business here...
    Reply to this Reply to original

  237. Please send me the code that shows .NET is so much faster[ Go to top ]

    Dear Edgar,

    Beautiful post!

    Edgar: "In this very machine, Java takes from 15.3 to 22.4 seconds, C# takes from 1.2 to 1.4 seconds, that doesn't look like 10 to 20% faster to me..."

    Good point. I'd like to know if you knew BigDecimal sucked eggs because you used to use Java or because someone was kind enough to point you to it. Either way, you are right. Absolutely right.

    Yes, it does appear that you found a test that shows .NET to be faster. So I improved the test to show just how fast .NET really is!

    import java.math.BigDecimal;
    public class DecimalAdd
        {
        public static void main(String[] args)
            {
            System.out.println("Starting ...");
            long lStart = System.currentTimeMillis();
            BigDecimal decTotal = new BigDecimal("100.00");;
            for (int i = 0; i < 10; ++i)
                {
                decTotal = decTotal.multiply(decTotal);
                }
            long lStop = System.currentTimeMillis();
            System.out.println("Total: " + decTotal);
            System.out.println("Time: " + (lStop - lStart) + "ms");
            }
        }

    using System;
    public class DecimalAdd
        {
        public static void Main()
            {
            Console.WriteLine("Starting ...");
            DateTime dtStart = DateTime.Now;
            decimal decTotal = 100m;
            for (int i = 0; i < 100; ++i)
                {
                decTotal *= decTotal;
                }
            DateTime dtStop = DateTime.Now;
            Console.WriteLine("Total: " + decTotal);
            Console.WriteLine("Time: " + (dtStop - dtStart));
            }
        }

    Can you please tell me what the following means:

    Application has generated an exception that could not be handled.
    Process id=0x3dc (988), Thread id=0x1b4 (436).
    Click OK to terminate the application.
    Click CANCEL to debug the application.

    Is that a UAE or a GPF? Unfortunately, with .NET being so quick, I wasn't able to get a good timing for how fast it blew up. Please advise.

    BTW - Java was 20ms.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  238. Please send me the code that shows .NET is so much faster[ Go to top ]

    <Unfortunately, with .NET being so quick, I wasn't able to get a good timing for how fast it blew up. Please advise. >

    Thanks Cameron. You just made my day :D

    Dan
    Reply to this Reply to original

  239. Please send me the code that shows .NET is so much faster[ Go to top ]

    Lol, excellent post Camery. IN YOUR FACE Edger!
    Reply to this Reply to original

  240. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron:

    "I'd like to know if you knew BigDecimal sucked eggs because you used to use Java or because someone was kind enough to point you to it."

    I still program in Java, I don't understand why you always presume that if we're proficient in any other technology then we can't possibly be proficient in Java. Beats me.

    I also see that as you couldn't possibly win in the original test, you changed the problem to "start with 100, multiply it by itself, take the result and multiply it by itself, and so on ten times". A funny business problem if you ask me but let's go ahead: you did this because you knew of BigDecimal arbitrary precision. You also chose carefully the parameters: should you have decided to do the multiplication 100 times it would have taken far, far longer than 10 times as much (I gave up after it took more than 10 minutes and my machine started to really drag). As for C#, I got a standard overflow exception trace due to the fact that decimal can only hold 28 digits, I never saw the cryptic message you mention but anyway, point taken.

    So in Java we have a slow but arbitrarily exact type: BigDecimal. In C# we have a fast but only 28 digit exact type: decimal. Or not? Well, actually in C# you can inherit from J# BigDecimal and also have a slow but arbitrarily exact type. Which one is more flexible then?

    Really peace (and remember this is about all of us learning not about winning the debate),


    Edgar S.
    Reply to this Reply to original

  241. Please send me the code that shows .NET is so much faster[ Go to top ]

    Thanks Edgar. You just made my day!

    Still waiting for some real Java code examples..

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  242. Please send me the code that shows .NET is so much faster[ Go to top ]

    Hi Edgar,

    Cameron: "I'd like to know if you knew BigDecimal sucked eggs because you used to use Java or because someone was kind enough to point you to it."

    Edgar: "I still program in Java, I don't understand why you always presume that if we're proficient in any other technology then we can't possibly be proficient in Java. Beats me."

    I made an incorrect assumption based on something that you wrote. I was not intending to cast aspersions on anyone's abilities.

    Edgar: "I also see that as you couldn't possibly win in the original test, you changed the problem to "start with 100, multiply it by itself, take the result and multiply it by itself, and so on ten times". A funny business problem if you ask me but let's go ahead: you did this because you knew of BigDecimal arbitrary precision."

    That's correct. Like you, I know a bit about both Java and .NET. In my case, it's apparently just enough of both to be dangerous. From a technological point of view, I like them both. From a business point of view, I think that Microsoft should have stuck with Java and prevented this collosal waste of time (including the arguments), but unfortunately, it probably _was_ in Microsoft's best interest to produce a proprietary system similar to (but not compatible with) Java.

    Back to the example. I didn't like the example of BigDecimal vs. Decimal for two reasons:

    1) BigDecimal is about the worst performer in Java because it is general purpose (and obtuse) to the Nth degree, and
    2) Decimal is not .NET's version of BigDecimal.

    Edgar: "You also chose carefully the parameters: should you have decided to do the multiplication 100 times it would have taken far, far longer than 10 times as much (I gave up after it took more than 10 minutes and my machine started to really drag)."

    Heh! But it would have eventually finished with the correct answer ;-)

    Don't give me too much credit. I assure you that it was not a scientific test.

    Edgar: "As for C#, I got a standard overflow exception trace due to the fact that decimal can only hold 28 digits"

    Hmm. I thought that I was on the 1.0.2 build (to fix the array allocation GPF,) but who knows? What's the current build number that you're running?

    Edgar: "I never saw the cryptic message you mention but anyway, point taken."

    My point was that fast but not working isn't worth anything. Reliability is key. You're probably right that this bug has been fixed, and .NET is certainly improving on the stability side (as most young products tend to do.)

    However, this is definitely classic Microsoft. It's one of the main reasons why companies don't put mission critical apps onto Microsoft platforms.

    Edgar: "Well, actually in C# you can inherit from J# BigDecimal and also have a slow but arbitrarily exact type. Which one is more flexible then?"

    Have you run any perf tests with the J# BigDecimal vs. the latest Java VMs? Now that would be more interesting. Note that to get stable perf numbers with HotSpot, you should run the tests in a loop. These tests that run just once are a great way to show how HotSpot doesn't optimize initially ;-). Or you could just use IBM's JIT.

    Edgar: "Really peace (and remember this is about all of us learning not about winning the debate)"

    Good points. Have a good weekend.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  243. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron: "From a technological point of view, I like them both. From a business point of view, I think that Microsoft should have stuck with Java and prevented this collosal waste of time (including the arguments), but unfortunately, it probably _was_ in Microsoft's best interest to produce a proprietary system similar to (but not compatible with) Java."

    May be so, the point is that .NET has technological merits and denying it actually endangers Java. Instead of saying that .NET decimals suck if I were Sun I would be adding fast, reliable and not arbitrarily exact decimals to Java 1.5, it shouldn't be that hard and it would be a service to the business programming community. I would respect them far more if they would do this kind of thing than endlessly sueing Microsoft.

    Cameron: "I didn't like the example of BigDecimal vs. Decimal for two reasons:

    1) BigDecimal is about the worst performer in Java because it is general purpose (and obtuse) to the Nth degree, and
    2) Decimal is not .NET's version of BigDecimal."

    Point 1 for not liking the example is Java's fault of course. Point 2 is correct from a technical perspective but from a business perspective they are equivalent. Why? Because if I would be programming a general ledger in Java I would use BigDecimal and in C# I would use decimal. Many people would say that I should create MyDecimal in Java but, as I said before, unfortunately we are paid for writing business solutions not infrastructure.

    Cameron: "What's the current build number that you're running?"

    .NET 1.0.3705

    Cameron: "My point was that fast but not working isn't worth anything. Reliability is key. You're probably right that this bug has been fixed, and .NET is certainly improving on the stability side (as most young products tend to do.) "

    Yes, I got that. Without reliability, speed is nothing. About bugs being fixed in .NET as the platform matures, .NET 1.1 is around the corner, can you hear the clock ticking for Java?

    Cameron: "Have you run any perf tests with the J# BigDecimal vs. the latest Java VMs? Now that would be more interesting."

    Nop and I agree that would be interesting, I hope me or someone else have the time to do it.

    You are a clever guy Cameron and even if I dissent with you in many points (or precisely because of it) I like arguing with you.

    Edgar S.
    Reply to this Reply to original

  244. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron: "1) BigDecimal is about the worst performer in Java because it is general purpose (and obtuse) to the Nth degree"

    Edgar: "Point 1 for not liking the example is Java's fault of course"

    There was no debate on this point. However, it's now a dead horse. You've beaten it. I've beaten it. However, if you've taken the time to profile BigDecimal, then I'm sure you've looked at other things in the language and come to realize that the CLR is not generally any faster than Java.


    Cameron: "What's the current build number that you're running?"

    Edgar: ".NET 1.0.3705"

    Same here. That program GPFd every time I ran it.


    Cameron: "My point was that fast but not working isn't worth anything. Reliability is key. You're probably right that this bug has been fixed, and .NET is certainly improving on the stability side (as most young products tend to do.)"

    Edgar: "Yes, I got that. Without reliability, speed is nothing. About bugs being fixed in .NET as the platform matures, .NET 1.1 is around the corner, can you hear the clock ticking for Java?"

    When the ticker stops, the spirit leaves. It's that simple.

    Regarding the threat of .NET trying to catch up, I don't see catching up as a big deal. Most of this stuff has been done before in other languages before Java. Java got it right better than any before it, and has become an acceptable industry platform, and for an amazing portion of the market, it is _the_ platform. To the rational man, it doesn't matter if .NET does catch up in features or performance, because it's not a huge feat and .NET is not a compelling product to switch to from Java. ("Hey, time to switch, this proprietary product now has as much functionality as the standard platform that we've been using.")

    I've long said that if I were targeting only Windows and had COM objects and MFC code and VB apps etc. that .NET would be a no-brainer. It's certainly compelling compared to MFC. COM is so simple in .NET that you accidentally are done before you start. But unless you're already stuck in that world, things like COM don't have any value.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  245. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron: "However, if you've taken the time to profile BigDecimal, then I'm sure you've looked at other things in the language and come to realize that the CLR is not generally any faster than Java. "

    Just when I am about to forget the whole thing you have to say something so general, let's try another small example. Given that BigDecimal is a deadhorse, let's pick a couple of battlehorses: the garbage collector and ArrayList.

    // Person.java: a very simple guy
    public class Person
    {
      private int id;
      private String name;

      public Person(int anId, String aName)
      {
        this.id = anId;
        this.name = aName;
      }

      public int getId()
      {
        return this.id;
      }
    }

    // Create 100,000 people in an ArrayList and access them
    import java.util.*;

    public class ManyPeople
    {
      public static void main(String[] args)
      {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 20; i++)
          new ManyPeople().average();
        long finish = System.currentTimeMillis();
        System.out.println("Average time: " + (finish - start));
      }

      private long average()
      {
        ArrayList list = new ArrayList();
        for (int i = 0; i < 100000; i++)
          list.add(new Person(i, "John " + i));

        long silly = 0;
        for (int i = 0; i < 100000; i++)
          silly += ((Person)list.get(i)).getId();
        return silly;
      }
    }

    Now the same code in C#:

    // Person.cs: a very simple guy
    public class Person
    {
      int id;
      string name;

      public Person(int anId, string aName)
      {
        this.id = anId;
        this.name = aName;
      }

      public int Id
      {
        get { return this.id; }
      }
    }

    // Create 100,000 people in an ArrayList and access them
    using System;
    using System.Collections;

    public class ManyPeople
    {
      public static void Main()
      {
        DateTime start = DateTime.Now;
        for (int i = 0; i < 20; i++)
          new ManyPeople().Average();
        DateTime finish = DateTime.Now;
        Console.WriteLine("Total time: " + (finish - start));
      }

      private long Average()
      {
        ArrayList list = new ArrayList();
        for (int i = 0; i < 100000; i++)
          list.Add(new Person(i, "John " + i));

        long silly = 0;
        foreach (Person p in list)
          silly += p.Id;
        return silly / 100000;
      }
    }

    Besides a couple of niceties (compare the access loops in both averages) the C# code takes an average of 19 secs to do the job, the Java code takes an average of 29 secs, so the C# code is 52% faster, is that what you call "any faster"?

    Regards,


    Edgar S.
    Reply to this Reply to original

  246. Please send me the code that shows .NET is so much faster[ Go to top ]

    <quote>
    Just when I am about to forget the whole thing you have to say something so general, let's try another small example. Given that BigDecimal is a deadhorse, let's pick a couple of battlehorses: the garbage collector and ArrayList.
    </quote>

    <code snipped>

    <quote>
    Besides a couple of niceties (compare the access loops in both averages) the C# code takes an average of 19 secs to do the job, the Java code takes an average of 29 secs, so the C# code is 52% faster, is that what you call "any faster"?
    </quote>

    Is there a particular reason why you didn't use the standard Java idiom for accessing items in a collection? Besides attempting to make the 'foreach' construct look more attractive that is?

    for (Iterator i = list.iterator(); i.hasNext();) {
      silly += ((Person)i.next()).getId();

    Furthermore, what exactly do you think this code snippet is testing? Efficiency of ArrayList access? Nope. Speed of properties vs. accessors? Nope. Speed of long addition? Nope. You are benchmarking the speed of *String concatentation*.

    Replace this line:

    list.add(new Person(i, "John " + i));

    with this line:

    list.add(new Person(i, "John"));

    On my machine (1.7 GHz Athlon, Blackdown JDK 1.4.1 beta), the time drops from 14 seconds to 3 seconds with that change.

    Another thoroughly useless microbenchmark.


    Jim S.
    Reply to this Reply to original

  247. Please send me the code that shows .NET is so much faster[ Go to top ]

    Jim:
    "Is there a particular reason why you didn't use the standard Java idiom for accessing items in a collection? Besides attempting to make the 'foreach' construct look more attractive that is?

    for (Iterator i = list.iterator(); i.hasNext();) {
      silly += ((Person)i.next()).getId();"

    Not really, you can use your elegant idiom instead of:

    foreach (Person p in list)
      silly += p.Id;

    If it so suits you. In any event, it doesn't change the timings as you probably already checked.

    Jim:
    "Furthermore, what exactly do you think this code snippet is testing? Efficiency of ArrayList access? Nope. Speed of properties vs. accessors? Nope. Speed of long addition? Nope. You are benchmarking the speed of *String concatentation*. "

    That's a good point from your part, so I stripped the concatenation from both Java and C# and got this results:

    Java: 6.89 sec (this looks consistent with your timing as my machine is a 996 Pentium III).
    C#: 3.44 sec

    So you are right, without concatenations the Java code is significantly faster but so is the C# code. Now that we have a more "pure" comparison C# is a 100% faster than Java. As my original test was only 52% faster may be someone around here is going to call you a troll :-)

    What I am really trying to prove is that easy said statement like ".NET CLR is not any faster than JVM" could actually be wrong and need some facts that back it before being accepted as a holy thruth.

    Regards,


    Edgar S.
    Reply to this Reply to original

  248. Please send me the code that shows .NET is so much faster[ Go to top ]

    <quote>
    That's a good point from your part, so I stripped the concatenation from both Java and C# and got this results:

    Java: 6.89 sec (this looks consistent with your timing as my machine is a 996 Pentium III).
    C#: 3.44 sec
    </quote>

    Are you using the -server switch? I get times of 1.6 seconds from the Blackdown VM, 2 or so from Sun 1.4.1_01 and 0.88 from IBM's 1.3.1 VM. Choice is a wonderful thing.

    <quote>
    What I am really trying to prove is that easy said statement like ".NET CLR is not any faster than JVM" could actually be wrong and need some facts that back it before being accepted as a holy thruth.
    </quote>

    You aren't doing much to provide such facts. Your code snippets are classic microbenchmarks that don't map well to the 'real' world. The execution models of Java and C# are so similar that it is silly to think that either will have a significant performance edge in a real application. It has been my experience that as things get more complex, the speed difference diminishes and other things become more important, such as reliability, security, ubiquity, etc...

    Jim S.
    Reply to this Reply to original

  249. Please send me the code that shows .NET is so much faster[ Go to top ]

    I'm sort of neutral in all of these performance arguments, as I have never had one of my applications fail due to a lack of performance. Hence, you could probably say that Java is more than fast enough for me.

    However, I thnk Jim makes a very powerful point with his statement: "Choice is a wonderful thing". I really believe this and wanted to highlight it.

    Another interesting thought though is that Java's *.class files are the machine code for the ideal Java CPU right? This concept dates back as far as the conception of Java, but it has not been forgotten. Companies are already building native Java hardware into PDAs and cell phones.

    http://www.nazomi.com/

    If performance was *really* a problem, then would it be so outrageous to introduce Java accellerators into PC and/or server hardware? How about an upgradeable hardware solution that can really perform?

    http://www.transmeta.com/

    Hmmm....Jrusoe....CrusoeJ.....CruseJoe! Ahh...whatever.

    Cheers,

    Clinton
    Reply to this Reply to original

  250. Please send me the code that shows .NET is so much faster[ Go to top ]

    Here's the other hardware Java accelerator that I couldn't find while I was writing the post above. This one is from ARM....

    http://www.arm.com/armtech/jazelle?OpenDocument

    Cheers,

    Clinton
    Reply to this Reply to original

  251. Please send me the code that shows .NET is so much faster[ Go to top ]

    Edgar:
    "That's a good point from your part, so I stripped the concatenation from both Java and C# and got this results:

    Java: 6.89 sec (this looks consistent with your timing as my machine is a 996 Pentium III).
    C#: 3.44 sec "

    Jim:
    "Are you using the -server switch?"

    Yes, without it the timing goes to around 8 seconds (in both cases time varies from execution to execution, I'm giving you averages).

    Jim:
    "The execution models of Java and C# are so similar that it is silly to think that either will have a significant performance edge in a real application."

    May be so or may be not. What I was trying to do is to point out a flaw in this other comment:

    Cameron:
    "However, if you've taken the time to profile BigDecimal, then I'm sure you've looked at other things in the language and come to realize that the CLR is not generally any faster than Java."

    My examples are trying to prove wrong that "the CLR is not generally any faster than Java". Whether they are very relevant or not relevant at all for "real world" applications is another discussion. By the way, may be you could contribute some code that, in your opinion, is a better example of a real world situation, I could try and translate to C# and see what happens. That would be educative, don't you think?

    Regards,



    Edgar S.
    Reply to this Reply to original

  252. Please send me the code that shows .NET is so much faster[ Go to top ]

    Hi Edgar,

      Just wondering, have you tune the Java VM to have larger heap? when you creating 100000 people, it is probably the GC that kill the performance. On my machine, without setting the -Xms flag, it took about 24 sec. If I set -Xms256 -Xmx256m, it took 13 sec. I don't have C# installed on this very machine i am trying here so i can't get the time for C#.

      BTW, what is the heap size for CLR?

      In any case, I am not really surprise that CLR is faster than Java in benchmark like this. After all, it is developed by Microsoft and running on Microsoft Platform. There were news few months ago that the CLR run time will be available on Linux, but the underlying service (MTS, DCOM, COM+... etc) probably still need to run on Microsoft platform. We've came a long way from Java 1.0 to J2EE 1.3. There are RMI, EJB, Servlet, JSP, JMS, JTS... etc all kind of different service available in the J2EE platform. It is the feature, performance, security and reliability of those services that interested me. Someone might complain that J2EE is too complicated, might be so, after all J2EE was developed to solve complicated problem in a real world application.

    -Stephen
    Reply to this Reply to original

  253. Please send me the code that shows .NET is so much faster[ Go to top ]

    <quote>
    Just wondering, have you tune the Java VM to have larger heap? when you creating 100000 people, it is probably the GC that kill the performance. On my machine, without setting the -Xms flag, it took about 24 sec. If I set -Xms256 -Xmx256m, it took 13 sec.
    </quote>

    Good point. The Blackdown VM and Sun times drop to about 0.3 seconds with that change on my machine.

    Jim S.
    Reply to this Reply to original

  254. Please send me the code that shows .NET is so much faster[ Go to top ]

    No comment on the performance of the 1.3.1 IBM VM? OK.

    <quote>
    By the way, may be you could contribute some code that, in your opinion, is a better example of a real world situation, I could try and translate to C# and see what happens. That would be educative, don't you think?
    </quote>

    Perhaps. However, I hope you do realize that every time you post results comparing .NET to anything you are violating the .NET EULA.

    Rather than posting some code for you to port, how about a simple application specification:

     
    ====================
    Create a Mandelbrot Set viewer which is both resizable and zoomable. The display will include the image of the set, a label above the image area to indicate the current mouse position (in the Complex plane) and a reset button at the bottom to return to the initial view of the Set.

    The set of sample points for creation of the set will be 512 x 512 and will initially span the area of the Complex plane bounded by the points <-2.0 - 1i> and <0.5 + 1i>. On zoom by the user, the set of sample points will still be 512 x 512, but will span the newly selected area of the Complex plane.

    The maximum number of iterations after which a point will be considered to have 'escaped' the Set will be 256.

    The image should be colored with the typical gradient scheme from red to violet with red representing points farthest from the Set, and black for all points in the Set. Additionally, Linas Vepstas' renormalized Mandelbrot escape algorithm should be used. A simple dscription of that, and an algorithm for generating the set which should be easy to port to C# can be found here:

    http://linas.org/art-gallery/escape/escape.html

    The cursor should be a crosshairs when in the image area.
    On mouse drag, the user selected region should be enclosed in an XOR painted Rectangle. When the mouse button is released, the view will zoom in to the selected area.

    While generating the image, a busy cursor should be displayed.

    Scrollbars should be provided in the event that the user resizes the display to an area smaller than the image size.
    ==================

    This little example will exercise many differnt aspects of the two languages and their libraries. We can both submit our code in a week or so and let everyone else lok at it to see if there are bits that can be improved.

    A friendly little challenge.

    Jim S.
    Reply to this Reply to original

  255. Mandelbrot Set viewer example problem[ Go to top ]

    I'd suggest picking a different problem; Do you REALLY want this to be a Swing/AWT vs. MS GUI speed???!!!

    Because of the platform indepeance and the necessary extra abstraction that requires, this would be just about the the worst problem you could propose. You could enhance it by adding a couple million BigDecimal calculations and String concatenations...It couldn't hurt.
    Reply to this Reply to original

  256. Mandelbrot Set viewer example problem[ Go to top ]

    Hi Michael,

    I have appreciated all your post but stop now. Enough is enough, this thread isn't going anywhere. Also there is something called SWT. If you check out Eclipse you can see that it have in all ways the look and feel of a native win32 application.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  257. Mandelbrot Set viewer example problem[ Go to top ]

    Rolf:

    I think that many people have learned to appreciate you, Cameron, Edgar Sanchez, Jim, et al for the quality of the technical analysis and how to optimize various functions. I'd love to find a forum for all of us like-minded geeks to compare topics like this since it it very helpful in determining what platform(s) to use for a problem and how to better use our current platform(s). "A rising tide lifts all boats" and all that rot...

    Eclipse does looks like a killer project, I want to look more closely at it and I would not have looked into without having someone whom I respect (like you) promote it. However, even (especially) if Eclipse emulates a Win32 Look and Feel through a skin, it has to pay a significant price. I expect that client-side, I may not be able to tell the difference between 100ms and 110ms, but a 64 Mb BitBlock transfer could suck, even on a 2GHz Proc.

    We are kinda getting off topic, however...
    Reply to this Reply to original

  258. TSS forum is great fun[ Go to top ]

    Hi Michael,

    When I say look and feel I mean response time, in short. I never use IDE's myself, but Eclipse is a good example to illustrate that SWT makes Java and C# performance about similar.
    You can download the open source project SharpDevelop (http://www.icsharpcode.net/OpenSource/SD/default.asp) and compare if you don't believe me!

    Yes, the TSS forum is great fun. After all, how many things are both entertaining and educational?

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  259. Mandelbrot Set viewer example problem[ Go to top ]

    <Michael>
    However, even (especially) if Eclipse emulates a Win32 Look and Feel through a skin, it has to pay a significant price.
    <Michael>

    Why? Please elaborate on this speculation.
    Reply to this Reply to original

  260. Mandelbrot Set viewer example problem[ Go to top ]

    <Ryan>
    <Michael>
    However, even (especially) if Eclipse emulates a Win32 Look and Feel through a skin, it has to pay a significant price.
    <Michael>

    Why? Please elaborate on this speculation.
    </Ryan>

    Because unlike the win32 calls, Swing/AWT/SWT GUI components need to have an abstraction layer between themselves and the machine specific code to render so that you get platform independance. Win32 GUI calls are closely coupled to the OS and hardware.

    The additional overhead on state-of-art equipment may be less noticable than it used to be, but it has to have a measurable effect...

    About 2 years ago (yes, things have improved since then, I KNOW), I wrote some SIMPLE apps in Swing, AWT, and VB and did some basic timing of the business logic. I automated a long string of task that performed calculations and updated the form. The logic executed in about the same total time (the resolution of the timer class sucked), but the rendering of the form took a noticably more time in Swing and AWT.

    The overhead of translating the abstracted UI to the OS/machine version is not completed in the make but does effect run time. Increasing the complexity will most likely increase the overhead (AWT less than Swing). Maybe Eclipse is magic, maybe not. Netscape certain wasn't magic(but lessons were learned...).
    Reply to this Reply to original

  261. Mandelbrot Set viewer example problem[ Go to top ]

    Michael,

    But C# has the same layer of abstraction! The situation then must be the same for C# and Java/SWT..

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  262. Mandelbrot Set viewer example problem[ Go to top ]

    <Michael>
    The additional overhead on state-of-art equipment may be less noticable than it used to be, but it has to have a measurable effect...
    </Michael>

    "Measurable effect" is a little bit of a step down from "significant price" which you originally stated.

    BTW - have you ever used IntelliJ's IDEA? It's a Java IDE written in Swing. Amazingly flexible, amazingly complex, and amazingly fast. Swing can be (nearly natively) fast. You just have to know what you are doing. (Same with server side apps, yes?)

    Ryan

    P.S. Good to see Sartoris Snopes, the C++ troll, back in action. It would not be an all out pissing-and-moaning thread without him :-)
    Reply to this Reply to original

  263. Mandelbrot Set viewer example problem[ Go to top ]

    I just responded to a message posted by someone else.
    You are a typical "Java is the greatest blah blah blah" Luddite. You're whistling past the graveyard with all the other Java zealots.
    Reply to this Reply to original

  264. Mandelbrot Set viewer example problem[ Go to top ]

    Look at
    http://www.nwfusion.com/news/2002/1118fedlinux.html
    This was possible because they used Java for app development.
    Reply to this Reply to original

  265. Mandelbrot Set viewer example problem[ Go to top ]

    Look at

    >http://www.nwfusion.com/news/2002/1118fedlinux.html
    >This was possible because they used Java for app
    >development.

    Absolutely brilliant. No marketing, no hype, no lame benchmarks. Just real success using the world's most powerful enterprise platform.

    Love it!

    Clinton
    www.ibatis.com
    Reply to this Reply to original

  266. Mandelbrot Set viewer example problem[ Go to top ]

    Clinton,

    <Q>loaded the Linux servers with a version of the Tomcat Java application server</Q>

    Exactly as I advocate!

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  267. Mandelbrot Set viewer example problem[ Go to top ]

    Look at

    > >http://www.nwfusion.com/news/2002/1118fedlinux.html
    > >This was possible because they used Java for app
    > >development.
    >
    > Absolutely brilliant. No marketing, no hype, no lame benchmarks. Just real success using the world's most powerful enterprise platform.
    >
    > Love it!
    >
    > Clinton
    > www.ibatis.com

    Haha till it gets redone in .Net.

    Dane-
    Reply to this Reply to original

  268. Java and Linux in FedEx[ Go to top ]

    A very nice article but something struck me as odd:

    Problem 1 From the article:
    "FedEx recently installed 15 Red Hat Linux 7.2 and 7.3 servers running Apache Web server..." and "The servers replaced a dozen Windows NT machines running Microsoft Internet Information Server as a Web server"

    They replaced 12 NT (not Win2K) boxes with 15 Linux boxes, they should have explained that, it seems like they need more hardware with Linux but they are (possibly) planning for the future. It looks kinky without the explaination.


    Problem 2 From the article:

    "One area of Linux expansion at FedEx Freight includes a server consolidation project Boreni and his team are planning. The company intends to consolidate 40 to 50 servers - including file, print and other applications - onto 20 to 25 "virtual" Linux server instances running on one four-processor Intel box."

    Pa-leeze! Lpars on VMWare are sweet, but these 40-50 boxes are either seriously underutilized or FedEx doesn't require pre-employment drug screening anymore. Anyone who has implemented VMWare partitioned servers know that you run into the physical limitations of the bus, drives, NICs, other IO, and memory that you can physically cram into the box LONG before you'd be able to consolidate that many servers that are IO intensive. I also hope that they plan for redundancy in this happy little world of theirs...

    I'll bet $1 that this ends up as around 8 to 10 4-CPUs servers if this consolidation happens.
    Reply to this Reply to original

  269. Mandelbrot Set viewer example problem[ Go to top ]

    <Sartoris Snopes>
    You are a typical "Java is the greatest blah blah blah" Luddite. You're whistling past the graveyard with all the other Java zealots.
    </Sartoris Snopes>

    This is a typical response. Rarely can you have a discussion without throwing in some charged words like "Luddite" and "zealot" to puff your chest. Same MO, as always.

    I will grant you the fact that you appear to know quite a bit about Java and other languages, as well. However, you always seem to have a little venom in your words:

    - "Java is STILL a pitiful language"
    - "As a language Java IS VB with inheritence"
    - "If it weren't for platform issues Java would be totally worthless"
    - "The only decent Java developers I've ever known are ones who know C++."
    - "My experience (from C to C++ to Java) is that Java developers are the worst by far."

    Why don't you lighten up a little? I Java is *that* bad, why do you use it? BTW - what is your evidence that I am in the "Java is the greatest..." camp?

    Ryan
    Reply to this Reply to original

  270. Mandelbrot Set viewer example problem[ Go to top ]

    All the quotes of mine you list I stand behind in the context in which they were stated.

    "Why don't you lighten up a little? I Java is *that* bad, why do you use it?"

    To feed my family. I had to do a little VB(what's the emoticon for vomitting?) a few years ago. I didn't like it but it paid the bills.

    "BTW - what is your evidence that I am in the "Java is the greatest..." camp? "

    Thou dost protest too much.

    If Java would upgrade it's feature set it would be a very good language/platform. C# would not have so easy a time to compete. As it stands now C# has raised the bar a little. The Java folks need to not put their heads in the sand. Release Java to ISO or ECMA or some true standards body. I believe Java would greatly benefit (albeit slowly, it may be too late for that anyway).
    Reply to this Reply to original

  271. Mandelbrot Set viewer example problem[ Go to top ]

    <quote>
     I'd suggest picking a different problem; Do you REALLY want this to be a Swing/AWT vs. MS GUI speed???!!!
    </quote>

    The *only* thing .NET has over Java in the GUI department is native L&F, and things like the Looks package (http://www.jgoodies.com/products/looks.html) eliminate even that advantage. Swing has a bad reputation because people don't take the time required to learn/understand it.

    <quote>
    Because of the platform indepeance and the necessary extra abstraction that requires, this would be just about the the worst problem you could propose.
    </quote>

    No, the graphics are icing on the cake. The real work is done in generating the images. Overall, this won't stress AWT/Swing at all. All the GUI has to do is draw an image and occasionally draw a rectangle and update a label.

    Oh ye of little faith.....

    Jim S.
    Reply to this Reply to original

  272. Please send me the code that shows .NET is so much faster[ Go to top ]

    Jim:
    "No comment on the performance of the 1.3.1 IBM VM? OK."

    Unfortunately I don't have the IBM VM installed on my portable so I can't comment on it. It would be nice if you had .NET installed in your machine so you can comment on it.

    Jim:
    "I hope you do realize that every time you post results comparing .NET to anything you are violating the .NET EULA. "

    Spreading fear, eh? I thought that was the other side tactics. I don't know much about law but I guess we can still publish our source code so that everyone can make their own benchmarks.

    Jim:
    "Rather than posting some code for you to port, how about a simple application specification:

      
    Create a Mandelbrot Set viewer which ... "

    I don't know Jim, Mandelbrot sets could be a fascinating mathematical subject but I don't know how well it maps to the usual business requirements. In particular the nice graphical behavior that you mention has little to do with server side business logic. I'd rather attack a problem with some of this characteristics:

    1. Create a number of diverse business objects
    2. Exercise a number of collections like lists, dictionaries and the like
    3. Call a number of methods with objects and collections of objects as parameters
    4. Use a number of usual patterns like: singleton, strategy, observer, facade, adapter and the like.
    3. Interact with relational repositories. Yes, I know this is very dependant on a number of external factors (like driver quality, etc.) so may be we should drop this one.

    It would be interesting to get on some agreement about the structure of such a set of benchmarking code and then, like I said, just release the code for public consumption. What do you say?
    Reply to this Reply to original

  273. Please send me the code that shows .NET is so much faster[ Go to top ]

    <quote>
    It would be nice if you had .NET installed in your machine so you can comment on it.
    </quote>

    I have .NET installed on one machine. I've used it. I haven't been all that impressed with it.

    <quote>
    Spreading fear, eh?
    </quote>

    No, spreading facts. Section 4.8 of the EULA to be exact. The EULA you agree to on installation that is. As opposed to the slightly different EULA that the installer puts on your hard drive.

    <quote>
    I don't know much about law but I guess we can still publish our source code so that everyone can make their own benchmarks.
    </quote>

    Yes. Nothing illegal about that.

    <quote>
    I don't know Jim, Mandelbrot sets could be a fascinating mathematical subject but I don't know how well it maps to the usual business requirements.
    </quote>

    Well, that would depend on one's business wouldn't it? In any event, I thought we were discussing the general performance of the CLR versus the various Java VMs. Your code snippets thus far have been all that business oriented.

    <quote>
    It would be interesting to get on some agreement about the structure of such a set of benchmarking code and then, like I said, just release the code for public consumption. What do you say?
    </quote>

    It seems to me that this already exists in the form of the PetStore.

    Jim S.
    Reply to this Reply to original

  274. Please send me the code that shows .NET is so much faster[ Go to top ]

    <Jim S>
    It seems to me that this already exists in the form of the PetStore.
    </Jim S>

    You have a sick sense of humor, Jim...I like you.
    Reply to this Reply to original

  275. Please send me the code that shows .NET is so much faster[ Go to top ]

    I've taken the C++/Java bench markes Dennis M. Sosnoski published in
    1999, and ported them to CS, and run them on the following:

    HW: 2.4Ghz dell with 510 mb ram.
    OS: Windows xp professional.
    JVM: Sun's JRE 1.4
    .Net: MS 1.1


    Heres the summary of the results.

    I used cpp as the base line.

    Memory
       Java 2.25 time slower.
       CS 1.1 times slower.

    Factors
       Java 1.5 times slower.
       CS 1.1 times slower.

    File IO
       Java 3.6 times slower
       CS 2.9 times slower.

    Dennis's orginal numbers and source code are available on:
    http://www.sosnoski.com/Java/Compare.html#Basic

    The numbers above should give indication of the performance level for basic
    opertions. The next plan is measure collection performance, and then finally
    database interaction performance. Finally I plan to intergrate the basic benchmarks into a webserver environment.

    Now that I've presented the basic numbers, my editoral view on the subject
    of the J2EE vs .NET bench marks is mainly, I'm surprised that some people
    are so quick to ignore or discount the results of the benchmarks. People have gone so far as to claim Microsoft, and TMC of fixing the results.
    I've worked in the software industry 10 years now, and find it humourous
    the replies people post to these types of threads.
    People can discount .NET all they want, but in my mind it has clearly surpassed
    java performance in most areas. With that said, performance is only one
    of mainy signifcant areas to concider in evualuating the two platforms.
    I watch the benchmark results closly, and its clear to me the performance
    of MS platforms on multi-proc systems is increasing at a rapid pace,
    and the advantage J2EE has on high end hardware is quickly being removed.
    Reply to this Reply to original

  276. interesting..[ Go to top ]

    I followed the link (http://www.sosnoski.com/Java/Compare.html#Basic) and downloaded the Java and C++ code. Could you possible provide a link to the C# source code too?

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  277. Please send me the code that shows .NET is so much faster[ Go to top ]

    Hi Edgar,

    When I get some time, I'll show you just how bad your .NET example is. It isn't even correct, since I'm going to make a SuperPerson class that extends Person and overrides (or attempts to override) the Id property accessor, I know I'll get the wrong answer to the average (it won't call the SuperPerson accessor because it's non-virtual and, for the sake of argument, let's say I got the Person class as part of a library so I can't just go in and hack the source.) Again, we see that .NET gives the wrong answer much faster. What's the point? Or are you just trying to tell me that no one actually uses .NET for anything serious, like getting the correct answer?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  278. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron:

    "When I get some time, I'll show you just how bad your .NET example is. It isn't even correct, since I'm going to make a SuperPerson class that extends Person and overrides (or attempts to override) the Id property accessor, I know I'll get the wrong answer to the average"

    No, you will get a compilation error (when trying to override the Id property in SuperPerson). But relax, if we wanted this property to be overridable, all we had to do is redefine the Id property like this:

      public virtual int Id
      {
        get { return this.id; }
      }

    Now, time the ManyPeople class again. Guess what: same results. Nice, isn't it?

    Regards,


    Edgar S.
    Reply to this Reply to original

  279. Please send me the code that shows .NET is so much faster[ Go to top ]

    Edgar: "When that happens in your machine and in mine it gives a overflow exception, it could also be a problem with your installation or even with your attitude (after all Java has its own huge bug parade but we can work it out, can't we?) Just some alternative thinking :-)"

    No, .NET installed itself. Part of Windows Update. You can't blame me or Sun or anyone else for .NET GPFing.

    The quality just isn't there. How can I tell my customers to ditch their enterprise servers and their enterprise software and all the other related things to go use some buggy GPFing software that only runs on the "blue screen of death" Windows OS with "nimble nimda" IIS?


    Cameron: "When I get some time, I'll show you just how bad your .NET example is. It isn't even correct, since I'm going to make a SuperPerson class that extends Person and overrides (or attempts to override) the Id property accessor, I know I'll get the wrong answer to the average"

    Edgar: "No, you will get a compilation error (when trying to override the Id property in SuperPerson). But relax, if we wanted this property to be overridable, all we had to do is redefine the Id property like this..."

    Like I said, "attempts to override." So with C#, I have to add keywords just to make my code object-oriented? Nice touch. Bet that saved a clock cycle or two. Don't you get it? Don't you see how stupid that was?


    Edgar: "Now, time the ManyPeople class again. Guess what: same results. Nice, isn't it?"

    Well, there's two problems here. I'll get to the second (performance) in just a second. First, though, let's deal with quality. Having methods be non-virtual by default is a great way to run into quality problems. .NET is not built for providing quality software. It reeks of that problem. And even on the simplest of examples (multiplication), .NET GPFs. That doesn't make me feel very safe.


    Now for the benchmarks:

    C:\temp\dotnet>ManyPeople.exe
    Average=49999
    Total time: 00:00:08.0615920
    Average=49999
    Total time: 00:00:08.1417072
    Average=49999
    Total time: 00:00:08.1116640
    ...
    Average=49999
    Total time: 00:00:08.0415632
    Average=49999
    Total time: 00:00:08.0415632
    Average=49999
    Total time: 00:00:08.1417072

    -- Java --

    Average: 49999
    Average time: 7911
    Average: 49999
    Average time: 6169
    Average: 49999
    ...
    Average: 49999
    Average time: 5118
    Average: 49999
    Average time: 4937
    Average: 49999
    Average time: 4977
    Average: 49999
    Average time: 4557

    BTW - that is on Sun's HotSpot, which is why successive runs get faster and faster. NOTE THAT EVEN THE FIRST PROBABLY-INTERPRETED RUN WAS STILL FASTER THAN .NET!!!

    The difference in the test is primarily that I put a loop to repeat the test so that HotSpot's optimizer would kick in, and I ran with -Xms and -Xmx set to the same value.

    Summary: .NET is buggy, helps developers produce quality problems in their code, and is still slower.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  280. Please send me the code that shows .NET is so much faster[ Go to top ]

    For reference, if you preallocate the array list to 100,000 items in both tests, the results become even more lopsided:

    C:\temp\dotnet>ManyPeople.exe
    Average=49999
    Total time: 00:00:06.9399792
    Average=49999
    Total time: 00:00:07.4306848
    Average=49999
    Total time: 00:00:07.2103680
    Average=49999
    Total time: 00:00:07.3305408
    Average=49999
    Total time: 00:00:07.0200944
    Average=49999
    Total time: 00:00:07.4707424
    ^C
    C:\temp\dotnet>java -Xms128m -Xmx128m -Xrs -da -dsa -server ManyPeople
    Average: 49999
    Average time: 6679
    Average: 49999
    Average time: 5508
    Average: 49999
    Average time: 5548
    Average: 49999
    Average time: 5698
    Average: 49999
    Average time: 5458
    Average: 49999
    Average time: 5438
    Average: 49999
    Average time: 5428
    ^C

    It looks like .NET is at least 30% slower in this test supplied by Edgar when compared to Sun's JVM, which is not even the fastest JVM. And that's even with the C# class having non-virtual error-prone methods.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  281. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron:
    "So with C#, I have to add keywords just to make my code object-oriented?"

    Well, encapsulation is another object-oriented tenet and to achieve it you have to enter the private keyword before every field in a Java class. So, any slip on the programmer side and you'd open up your contract too much, the next thing you know you won't be able to change your implementation because of inadvertenly public fields. But let's not get so dramatic, you wouldn't call Java non object-oriented because of that, would you?
    Reply to this Reply to original

  282. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron: "So with C#, I have to add keywords just to make my code object-oriented?"

    Edgar: "Well, encapsulation is another object-oriented tenet and to achieve it you have to enter the private keyword before every field in a Java class. So, any slip on the programmer side and you'd open up your contract too much, the next thing you know you won't be able to change your implementation because of inadvertenly public fields. But let's not get so dramatic, you wouldn't call Java non object-oriented because of that, would you?"

    I'm not going to argue the details of package private fields; you know that the fields are not public by default, and I'm sure you have a reasonable point even if you're only trying to cause another argument. ;-)

    In the interest of software quality, to me, it is self-evident that methods in an OO language should be virtual by default. In a reasonably high level OO language, there is even a logical argument that non-virtual invocations should be disallowed. What do you think, honestly?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  283. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron:

    "In the interest of software quality, to me, it is self-evident that methods in an OO language should be virtual by default. In a reasonably high level OO language, there is even a logical argument that non-virtual invocations should be disallowed. What do you think, honestly? "

    I'm not really a language expert (OO or otherwise) but I agree with you that having methods polymorphic by default and disabling this ability only explicitly sounds more consistent with the OO way of thinking. Non virtual invocations totally disallowed...? Mmmm, this one sounds to strong for me but, as I said, I'm not a language expert.
    Reply to this Reply to original

  284. Please send me the code that shows .NET is so much faster[ Go to top ]

    Hi Edgar,

    One other question, were you able to reproduce the performance results on your test showing Java to be 30% or so faster than .NET on that test?

    FWIW - that's not typical. Usually Java is about 10-15% faster, but I haven't checked to see if it is due to improvements in 1.4.1_01 or just the test favors Java more (although I realize that it was a test you made to show how much faster .NET is.)

    Lastly, even if one is slower than the other on a test or two, who cares? They are both plenty fast enough for all but the smallest percentage of uses. (Except BigDecimal I guess ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  285. Please send me the code that shows .NET is so much faster[ Go to top ]

    And with a well written class (i.e. public void increment()), a different API, etc. could be used if need be. And the calling 'program' would be none the wiser.
    Reply to this Reply to original

  286. Please send me the code that shows .NET is so much faster[ Go to top ]

    I haven't read this whole thread (it's huge and I don't have the time), so I'm sure I'm not considering many factors mentioned here, but I did notice a couple of things by quickly glancing at the posts.

    I'll add before I start that I have no C# programming experience and I read the language reference more than a year ago and never touched it again. So my points won't be based on this specific experience. What's more, my first point is based on the immediate impressions I get from looking at C# code for the 'first' time.

    While looking at the ManyPeople benchmark, I noticed how the current time was accessed in C#. It's done through a getter method, there are no parenthesys after DateTime.Now . Staying objective, I believe that a programmer should be able to clearly distinguish a native variable access from a function call for the simple reason that this always incurs in a performance hit, specially for setter routines that might involve additional calculations. I believe the 'restrictions' placed on Java by design, enforce clear code that is consequently easier to read and understand. It also has a simpler structure, you have data and routines, at most two types of routines if you count constructors as a different type of method. In c# (although I can't comment on what the compiled code looks like) you have data, and getter code, setter code, normal function code, constructor code if we're counting, and perhaps some others I havent seen here. This is just a lot of added structural complexity that also happens to hide too much implementation detail (at least by first glance) making mental performance analysis more complicated. Simplicity paves the way for plurality in implementation. In less fancy words, it's better to have fewer, well designed, turing complete, generic constructs that enable you to build constructively in layers of your own choosing. I'm sure some of you will agree. After all is there any syntactic sugar in c# that truly makes code more readable and makes you code in less lines?? I don't think I would like foreach. It seems to rely on higher level language constructs just like the java compiler relies on java.String, which I don't like either, because it immediately locks you down to using that particular implementation and API of a string. Same things apparently apply here. I believe java however has fewer of these.

    By the way, just to point I'm not biased against M$ ( flamers, sorry :} I couldn't help the $ ) I have to point out that someone in Microsoft is working on an excelent language on this respect, it's called Vault and it's the most well defined, type safe language I've seen so far. They still have some wrinkles to iron out, and for the moment at least its an experimental language, but it's really promising and inovative in ways c# or Java aren't. Now, only then is there really a point in developing a new language. I don't have a link, search for it in MS research site if interested.

    Onto something else... The ManyPeople benchmarks apparently show Java is faster after all optimizations, am I right? However, I find it pointless to argue about differences in performance of less than one order of magnitude. They could change depending on a particular CLR or VM implementation. What's important, and what get's people's attention, is when the difference is several orders of magnitude.

    This is what happened in the Pet Store benchmark. But as some of the so called 'Java advocates' pointed out, I'll just call them good analysts as I'm sure they would immediatley point out something good about c# if they saw it (don't flame me on this, it can't be practically argued), in this benchmark we've compared apples and oranges. The orders of magnitude of difference in performace can be completely explained by the orders of magnitude in structural differences between the tested implementations. The Sun implementation uses every bit of J2EE component it can, just to show it's place in an application. The Microsoft imlementation is streamlined to this particular task. For example, I've heard the MS imp. calls the server with SQL directly from the ASP page while Sun goes the full length and implements it's Pet Store only in ways someone would to show the components the demo can use, not for performance. I have to agree that whoever did the last bit of optimization did a lousy job at it, but it's a simple mistake that could happen to anybody on a bad day, they just didn't realize they could write it all over again for a performance competition. I've also heard that Ibatis has a streamlined Java implementation with comparable performance and comparable implementation streamlining.

    After a well executed benchmark includes this or some similar Java implementation, and why not some other .NET implementation, stating that one platform is better and the other sucks at performance is also just pointless.

    Sebastian Ferreyra
    Reply to this Reply to original

  287. Please send me the code that shows .NET is so much faster[ Go to top ]

    Sebastian,

    So you couldn't resist the $ after all.

    There are many reasons for why .NET will replace J2EE, performance being only one of them. But even if there was none I still would avoid J2EE if only for their followers extremely rudeness and impoliteness.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  288. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf: "There are many reasons for why .NET will replace J2EE, performance being only one of them."

    Generally speaking, Java is 10-15% faster than .NET. See above examples (thoughtfully provided by .NET evangelist) showing Java to be at least 30% faster for example. Until you can show otherwise, please stop repeating something that is known to be false.


    Rolf: "I still would avoid J2EE if only for their followers extremely rudeness and impoliteness."

    That statement is rude and impolite. You suggest that people who have selected a technology are "followers" (a term with obvious religeous overtones) and you paint them with a broad brush as being extremely rude and impolite. You do so while claiming to "avoid J2EE" while posting on "Your J2EE Community" site.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  289. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron,

    Why do you bother? You know very well that I don't discuss with anybody who calls me a babbling idiot and suggest that I should be put in a home somewhere..

    Rolf Tollerud
    Reply to this Reply to original

  290. Please send me the code that shows .NET is so much faster[ Go to top ]

    <statement>Java is 10-15% faster than .NET</statement>
    I should ask you where you got your statistics. Didn't .NET just wipe the floor with J2EE, or were you sleeping or decides to be blind and deaf?
    Reply to this Reply to original

  291. Please send me the code that shows .NET is so much faster[ Go to top ]

    <statement>Java is 10-15% faster than .NET</statement>

    Slem Slem: "I should ask you where you got your statistics. Didn't .NET just wipe the floor with J2EE, or were you sleeping or decides to be blind and deaf?"

    The code is in this thread, for example. Two quick notes: (1) it was provided by someone attempting to show that .NET was faster, and (2) it runs about 30% faster in Java on Windows than in C# on .NET on Windows, which is more than I saw (on average) for the fairly substantial number of tests that I ran comparing Java to .NET, which generally showed that Java on Windows was 10-15% faster than C# on .NET on Windows.

    You can test it yourself. To compile for .NET, you need to be running on Windows 2000 or XP, and just type "csc Test.cs" (assuming the source is in a file called Test.cs) and it will make an EXE that you can run. Similarly in Java, just type "javac Test.java" (assuming the source is in a file called Test.java) and it will make a .class file. To run it, type "java Test" (assuming that the class with the main() method is called Test.)

    Regarding ".NET just wipe the floor with J2EE", I wasn't involved with those tests at all and so I hope you wouldn't ask me to defend their results; however, for what it's worth, they definitely showed two things:

    1) On the selected tests, .NET definitely performed better
    2) One of the J2EE servers failed on one of the tests, which is much more worrisome than its performance, IMHO

    Since I have already explained why Microsoft picked specific test attributes (e.g. forcing the J2EE implementation to use XA, while Microsoft's implementation did not), I will not bother to revisit the discussion in detail here.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  292. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf,

    Well, I don't mean to be rude or impolite. I usually just choose technology based on what it can do for me and my clients. It's a complicated decision that doesn't involve considering who else is 'following' it.

    Doing this makes me feel confident the solution I work on will provide short & long term benefits for the both of us. It also prevents me from appearing as someone that makes bussiness decisions based on emotional judgements, it just doesn't look good.

    Sebastian Ferreyra
    Reply to this Reply to original

  293. Please send me the code that shows .NET is so much faster[ Go to top ]

    Sebastian,

    Well if you want to be professional you should avoid the "$". I don't want to be emotional either, but that are a little difficult as you no doubt you are aware so have Scott McNealy and Harry Ellison for 3 years led the whole Unix community in a very aggressive and emotional campaign against MS where some bagatelles like "truth" is the first to fly out the window. And all the time I have no problem with to se that the level of professionalism and quality of the Microsoft teams has no match. The word witch-hunt comes to my mind. Or mobbing. And they want to replace MS products with something like Websphere?
    I can only say, Madre Mia.

    "makes me feel confident the solution I work on will provide short & long term benefits"

    How come that nobody have answered my former post #66042, what about it? It is Microsoft that keep everyone on their toes, keep the prices down, and helps on to goal at finally put the "mainframe attitudes in the world" at rest in some museum where they belong.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  294. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf: Well if you want to be professional you should avoid the "$".

    I don't believe humor hurts, in the very same post I mentioned a language (Vault) I very much like being designed by someone at microsoft. If you visit their research site, you'll see many other great projects they're working on. There are some really smart, dedicated people working there.

    Vault: http://research.microsoft.com/vault/
    Researchers: Rob DeLine & Manuel Fähndrich

    I do think however C# is there to compete with Java only because Java threatens to provide developers with real choice (of operating systems particularly). I don't mind companies competing, but they should also collaborate to promote standards and technologies that help everybody, including the small developer.

    Although I have seen unexperienced developers (mostly kids) post unfounded anti-microsoft statements (just like many more posting unfounded anti-Sun/Java stuff), I've also seen some very serious people comment critically and objectively on specific practices or technologies developed by microsoft. I don't think there is a 'destroy microsoft' cult anywhere.

    Rolf: "And they want to replace MS products with something like Websphere?"

    One of the things the Java platform provides is choice. Developers using Java can choose between many many different libraries, servers (many excellent open-source or 'source code included' ones, I personally love Resin), applications. We're not limited to WebSphere, or IIS.

    Rolf: "How come that nobody have answered my former post #66042, what about it? It is Microsoft that keep everyone on their toes, keep the prices down, and helps on to goal at finally put the "mainframe attitudes in the world" at rest in some museum where they belong."


    What part? I think free open-source software does a better job at keeping prices down, and at keeping microsoft on their toes. I don't think many people felt threatened or offended by the 'mainframe attitudes' remark, I personally like to keep everything as small as it can be.

    Sebastian Ferreyra
    Reply to this Reply to original

  295. Please send me the code that shows .NET is so much faster[ Go to top ]

    <Q>
    I still would avoid J2EE if only for their followers extremely rudeness and impoliteness
    </Q>

    Do you think .Net followers are any less rude and impolite? I know it isn't true. I'm reasonably sure each technology (C/C++, ...) has its fair share.
    Reply to this Reply to original

  296. Please send me the code that shows .NET is so much faster[ Go to top ]

    "...a programmer should be able to clearly distinguish a native variable access from a function call for the simple reason that this always incurs in a performance hit..."

    Not always. Simple field accesses will be inlined. However, when using C#, I assume every "field-like" call is a property. If I really need to know if it's a field or not, I look at the class definition. I believe properties make code easier to read because they don't sandwich the most important thing (the name) between get...() or set...(). I don't like getters and setters for the same reason I don't like hungarian notation. Just gets in the way.

    "The ManyPeople benchmarks apparently show Java is faster after all optimizations, am I right?"

    No. 1- It's a very narrow and synthetic benchmark, 2- not all of the possible optimisations were made (certainly on the C# side), and are never likely to be. The problem seems to be that no-one really knows how to benchmark correctly, or has sufficient knowledge of both languages to do a decent job (least of all the owners of this site...)

    "However, I find it pointless to argue about differences in performance of less than one order of magnitude"

    That's mostly true, for the majority of applications. Although I am a speed freak and spend far too much time optimising my code than I should :-)

    Jim
    Reply to this Reply to original

  297. Please send me the code that shows .NET is so much faster[ Go to top ]

    "I believe properties make code easier to read because they don't sandwich the most important thing (the name) between get...() or set...(). I don't like getters and setters for the same reason I don't like hungarian notation. Just gets in the way. "

    A public interface should (for the most part) be comprised of verbs, or actions taken upon an object.

    What if you had an object that had a property of color and an action color? myObject.color is different then myObject.color().
    Reply to this Reply to original

  298. Please send me the code that shows .NET is so much faster[ Go to top ]

    Sartoris: "A public interface should (for the most part) be comprised of verbs, or actions taken upon an object."

    If you're using a language without support for properties, perhaps. Properties are just an abstraction after all. They help you see objects in terms of nouns and verbs, rather than just verbs, *and* retain encapsulation. IMO, that's a good thing.

    "What if you had an object that had a property of color and an action color? myObject.color is different then myObject.color()."

    Change the color() method to something more intuitive? When you think of the word "color", do you think of the noun first, or the verb?

    Anyway, I think you've just answered your question on my behalf. I know that Color is different from Color() when using C# because one is a property and the other is a method.

    Jim
    Reply to this Reply to original

  299. Please send me the code that shows .NET is so much faster[ Go to top ]

    Jim: "...Not always. Simple field accesses will be inlined..."

    Well, that wasn't exactly my point. I meant, it is impossible in c# to be 100% certain that you're actually performing a simple field access without looking at the source code of the getter/setters (something that's not always possible). This makes it harder to decide (from a single glance), for example, if I may modify a property in a tight loop. There are workarounds obviously (benchmarking, something you don't have to do for that particular case in Java, you just know it's as fast as it gets if its a native variable) and perhaps it's a matter of taste for most, but I prefer unambiguous, clearly-meaning-only-one-thing code, it's actually easier to read and understand.

    Jim: "It's a very narrow and synthetic benchmark..."

    It's the benchmark everyone is arguing about.

    Jim: "That's mostly true, for the majority of applications."

    Right, specially for the server applications where referring to on the thread. Not only can we throw more hardware at it, we can also change VMs/CLRs, settings, optimize some critical code... etc.

    Sebastian Ferreyra
    Reply to this Reply to original

  300. Please send me the code that shows .NET is so much faster[ Go to top ]

    Sebastian: "...it is impossible in c# to be 100% certain that you're actually performing a simple field access without looking at the source code of the getter/setters..."

    Just as it is with get/set methods in Java.

    Sebastian: "This makes it harder to decide (from a single glance), for example, if I may modify a property in a tight loop."

    So how would this:

    foo.getBar()

    provide you with any more information about the speed of the function than this:

    foo.Bar

    ? It might be a field access, or it might call a database halfway around the world. Honestly, it's six of one, half a dozen of the other.

    Recently, I've been porting a lot of code from C/C++ to C#. The abstractions, such as properties, that C# provides have made the code so much easier to understand. It feels like the language is much more transparent.

    "It's the benchmark everyone is arguing about."

    This lot would argue about the price of fish if someone started such a thread. I was surprised that no-one suggested making the Person class into a struct, and using a strongly-typed collection to avoid the boxing and casting that ArrayList would do. As far as I'm aware, there's no way to do that in Java, so I would expect C# to win. But then, I don't know Java well enough to be unbiased. You could also use pointers to avoid bounds checking on the array, but then the argument would switch from performance to some tedious bun-fight about memory leaks and code maintenance.

    Jim
    Reply to this Reply to original

  301. Please send me the code that shows .NET is so much faster[ Go to top ]

    Jim: "...
    foo.getBar()

    provide you with any more information about the speed of the function than this:

    foo.Bar
    ...
    "

    Well, I think I was clear when I explained that 'foo.bar' is clearly a native variable invocation in Java, clearly as fast as it gets. Of course there is no way to know anything about the internals of foo.bar() in either language. I maintain Java code is more strict, hence simpler, hence clearer.

    If you want some important counter arguments to what I say, you might mention how it's difficult in some cases in Java (and c# I'm sure) to ensure a native variable access is not delayed by a hidden monitor locking the object containing the variable. But that falls on another category of application design.

    Sebastian Ferreyra
    Reply to this Reply to original

  302. Please send me the code that shows .NET is so much faster[ Go to top ]

    Sebastian: "Well, I think I was clear when I explained that 'foo.bar' is clearly a native variable invocation in Java, clearly as fast as it gets...I maintain Java code is more strict, hence simpler, hence clearer."

    Without looking at the class interface you wouldn't know the field or property "bar" even *existed*. How can you not know what type of member it is?

    "If you want some important counter arguments to what I say..."

    Thanks for patronising me, but I have plenty of points already :-)

    Jim
    Reply to this Reply to original

  303. Please send me the code that shows .NET is so much faster[ Go to top ]

    Jim: "Without looking at the class interface you wouldn't know the field or property "bar" even *existed*. How can you not know what type of member it is?"

    Well, you're right about that. I meant however in Java is easier to know how the code is going to behave at a lower level even if you're reading code you didn't write.

    This could be an advantage in, say, in a group programming environment. But I can't really argue how much of an advantage since, as I said in my first post, I don't have too much c# experience.

    The basic algorithm in a routine should be discernible independent of how properties/fields are accessed, still I fail to see how the sintactic sugar in c# provides any advantages over Java.

    I will get up to speed on this as there are however some interesting ideas, structs and unsigned natives, for example, that might provide some advantage, although there are sound reasons as to why these where not included in Java.

    However, as a platform, I think Java makes it possible for me, a poor ( but talented :D ) programmer writing app servers in Argentina, a poor country with poor clients :P, the option of building great systems under linux, for the price of hardware. Microsoft just can't compete with that.

    Sebastian Ferreyra
    Reply to this Reply to original

  304. Please send me the code that shows .NET is so much faster[ Go to top ]

    Sebastian: "The basic algorithm in a routine should be discernible independent of how properties/fields are accessed, still I fail to see how the sintactic sugar in c# provides any advantages over Java."

    See my reply to Sartoris a few messages up. I think properties make tasty sugar.

    "I think Java makes it possible for me, a poor ( but talented :D ) programmer writing app servers in Argentina, a poor country with poor clients :P, the option of building great systems under linux, for the price of hardware. Microsoft just can't compete with that."

    Absolutely, and good luck with it. The reason for me using .Net over Java is mostly accidental.

    Jim
    Reply to this Reply to original

  305. Please send me the code that shows .NET is so much faster[ Go to top ]

    Hello Sebastian Ferreyra,
    "Please send me the code that shows .NET is so much faster"??

    That is easy look at Sun's Pet Store application that they (Sun Microsystems®) did and then look at the on Microsoft did in .Net. That was easy. Both companys make BIG $$$$ and have the means develop with their platform better then any of us. So all-in-all that is the best place to get the code your asking for.

    Dane Jurkovic-
    Reply to this Reply to original

  306. Please send me the code that shows .NET is so much faster[ Go to top ]

    BTW on my computer I get the following results:

    Java VM 1.4.1_01 10.1 seconds
    J# 7.9 seconds
    C# 1.6 seconds

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  307. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron,

    Wow, if I had thought of that I wouldn't have wasted so much (little?) time writing JPetStore. Kudos to you for proving how bad C# sucks in the fewest lines of code! :-)

    Best regards,

    Clinton Begin
    www.ibatis.com
    Reply to this Reply to original

  308. Please send me the code that shows .NET is so much faster[ Go to top ]

    Clinton: "Wow, if I had thought of that I wouldn't have wasted so much (little?) time writing JPetStore. Kudos to you for proving how bad C# sucks in the fewest lines of code! :-)"

    Well, it was unfortunately necessary.

    BTW - I don't think that C# "sucks" ... I just don't think that it should exist. There is a difference. It's a language that was created specifically to be a little different from Java. Kind of like LotusScript trying to be VB without being VB. Not very innovative.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  309. Please send me the code that shows .NET is so much faster[ Go to top ]

    Clinton

    I was just in the process of testing your JPetStore with SAP DB when I read your post. Then I realized how vain it will be to try to argue with somebody who claims that when you get an error exceeding the 28 digits limit in a type it is a bug.

    (BTW this was from the same guy which put a link to the Oracle claim that they had improved their version of Petshop 28*28=784 times faster with a litte twinkling of the code).

    So I just threw it away.

    Anyway it is a good example on my point that it is not the Java technology that is at fault, it is the Java Community.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  310. Please send me the code that shows .NET is so much faster[ Go to top ]

    Then I realized how vain it will be to try to argue with

    >somebody who claims that when you get an error exceeding
    >the 28 digits limit in a type it is a bug.

    Rolf Tollerud thinks I was arguing with him. Funny, I don't recall ever communicating with him before!? In any case, if he took Cameron's post or my response even remotely seriously, then he needs some help.

    >So I just threw it away.

    Excuse me while I grab a tissue to wipe the tears from my eyes. (Rolf Tollerud thinks I care.)

    >Anyway it is a good example on my point that it is not the
    >Java technology that is at fault, it is the Java
    >Community.

    Rolf Tollerud is trying to hurt my feelings. He'll have to pardon me for being insensitive.

    The only point Rolf Tollerud proves is that he is insecure with his choice of .Net and therefore he finds a need to hang around a *J2EE Community* as a common troll. That's too bad.

    ...
    Reply to this Reply to original

  311. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf: "Then I realized how vain it will be to try to argue with somebody who claims that when you get an error exceeding the 28 digits limit in a type it is a bug."

    When you run a little program, and it hurls its inner guts, it's a bug, yes it's a bug.

    When you multiply a number, and it seg faults your computer, it's a bug, yes it's a bug.

    When you're using such safe code, and it GPFs your node, it's a bug, yes it's a bug.

    When that process is a server, and your site barfs for the surfers, it's a bug, yes it's a bug.

    I do not like blue screens and spam.

    (In memory of Dr. Seuss, 1904-1991, probable anonymous author of Lisp.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  312. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron,

      I don't think Rolf understands your jargon...They call this(i.e. bug) a "service pack" update in the Microsoft world.


    service pack = sorry we just crapped ourselves. We will now attempt to clean up after ourselves. Futhermore, lets address this incident as "poop"(i.e. service pack) and not "crap."(i.e. bug)
    Reply to this Reply to original

  313. Please send me the code that shows .NET is so much faster[ Go to top ]

    Are you not forgetting something? Actually there are just a few people actually posting here in this forum of ca 200.000.

    Most are just monitoring, decision makers of all kinds, CEO's, CTO's, real programmers, super users etc, etc, and yes, I think investors too.

    And, I am sorry; I do not think these people are as stupid as it you think they are. These last posts illustrate my viewpoint better than I ever could do myself, they can just be left in the air.

    Meanwhile, I play with my new toy, the excellent and powerful SAP DB, satisfied that it will become a hard blow at Oracle, and so indirectly yet another shot in the bow of the infamous Sun - Oracle alliance.

    I am sure that even if the in the near future still will be many who prefer to have a big, bloated, slow and buggy piece of software between themselves and their customers, with a hefty $50.000 price tag + 20% yearly licensing + consulting fees. Preferably with a nice cheap Oracle database in the back..

    But I think they will diminish pretty fast though.

    Don’t kill me - I’m only the messenger.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  314. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf,

      Your employer (i.e. http://www.telia.com) has done a fabulous job using J2EE technology. Why the need to troll the Java Community?


    http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=%22Rolf++TOLLERUD%22&btnG=Google+Search
    http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=%22rolf+tollerud%22&btnG=Google+Search

    Maybe if you had spent your time more wisely applying J2EE you would have understood Cameron.
    Reply to this Reply to original

  315. Somebody have to do it![ Go to top ]

    It is not a pleasant job - but somebody have to take on the pretentious, bombastic and condescending people in the world. I am sure you as an American can understand this - you usually didn't had so much patience with such people before..

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  316. Somebody have to do it![ Go to top ]

    I am sure you as an American can understand this - you

    >>usually didn't had so much patience with such people
    >>before..

    Rolf Tollerud, in addition to being a troll, has now proven himself to be a bigot as well.

    Rolf Tollerud should take his intolerance elsewhere. Perhaps to the .Net communities he speaks so highly of (and yet he spends so much time here).

    ....
    Reply to this Reply to original

  317. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf: "Meanwhile, I play with my new toy, the excellent and powerful SAP DB, satisfied that it will become a hard blow at Oracle, and so indirectly yet another shot in the bow of the infamous Sun - Oracle alliance."

    You need help. Serious help.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  318. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron,

    I am tired of being called different epithets from you. If I where you I would try to keep to rational arguments and to the subject instead of this personal bashing. But as you want.

    Here is my assessment of you.

    Pretentious, bombastic and condescending is only your middle name. You also are a dishonest arguer and a hypocrite.

    You all time tries to appear as an objective participant, you are always particular in explaining that you use all kinds of systems. But the reality is that you work mostly with Weblogic.

    Moreover your own product is a system that is mainly used with these overpriced J2EE servers to try to salvage as much as possible from their deficits. So the situation is kind of similar to Charley Chaplin in the film where he was a vendor of windows glass with a little boy who threw stones at windows.

    Diderot: "Thief, murderers and ruffians of all kinds I can stand, they are all part of the plurality of the world. But the intellectual hypocrisy do I have more problem with"

    I do not know anyone which this description suits as perfectly as you and I say as him, I can stand your being pretentious, bombastic, condescending and even dishonest!

    But I can not stand your hypocrisy.

    But don't despair; there is a use for everybody. If you are useless you can serve as a bad example for others to avoid.. At least you give the Java community a face!

    Bye
    Rolf Tollerud
    Reply to this Reply to original

  319. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf,

    Once again, I submit that you need serious help.

    Rolf: "I am tired of being called different epithets from you."

    What I said was that you need help. That is not an epithet. Perhaps you meant an ad hominem?


    Rolf: "If I where you I would try to keep to rational arguments and to the subject instead of this personal bashing."

    See above. I have clearly shown that the performance of Java is at least 30% better than .NET on a test provided by a .NET evangelist (or better yet, search this page for "Edgar" to see how many times he has beaten this horse. Thanks DH.)

    More rational than the fact that Java blows away the performance of .NET (on the .NET evangelist's own test) is that .NET's quality is not acceptable for production applications. It GPFs doing multiplication! Hello?!?!

    Furthermore, as long as it runs only on a desktop OS, I cannot see how it will ever be applicable for server-based enterprise applications. Seems rational to me. Just because you can't make any reasonable rational response doesn't mean you need to go around insulting people and being rude.


    Rolf: "Pretentious, bombastic and condescending is only your middle name. You also are a dishonest arguer and a hypocrite."

    Frankly, I suffer from more human faults and failings than most people, but I hardly require you to list them. However, while we are on the subject, I will point out that dishonesty is not one of my many faults. In fact, it would seem that my honesty is what perturbs you most of all.

    I do particularly like the sound of "bombastic" though. It has a very nice ring to it.


    Rolf: "But the reality is that you work mostly with Weblogic."

    I have spent probably less than 100 hours in this entire year working with WebLogic. I've probably spent more time than that counseling you to get some serious help.


    Rolf: "Moreover your own product is a system that is mainly used with these overpriced J2EE servers to try to salvage as much as possible from their deficits."

    Yes, exactly, just like Michelin tires are used with overpriced automobiles to try to salvage as much as possible from their otherwise immobile state. Go bother Michelin or something.


    Diderot: "Thief, murderers and ruffians of all kinds I can stand, they are all part of the plurality of the world. But the intellectual hypocrisy do I have more problem with"

    Yes, but Diderot was an intellectual, and thus could theoretically perceive intellectual hypocrisy.

    On this subject, however, I prefer Churchill: "He is one of those orators of whom it was well said, 'Before they get up, they do not know what they are going to say; when they are speaking, they do not know what they are saying; and when they have sat down, they do not know what they have said.'" [1912]

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  320. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron,

    <Q>I submit that you need serious help</Q>

    I will not suggest that you go somewhere to seek help. On the contrary, I think you can help yourself! First, try not to dishonest in the first 10 minutes of the morning. With that accomplished you can try the next 10 min and so on, and before many weeks have passed you will be able to pass an entire morning to lunch without being dishonest. Then you try the first 10 min after lunch - I am sure you get my drift.

    And don't be so desperate - I am sure you can sell your old Java legacy code for many years to come!

    Rolf Tollerud
    Reply to this Reply to original

  321. Please send me the code that shows .NET is so much faster[ Go to top ]

    Rolf, Cameron,

    You are probably both very clever and just like Arafat and Sharon will never get on well with each other for oversized ego-pseudo religious reasons-whatever but...

    YOU ARE GETTING ***BORING***!

    Would you mind shifting your personal flamewar to a private forum elsewhere ? I'm pretty sure I'm not the only one who will appreciate this.

    Cheers,

                    Yann
    Reply to this Reply to original

  322. Rolf, Cameron, and Flame Wars[ Go to top ]

    Yann's right: I don't give a rat's ass what you guys think of each other. I see great stuff coming from both of you guys, I'd rather judge you on the quality of your posts.

    I have a long running joke; "In order to get a high level IT job, you need to have at least one major personality defect; and if that defect is just "Poor Personal Hygiene", you're getting off light".

    'nuff said.

    Try to rise above, ok?

    Thank you for your support...
    Reply to this Reply to original

  323. Please send me the code that shows .NET is so much faster[ Go to top ]

    Cameron:
    "When you multiply a number, and it seg faults your computer, it's a bug, yes it's a bug.

    When you're using such safe code, and it GPFs your node, it's a bug, yes it's a bug. "

    When that happens in your machine and in mine it gives a overflow exception, it could also be a problem with your installation or even with your attitude (after all Java has its own huge bug parade but we can work it out, can't we?) Just some alternative thinking :-)
    Reply to this Reply to original

  324. Please send me the code that shows .NET is so much faster[ Go to top ]

    Can you please tell me what the following means:


    Application has generated an exception that could not be handled.
    Process id=0x3dc (988), Thread id=0x1b4 (436).
    Click OK to terminate the application.
    Click CANCEL to debug the application.

    Is that a UAE or a GPF? Unfortunately, with .NET being so quick, I wasn't able to get a good timing for how fast it blew up. Please advise.

    [adi] This is a unhandled exception, not an AV or a "GPF" (I guess by "GPF" you meant an unhandled SEH hardware exception like STATUS_ACCESS_VIOLATION). This simply tells you that your code threw an exception that got unhandled. The behavior is by design...

    >>> .NET is not built for providing quality software. It reeks of that problem. And even on the simplest of examples (multiplication), .NET GPFs. That doesn't make me feel very safe.

    [adi] I would disagree. Throwing exceptions on overflows is actually a good thing. Do you think that, in general, the safest behaviour on overflows is just to continue execution?



    Thanks,
    Adi Oltean [Microsoft]


    P.S. This posting is provided "AS IS" with no warranties, and confers no rights.
    Reply to this Reply to original

  325. Please send me the code that shows .NET is so much faster[ Go to top ]

    Hi Adi,

    [adi] This is a unhandled exception, not an AV or a "GPF" (I guess by "GPF" you meant an unhandled SEH hardware exception like STATUS_ACCESS_VIOLATION). This simply tells you that your code threw an exception that got unhandled. The behavior is by design...

    My apologies. That makes sense now, since the console application didn't perform any exception handling.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  326. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    My suggestion for a 2nd round is this:

    1. Both sides/teams develop on a known system.
    2. For the actual tests a independent third party selects another operating system (both architectures claim to be OS independent, right?) and another database than the one that was used for development. Let's call this "competition configuarton". Noone knows in advance how the competition configuration will look like.
    3. Both sides get 20 hours to install and fine tune their implementation on the competition configuration.
    4. The benchmarks are run on the competition configuration.

    If you do this then I really would be impressed by the results ;-).

    Ciao!
    Reply to this Reply to original

  327. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    If I had the time, the best rematch would be to code both. i.e. have the same team do their best job in java and .Net. This has to be a team that is really interested in the answer of which is 'quicker'.

    Ignoring java's main selling point of portability, I believe the same team would use the same 'architectures' (layers/components/decoupling) in the solution. And I believe they would both perform fine on the target system - one would be slightly quicker. Don't really care which.

    But, the strength of java is portability. Basic java is portable accross OS and CMP/OR tech is portable accross DB's.

    Jonathan
    Reply to this Reply to original

  328. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    <quote>
    both architectures claim to be OS independent, right?
    </quote>

    No. Microsoft hasn't claimed OS independence for their implementation of .Net. Windows is required to run a .Net program. Period.

    (As has long been the case with Microsoft technologies, the persistence engine (db) can be on any platform for which a data provider is available. Virtually every commercial and non-commercial db offers at least an ODBC driver. Many offer the slightly more efficient OLEdb drivers. Microsoft offers the most efficient .net managed providers for SQL Server and Oracle. Oracle also offers their own version of a .net managed provider for Oracle.)

    Microsoft does claim that the ECMA/ISO standard for C# and CLR could be implemented on another OS, but they've made only the most trivial of attempts to do so. I'd be surprised if they ever made their own implementation for anything other than Windows and (maybe) Mac OSX.

    What they do claim (quite loudly) is that .Net can be used to create services that are platform-agnostic on the edges -- where they communicate with other such services. That's one reason for the heavy emphasis in their marketing on the "Platform for XML Web Services" aspects which are actually a small subset of the overall platform-dependent dotNet system. (XML is, however, tightly woven into virtually all aspects of the system.)
    Reply to this Reply to original

  329. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I think the testing mixes and criteria needs to be completely defined, agreed and signed off for by each vendor participant (The .NET & J2EE communities should be able to VOTE on a final draft presentation for those participating vendors.) (Once agreed upon, no vendor should have the opportunity to back out and/or withhold results - the legalise should be there to deny it.)

    I think the final benchmark application(s) should be submitted as a test suite to www.tpc.org and REVALIDATED by www.tpc.org/www (shortly thereafter).

    tutor
    Reply to this Reply to original

  330. Start with www.ibatis.com[ Go to top ]

    Money seems to be a real issue. So TMC should definitely start with http://www.ibatis.com/
    It seems to be ready to go and it will be the most economic approach.

    I think TSS and TMC deserve credit. Blaming it on MS is not the solution. It is the right and duty of the MS engineers to do their best.
    .NET is not bad, it is just evil :-)

    Probably the time has come to put J2EE patterns to the real world test. Most things on this earth can grow better over time as experience is gained. Design patterns for distributed OO systems most likely are not an exception. I don't think it will make anybody wrong if Sun's original architecture is improved. This is just the natural und normal thing to happen and not a shame for the original authors.

    The best outcome of this discussion would be an optimized Petshop blueprint on the Sun site. All J2EE developers would benefit from that.

    I think the quest for performance can lead to a simpler design, which may well be superior in every respect to the original Sun architecture.

    Let's have at it!
    Reply to this Reply to original

  331. Start with www.ibatis.com[ Go to top ]

    I just found out that iBATIS has released JPetStore 2.0, a competitor to PetShop.NET 2.0:

    iBATIS

    iBATIS releases JPetStore 2.0, asks for Peer Review
    Reply to this Reply to original

  332. Start with www.ibatis.com[ Go to top ]

    Just came across another interesting implementation:

    http://66.54.199.205:8080
      by
    http://www.rtcdesigns.com (Robert Tu)

    I saw this at the following link and hope the poster does not mind that I mention it here. His posting is very interesting reading, could be another starting point for a faster Petshop:

    http://www.javalobby.org/threadMode3.jsp?forum=61&thread=5698&message=13115710
    Reply to this Reply to original

  333. Run MS cross platgrom[ Go to top ]

    http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/MSDN-FILES/027/002/097/msdncompositedoc.xml

    If we use MS .net, run on BSD!

    This would be good for all the MS cross platform people.

    .V
    Reply to this Reply to original

  334. Run MS cross platgrom[ Go to top ]

    Did you read what it is for? Should make a great highschool project for you!



    good luck!

    com on unix anyone?
    Reply to this Reply to original

  335. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    It's so interesting that any post with J2EE vs .NET can easily get more than 100 replies. How about stop arguing and do some real stuff? We are building a Pet Store demo application using EJB 2.0. The persistent layer is CMP entity bean, and presentation layer is Struts. We are using MySQL and JBoss, all open source free-wares, and they are running very well.

    Yuan Ji
    J2EE Study Group
    http://groups.yahoo.com/group/j2eestudy/
    Reply to this Reply to original

  336. This is not cricket[ Go to top ]

    I am really disappointed over the reaction of the Java community. It leaves a bad taste in the mouth. Are these squirming excuses your idea of sportsmanship?

    And especially Rickard Oberg, I would have expected more from him. He knows very well that code is never finished and it’s always possible to improve. And asides from that you don’t even have to be a good programmer to do so. If they ever publish any code from the Petshop open source that has been started it will be a pleasure to point out all things that can be bettered and 'which they have done wrong'.

    The point is that even if the Middleware coders not is the best programmers in the world they are certainly above the usual grain of everyday J2EE consultants –they have really been working hard - and they could not make it.

    For the conspiracy theories I will not waist a single word

    After all what is strange with MS succeeding within their own OS? Remember that MS have the highest percentages of IQ per square foot in the world. There is not enough with one talented person – this type of plants grows best in teams

    1) If I should venture an opinion I would say that with everything done correctly J2EE is about 2-2.5 times slower than .NET.

    2) But, if it is beginners who just use the tools and adheres to “standard usual practice”, I would say that the performance is about 8 times slower.

    3) And last, if the project is done by impractical theorist with pet ideas, the performance is somewhat 28 times slower - as has been demonstrated.

    For me it is more interesting to compare the forthcoming Mono framework with J2EE. I would expect the performance differences to go away. But if the Java community persist (no pun intended) with their pet theories, 2) and 3) will continue as before.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  337. This is not cricket[ Go to top ]

    Rolf,

      First, if you have read it yet, i suggest you to read the following article first: PetShop Architecture.

      A lots of people have probably read the Java Petstore source code written by TMC, but not to many ppls has read the .Net source code. The above report give you the comparsion between the .Net and Java Petstore architecture. Few points i want to highlight in the report:

    1. In the .Net application, the Service Layer is mix with Data access code (Product.cs). If the SQL statement need to change later it will be nightmare because the data access code will span in different classes.

    2. Seperation of layters is not respected, just look at Order.cs class. They actually contains the code that will forward your browser to ShoppingCart.aspx if your cart.Count < 1. It is like I have a OrderEJB that will forward the user browser!!!

    3. The presentation layer (ASPX page) actually directly call the persistent objects.

    4. The complete application is only one namespace!! (two namespace if you also count the ASPX page) !!!

    5. Last, but not less, take a look at the OrderWebService.cs code from the .Net application and compare the web service code with the Java Petstore one and you will be surprised.

    I agree that no application is perfect and there is always room for improvement in every application. TMC probably did their best to improve the Java Petstore. But this is clearly not a fair comparsion. I think most of us are disappointed on TMC because they didn't notice the different.

    Please refer back to the TMC report, page 5, which it indicate that "2. Both applications had to be created according to best-practice coding standards such that each serves as a valid design pattern" and "3. Each application had to be a logical three-tier implementation, with the use of well-partitioned components to encapsulate middle-tier business and data access logic" Now, take a look again on the .Net application and compare it with the Java Petstore. How can TMC miss that??? Rickard has his point when he question TMC did they perform a code-audit of the .Net code, and who performed this audit???

    One last point: It is not really about design pattern or EJB, dataaccess layer... blah blah.. It is about fair comparsion! We can rewrite the Java petstore just the way .Net did and do the benchmark again. If the benchmark result still indicate .Net is faster (which i think it will still faster) then I guess the Java community will accept the result.

    Regards,
    -Stephen Yau
    Reply to this Reply to original

  338. This is not cricket[ Go to top ]

    So lets say this then.

    People seem in violent agreement that the java petstore sucks. Rickard spelled out just a few of the reasons. But suffice it to say, that is the general concensous here.

    People recently are exposing that the .NET pet store sucks too. Framing it as an anti-patterns.

    I propose that them sucking isnt a bad thing. Actually, I might propose that the vast majority of people who will use this technology will use it poorly. The vast majority of people are not software engineers. They are developers who work hard and learn more every day. I would actually contend that both of them sucking is a pretty realistic benchmark. I would go further to claim that rewriting them both 'perfectly' is not a very accurate benchmark.

    I personally would rather see your average joe developers given a fixed amount of time, say 12 hours to develop each. Then benchmark them.

    The arguments here are that if I use these 94 patterns and persistance layers and everything else, then the Java version wont have sucked so bad. But guess what, the average schmoo doesnt know how to do that. So isnt that whats broken here about the java pet store? Its that the performance sucks UNLESS you are a total expert.

    Isnt this about John Q Public? Is .NET easier for the average folk?
    Reply to this Reply to original

  339. This is not cricket[ Go to top ]

    <quote>
    I propose that them sucking isnt a bad thing. Actually, I might propose that the vast majority of people who will use this technology will use it poorly. ...

    The arguments here are that if I use these 94 patterns and persistance layers and everything else, then the Java version wont have sucked so bad. But guess what, the average schmoo doesnt know how to do that. So isnt that whats broken here about the java pet store? Its that the performance sucks UNLESS you are a total expert.

    Isnt this about John Q Public? Is .NET easier for the average folk?
    </quote>
    Love your reasoning!
    So in an ideal environment you would take 2 'average' programmers who had no clue about the technology they were using and then ask them to develop the software. The program that comes out faster and in fewer lines of code is the winner!
    Let's see how this compares to a real life example.
    I would hire 2 'average' builders who have no clue about the tools and materials they are using going to use to build houses. The builder that builds a house using the least amount of materials and in the quickest time wins!(shudder).

    See anything wrong with the reasoning?
    Regards
    Ravi
    Reply to this Reply to original

  340. This is not cricket[ Go to top ]

    I dont see anything wrong with the reasoning but I do see something wrong with your analagy. But lets stick with the house example you give. Imagine two companies who sell a kit to build a deck on your house.

    Company A sells a super engineered very technical kit. Every seam fits together to exacting standards. It is the most beautiful deck kit in the world. Perfectly engineering, amazingly elegant. All the forethought in the world into how to extend that deck later. The problem is is really hard to build right. The average person who buys this kit struggles to get it built using the very complex directions.

    Company B sells a fine deck kit. Its not as perfectly engineered as the deck from Company A. The seams are a bit sloppy. The pieces dont fit together perfectly. It wasnt designed to be as easy to add onto. But, the kit is very well documented, very easy for the average person to put together.

    I would challenge that Company B will be alot more successful. I would also challenge that Company B built a better kit. There will be people who will buy company A's deck. Most of them will hire a construction company (read expensive consultants) to build it for them. But the most pervasive and popular deck will be the one that does a fine job and is easies for the average person to put together.
    Reply to this Reply to original

  341. This is not cricket[ Go to top ]

    Stephen,

    It is only too easy to see the tree and not the forest.

    For me it is enough when content and code is separated (no matter if you call it MVC or whatever).

    Business objects? What kind of business object is needed it in such a simple application? Of course I am not saying that the .NET Petshop can not be improved, everything can be improved. All craftsmen are alike. When they open something which has been done by another craftsman they just always says it is shit. As a matter of routine. I sometime think that it would be fun to cheat somebody into open their own work without knowing it. Imagine them bashing their own work! That would be fun..

    If you try to see the forest instead of the tree it’s easy to understand why C#/.NET always will be faster on Windows. 1) COM+ is done in optimized C++/assembler code (that downright cheating). 2) If you study the .NET classes you can see how much better they are done: consistent, very well thought out, implemented by people who have thought performance morning, midday and evening. They either have had more time or resources or could afford to hire the more skilled staff. Or both.

    These young j2EE engineers reminds me of old Visual Basic times - we made a lot of money in these days saving crashed project, or project that where about to crash. And the first thing you saw when you fired up one of these apps where that they usually took a whopping 50% of the system resources.. They just work on without having a clue to what resources they use up along the way -.

    The best programmer is the person who can do it with less rows of code, less memory and best performance. If he can do it, he is better quite simply IMO, then the people who teaches: "Organize inter-service transfers according to use case from known domain objects into a coarse-grained Composite".

    I have the greatest confidence in Ximian and Miguel de Caza. But the Mono Framework will not have the advantage of COM+, neither do they have unlimited time, money and resources. Then it will be a fair comparison.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  342. This is not cricket[ Go to top ]

    The best programmer is the person who can do it with less

    >> rows of code, less memory and best performance. If he can
    >> do it, he is better quite simply IMO, then the people who
    >> teaches: "Organize inter-service transfers according to use
    >> case from known domain objects into a coarse-grained
    >> Composite".

    Complete Rubbish!

    (This issue is completely independant of any debate on language/platform)

    I dont care what language you write it in, for me, the maintainability of the code is paramount.
    The one thing you can be guaranteed of, is the fact that whatever you write today will have to change.
    IT professionals have a job to not only deliver todays functionality but to try and make change cheap.

    Having a good separation of concerns, making sure there is good encapsulation, making sure there is not duplication of code, making sure it is readable, making sure it is simple ARE important considerations.

    How fast it goes, how many lines of code there are, how much memory it uses are all issues for those who have nothing better to do.
    Instead, is it fast enough, is there unnecessary code, is there a memory leak are the questions that should be asked.


    -Nick
    Reply to this Reply to original

  343. This is not cricket[ Go to top ]

    I guess since with VB you can write real fast code and anyone can drap and drop to create nice looking blah blah .....and make single threaded enterprise app.


    ahh what a crock of bull shit'

    .Not is still a piece of crap
    Reply to this Reply to original

  344. This is not cricket[ Go to top ]

    Nick,

    <Q>Complete Rubbish!</Q>

    There are really funny how you can argue that the 14000 code of rubbish that was published by the TMC engineers in any way can be more maintainable than the clean 2000 rows in the .NET Petshop.

    It is Weblogic who is "Complete Rubbish". In fact I am speechless to how people can pay any money at all for such a piece of crap.

    "I don't know whethever to laugh or cry.."

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  345. This is not cricket[ Go to top ]

    <Q>
    There are really funny how you can argue that the 14000 code of rubbish that was published by the TMC engineers in any way can be more maintainable than the clean 2000 rows in the .NET Petshop.
    </Q>

    Maintainability also includes ease of change and how it can adapt to change. Sometimes it means more code. Not saying this is the case in the Java Petshop but the Petshop is not proof of anything.
    Reply to this Reply to original

  346. This is not cricket[ Go to top ]

    Hi Rolf,

      I am not saying that .Net will not be faster than Java. It is also NOT about design pattern or whether it is using EJB, Sessionbean... MVC blah blah. Most of us are angry at TMC because this is clearly not a fair comparsion! Remember we are comparing .Net and J2EE, not comparing what kind of design pattern we are using. Design pattern can apply on C+, C#, Java... or even VB, that's not the point here.

      Why everyone think that Java MUST be written in "Best Practice", Factory pattern, DAO.... etc I have seen A LOTS of so call "senior programmer" who still put their data access code and SQL statement in JSP pages! This can also be done in Java and probably the performance will be a lots faster with all the distributed object in place!!! After all, who give a damn if it cost less and faster... certain not the CEO of that company. It didn't take a genius to write code like this, just a couple of programmer who don't know anything about design pattern or never read the GoF book.

      In order to have a fair comparsion, we need to have some kind of Class diagram or activity diagram draw up and make sure both side are following it. We need to make sure we are comparing .Net and J2EE, not comparing the design pattern.

    -Stephen
    Reply to this Reply to original

  347. This is not cricket[ Go to top ]

    Hi Stephen,

    The only thing which is really important is to keep content and code separated. Business objects and "separation of concerns" it is of course important to customers like the Costa Rica National Bank who are porting 3 millions of mission critical code to .NET. But to the 2000 rows of code in Petshop "Java Patterns" and "Best Practice" is utterly useless.

    It is these issues, the inability of the J2EE Engineers to "keep a sense of proportions" that are killing Java.

    As I said in a previously post, the really big difference doesn’t come from the language or the classes but from the Java guys preoccupation with impractical theory, they <prefer to look themselves in the mirror and keep saying how great they are, and how nice and good, especially compared to the "evil monopolist">

    Your proposal that both camps should use the same pattern will result that the .NET programmers is drawn into the same swamp as J2EE. No thanks! I prefer to keep my sense of proportions.


    Regards
    Rolf Tollerud
    Reply to this Reply to original

  348. This is not cricket[ Go to top ]

    Hi Rolf,

      It seem that you really don't catch the point here. As I say it again and again, design pattern is not just for Java, it is also for .Net, C#, VB... etc. In fact, when the book "design pattern" release by GoF Java was not even in the world.

      Shall we let's go back into little history of Java Petshop?? the Java Petshop was originally created by SUN as a show case on their technology and what should be the "best practice". Of course it is overkill and useless if the petstore is a realworld application!!! It is not for performance and benchmarking. It is just a show case.

      Can we rewrite java petstore with lesser line??? of course we can, take a look at iBATIS's JPetstore, it is only 2178 lines of Code, 82 lines difference than the .Net!

      It seem that you really think that we, the java community, has the inability to say java is bad. All i want to say that a lots of us still keep a open mind, a lots of us still looking for a fair comparsion between J2EE and .Net... not comparing the different design pattern. I am also some what disappointted in ppls here who take this too personal, almost take java as a religion. But please don't compare them to the majority of us. The more i read your post the more i get the sense that you are not really comparing the technology here. Rather, you are comparing the community and that you think the .Net community or by using .Net can result writing smart code and clear code.. it is not what we are comparing here.

    -Stephen
    Reply to this Reply to original

  349. This is not cricket[ Go to top ]

    Hi Stephen,

    It is always nice to be understood, even better than I understand myself!

    Yes I have to agree with you. There are not the technology who bothers me but the Java community. First it is this idiotic theory talk. Then it is this religious anti MS bigotry. Then there is all this shouting and screaming. It is not so much in this TSS forum as in Javalobby. They actually do scare me..

    Altogether it reminds me to much of rather unpleasant groups in our history.

    So the fight is not about comparing technologies then. Rather it is about the Java community against the .NET community.. Two different ways of life.

    I have just download ibatisjpetstore, I will return to you with a comment when I have tested on my own computers. But clearly these guys seem more like people from .NET community (even if they are programming in Java!).

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  350. This is not cricket[ Go to top ]

    <quote>
    Then it is this religious anti MS bigotry
    </quote>

    Talking of "religious" bigotry, you wouldn't be the same Rolf Tollerud who said "I am constantly amazed to why Open source un-American movement gain so much space..I think you should read some stuff at www.softpanorama.org.
    The open source people can only make software by stealing."

    in http://forums.zdnet.com/group/zd.Tech.Update/it/itupdatetb.tpt/@thread@1371@forward@1@D-,D@ALL/@article@1371?EXP=ALL&VWM=hr&ROS=1&

    Personally I've used MS, J2EE and open source stuff and I'll use whats suitable for the occassion rather than get caught up in these silly religious wars.
    Reply to this Reply to original

  351. This is not cricket[ Go to top ]

    <Q>
    The best programmer is the person who can do it with less rows of code, less memory and best performance. If he can do it, he is better quite simply IMO, then the people who teaches: "Organize inter-service transfers according to use case from known domain objects into a coarse-grained Composite".
    </Q>

    Engineer, yes. Programmer, no. A good programmer will develop for maintainability first. Then change the code for performance if and where needed.
    Reply to this Reply to original

  352. This is not cricket[ Go to top ]

    And especially Rickard Oberg, I would have expected more from

    > him. He knows very well that code is never finished and it’s
    > always possible to improve. And asides from that you don’t
    >even have to be a good programmer to do so. If they ever
    >publish any code from the Petshop open source that has been
    >started it will be a pleasure to point out all things that
    >can be bettered and 'which they have done wrong'.

    The difference is that we won't say that it's been "fully optimized for performance", and furthermore we'll say "any ideas on how to improve this would be highly appreciated".

    If you're into pissing contests, that's just fine. I'm not. I want good code that people can use as an example in their own project. I don't care one damn bit if that code has been contributed by me or by you or whoever.

    /Rickard
    Reply to this Reply to original

  353. This is not cricket[ Go to top ]

    Just posting for the hell of it.

    Jonathan
    Reply to this Reply to original

  354. Misconceptions re speed[ Go to top ]

    Rolf claimed:

    1) If I should venture an opinion I would say that with everything done correctly J2EE is about 2-2.5 times slower than .NET.

    This sure does not correspond to recent benchmarks reported by IBM and BEA.

    Yes, J2EE mis-used can have horrible performance. Using EJB 1.1-based designs without use of caching design patterns falls into the "mis-use" camp. That's why EJB 2.0 was developed.

    An app designed to take advantage of a solid EJB 2.0-based server like Websphere 5.0 or WebLogic 7.0 should not be slower than a corresponding app run on .NET. It also should not need to be badly designed. The really big advantage of J2EE from a total-cost-of-ownership viewpoint is that it encourages good design based on open APIs that is portable, easily maintained, and extensible. Current J2EE servers make implementations based on such designs performant, TMC benchmark notwithstanding. The problem is the TMC implementation, not J2EE 1.3.

    I agree that the comments about conspiracy theories that have littered this thread are a total waste of time. But let's not fall into the opposite error of calling valid criticism "unsportsmanlike". Ignore Rickard's comments on motivation and concentrate on his criticisms of the TMC implementation (http://dreambean.com/petstore.html). The criticisms are valid.

    The real problem with the TMC benchmark is that, based on the outdated EJB 1.1-based Petstore example (version 1.2.1), it doesn't use the EJB 2.0-based optimizations incorporated in modern J2EE 1.3 servers. Using an EJB 1.1-based teaching example to represent what J2EE 1.3 can do is like racing a hobbled mule vs. a Kentucky Derby winner.

    John
    Reply to this Reply to original

  355. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    First, decide whether SPEED alone is the variable that determines a 'winner' to this beauty contest, or whether robustness, maintainability, security & etcetera are to be considered.

    Second, if speed alone IS the variable that determines a winner, then do what MS did and confine the new design to those elements of J2EE/Java that are certain to realize the best performance.

    MS took what was intended to be a showpiece for J2EE design possibilities (e.g., a learning tool) and turned it into a drag strip. That's like racing a stock Toyota against a slingshot.
    Reply to this Reply to original

  356. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Guys,

    I like TSS. I think the original benchmark hurt you a lot, and I don't want to see the site slide downhill. So I really think you should just give up. Because this is a lose-lose scenario for TSS.
    (and for TMC too)

    You have lots of people saying things like this:

    "Thus the only way we can fairly compare J2EE and .NET is in an apples-to-apples comparison of identical..."

    But TMC and TSS can't do that.

    J2EE is platform-independent specification, not an implementation. So you just aren't comparing apples to apples if you compare J2EE to .Net (unless you can run benchmarks on the platonic ideal of J2EE). Balancing the implementations and hardware to be completely fair is impossible. No matter what J2EE implementation you pick (what hardware, what vendor, what database), a lot of people will feel betrayed and accuse you of being unfair.

    Two applications written in different languages for different environments will always be different, even if you start with a requirements document that's staggering in detail. Being completely 'fair' in writing the apps is impossible. And so no matter what you do, a lot of people will feel betrayed and accuse you of being unfair.

    I admire you admitting that you went wrong, and I admire your pluck in being willing to get back up and give this public-relations fiasco another try. But you're going to get hurt here, again.

    Take the excuse that many developers seem to oppose this, set up a SourceForge project, and tip-toe away from the ticking bomb. While you still can.


    Sean
    Reply to this Reply to original

  357. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Hello gang,

    I have not read the other comments.

    I just hope that there isn't over- engineering, and I hope a lightwieght framework is used to simplify and speed up things. Services should include caching, dbmgmt, filters (use it where it makes sense), thread pools, Non-blocking IO. EJBs should not be used, because this is a demonstration of speed and nobody cares about scaling or elegant design and manageability. Its like Database design "sometimes its ok to de-normalize".
    Use Open source like Jetty.. if Open source is comparable or better then something you pay for like .Net that is a big value to the customer.
    Let many others join.
    Heck, Use JRockit and jdk 1.4.1 and Oracle 9i jdbc drivers!
    Don't forget .Net compiles there code.
    This type of situation has happend to Oracle. This will always be subjective. No one will really win.

    In conclusion,
    My experience is that I've created apps using Java on various platforms with great speeds because of great services(framework), performance tricks (Orielly performance book), tuning on the application server(jsp caching), use a good profiler tool. Speed is one simple aspect of a platform. There are many other qualities that play an important factor in enterprise application building arena. Java simply has solved many problems in a huge enterprise environment, .Net has not even touch the surface. If .Net is not much faster Nobody would even care. I can say this, Java does live up to its promise WORA, and Web services is just a new feature in the enterprise environment. .Net is good for MS shops only.


    -Carl
    Reply to this Reply to original

  358. This is a good opportunity....[ Go to top ]

    Since there are so many options on how to build a demo application and the idea that this is do be a best practices exercise, let's do it as a best practice so that we can make non-specific conclusions based on the outcome.

    How about:

    1. Let's get a functional spec/Use Case set on what functions the app must perform and what constraints (like transactional functionality) must be maintained. We can track feature implementaion effectively this way.

    2. Document required test cases that include transactions completing and failing, etc

    3. Include sufficient requirements/facilities for profiling. This will allow us to make VALID conclusions like "the performance is CPU bound in the business logic so the database doesn't matter" or "PreparedStatement persistance is xx% slower then Stored Procedure persistance"


    Until we get this far, we really are just talking out our heineys because the results are open to "Platform X didn't do this"...


    Is .Net fatser than Java? Maybe. Do I care? To some extent, yes, but not really, I do care that I have some measure of confidence and independant validation that my pet architecture (pun unintended) will scale to what I need. I do not pray at the alter of Sun, BEA, IBM, MS that "If you build it, it will scale (with us)"
    Reply to this Reply to original

  359. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    excuse my language, but microsoft has once again screwed its competitor. They know speed is not on the J2EE side with all its layers and layers of objects with design patterns and with EJB, so they hit you where it hurts the most while avoid their shortcomings. They had you playing their game by their rules again. I'd say if you want to win the benchmark war, then forget design pattern, forget EJB, put the sql in stored procedure, etc. You'll have to play dirty to win. their object is to win the benchmark, not designing the most loosely coupled, scalable, well-engineered application of the world. wakeup, TMC !!!
    Reply to this Reply to original

  360. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    <quote>excuse my language, but microsoft has once again screwed its competitor. They know speed is not on the J2EE side with all its layers and layers of objects with design patterns and with EJB, so they hit you where it hurts the most while avoid their shortcomings. They had you playing their game by their rules again. I'd say if you want to win the benchmark war, then forget design pattern, forget EJB, put the sql in stored procedure, etc. You'll have to play dirty to win. their object is to win the benchmark, not designing the most loosely coupled, scalable, well-engineered application of the world. wakeup, TMC !!!
    </quote>
    I think you're right. MS is going to be faster on Windows, no matter what people say, especially with an architecture tweaked for performance, so the MS marketing is pushing that as being the agenda. If raw speed was the only issue, and all companies had equally competant developers, then .NET is probably the winner on Windows. I don't know about maintainability ( and i'm not sure how you'd benchmark that ) so I couldn't say either way, and I'd be interested in how much difference developer ability makes to the performence of systems. I think it is clever of MS to make this seem like the only issue.
    Reply to this Reply to original

  361. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I just want to let you know guy that I've rewritten a portion of PetStore with xDoclet (EJB layer only), and it reduce by the total line of code by 70%!
    And also, I used xDoclet to port the application from JBoss to
    WebLogic ;-).

    BTW: it took me 4 days to write the EJB layer, 1 day to configure it with JBoss, and 1 week-end to port it to WebLogic (it was my 1st contact with WebLogic).
    I don't understand how the TMC took 4 month to produce their PetStore !?

    check it ou at http://www3.sympatico.ca/htchepannou
    Reply to this Reply to original

  362. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    TMC should not do the official rematch until PetStore is implemented by major vendors(J2EE & .NET) as a proper performance benchmark candidate under clear hardware/software platform specs.

    Or TMC can make the rematch a fun open source project to
    invite J2EE and .NET supporters to tune up the implementations and see what happens. General speaking Java is slower than C++ or C# on WinTel machines and it is tough to make J2EE faster than .NET.

    But on the other hand people choose a language/application platform not soly based on its speeds. Just like buying a car you consider many factors, not just engine power.
    Reply to this Reply to original

  363. mainframe people[ Go to top ]

    To clarify.

    1) I am *not* against Java, whoever is 10 - 30% is unimportant. Java is great technology used correctly.

    2) I fact I am not against Java Community either, not the guys at Jakarta.

    3) What I'm against is what I call "mainframe people", in lack of a better term. They are not of course working with mainframes, but share many of their views and attitudes. They are, in short, those who think it is a good idea to put together some expensive Sun boxes, a big Java app server, and an Oracle database,

    Some citations to show my point.

    <Q1>But if those $4,000 boxes rolling off the assembly lines at Dell Computer Corp. aren't technically commodities, they behave very much like them, pummeling prices in Sun's core business. Consider Sun customer E*Trade Group Inc. (ET ). In August, the $1.3 billion online financial-services company finished yanking out 60 Sun servers that cost $250,000 apiece and replaced them with 80 Intel-powered Dell servers running Linux that cost just $4,000 each. That took a huge bite out of expenses, including a one-time depreciation of the Sun gear and big maintenance fees. The savings so far: Nearly $13 million--and the company expects to shave another $11 million annually from its $220 million tech budget. "It wasn't a hard decision," says Joshua S. Levine, chief technology officer at E*Trade. And here's the really painful part: When the Intel-powered machines break, E*Trade doesn't bother calling a repairman. It just junks the server and plugs in a new one.<Q1/>


    <Q2>Is it ethical to let companies just blindly walk into the gas chambers of websphere?
    "Is it good for anyone or any company if they waste money on such an inefficient kludge as Websphere is ( 300 products and $11 spent on services for every dollar on product -per IBMs own study!)
    It is because of "products" like websphere that gives the whole industry a bad reputation and makes consulting a scam rather than a honorable profession.
    As far as ethics goes, "Intentional negligence" that leads to harm is no different than "Intent to harm"<Q2/>


    <Q3>SAP DB can easily replace Oracle in deployments. You can connect to SAP DB in "Oracle-like" mode, where almost all SQL statements have the same syntax. I have ported a couple of applications just by replacing the jdbc driver!
    Great piece of software.<Q3/>

    The "mainframe people" reminds me of the bad guy in a b movie. No matter how many times he is shot he miraculously recover again..


    Regards
    Rolf Tollerud
    Reply to this Reply to original

  364. mainframe people[ Go to top ]

    <Q>NET is not built for providing quality software.
    It reeks of that problem</Q>

    Done by .NET users (no Sun boxes, Java Servers or Oracle):

    <Q>Merrill Lynch at 75 million transactions per day at 25 million users (that’s 21,000 transactions per second!)</Q>

    Done by "mainframe people":

    <Q>To date, around 70 percent of initial Java implementations have been unsuccessful, according to new research from Gartner Group.</Q>

    And before you bash Gartner Group and says that they are bought by Microsoft remember that this where the people that advocated last year that everybody should stop using IIS, on grounds of security problems.

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  365. mainframe people[ Go to top ]

    <Q>
    And before you bash Gartner Group and says that they are bought by Microsoft remember that this where the people that advocated last year that everybody should stop using IIS, on grounds of security problems.
    </Q>

    I applaud them for getting something right. Finally. Of course this was not news to anyone who knows anything.

    http://www.msnbc.com/news/837799.asp?0si=-
    Reply to this Reply to original

  366. mainframe people[ Go to top ]

    Again, I assert: This is a no-brainer here. NO ONE should choose m$ over Java because of one reason, and one reason only: You start out from day one with the ceiling of only being able to scale so far. It isn't portable.

    Also guys, remember when comparing these execution times, that Java is using a JIT compiler.
    Reply to this Reply to original

  367. mainframe people[ Go to top ]

    Hi Tracy,

    Do you mean this ceiling?
     
    <Q>Merrill Lynch at 75 million transactions per day at 25 million users (that’s 21,000 transactions per second!)</Q>

    isn’t high enough?

    About other platforms, have you not heard about Mono? In a few months there will exist a .NET version on Linux and eventually on the other Unixes whenever you like it or not. And I mean all, ASO.NET, ADO.NET and Windows Forms.

    Try to read this article:
    "Why .NET will benefit other platforms"

    http://zdnet.com.com/2100-1107-960049.html

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  368. mainframe people[ Go to top ]

    And whether you accept it or not it will not be MS.Net. And more than likely will not be very compatible except on a low level.

    Here are some quotes from JDJ's interview with MS:

    <jon strayer>: What are your plans for porting .NET to other operating systems (HP-UX, Solaris, AIX, Zos)?
    <microsoft>: We do have a noncommercial implementation of the C# and Common Language Infrastructure ECMA standards running on FreeBSD and on Windows XP, but customers shouldn't read anything into that except that those standards are true, open, platform-neutral standards from a recognized standards body. That said, we haven't announced any plans to implement the .NET Framework on other operating systems.

    <lee graba>: Can the entire .NET Framework (or at least C#, the CLR, and the .NET libraries) be clean-room duplicated by any third party without any IP restrictions imposed by MS? Do you have patents on technologies within .NET, and, if so, will you renounce any intention to limit the work of the Mono project and .NET clones through patent enforcement?
    <microsoft>: The .NET Framework includes valuable intellectual property belonging to Microsoft. Just like any other company, we will review any action that may affect our intellectual property rights before making a decision about how to proceed.
    Reply to this Reply to original

  369. mainframe people[ Go to top ]

    Mark,

    It is better to just wait and see. I know one thing, when Mono 1.0 is released I will start using it even if it only is a subset of MS.NET. Then I have platform compatibility. The alternative, to help Sun cashing in over $200 mill in license fees for Java is to me absolutely unbearable. ($200 mill as estimation, Sun will not disclose the real amount).

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  370. mainframe people[ Go to top ]

    "<Q>Merrill Lynch at 75 million transactions per day at 25 million users (that&#8217;s 21,000 transactions per second!)</Q> "

    Just imagine what could be done if those pc's were Sun's or OS/390's... case CLOSED.
    Reply to this Reply to original

  371. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    I could have used the benchmark results much sooner. Our technology team ported a large application from MS to j2ee. The j2ee performance was not acceptable and the project was killed. The j2ee version would have drastically increased our technology costs ... a negative for the bottom line.

    I encourage that your firm continues the j2ee vs. .net study. My suggestion is that any optimizations done on either platform are normal ( i.e. they follow each firms best practices ). We do not want optimizations that require rocket scientists on our staff.
    Reply to this Reply to original

  372. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    James: "I could have used the benchmark results much sooner. Our technology team ported a large application from MS to j2ee. The j2ee performance was not acceptable and the project was killed. The j2ee version would have drastically increased our technology costs ... a negative for the bottom line."

    That's unfortunate. I too have personally been involved with some really bad J2EE projects, and I was even responsible for architecting one of them (speaking of bone-headed) that caused a 4-CPU Oracle database to crawl under even minor load (like 2-3 concurrent users). (Disclaimer: That was back in 1999 when the J2EE spec was brand new -- still beta -- and no one had much of a clue how to use it.)

    However, J2EE is a fine foundation for scalable and performant systems, and a much better choice (from a CIOs perspective) for many applications than a closed product or technology, such as .NET. (I'd probably still do Windows-only GUIs in VB (v6) or C#/Winforms.)

    OTOH, most apps get ported on whim from one technology to another, and unless there was a good reason to do so, or a big set of changes required to the application, then yours was probably better off being left alone in its MS-based incarnation. Just because one technology is newer and better and more open doesn't imply that you have to port everything to it. Especially if the team doesn't have the skills and knowledge necessary at that point in time.

    Java is still faster than .NET and probably will remain that way (since the CLR is built on a simple JIT model), but the difference is so small (like 10%) that it really is not enough to influence any serious decisions. If you really needed the extra speed that badly, you wouldn't be using such high-level platforms as Java or .NET in the first place. As you no doubt witnessed, most performance is lost by the architecture or the application developer, not the platform.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  373. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Quite frankly in the real world (i.e. outside of IT), no one cares who performs the best on hardware X or with database Y or using technology Z. What people want to know is within a given budget, give me the best performing application that you can. As such, I am a firmly against a comparison that limits the architecture to the Intel platform. The community as a whole would be much better served if the primary constraint were dollars not hardware.

    The dollar constraint would apply to a combination of the dollars required for consultants to build the application, the licensing costs for the software required, and the costs of the associated hardware. It would be perfectly fair to cost out the fees of .Net consultants vs Java consultants differently based upon the industry average for these skill sets. It would be perfectly fair to use different hardware...one of which may be more powerful than the other. It would be perfectly fair to use expensive software or inexpensive open source software.

    The idea is to build the best application possible given the constraint of dollars. I would set the dollar limit based upon on industry average of what company's would likely be willing to pay for an application like Pet Store.

    Limiting the test to a particular hardware platform is just plain silly (at least for those outside of IT). Limiting the test to a dollar constraint, however, is the real world we all live in each and every day.
    Reply to this Reply to original

  374. Suggestions for rematch and comments[ Go to top ]

    My company does both .NET and Java development so we have these debates (sometimes red faced) all the time.

    I have a couple of comments and also some suggestions for the rematch (if there is one).

    Comments:
    - I had a lot of experience writing C code on HP/UX as well as C++ server code on Windows before I switched to Java 5 years ago. The reason why I switched (and my fortune 500 employer at the time also switched) was not because Java executed faster. In fact, the JDK 1.1.x I was using at the time was about 10x slower than the same C++ code. The reason we switched was that there was no affordable vendor provided DB connection pooling in C and C++ (including ODBC) and it was too difficult and risky for us to implement one in native code. So I found some free connection pooling code in Java and implemented a small subset of our server in Java. Which beat the crap out of the same C++ code with no DB connection pooling. And no access violations, core dumps, or third party library side effects (like the memory leaks in MFC). One of things that makes Java cool is the ability to share code across platforms transparently without you having to worry as much about wierd side effects screwing up your program.

    - Why are we suprised to find that .NET executes faster than Java? MS had Java to work from and built a set of bytecodes which are specificly designed to be compiled, not interpreted. The CLR takes full advantage of that and also provides many of the same features the JVM provides including garbage collection and disallowing pointers (in managed code). The fact that it executes faster or not is not the point. The fact that you can still easily have stray pointers and memory leaks in unmanaged CLR code makes that point moot. I've heard that .NET Server puts the IIS process and the CLR in protected OS areas to increase performance, so what does this say about real world "performance"? I don't want my production server crashing because some retard (including myself) can't keep track of his memory.

    Suggestions for rematch:
    - If you're going to run .NET Server, then run J2EE on Solaris. .NET Server is a different OS because it runs IIS and CLR in a unprotected system area for performance reasons.

    - Don't run .NET against SQL Server, run both apps against Oracle 8.1.7 with the appropriate patches applied. SQL Server is faster but less accurate because of it's use of dirty reads. If you do run against SQL Server, then aquire a write lock on every read so that SQL Server's data accuracy is similar to Oracle.

    - Don't run WebSphere. Use Oracle AS instead. I want to see if Oracles claims are valid and they are actually faster than .NET.

    Thanks,
    Matt
    Reply to this Reply to original

  375. A change I would like to see[ Go to top ]

    A couple of points here:

    1) I agree with you: the point is not to have J2EE come out the winner, the point is to know what really is faster and if so by how much.

    2) The key factor to me is the use of ENTITY Beans. I would like to see a rematch, but a rematch with only Session Beans (of course with all the performance features: caching of Initial Context, Home interfaces, etc). We all know that Entity Beans do not perform, and as far as I know .NET does not have a comparable "feature"

    I hope you do it.

    Ciao
        Ferruccio
    Reply to this Reply to original

  376. What we really need![ Go to top ]

    It would be nice to have a cost comparison, for example:

    Take 100k for example, let each vendor price out developers labor, hardware, and software and see what you can scale the application to. Let the individual companies determine how to spend the money. Use retail pricing, not some discounted amount and let them have at it.

    No restrictions, no holds barred contest. It is not "what is better" from a technology benefit that matters to the IT community, but where can I get the most bang for my buck!
    Reply to this Reply to original

  377. The Middleware Company Asks for Input on J2EE vs. .NET Rematch[ Go to top ]

    Good reading people:

    http://www.fawcette.com/javapro/2003_03/online/j2ee_bkurniawan_03_11_03/
    Reply to this Reply to original

  378. Poor Java....better get up on those .Net skills ;)[ Go to top ]

    All these programmer yacking about Java design this and multiplatform OS that...its all bullshit to the user and more often then not, probably always...a user of a web app or heavy client will ALWAYS choose the faster loading web page or windows application built using Win32 on the Windows OS (respectively). I have seen, heard and stood by as numerous Java projects have failed due to over engineering, poor performance, un maintainable code and over budget development cycles (trying to “tune” of course). DAO is bullshit (especially the term “database agnostic”—USE the DATABASE) in an environment where performance is critical (and please NAME a prevalent business context where performance is not an issue!), and of course, those programmers that do, are the “programmers and architects” that consider performance as a “side note” or “not always as important”. Try telling that to the insurance data entry clerk trying to meet quota for the day or the home user waiting for their product page to render while their kid screams in the background! GET REAL PROGRAMMERS stop living in your BLOG world where the only discussions and inputs that count are those of your fellow geeks and clueless CTO’s.

    MS makes products that people want and the support and documentation is superior. Some programmers HAVE A LIFE and do not want to work 16-18 hour days playing with or god forbid “tuning” poorly document containers and learning “new” Java standards. Java has TOO many influences, too many contributors and in essence each will be benevolent to its downfall. You see, there is NO single point of authority only a disparate and discouraged community that has lost touch with what quality software IS….screw cross platform (write C++ if you want to run on n platforms…can you say FLASH!)….performance, usability and maintainability are paramount. Java will end up like Perl…barely used and regulated to a few geeks creating about 10% of the web sites in world….

    By the way…look at your next pay check and thank Bill for it…because without him your beloved “industry” and open source community would still be anonymous and confined to some lame university research center.

    jason
    Reply to this Reply to original