Slashdot Mirror


J2EE vs. .NET in Productivity Comparison?

Matt Hughes asks: "When does one programmer's preferences (Java over Microsoft-anything because they hate Microsoft, or Microsoft over open-source because open-source is evil) and the variety of choices start to erode productivity? As a J2EE developer for the past few years, I admit that I've become frustrated at the number of choices out there. Every one offers a different way of doing things but they don't all interoperate (JBuilder doesn't natively understand Struts) and none of them -- in my experience -- pulls all of the web technologies together very succinctly. Does Visual Studio .NET and the .NET framework pull this together better than the open-source projects out there, or is it just as complicated in your experience? Is .NET too immature to be trusted? What are your thoughts?" For those interested in the raw performance numbers, Slashdot did a performance comparison between the two technologies, in an earlier article.

"I've recently been asked to produce a report listing the pros and cons of J2EE and .NET as a web application development platform. I've been using J2EE for years now and haven't even touched .Net as I dislike most Microsoft products. However, for the report, I am trying to be objective. From my own experience and from what I've read, it seems the defining issue for some people is choice.

As far as language preference, some argue Microsoft allows too much (VB.NET, C#, and supposedly everything else *eventually*) and J2EE too little (Java). As far as development environments, Microsoft offers too little (Visual Studio .Net, Windows Server 2003, Windows only) and J2EE provides too much (JBuilder, Eclipse, Tomcat, JBoss, Websphere, any OS/hardware combo, etc)."

68 comments

  1. Struts by KDan · · Score: 2, Informative

    JBuilder has support for Struts. 8 even has rudimentary support for 1.1. 9 has full support as far as I'm aware. Eclipse can also use plugins to have that support, but I haven't used them personally. I don't see what there is to complain about in J2EE development environments...

    Daniel

    --
    Carpe Diem
  2. Looking for Trolls? by ClosedSource · · Score: 4, Informative

    Believe it or not some people use Java for reasons other than hating MS. Some people use MS for reasons other than disliking open source.

    Having said that, I do note that you are perpetuating the myth that Java runs on "any OS/hardware combo". This is untrue of any language but I suspect "C" comes closer to achieving it than Java.

    1. Re:Looking for Trolls? by KDan · · Score: 2, Informative

      Actually, the J2EE platform is extremely portable. We're talking about websites that can be moved from a windows i386 server to a unix mainframe without a glitch. Obviously "ANY" OS/Hardware combo is exaggerated, but there is a wide range of supported hardware and the web application servers are rigorously identical on all those machines and OSes. The only difference there might be is in threading specifics, but so long as you designed with that in mind it shouldn't be a problem.

      Daniel

      --
      Carpe Diem
    2. Re:Looking for Trolls? by scrytch · · Score: 3, Informative

      Having said that, I do note that you are perpetuating the myth that Java runs on "any OS/hardware combo". This is untrue of any language but I suspect "C" comes closer to achieving it than Java.

      I suspect you'll have a hard time running compiled C on any platform for which there is a compiler. Or for that matter, even build it unmodified without the benefit of autoconf unless it's among the most trivial of programs.

      Not that Java has a lock on portability -- Perl and Python do just fine in that area too.

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
    3. Re:Looking for Trolls? by stevey · · Score: 1

      Considering you'll need a C compiler to bootstrap and build the Java Virtual Machine I think it's fair to say that for any OS/Platform Java exists upon you'll find a C compiler.

      Unless the JVM is bootstrapped in something baraque like Forth ;)

    4. Re:Looking for Trolls? by lewp · · Score: 2, Informative

      Without a glitch? Someone's never written any J2EE code...

      --
      Game... blouses.
    5. Re:Looking for Trolls? by sheldon · · Score: 1

      "We're talking about websites that can be moved from a windows i386 server to a unix mainframe without a glitch."

      We recently acquired a company that had a web site built on the Weblogic J2EE platform, running on an HPUX machine. For whatever reason, we didn't acquire the whole company so we lost the licensing for Weblogic in the deal. Rather than pay BEA, we tried to move the site over to Oracle's app server which we already have paid for.

      It most certainly did not work without a glitch. Apparently Weblogic(like most J2EE platforms) has all kinds of proprietary methods in there to differentiate themselves from the competition.

      We reevaluated the project and decided it was cheaper to buy a license for Weblogic than to rework the site to work with Oracle.

      So much for portability.

    6. Re:Looking for Trolls? by KDan · · Score: 1

      I was more talking about each application server (which works on several machines/OS'es) being identical on all of them, and the code running fine. So if you ported from BEA on Linux to BEA on windows and then to BEA on Unix, you wouldn't have to do anything to make it work. Of course, trying to switch the actual app server soft is a bit more of an endeavour...

      Daniel

      --
      Carpe Diem
    7. Re:Looking for Trolls? by Anonymous Coward · · Score: 0

      Java's pride is not in simply running on any OS/hardware combo. It's WRITING CODE ONCE to run on any OS/hardware combo. Java does not achieve it. But C is far worse than Java on that front.

    8. Re:Looking for Trolls? by CodeWanker · · Score: 1

      The gripe I have abour C# versus Java is that C# error handling (Try Catch) is OPTIONAL. So you can ( and my team has) rolled merrily along writing things that if we knew we shoulda trapped for we woulda. I LOVE that Java forces you to admit "Yeah, I'm too lazy/ in a hurry to worry about incorrect input here."

      --


      "Wow. Now THAT'S a lot of angry Indians." - Lt. Col. George Armstrong Custer
  3. Maslow Hammer by Khazunga · · Score: 3, Insightful

    I think everyone suffers from the Maslow Hammer syndrome. We all prefer to use the tools we already know. This is not an entirely wrong attitude, since anyone is more proficient with the tools used regularly. The Maslow Hammer syndrome is dangerous only when its threshold is so high it prevents changing to a tool that is much better. This is not the case for either of J2EE/.NET. If I changed to .NET now, I'd take a few months to develop as fast as I do now in Java.

    --
    If at first you don't succeed, skydiving is not for you
  4. .NET vs Java by Per+Wigren · · Score: 4, Insightful

    I haven't coded neither Java or C# much, but I know the basics for both of them. C# to me seems a bit clearer and easier to get a hang on than Java. I also like the fact that I can code in C#, Smalltalk, Eiffel, ilasm (yeah right;)) or some other language, and if a Visual Basic programmer want to use my classes (s)he can just use them, like they were native classes.. No modifications needed. No wrappers needed.
    I haven't done any testing on raw performance, but I have noticed that running "mono app.exe" starts the app almost as fast as a native app while Java takes WAY more time to start up.. Also, Java seems to have much more RAM overhead..

    --
    My other account has a 3-digit UID.
    1. Re:.NET vs Java by UPi · · Score: 5, Informative
      Please note that the question wasn't C# vs Java, but .NET vs J2EE. The languages themselves are just plain irrelevant in this case. Also note that .NET is not just C#, but a whole bunch of CLI'ed languages (there's even a bastardization of C++ there).

      I have used both J2EE and .NET, and there are a few things I can offer for the report.

      • J2EE is more mature. It's been around longer, so it simply had a longer time to grow out of childhood sicknesses. For example: The documentation is more complete. .NET's docs are like all Microsoft docs: mostly generated, and sometimes the very reason you're reading them is missing. For example sometimes you don't have a clue what exceptions a library method can throw...
      • .NET is pretty handy for what it was concieved: creating simple web-based DB frontends. If you want an object model behind it, with good persistency options, you will want to choose J2EE instead with it's Enterprise Java Beans.

        This is quite general for everything: e.g. .NET has the almighty DataSet, J2EE has persistent beans. DataSets are simple, but go back to the structured programming age. The beans are more sophisticated, but take a little longer to get the hang of.
      • Learning curve: IMHO J2EE takes a little longer to comprehend. Once you got the hang of them, though, both environments are easy to use.
      • Oh and one more thing: C# doesn't check the exceptions. I may be a purist, but I just detest that. You have to document, maintain, and generally keep an eye out for your and the system's exceptions all the time (of course sometimes you have no idea what system exceptions there are..)


      Summary: If you want a quick and dirty DB frontend, go for .NET (with C# or VB). If you want something more complex, I'd recommend J2EE.
    2. Re:.NET vs Java by Khazunga · · Score: 3, Informative
      I also like the fact that I can code in C#, Smalltalk, Eiffel, ilasm (yeah right;)) or some other language, and if a Visual Basic programmer want to use my classes (s)he can just use them, like they were native classes.. No modifications needed. No wrappers needed.
      The multi-language aspect of .NET, much hyped by MS-marketing, is a common characteristic to all bytecode-interpreted languages. Java has its own list of bytecode compilers: 165 of them, by current counts.
      --
      If at first you don't succeed, skydiving is not for you
    3. Re:.NET vs Java by __past__ · · Score: 2, Insightful
      But how many of these 165 languages are really integrated with Java, as opposed to merly using the same bytecode representation? I.e. how many of these languages allow you to use Java libraries, and use libraries written in them in Java? Looks way worse then.

      That said, .NET is not as language-agnostic as MS would want you to believe. Basically, all languages can be ported to .NET as long as they are sufficiently similar to C#. Note that, for example, "Managed C++" is something very different from C++, and there are lots of rants on the web of people who tried to port languages like Scheme or even Python to it - it can work, but it might end up very inefficient, or with substantial changes to the language.

      However, I don't think that this is really that bad - the idea of using libraries with different languages isn't that good in the first place, IMHO. A good library for Lisp would certainly look very different than a good VB library, with a very different interface. Tying yourself to language independence will lead to least-common-denominator quality code, not everybody is satisfied with that.

    4. Re:.NET vs Java by The+Bungi · · Score: 1
      Note that, for example, "Managed C++" is something very different from C++

      MC++ is a misnomer. The VC++ compiler has a set of extensions that allow you to easily hook into the managed CLR using a few new pragmas and keywords. Other than that, your code looks pretty darn much like your average C++ application. You can use the STL, ATL or just about any C++ library that is compatible with VC++. Even MFC, if that's your poison.

      C++ is really just that, C++. Even if you're using the managed extensions. About the only thing I don't like about MC++ is the whole casting thing for managed types. That stuff can get nasty at times... it looks like bad macros on crack =)

    5. Re:.NET vs Java by __past__ · · Score: 1
      Other than that, your code looks pretty darn much like your average C++ application. You can use the STL, ATL or just about any C++ library that is compatible with VC++.
      *cough*multiple inheritance*cough*friend classes*cough*
    6. Re:.NET vs Java by The+Bungi · · Score: 1
      Well, true to a certain extent. You can still do things like those, except not in managed classes. Anything that is not marked with __gc goes.

      Who uses MI these days anyway =)

    7. Re:.NET vs Java by Khazunga · · Score: 1
      But how many of these 165 languages are really integrated with Java, as opposed to merly using the same bytecode representation? I.e. how many of these languages allow you to use Java libraries, and use libraries written in them in Java? Looks way worse then.
      How many? All of them. They produce valid bytecode, which must be run inside a Java Runtime Environment, responsible for providing the J2SE libraries. I don't get your point.
      --
      If at first you don't succeed, skydiving is not for you
    8. Re:.NET vs Java by __past__ · · Score: 1

      There is a difference between running in a JVM and being able to interoperate with Java classes, just like you cannot automatically use C functions just because your language compiles to the same binary code. Not all of these languages allow you to use System.out.println, or create a JTree object, even if I admit after a second sight that more seem to allow this than I initially thought.

    9. Re:.NET vs Java by kupci · · Score: 1

      Exactly. And I think you missed one of the best examples: Cobol.NET. To extend your point then, with dot net we are tying ourselves to the least common denominator, or COBOL. Rock on, all you .NETers! COBOL rules!

    10. Re:.NET vs Java by Khazunga · · Score: 1
      There is a difference between running in a JVM and being able to interoperate with Java classes, just like you cannot automatically use C functions just because your language compiles to the same binary code. Not all of these languages allow you to use System.out.println, or create a JTree object, even if I admit after a second sight that more seem to allow this than I initially thought.
      Geez. Why keep on insisting on error? All of them allow System.out.println. Please name one that does not.
      --
      If at first you don't succeed, skydiving is not for you
    11. Re:.NET vs Java by Anonymous Coward · · Score: 0

      > I also like the fact that I can code in C#, Smalltalk, Eiffel, ilasm (yeah right;)) or some other language, and if a Visual Basic programmer want to use my classes (s)he can just use them, like they were native classes.

      Just one point, VB != VB.Net. Microsoft had done a really good job of marketing this "language options" in .Net, but it is only a marketing gimmick. A VB programmer will require the same effort to learn VB.Net as learning C# or Java.

  5. They both work well by cookd · · Score: 5, Interesting

    I think letting "I hate Microsoft" or "I hate open source" sway your decision is unprofessional (besides -- do people really hate open source? I don't even think Bill Gates *hates* open source, he just wants to keep his market share). Rant and rave one way or the other on Slashdot all you want, but make your business decisions based on facts. There are plenty of pros and cons on both sides.

    Variety can definitely erode productivity. At work, I have to keep up on the Win32 API, the Windows CE API, C++ (with ATL, MFC, and STL), C#, Perl, 2 variants of SQL, makefiles, with some VBScript and JavaScript thrown in for good measure. At home, I try to keep up with the FreeBSD API, 2 more variants of SQL, PHP, Java, a different structure for makefiles, etc. And the alphabet soup doesn't seem to be getting any better.

    Open source seems to have a tendency to have several projects around a given problem (MySQL, PostgreSQL, FireBird, SAP databases), while businesses tend to lead to bigger, more fully featured (also called bloated -- depends on your point of view) products (SQL Server, Oracle, DB2). Performance varies by application -- for jobs that don't need the extra features, sometimes the simpler products are better. And sometimes, open source results in a real beast (Mozilla). Java is somewhere in between I guess. But since the question was more about Java vs. .Net than open source in general, I'll get to the point.

    I haven't used Java much for web apps, but I have done some general development in Java. I have done some web development with .Net (C# in particular), and a lot of general development. From this limited perspective, here are my observations:

    The performance benchmark you linked to was pretty meaningless. It seems to have been funded by Microsoft, so that just might have biased the methodology a bit. Nevertheless, I think there are some general gut feelings that I think are reasonably accurate regarding the performance of Java and .Net. Both have roughly similar execution speeds (both have decent JIT engines under the hood). Most performance differences in benchmarks will probably be found to be due to the quality of the benchmark code or the quality of the libraries (such as database drivers) being used. I know that Microsoft has gone to great lengths to optimize their database drivers, and a while ago some benchmarks were posted that showed some significant advantages to their drivers. Perhaps Java has caught up since then -- I don't know.

    As far as IDEs go, I'm not sure why "choice" in this matter is really an advantage. .Net only has one decent IDE, and some people don't like it, but it gets the job done well. There are side utilities that fill in any gaps left. I don't have as much experience with Java IDEs, but I'm sure they are also decent, but that there is no one single IDE that makes everybody happy. Since most workshops have to pick one IDE for the team to agree on, somebody is going to be unhappy no matter what, just like some people might be unhappy with the Visual Studio IDE.

    As far as language goes, I guess it is nice that .Net supports multiple languages, but I suspect that most workshops will only make heavy use of one or maybe two. It just gets too complicated otherwise. The nice thing is that no matter what language you pick, you can access the same support libraries. But the more important question is which language is better for your purpose -- Java or [whichever language you decide to use].

    I personally like C# over Java. Things like ref and out parameters, boxing, and attributes are things that are quite simply missing from Java. They are needed, and they aren't there. Obviously Microsoft took a lot of good ideas from Java, but since they got to start over with it, they got to improve on the parts of Java that drove Java programmers nutty.

    On the other hand, .Net hasn't been around as long. And whi

    --
    Time flies like an arrow. Fruit flies like a banana.
    1. Re:They both work well by Tim+Macinta · · Score: 1
      I think letting "I hate Microsoft" or "I hate open source" sway your decision is unprofessional
      Many of the reasons that people hate Microsoft are very relevant to what is the best tool for a job. Microsoft has a very long history of screwing over people, including their own customers, they have a long history of insecure products, a long history of bugs, a long history of thwarting interoperability, and many other things which really should be considered. People who hate Microsoft and apply this to their choice of tools to use for a job may have just internalized the knowledge of the risks that generally come with using Microsoft products. It doesn't just matter how well the product works, it also matters whether the company that makes the product is going to knock on your door a year later demanding that you prove that you paid for all of your software, it matters whether your software will suddenly stop working because you can't re-register it when it decides to demand it, it matters if the product plays nice now but down the line breaks interopability with standards such that it only works with other products from the same company. Just because .NET may work fine now doesn't mean that it is a good business decision - Microsoft's sordid history should be a consideration and it is not unprofessional to factor in a company's past business practices into whether using its current products is a good idea.
    2. Re:They both work well by cookd · · Score: 1

      Well, then. Those are facts and reasons, aren't they? Those are more professional reasons.

      --
      Time flies like an arrow. Fruit flies like a banana.
    3. Re:They both work well by fastdecade · · Score: 1

      This is a great comparison, but I want to clarify one point:

      Things like ref and out parameters, boxing, and attributes are things that are quite simply missing from Java. They are needed, and they aren't there.

      Yes, they are needed. And version 1.5 (betas already available) will include boxing, attributes (ie meta tags), as well as the long-awaited template facility.

      Just as MS haven't acknowledged Java as an inspiration (I've heard C++ mentioned several times, never Java), Sun seems to have done the same back regarding 1.5 features (at least according to recent interviews with Sun engineer Josh Bloch). But no matter what they say, each language development will push the other one along.

      This goes for the languages (C*/Java) as well as the platforms (CLI/J2EE containers,JVMs).

    4. Re:They both work well by Anonymous Coward · · Score: 0

      >I don't even think Bill Gates *hates* open source, he just wants to keep his market share.

      Since people often hate what they fear, Mr. Gates may actually hate open source. Or at least OSS that he cannot co-opt.

      -- A.C.

  6. windows env by raffe · · Score: 1

    I have using both. The difference is not big. The only reason why i would choose .Net is that i am using MS only. You know that your not gonna move to solaris or mysql or anything else. I know its working but .net on windows is better that java on windows. So if you arent sure if you gonna use windows/exchange and so on - stay with java.

  7. J2EE becoming the de-facto standard... by HawkingMattress · · Score: 3, Interesting

    Several times recently we have had opportunities to have contracts with public shops, like governemental agencies and the like.
    They all sent us loads of papers describing what type of architecture they expected, and what rules we'd have to follow. What they all want to ear is : open standards, evolutivity, free (as in beer) libraries, maximum portability, and connectivity.

    Now, guess what they like to hear between J2EE, jakarta libs, JNDI, linux, or... .NET, microsoft, sqlserver, licencing ??
    It seems big shops really start to get the point about the advantages of open standards.

    (Note : I'm talking about french agencies, it might not be true everywhere. But I suspect most european countries are following those lines too.)

    1. Re:J2EE becoming the de-facto standard... by HawkingMattress · · Score: 1

      What they all want to ear is

      Note that on the other hand, it seems J2EE is trying to invade my language ;)

    2. Re:J2EE becoming the de-facto standard... by Kz · · Score: 2, Informative
      (Note : I'm talking about french agencies, it might not be true everywhere. But I suspect most european countries are following those lines too.)


      here in Peru they ask the same things: "open standards, evolutivity, free (as in beer) libraries, maximum portability, and connectivity";

      but... this is an extract taken from their dictionary:

      'standards' = windows
      'evolutivity' = XP! .Net!, XML! (yes, with exclamation points they hear better)
      'free' = 'i can get a CD for S/. 5' (that's five soles, less than 2 US dollars)
      'portability' = ??
      'conectivity' = IE.

      now guess why i don't do web development.
      --
      -Kz-
    3. Re:J2EE becoming the de-facto standard... by lewp · · Score: 1

      Does this mean... war

      I know, I know...

      --
      Game... blouses.
    4. Re:J2EE becoming the de-facto standard... by jmauro · · Score: 0, Offtopic

      No, war is now only possible if J2EE is attempting to develop weapons of mass destruction. If they already have WMD, then war is again out of the question.

  8. .Net is too immature by nado · · Score: 2, Informative

    Windows XP really impressed me. With that and having heard of J#, I thought wow, that'd be great, because I like Java, but it's too irresponsive for GUIs and even though hand-coding GUIs makes nice code, I don't like it (using Eclipse for java). So I got a copy of VS.Net from campus, which goes for not so much.

    At first I thought it was damn cool. You could just build your GUI very quickly by clicking around, the online help is nice and all, multi-monitor support is really good, etc. Then bugs started popping from everywhere and I found I was spending more time on writing workarounds than "real" code itself (or simply redoing dialogs because the IDE decided to forget about some). Then, when I had assignment demos to do for school, I was writing them in J#, but I had to redo the GUI by hand anyways, because you can't run J# on .Net by itself, you also need a redistributable for J#, which isn't installed in the computer labs. Deployment is also very complicated. You have to distribute the .Net and J# distributables along with your app, then if you want DB support, you need a third one and then your app by itself is already big...

    So I just switched back to Java, where you just install one distributable sometimes, for machines that don't already have it. And then deployment is a joke, you just send a 50k jar and that's it. No 2-3 megs for simple apps! Sure the GUI's not too responsive, but I'm waiting for 1.4.2 eagerly now instead of wasting time on .Net.

    I payed .Net from my pocket because I wanted to use it and at the end, the only thing I can say about it is that I got robbed. Eventually, it will mature up and if it gets accepted as well as Java, it might become interesting. But next time around, it's gonna be forced on me, I won't switch by will.

    1. Re:.Net is too immature by Anonymous Coward · · Score: 0

      If there were bugs in your GUIs, I'd say that was your coding, not .NET as I've written some extremely complex GUIs in it without encountering a single bug.

      Deployment is no more complex than Java: you need the .NET framework installed, but Java needs the runtime too. Our completed apps are pretty small. I think you must have been doing this wrong, too.

      What does a bad workman do?

    2. Re:.Net is too immature by Gaijin42 · · Score: 1

      A few things :

      J# has issues, dont interpret J# as the whole of .Net J# was really just a marketing ploy to get Java people over. Use C# or VB.Net. and you wouldnt have had the deployment issues

      Yes, .Net has a nice sized redistributable, but so does Java, so its pretty even.

      You did something wrong if your GUI didnt work right. This thread is about web development, and the GUI is therefore HTML. If you were using NS4 then yes you had lots of issues, because NS4 doesn't support CSS2, which .net likes to use, but you can turn that off pretty easy. So anyway, if you are on topic, then the flaw is your HTML skills, not .net.

      If you were talking a Windows Forms app. well, I think you are smoking crack if you think swing/awt is easier or more consistant. Using awt is like handing someone a chainsaw and then bending over.

  9. Depends on your programmers by Leknor · · Score: 2, Informative

    First, familiariarity breeds increased effency. If you don't have the time to study all choices and train on something new then pick a familar one.

    .Net is younger and has fewer choices when it comes to web framworks and external libs which some people prefer. This blog enty explains it better than I can: http://javablogs.com/ViewEntry.jspa?id=31449

    Java is more of a Language For the Masses than C#/.Net. While us alpha-geeks like Languages For Smart People that does not make them better, espcially when we have to work with less smart people on your team. Much more on this at: http://madbean.com/blog/20/.

  10. Objective-C (Old version of Web Objects) by norwoodites · · Score: 0, Offtopic

    An even better than both of those two crapper products and older. Faster to build and faster to depoly.

    1. Re:Objective-C (Old version of Web Objects) by artur9 · · Score: 1

      Even the pure Java version of WebObjects is at least one order of magnitude more productive than this bologna.

      --
      ------- MacOS X, WebObjects, Apple (G5) hardware triply tied
  11. Not a technology decision by bay43270 · · Score: 2, Insightful

    The choice between .Net and J2EE is a cultural one. Many companies would rather have one solution, even if it limits them in many ways. Others would rather have more flexibility, even if it means more work (learning how to use struts and JBuilder together).

    J2EE technologies aren't flexible by chance and .Net isn't easy to use on accident. Each company chose their strength and built around it.

    1. Re:Not a technology decision by massive-cow · · Score: 1

      Can you objectify your implication that .NET is 'easier' and J2EE is 'more flexible' ?

      --
      Simplicity is prerequisite for reliability. - Dijkstra
  12. Slashdot did a comparison? by zero_offset · · Score: 1
    Funny, I thought TMC did the comparison and slashdot just linked to it.

    (No wonder they're so far behind on submissions, they're all busy in Slasdot Labs (TM) running the latest round of amazing new benchmarks. I can't wait to see the results!)

    --

    Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005

  13. We can't talk about .NET by ratboy666 · · Score: 1

    I just did a security update on my wife's laptop. That machine uses Windows 98, but doesn't actually include .NET (at least, I never selected it for download).

    The last Microsoft Update included a paragraph in the EULA, that indicated that you may not mention any benchmark comparisions about .NET.

    I presume that this includes performance and usability (no mention made of that in the EULA). Now, my wife agreed to the EULA (She must agree to the EULA, so I am not bound by it). Anyway, I have never used .NET, because I do not have a license, nor have I agreed to the EULA.

    But, I do take these things seriously. If you HAVE had exposure to .NET and agreed to the EULA, then you are under a gag order from Microsoft. Unless, of course, you have a Microsofts permission. In which case you are a shill.

    Now, the SUN license doesn't have such a clause, so you are free to comment on performance 9or lack thereof). So, make comments about J2EE, its performance and its usability.

    Ratboy

    --
    Just another "Cubible(sic) Joe" 2 17 3061
    1. Re:We can't talk about .NET by Anonymous Coward · · Score: 0
      Actually it says this:

      * You may not disclose the results of any benchmark test of the .NET Framework component of the OS Components to any third party without Microsoftâ(TM)s prior written approval

  14. J2EE (JSP) vs ASP.NET by Gaijin42 · · Score: 5, Insightful

    Okay, here is my anti-disclaimer. I _AM_ a web developer, and I do web development all day long, every day, since there was a web pretty much.

    When JSP first came out, it was a significant step forward from the tool that I was using at the time, ASP (classic). The advantages were many. Exception handling, and objects were the primary ones. Other things (like being strongly typed) also were a significant step forward. Yes you could get many of these things by doing your ASP development in JScript, instead of VBScript, but nobody really did.

    However, the disadvantage of Java : over-architected. If you follow the blueprints, or examples provided by Sun, or Apache, or any other big shop out there, you end up with thousands of classes. Java itself doesnt have this issue, (IE, the language does not require this) its more of the paradigm that the whole J2EE world evokes.

    ASP.Net has many of the same advantages that JSP has. Exceptions, classes, strong types (if you want them)

    However, as a bonus, the .Net model encourages a better web architecture (IMO).

    For example, take a look at Java Pet Store vs PetShop.net. Yes there are complaints from the Java world that its not a fair comparison, because they did things differently. THATS THE POINT. If Java encourages you to do things in a way that uses 4x the code, and runs slower, thats a problem. Microsoft is under no obligation to do things in an inneficient manner to match Java, because thats what Sun wants. MS set out to compare "how much code to make this functionality happen, and how does it perform"

    Some may say : but the Java code might be better architected! How do you judge architecture? Only 2 things matter. Maintainability, and Performance. The .Net solution performs better. So thats 1. The Java code might be more "correct" OOP design, but in terms of maintainablilty, mediocre code, vs 4X perfect code is gonna be a close call. And I don't think the .Net code is mediocre, its very readable. And the Java code isn't perfect. So in my book, .Net wins the pet store competition.b

    Now, from a platform perspective, Java did some things that I wish would have made it into .Net (specifically C#). .Net has a problem of swallowing exceptions. In Java you have to declare what any function can throw. Therefore the caller of your function can know to handle the error, pass the error, or ignore (swallow) the error.

    Since you dont declare exceptions in C#, callers of functions have to be prepared to handle any exception. As a result, most callers just end up catching Exception and then they never get passed up.

    Some other things are enviromental. Visual Studio.net is FAR AND AWAY the best IDE I have ever used. Seamless integration of HTML, code, Javascript, database etc. Integrated debugging of client and server side code, including database calls (it will jump into the stored procs and let you step through them!)

    While integrated debugging is something available in Java, I have not seen it to this degree.

    Also, ASP.net seems much easier to extend. Making new controls (user controls or server controls) is trivial compared to the work required in Java.

    Now, Java's big claim to fame is of course cross platform compatibility. If you need to run on Unix TODAY, then obviously go with Java (or python, or perl or whatever)

    But Mono is just around the corner. Mono will already run iBuySpy (a pretty complex app) without modifications. So cross platform for .Net is a reality too.

    1. Re:J2EE (JSP) vs ASP.NET by GOD_ALMIGHTY · · Score: 4, Interesting

      However, the disadvantage of Java : over-architected. If you follow the blueprints, or examples provided by Sun, or Apache, or any other big shop out there, you end up with thousands of classes. Java itself doesnt have this issue, (IE, the language does not require this) its more of the paradigm that the whole J2EE world evokes.

      This is just plain incorrect. J2EE is not over-architected. Have Sun and the various Java vendors done a really crappy job of providing "How do I get from A to B" info? Yep, but it's not over architected. In fact, the core J2EE libraries don't have much in there that isn't necessary.

      The thousands of classes are necessary when you want to deploy portable, clusterable, scalable components. The trick is, how to not write all that by hand. I personally haven't written any of those classes by hand, or maintained the XML descriptor files needed in over a year. I use XDoclet to manage that. It's portable between IDE's and supports almost all the containers available. If you're application is portable between IDE's (in other words, you used Ant to build it and didn't use weird wizard things that store meta-data in the IDE somewhere), then incorporating tools like XDoclet shouldn't be an issue.

      I write one class for an EJB, I add XDoclet tags that generate it's Local and Remote interfaces, Utility objects, Value Objects, XML descriptors and SOAP descriptors. All in one file, so where's the bloat?

      The XDoclet paradigm is going completely mainstream in Java 1.5. You can go look at it on the JCP as JSR-175.

      For example, take a look at Java Pet Store vs PetShop.net. Yes there are complaints from the Java world that its not a fair comparison, because they did things differently. THATS THE POINT. If Java encourages you to do things in a way that uses 4x the code, and runs slower, thats a problem. Microsoft is under no obligation to do things in an inneficient manner to match Java, because thats what Sun wants. MS set out to compare "how much code to make this functionality happen, and how does it perform"

      Some may say : but the Java code might be better architected! How do you judge architecture? Only 2 things matter. Maintainability, and Performance. The .Net solution performs better. So thats 1. The Java code might be more "correct" OOP design, but in terms of maintainablilty, mediocre code, vs 4X perfect code is gonna be a close call. And I don't think the .Net code is mediocre, its very readable. And the Java code isn't perfect. So in my book, .Net wins the pet store competition.b

      The Petstore comparison doesn't hold any water anywhere. If you are designing webapps the way the Petstore projects were built, you need to find another profession. The original Sun Petstore was built as an example of how to get basic stuff working, not a working example of how to build enterprise apps. It was used as part of a short tutorial where they wanted to demonstrate every J2EE technology in one bang.

      The Microsoft .Net Petstore was a cheap shot at Sun. Rickard Oberg, who started the JBoss project and the XDoclet project has written extensively on why both are crap and Microsoft was pulling a fast one. Frankly, I haven't looked at the Sun Petstore stuff in several years, because it's useless for doing real work.

      Sun has a long history of great technology, but they couldn't market themselves to save their life. Seriously, how many people know what the hell, the benefit of SunONE is? Sun's software strategy appears to be a world of contridictions.

      If you want to do J2EE, don't ask Sun how to do it. Go to the Open Source Java community. These are the guys that are innovating. They see the holes that Sun has left and have gone and plugged them.

      If you really wanted, you could write your next webapp in the same way Microsoft wrote their Petstore, load the entire database into memory, t

      --
      Arrogance is Confidence which lacks integrity. -- me
    2. Re:J2EE (JSP) vs ASP.NET by Mad+Browser · · Score: 1

      While I think I see your point about architecture, I would argue that it is up to the developer/architect to choose an architecture that makes sense...

      Design patterns can help, but as you said nothing in J2EE is forcing you to over-architect.

      I've been very successful in building J2EE web apps that handle lots of clients and resemble what I think is a good design that is still useable.

      I haven't used .Net yet but I do plan on getting a PC to try it out (I do all my stuff on OS X and I don't think the Mono port is anywhere far enough along yet). From what I have read it seems like .Net is a good step forward for Win programming and that is good...

      Still, I think J2EE is more mature and at this point probably a 'safer' bet. That's not to say that .Net is no good. I really don't have any personal experience with it.

      --
      RateVegas.com - Vegas Reviews
    3. Re:J2EE (JSP) vs ASP.NET by lewp · · Score: 1

      While I think I see your point about architecture, I would argue that it is up to the developer/architect to choose an architecture that makes sense...

      Spot on. Regarding the Java Pet Store example used above, there's an alternative implementation that might be more appealing to people who preferred the .NET implementation to Sun's (including myself).

      The purpose of Sun's Pet Store was to demonstrate "best practices" (not performance, which is why the more performance-oriented .NET store smoked it). Unfortunately, they layered best practice on top of best practice until all they had left was a completely bloated mess.

      Oracle has their own implementation as well, which I believe is also competitive with the .NET store.

      --
      Game... blouses.
    4. Re:J2EE (JSP) vs ASP.NET by sheldon · · Score: 1

      I'm curious why no J2EE vendor, or even JBoss hasn't rewritten the Petstore functionality in an intelligent manner to make for a better comparison?

      I know Oracle tried to do something like this, but they seriously screwed up. I read the Veritest examination of that test, and I'm very familiar with using Loadrunner and can see that they purposefully set options to skew results in their favor. The only thing Microsoft seems to be guilty of is trusting Sun to provide a good app.

      Just seems like your complaints would have more credibility if you backed them up with actions.

    5. Re:J2EE (JSP) vs ASP.NET by styrotech · · Score: 2, Insightful

      You comparing apples and oranges.

      If you just want JSP stuff, you shouldn't be using J2EE. You're adding unnecessary 'enterprise' features, then wondering why it's too complex. Just use a web container like Jetty or Tomcat etc. Not many websites would need J2EE unless they had to integrgate with a ton of other backend systems.

      J2EE is more comparable to the entire .NET framework (at least), not just ASP.NET.

      And anybody bringing up Pet Store either is slightly ignorant of what it was for, or has another agenda. Pet Store was a demonstration of every little feature, not an example of a well architected application.

    6. Re:J2EE (JSP) vs ASP.NET by Gaijin42 · · Score: 1

      From Java.Sun.Com. Emphasis mine. Looks pretty much like a description of a model to follow. Not something that shouldn't be copied.

      Again, my point was not that Java required you to write this type of code, merely that Java encourages it, and the examples provided encourage it.

      The Java Pet Store Demo is a sample application from the Java 2 Platform, Enterprise Edition ("J2EE") BluePrints Program at Java Software, Sun Microsystems. It demonstrates how to use the capabilities of the J2EE 1.3 platform to develop flexible, scalable, cross-platform enterprise applications.

      The Java Pet Store Demo comes with full source code and documentation, which illustrate the typical design decisions and tradeoffs a developer makes when building an enterprise application. The demo shows how to use JavaServer Pages ("JSP"), JavaTM Servlet, Enterprise JavaBeans ("EJBTM"), and Java Message Service ("JMS") technologies. It also uses new technologies in the J2EE 1.3 platform, which you can experiment with and learn how to use in your own enterprise solutions..

      With real, working code illustrating the BluePrints guidelines, the Java Pet Store Demo reduces the learning curve of the J2EE 1.3 platform, enabling you to deliver complete end-to-end solutions with faster time-to-market. .

      The Java BluePrints Program program helps developers create robust, scalable, and portable applications by providing guidelines, patterns, and code that illustrate best practices on how to build end-to-end applications using Java technology.

    7. Re:J2EE (JSP) vs ASP.NET by Gaijin42 · · Score: 2, Informative

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

      However, they don't provide any benchmarks other than lines of code.

  15. conflation by rodentia · · Score: 2, Interesting

    I'm a little concerned at the way the question conflates open-source with J2EE. Java can be used in an open-handed fashion but it is not inherently open. Certainly J2EE is not though JBoss gets props for trying.

    Anyway, why take the pill? If you don't like the infrastructure, build and borrow the tools you need. It's not rocket science, as much as MS wants you to fear its complexity. A decent controller and a quality markup regime and you can do *web services* as you see fit on top of Tomcat.

    --
    illegitimii non ingravare
  16. J2EE vs .NET by AmbushBug · · Score: 2, Insightful

    The two technologies are really targeting different markets. J2EE is really aimed at large enterprises. As such, it was designed primarily for scalability (not performance). That means lots of layers, etc. so that they can be put on different machines and clusters and stuff like that. This makes J2EE more complex as well but once you learn it, you can do more with it. J2EE application servers also do a lot more for you than Microsofts application server technology. .NET (as with all MS software) is really aimed at the small to medium sized enterprise. MS is focused mainly on making their stuff easy to use. So the learning curve isn't as steep, but once you start building more sophisticated applications, .NET is not as flexible.

    Tool support is the biggest draw to .NET. Visual Studio is really easy to use. While the Java folks have spent the past few years focusing on refining the technology itself - tool support has suffered. However, that will soon change - Eclipse and Netbeans are coming along and Sun will soon be releasing new easier to use tools.

    You also cannot ignore the proprietary nature of .NET. You will be locked in if you use it. Mono is coming along nicely but do you really think that MS will maintain compatibility with it in the long run? Given their history, I seriously doubt it. With Java and J2EE I can setup complete development and production environments without paying a single license fee. There is also healthy competition in the J2EE app server market so if you are using Websphere and IBM pisses you off, you can dump them and switch to BEA (with minimal porting effort).

    Like you, I've also had to evaluate both technologies (I work for an enterprise consulting firm) and believe that J2EE is the way to go. Initially, it may cost more (if you use the proprietary software) but it is worth it since you have far more control over it and more options.

  17. .NET over J2EE any day by shadowxtc · · Score: 1

    I've worked with both platforms for years now. .NET is definitely matured, it's simply the next logical step in the evolution of VB, ASP, and MFC, although somewhat hybridized now. Depending on your preference, it may be quicker to develop in Java, as C# is just as much if not more effort. But VB has finally matured into a respectable language, and provides for truly rapid development. And for all you JavaBean lovers, stop wasting your time. Visual Studio .NET is definitely a good match for its competition, and .NET provides "components", which parallel beans, and make more sense IMHO. Oh yes, and then there's web services. Did I mention it all runs on Linux?

    1. Re:.NET over J2EE any day by jester · · Score: 1

      You've not mentioned one reason why you prefer .NET. Please state why you think .NET is better, and if so, for which type of projects.

      I have never used .NET, but have used Java, and J2EE for several years. I see many drawbacks in the J2EE 'system' (even at ver 2.0) ... lack of ability to extend entity beans, weaknesses of EJB-QL, and the lack of control over query capability.

  18. Objective .NET/C# vs J2EE/Java Comparison by massive-cow · · Score: 3, Informative

    I have used both a fair amount. My previous job was writing Java business web applications, and I am currently managing the development of a C# webservice (for the server) and a C# winforms client.

    Let's start with the picture from 10,000 feet: C# is aimed squarely at Java, and for all intents and purposes, it is a superset of Java. Similarly for .NET and J2EE, though they are less similar than the language comparison.

    Language Differences:

    C# has less integrated threading support. (which is a bad thing, imho)

    C#'s XML and SOAP integration make it /ideal/ for any application dealing heavily with either protocol. In fact, I would say that it is nothing short of brilliant.

    Java's XML integration is a nightmare. JAXB is the only thing that comes close to being halfway decent, and it still doesn't come close to the integration C#. XML serialisation in C# is fast and beautiful.

    C# gives you far more control over the dynamic reloading of classes, as well as increased security through what .NET calls 'AppDomains'. This is a very powerful feature.

    C# documentation isn't quite as nice or refined as the standard javadoc fare, but MSDN is a pretty nice source, though sometimes you have to look a little harder or deeper than you would with the javadocs.

    In general, both APIs are very clean.

    As for maturity, I don't really think that's an argument. Most of the Java technologies available now (especially the XML/web services bits, in which the competetition is most fierce) are no older than .NET/C#.

    I think the larger question is the underlying /platform/ maturity, but I will leave the zealots to argue Windows vs Unix.

    Do you feel comfortable locked into a Microsoft platform and x86 hardware? Personally, for a server, I don't. Go help out Mono, which is progressing nicely, but could definitely use some more help. (http://go-mono.org)

    If you do, I would definitely go with .NET and C#. When Mono gets further along for web services, it will certainly be a force to reckoned with. As for writing webservice and database clients for Win32, it is really quite nice. You could use GTK# and have it cross-platform, yet still take advantage of features that C# includes.

    In short, the pros: excellent XML and SOAP handling, speed, many small features which are currently emulated at the API level in other languages ...and the cons: currently somewhat locked into MS' platform (though this should change shortly with Mono), somewhat inferior auto-documenting to javadoc.

    --
    Simplicity is prerequisite for reliability. - Dijkstra
    1. Re:Objective .NET/C# vs J2EE/Java Comparison by AndersDahlberg · · Score: 1
      C# gives you far more control over the dynamic reloading of classes, as well as increased security through what .NET calls 'AppDomains'. This is a very powerful feature.
      Mod parent up as troll or atleast overrated *sigh*
      related links:

      http://www.freeroller.net/page/ceperez/20030520#p_ the_problem_with_cameron
      http://roller.anthonyeden.com/page/ceperez/2002120 5

      (let me give you a small tip:
      The performance of the C# version (regex example) is related to .NET's "far more control over reloading of classes" - maybe you should check your facts about reloading classes - pay extra attention to sections labeled "unloading" if you can find any... - in the java vm and .NET spec. ;)

      PS: Don't take that article too seriously, it was just thrown together to humiliate a MS clown known as Rolf Trollerud - just gotta love that name, shift some characters around ;) - residing in theserverside.com
  19. .net/C# is a limited subset of Java by kupci · · Score: 1
    Check out some of the excellent open source libraries available for Java as they are very easy to use. Furthermore, in terms of quality, power, performance, and support they undoubtably far exceed Microsoft's offering. I'm not sure which, except for JAXB, of the XML and SOAP tools you used, but apparently you had some difficulty with them. JAXB is actually for data binding, it is one many data binding tools available for Java, confusing maybe, but welcome to the freedom of choice provided by Java!

    I'll give you the fact that integration is probably easier with M$ since you don't have the plethora of choices you have with Java, but once installed (a trivial task), they are a snap to use, including "XML serialization", (although that doesn't really even seem much of a test of an XML parser, with the competition within the Java world, it usually revolves around which parser is the fastest, has the smallest memory footprint, best supports the XML standard etc. Again, a non-issue if you're stuck with one parser.

    So I'd conclude, you're probably seriously limiting yourself with M$, however, there is the no hassle benefit of not having to go and install stuff etc, sort of like using IE because it's right there, users don't have to download something off the net to use.

    Also, .NET/C# - it's a Java clone alright, but it's a subset being limited to a specific OS, unlike Java. So it's kinda like Java for Microsoft boxes. MONO? I find it very hard to believe M$ will let Mono get past the training wheel stage. Nice idea though, but hey, this is M$, not some charity.

    1. Re:.net/C# is a limited subset of Java by massive-cow · · Score: 1

      C# is a subset of Java? Are you on Crack?

      Your obvious bias against Microsoft has slanted your views on an excellent platform.

      C# is a *super-set* of Java, meaning it has more features.

      Also, C# is far more standardised than Java will ever be, even though pundits have attempted to get a proper Java specification in the works lots of times.

      The only half-way decent XML serialisation I saw for Java was something a company offered as commercial software, and it still didn't come anywhere as close to the way C# handles XML.

      I like Java. I also think Sun has done excellent things for the open source community (mainly OpenOffice), though it is still an old school UNIX hardware company at heart.

      It's just that C# exceeds the performance and functionality of Java in most cases, now on the Win32 platform, and other implementations are rapidly catching up - mainly due to Microsoft's surprisingly open standards.

      Nice try, though.

      --
      Simplicity is prerequisite for reliability. - Dijkstra
    2. Re:.net/C# is a limited subset of Java by Anonymous Coward · · Score: 0

      Java and C# are improper subsets of each other--both have distinct features. For example, C# has no checked exceptions (a horrifying mistake) or what Java calls nonstatic nested classes (syntactic sugar, but typesafe--unlike delegates).

      Features like XML serialization can and should be language-independent, supported for all languages by the platform. And as far as standardization, is there any doubt that the language specification Sun has published is complete and sufficient to enable independent implementations? I'd be impressed if IETF or ISO took ownership of C#, but who died and gave "ECMA" any clout?

    3. Re:.net/C# is a limited subset of Java by AndersDahlberg · · Score: 1

      C# is a *super-set* of Java, meaning it has more features.

      C# versus Jave (the language)

      more features != better language (IMHO it's actually the opposite - less features => better language, yes I like Smalltalk and Common Lisp ;)

      .NET versus Java (the platform)

      If you count available third party libraries and tools you probably see his point...



      Also, C# is far more standardised than Java will ever be, even though pundits have attempted to get a proper Java specification in the works lots of times.

      This is clearly just marketing bullsh*t, who *beep* cares if the "syntax" is standardised - do you even now what that means? The important api's are NOT standardised in .NET in any way whatsoever.



      Java atleast got standardised *API's* by www.jcp.org (it's a STANDARD).



      It's just that C# exceeds the performance and functionality of Java in most cases,

      And you know this how? Have you actually tried a .NET application - perhaps something involving a GUI (hint: GDI is not a great performer in .NET ... check your favourite Newsgroup for sources on that :)



      now on the Win32 platform, and other implementations are rapidly catching up - mainly due to Microsoft's surprisingly open standards.

      Open Standards: *sigh*

  20. How can one write custom ClassLoader in C#? by Anonymous Coward · · Score: 0

    If there is a way, I am not familiar with it (other than getting an assembly as a file and loading it).

    Java's classloader structure, built-in URL class loader, security and flexibility of dynamic classloading is incredible.

  21. .NET vx. J2ee by Anonymous Coward · · Score: 0

    this is .NET vs. j2ee, okay?
    not Java vs. C#and which is more productive, allright?

    J2ee:

    Servlets
    JSP
    JDBC
    Transactions
    RMI
    Reflecti on
    Java beans .NET:
    - no servlets, 1 for J2EE, on the other hand, there's no need for APP SERVERs

    - ADO .NET instead of JDBC -- ADO .NET has a better API IMO, but both are pretty simple

    - ASPX vs. JSP -- JSPs get really ugly really fast, ASPX does a better job of keeping the HTML and Code separate (the notion of code behind) -- again, ASP .NET is better than JSP (hit, ASP .NET is NOT ASP , its ASPX). You can mix the code in if you want, but you don't have to.
    - transactions, I haven't used those in J2EE , only in JDBC,

    - RMI, .NET doesn't have that, has web services instead. Web services are very nice, but everything gets converted to XML, so its slow.

    - reflection -- both have reflection, it works, even score.

    - beans -- .NET has "datasets". I like datasets, but have never coded the beans. Entity beans are crappy, from what I've heard, transient beans are OK. Datasets are pretty amazing, lots of code already built in.

    I give the edge to .NET in productivity

    1) the IDE is far superior
    2) microsoft has more experience with business applications: what does Sun know about business applications? they make boxes
    3) you don't need a separate app server/servlet server/J2EE compatible bean server etc., it already in IIS.

    I agree with complaints about the .NET licensing scheme -- its very complicated and prone to error.

  22. AMEN! by beavis88 · · Score: 1

    >> Oh and one more thing: C# doesn't check the exceptions. I may be a purist, but I just detest that. You have to document, maintain, and generally keep an eye out for your and the system's exceptions all the time (of course sometimes you have no idea what system exceptions there are..)

    I think this gets especially fun when using 3rd party/closed libraries, where you don't necessarily have any idea what exceptions they might throw.

    In practice, I have not found it to be a big deal. Then again, i'm pretty anal about exception handling due to experience with Java...seems like it *should* be easy enough for MS to provide this type of checking as a compile-time option....