Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Programming IT Technology

J2EE vs. .NET in Productivity Comparison? 68

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)."

This discussion has been archived. No new comments can be posted.

J2EE vs. .NET in Productivity Comparison?

Comments Filter:
  • Struts (Score:2, Informative)

    by KDan ( 90353 )
    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
  • Looking for Trolls? (Score:5, Informative)

    by ClosedSource ( 238333 ) on Friday June 13, 2003 @04:50AM (#6189033)
    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.
    • by KDan ( 90353 )
      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
      • by lewp ( 95638 )
        Without a glitch? Someone's never written any J2EE code...
      • "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 Webl
        • 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
    • by scrytch ( 9198 ) <chuck@myrealbox.com> on Friday June 13, 2003 @10:12AM (#6190458)
      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.
      • 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 ;)

  • Maslow Hammer (Score:4, Insightful)

    by Khazunga ( 176423 ) * on Friday June 13, 2003 @05:04AM (#6189075)
    I think everyone suffers from the Maslow Hammer [wastholm.net] 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.
  • .NET vs Java (Score:5, Insightful)

    by Per Wigren ( 5315 ) on Friday June 13, 2003 @05:08AM (#6189087) Homepage
    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..
    • Re:.NET vs Java (Score:5, Informative)

      by UPi ( 137083 ) on Friday June 13, 2003 @06:31AM (#6189308) Homepage
      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.
      • >> 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 pre
    • Re:.NET vs Java (Score:4, Informative)

      by Khazunga ( 176423 ) * on Friday June 13, 2003 @06:49AM (#6189371)
      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 [tu-berlin.de].
      • Re:.NET vs Java (Score:3, Insightful)

        by __past__ ( 542467 )
        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

        • 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

          • 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*
            • 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 =)

        • 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.
          • 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.
            • 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.

        • 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!
  • They both work well (Score:5, Interesting)

    by cookd ( 72933 ) <[moc.onuj] [ta] [koocsalguod]> on Friday June 13, 2003 @05:47AM (#6189175) Journal
    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
    • 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 th

    • 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 sam
  • 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.
  • by HawkingMattress ( 588824 ) on Friday June 13, 2003 @08:19AM (#6189640)
    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.)
  • .Net is too immature (Score:2, Informative)

    by nado ( 101599 )
    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 poppi
    • 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 t
  • by Leknor ( 224175 ) on Friday June 13, 2003 @08:33AM (#6189733)

    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 [javablogs.com]

    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/ [madbean.com].

  • An even better than both of those two crapper products and older. Faster to build and faster to depoly.
  • by bay43270 ( 267213 ) on Friday June 13, 2003 @10:11AM (#6190443) Homepage
    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.
  • 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!)

  • 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,
  • by Gaijin42 ( 317411 ) on Friday June 13, 2003 @10:46AM (#6190725)
    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.

    • by GOD_ALMIGHTY ( 17678 ) <curt.johnson@nospAM.gmail.com> on Friday June 13, 2003 @12:26PM (#6191673) Homepage

      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

      • 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 complain
    • 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
      • 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 [ibatis.com] 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). Unfo
    • 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 age
      • 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
  • conflation (Score:3, Interesting)

    by rodentia ( 102779 ) on Friday June 13, 2003 @12:25PM (#6191667)
    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.
  • J2EE vs .NET (Score:2, Insightful)

    by AmbushBug ( 71207 )
    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 rea
  • 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 competi
    • 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.
  • 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.
    • 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

      • 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
        • 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

    • 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 o

"It may be that our role on this planet is not to worship God but to create him." -Arthur C. Clarke

Working...