Opinion: Java to J2EE to Oblivion?

Discussions

News: Opinion: Java to J2EE to Oblivion?

  1. Opinion: Java to J2EE to Oblivion? (403 messages)

    I am a senior Java architect/developer, and my normal projects are global systems for 2000 to 5000 users. Traditionally these have been hosted on Unix systems and java has become the server side language of choice.

    But I feel that the complexity of J2EE is creating problems and not solving them. Even with tools like my own LowRoad code generator creating J2EE solutions is complex, and needlessly so in my opinion. The power of the PC and the growing stability of Microsoft offerings will dent our current Java/Unix view of the world.

    I have formalised my arguments in a paper:
    Java to J2EE to Oblivion

    My conclusion is that every Java developer should start to gain a working knowledge of .NET and be ready for the industry to switch many server systems over.

    Threaded Messages (403)

  2. Jonathan,

       Thanks for posting this opinion piece. A very interesting read.

       I think Linux+J2EE for mid-sized applications has a much higher place in enterprise development than you gave credit. I think it is more likely that mid-level projects will move not from Unix to Windows (as you suggest) but from Unix to Linux. Its cheaper both in software costs and in training costs.

    Floyd
  3. I agree with all your points in theory, but I think the M$ security holes that are everywhere and with more happening every day it will be a while until your transition happens. I have not yet seen the ground swell that you are talking about, I also still see a lot of momentum behind java development.
  4. Hi Floyd,

    Linux is the one thing I'm still not certain of. I really thought it would escalate about two years ago and so installed it on a couple of PC's and had a play. It was not a happy experience.

    Then XP came out, and all my valid reason for immediately moving to Linux simply vanished. And XP, as it turns out is stable (in my experience). Which is why I say in the artical that the old arguments about robustness and speed of Linux compared to msoft are not so valid anymore. It's now a straight comparison of cost for workstation software. And for server software I have not yet worked in an organisation where you can officially run Linux servers. Techies do it, but very hush hush.

    I hope I'm wrong and Linux does rise - msoft needs the competition. I just do not see a compelling reason at the moment.

    Jonathan
     
  5. How expensive is XP? Have you seen the new "licensing" scheme? :)

    I do not believe XP can scale as well as UNIX servers.
    I have done many benchmarks that show performance is comparable, and then the load just kills XP.

    Another item to think about is integration. Microsofts solution is Web Services... but try getting the legacy guys to want to put a web services stack on that bad boy. This is where J2EE CA is a good thing, and then you can expose your adapters via Web Services *if* you need external people to talk to them.
  6. Hi Jonathan,

    I agree that J2EE requires more-than-necessary development complexity, or at least that it has moved the complexity of implementing supporting services and life-cycle management (eg: writing custom C++ solutions) to complex deployment configuration issues.

    However I cannot see how that itself could kill the Java enterprise, not forgetting that ALL advantages of raw Java (eg: built-in security, serializatoin, RPC, exceptions, run-time verification..) are very much a part of J2EE.

    I also cannot see how .NET/Windows combination would wipe out the alternatives, notably Unix, considering that most of today's enterprise software (eg: Oracle, SAP) runs significantly better on Unix flavours, notably Solaris, and that the upper limit if operability for M$ Win platforms are considerably low, and less flexible compared to Unix members.

    I agree with your point of J2EE being too fast changing, and somewhat difficult to benchmarck (where setting up ecPerf in itself may amount to a considerable effort), but I think developer community and middleware providers are beginning to understand the need to control the beast, but I think that enterprise community by and large see it as an opportunity to refine the J2EE archtecture and its usage, for example, with design patterns, local interfaces, caching etc..

    Of course, .NET/C# do have improvements from the predecessors, Im not convinved that they are enough to seriously erode the existing UNIX-Java enterprise market, at least for the time being.

    cheers,
    -Harindra
  7. Floyd,

    Is this thread actually some kind of real-world stress test of the TSS application framework? :-)

    Tibi
  8. I am not sure that .NET is superior to J2EE. I think they are pretty close (and I do like .NET). I have seen a lot of large companies buy into J2EE recently (let alone non-M$ hardware), and I don't think they will switch to .NET right away, for many political reasons, as well as technical.

    I am excited to see .NET push Sun and Co. into working harder on the J2EE platform (and stealing ideas from .NET).

    We have yet to see real proof of .NET running huge enterprise systems (can we trust XP as the OS?)
  9. U forget just one thing my dear fella and that is however good .NET may be than J2EE (if at all), NOBODY would like to end up married to Mr. Gates and for me, its 'Until death do us part' with J2EE. I personally think you are a microsoft stooge posting these silly 'Nemesis of J2EE' atricles to fool the J2EE commmunity. U bloody ought to be delisted from this site.
  10. Hi Amit,

    delisted. Sounds extremely nasty. And I was contemplating how crappy msoft is being for not holding honest debate. In fact I was wondering if there is an equally knowledgable .Not (& java) site to this one. One where folks are honest, cos I really want real life experience and stories from the unbiased. Just cos I'm learning the stuff doesn't mean my brains have turned to mush. I too have a history of hatred for everything msoft, which is why this is so unusual for me .

    As for being married to msoft. Who is the nicer corp, Sun, HP-UX, IBM, BEA or MSoft? Why? I agree emotionally that one of these has shafted techies more than the other - or at least unix/java techies. I guess VB techies love them - that is a guess, I remember much shouting about 16/32 bit thunking. I still wish they had been cut in two... it would have done everyone a lot of good.

    Jonathan

  11. Jonathan wrote:

    "I still wish they had been cut in two..."

    I can assure you that you do not want that. The only thing that protect Java is that C#.NET not exist on UNIX. If MS was split the company that did not have Windows would immediatly port .NET to UNIX and that would be the end. (for Java). I also can assure you that my hatred for Sun is equally strong.

    Regards
    Rolf Tollerud
  12. Rolf: "I can assure you that you do not want that. The only thing that protect Java is that C#.NET not exist on UNIX."

    While C# has a few nice little bells and whistles, things like non-virtual methods are atrocious and totally unacceptable. It kept just enough C++_not_Java stuff to make it untenable.

    Rolf: "I also can assure you that my hatred for Sun is equally strong."

    We didn't notice. Unfortunately for you, you are stuck with Microsoft-market mentality, which means .NET==Microsoft and Java==Sun. While the former, as a proprietary set of technologies and rebadged products is true, the latter is not.

    Peace,

    Cameron Purdy
    Tangosol, Inc.

  13. Cameron wrote:

    "While C# has a few nice little bells and whistles, things like non-virtual methods are atrocious and totally unacceptable."

    Churchill had gone to Eton and Oxford but forgot everything that he ever learned except "the only thing that it is important is a sense of proportions". That is what he used to say to himself in the mirror every morning.

    To set attention on some unimportant bagatelles which then are discussed for ever is an old trick in argumentation.

    I am not here to quarrel about boxing or not boxing, delegates or not delegates and so on. The three most important things in the Java vs .NET discussion are as in all other programming platforms, speed, maintainability of code and productivity.

    C# is in its most basic level is ca 30 - 40% faster that Java. However, as you built your application the gap widens more and more (Struts for example is a performance disaster), until your finished app where performance easily can be 10 times better for the .NET as previously demonstrated in TSS.

    Rows of code can be 25% of recommended Java solutions. The MVC is better. Productivity is by a level of degree higher. The libraries are consisting, not overlapping and bloated, with fewer bugs than the 6 year old Java.

    Then we have things that just feel better, comparing C#.NET to driving a luxury car. In my experience 9 out of 10 Java programmers never even use a debugger..

    As I said before, the only thing that protects Java is that .NET does not exist on UNIX. But Microsoft can if they choose so, make a quality port in 3 months. They can also take BSD and make a proprietary UNIX for themselves. Then you have a real monopoly.

    There would be nothing left.

    Regards
    Rolf Tollerud
  14. Rolf Tollerud wrote:

    "Churchill had gone to Eton and Oxford but forgot everything that he ever learned except "the only thing that it is important is a sense of proportions". That is what he used to say to himself in the mirror every morning."

    Churchill may have attended Oxford (though I have never heard that myself), but he most certainly never graduated! He barely made it into Sandhurst as a cavalry officer candidate on his third (and last) examination. The English-speaking world's greatest leader of the 20th century was an abysmal student!

    What Winston Churchill has in common with this topic is beyond me. I rather doubt that he would favor Microsoft products if he were a developer today. He was more of a romantic than that! I can see him doing Linux..... ;-)
  15. Churchill on MS.NET[ Go to top ]

    "We shall fight them in the air, we will fight them on the seas. We shall fight them in the hedgerows, We shall fight them on the beaches!. We will NEVAH surrender!"

    So there! ;-)

  16. Don Stadler wrote:

    ”We will NEVAH surrender!"

    My mistake, It should have been Harrow and Sandhurst.
    But, sigh, another example of dividing the attention to irrelevances. I guess I have to be happy that I don't get comment for the spelling.

    Anyway I am sure Churchill would not have chosen a copy of a 30 year old operating system.

    Java can live on as far as I am concerned, I only want to get rid of SUN.


    Regards
    Rolf Tollerud
  17. "Java can live on as far as I am concerned, I only want to get rid of SUN."

    What exactly is your problem with Sun?

    I don't particularly like their software marketing and PR(J2EE, Forte, iPlanet, now Sun ONE). But IMHO they deserve respect for their Java innovations, their largely open enhancement processes, and open-sourcing many of their products (not only Java base technology and Jini, but also NetBeans, Tomcat, OpenOffice etc).

    Basically, the same applies to IBM. Think about all their contributions to the Java platform itself, and the IBM JDK, and Jikes. On the other hand, I consider their "corporate" products a bit idiosyncratic and unnecessarily complicated in terms of usability and handling (VisualAge, WebSphere, DB2).

    Regards,
    Juergen
  18. One thing I dislike about Sun is their penchant for filing lawsuits at the drop of a hat. I dislike Microsoft's inability to play with others without taking or modifying their toys......
  19. An answer to myself here.

    According to something I read this afternoon, Sun didn't sue Microsoft for adding the standard M$ API's to J++, but rather for removing standard Java API's (e.g. RMI) from the Microsoft version of Java.

    If this is true, Sun's lawsuit against Microsoft makes a lot more sense to me than it did. Java is not merely a syntax but includes the standard set of Java API's. Remove one or more of the Java API's and you break the 'contract' with the developers and users. The write once, run anywhere.

    Adding more API's (even Microsoft API's) is merely operating-system specific code (like JNI supports). Removing one or more standard Java API's from a 'Java' distribution (or a programming language which describes itself as Java in any way) breaks the contract, and I am pretty sure that Sun wrote the contract to preclude this.

    Microsoft is free to create a language named 'J++' or 'C#' which purport to have similar syntax to Java without the Java API's, but claiming that J++ is Java when it doesn't contain the API was going over the line.
  20. Don,
    M$ is very skilled at filing lawsuits as well, you know that (and it all began with DOS and IBM, remember?). Besides, lawsuites won't help Sun in taking over the world. Unlike M$ maybe... ;)

    About the Java vs .Net tech issues:

    When I was a Cobol AS400 programmer, well err, there were no issues really to compare with ;)...
    When I was a DOS programmer issues were "procedural vs object", "Mainframes vs Mini", "Pascal vs C", "C vs Fortran" etc.
    When I was a Delphi/Windows developer, issues were "C++ vs Delphi", "RAD vs Traditional", "Powerbuilder vs Delphi", "to DCOM or not to DCOM", "Merise vs UML", "VB vs NAT Systems", "Eiffel vs Lisp" etc. etc. etc.

    Now it's ".Net vs J2EE" and what's the difference? (Jonathan?)
    In the end, I always did what I wanted to and never ran out of work. No matter what orientation the market took or the amount of hype distilled by M$. So, this time will be just the same, I won't learn .Net as Jonathan suggested and I think I won't regret it. I'll just stick with J2EE because I find it easy enough for me. At most I'll keep an eye on .Net like I always do with competitors. By the time either one (J2EE or .Net) gets replaced by Z#EE++ I'll be retired or six feet under... :)

    As for the productivity issue:
    (and here goes the <Irony> tag...)
    A quote from one of my "beloved" former bosses:
    "What do you mean a new toolkit?! Programmers would be much more productive if they'd really work instead of chatting all day long on the damn Usenet!"

    Would the following article be acceptable to all of you guys?
    http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-j2eevsnet.html

    Cheers, I'm off.

    PS: Jonathan, you know I like to flame people for no good reason, please pardon me, my 16 year old son's website looks more professional than yours :D
  21. ouch
  22. Stephen,

    "Powerbuilder vs Delphi" easy... Powerbuilder because of one thing... the datawindow :)






  23. Jurgen,

    First, I know I am playing Devils advocate here, but remember it would be very boring if everybody agrees and pat each others back.

    I know that it is possible to set up a deployment of Weblogic that scales well and perform acceptable with custom tags and everything. But it is extremely difficult. With .NET you get it right out of the box. And thanks, yes, I always Keep Things Simple and Stupid.

    I was extremely happy working with Tomcat/velocity. If only all this the pooling/Optimizing/connection sharing and so on could be applied to ordinary beans out of the box.. That was only when the whole J2EE juggernaut come rolling in that I gave up and threw in the towel.


    Regarding the Open Source JPetStore they use a home rolled persistence layer that is not tested yet.

    "Only 10% of Java developers ever use a debugger?" Well that is my experience, even if it is perhaps not so extensive. But I remember somewhere here in the discussion, that Cameron Purdy, probably one of the worlds leading experts in Weblogic explained himself that he never used a debugger. Correct me if I am wrong. I used a debugger from a Canadensian company for a while, I think it was named Bugseeker. It had at least 50% of the functionality of a normal MS debugger. But the upstart time was long, and the

    installation to make it run was not for the faint of heart. But then the company went out of business..

    Regarding bugs that again is my own experience after struggling with the Calendar class for a while. Also I am reading Javalobby.

    Why I hate Sun? For the first SUN destroyed a large project for my company when they sued MS. For the second Suns Scott McNealy constantly been bashing MS and MS programmer over the years. It is a little boring. IMO an environment should be as chess, you learn how the pieces move in 10 minutes but to become a grand master takes a while. So the conception that all MS programmers are morons because it is easy to learn is a little stupid. There is at least the same amount of MS "Grandmasters" in the world as there is Java "Grandmasters". And I can assure you that all of us are dead set on destroying SUN.
    As is Microsoft.

    Now I have to work hard to finance my HP Itanium2 4 processors rx5670 with MS .NET Server. ($23,400)

    Regards
    Rolf Tollerud
  24. Rolf,

    You do sound pretty biased. However, on the subject of Struts, your comments are pretty a little specious I think. I've seen it scale quite acceptably in _very_ large scale projects.Have you actually used Struts yourself in large scale projects?

    Struts, like most things either from MS or anyone else, will scale and perform well _when it is well designed_.

    I've known guys that could probably get access to run a big transactional system, and I've known guys that couldn't get oracle to run 5 transactions per year (ok I'm exagerating on both, but you get the point).

    It comes down to quality. Struts is pretty good in my opinion. And a good developer can use it very effectively. It's certainly not for all projects though.

    I've just gone live with a system using Struts with about 6,000 - 10,000 daily users in a high security environment. It'll perform just fine (I will say that TagHandler reuse/caching is definitely a Good Thing with struts).

    -Newt

  25. Rolf,

    Concerning tools and configuration: Resin as Servlet container and IntelliJ IDEA as IDE and debugger are easy to install and need minimal configuration effort. And working with them is intuitive and a relief if one is used to more complicated tools like for example IBM's.

    Working with database via JNDI DataSources is straightforward with Resin 2.1, and also with Tomcat 4.0. Yes, connection pooling and the like have too long been an issue, but it's not that hard anymore.

    "And I can assure you that all of us are dead set on destroying SUN. As is Microsoft."
    Well, that's constructive competition at its best, is it? And a really positive attitude towards life... Are you really that full of hatred?? Please use your energy for creating something, not for wanting to destroy something, will you?!

    Regards,
    Juergen
  26. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    With .NET you get it right out of the box.


    If you go single vendor with Java this can be had.

    >Why I hate Sun? For the first SUN destroyed a large
    >project for my company when they sued MS.

    Then you should hate MS no less for destroying countless other companies, unless, like MS, you don't care about anyone else.

    >For the second Suns Scott McNealy constantly been bashing
    >MS and MS programmer over the years.

    Sounds alot like Bill and Steve.


    >And I can assure you that all of us are dead set on
    >destroying SUN.

    And destroying Sun will gain??? It definitely won't destroy Java. In may even do good.
  27. Rolf,

    While I agree with you concerning argumentation - yes, it is important to concentrate on the really important issues - I have to say that you are extremely biased on the Microsoft/Java issue, playing hardliner here.

    I am not a real fan of Struts, but why is it a performance disaster? Because of the instantiations of that little Action objects? Come on... Maybe you mean Struts' custom tags, custom tags are indeed a performance issue, but optimized Servlet containers can handle them acceptably.

    "Recommended Java solutions"... We all know that Sun's Pet Store implementation is bloated. Have a look at the Open Source JPetStore recently discussed at TSS - it is much closer to a real-life implementation. You have the choice: Keep it simple and stupid if you want to, or use a bloated framework if you feel the need to.

    You can develop Java web apps with little amount of code and clean architecture including MVC easily, in a reasonable amount of time, and with hardly any license costs for base technology or tools. Just think about what is appropriate for your project, stick to the basics and keep it simple.

    I guess it's the same with .NET: You can easily develop appropriate apps with little effort. But why should it be superior to wisely applied Java? It might be in terms of RAD productivity of juniors. But a senior can really understand what goes on in a Java app (think about debugging tricky issues), and I am not so sure about .NET in this respect...

    Apropos: Only 10% of Java developers ever use a debugger? Man, you have probably never worked in a team of Java professionals developing a complex server-side application...

    And .NET having fewer bugs than the Java libraries because it is younger? Isn't it normally the other way round - software maturing release after release? Finally, your claim of Microsoft being able to make a quality port of .NET to Unix in 3 months is at best absurd.

    Regards,
    Juergen
  28. "And .NET having fewer bugs than the Java libraries because it is younger? Isn't it normally the other way round - software maturing release after release?"

    Good point, Jurgen. It's difficult to forget the Microsoft track record on releasing software with many known bugs. Nor it's record of bloatware.
  29. Rolf: "To set attention on some unimportant bagatelles which then are discussed for ever is an old trick in argumentation."

    I don't know what you are babbling about. BTW your fly is down.

    Rolf: "The three most important things in the Java vs .NET discussion are as in all other programming platforms, speed, maintainability of code and productivity."

    Those are certainly important. Why not add "must not come from Sun and must be tightly integrated with MS Office" to the list. ;-)

    Rolf: "C# is in its most basic level is ca 30 - 40% faster that Java."

    You are so full of it. Even tests by MS biggots have shown that Java (friggin Hotspot, which _is_ slow) blows away .NET on a whole variety of tests.

    All in all, performance of .NET is about 5-10% slower than Java (Hotspot Server edition) and other JVMs are even faster.

    If you compare the first run of JITed MS .NET code against the first run of Hotspot client (interpreted) then yes, .NET comes out ahead -- but not by much! But you'd also look really ignorant if you used those numbers.

    Rolf: "However, as you built your application the gap widens more and more (Struts for example is a performance disaster), until your finished app where performance easily can be 10 times better for the .NET as previously demonstrated in TSS."

    Another bunch of BS. Java can be as slow as you make it, but Struts isn't slow when used correctly. And the silly MS numbers comparing SQL Server stored procedures with some Sun tech support guy's code (the old Petstore) is ridiculous. Like Oracle showed, Java is 18x or 28x as fast or something (also pure BS of course).

    When it comes down to it, Java is plenty fast, and typically (not always) faster than .NET.

    But .NET is fast enough.

    You won't win a perf argument. Certainly not against anyone with a brain.

    Rolf: "Rows of code can be 25% of recommended Java solutions."

    Baloney. Lines of code are based on what libs and tools you use. I can parse an XML document and extract an element out of the middle of it and flip it backwards and concatenate it to itself in one line of Java code.

    Same with C-pound/.NET.

    Rolf: "The MVC is better."

    Bologna. MVC is based on the libs. There are many more and much more mature libs for Java. But .NET will eventually be OK here too. Who cares? Who'd be stupid enough to invest in another single-vendor closed solution? "Hey, let's dump Java and go back to VB or Powerbuilder!" (Both great products, but not the future!)

    Rolf: "Productivity is by a level of degree higher."

    In some cases, you are correct. WinForms kicks azz, not surprisingly. We need to embrace and extend (oops, I mean "hug and inherit from") some ideas there.

    Rolf: "The libraries are consisting, not overlapping and bloated, with fewer bugs than the 6 year old Java."

    Yes, better named and more consistent. Yet useless because no intelligent preson will choose another single-vendor closed solution. Powerbuilder had some nicely named functions too.

    Rolf: "In my experience 9 out of 10 Java programmers never even use a debugger.."

    Ditto. I haven't really used a debugger since leaving C++. I think I used to miss it.

    There are really good debuggers for Java, though. Several.

    Rolf: "As I said before, the only thing that protects Java is that .NET does not exist on UNIX."

    And the fact that most IS/IT managers have more insight into the future than you do ;-).

    Look, buddy, I know you hate Sun and love to be a PITA about it. But get over it. Your facts, by and large, are incorrect opinions, and your opinions are all based on your dislike of Sun.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  30. Game, Set, and Match to Cameron Purdy!

  31. This is my last post in this thread.

    The discussion have degraded to "Mine is faster" "No its not", "Mine is better" "No its not" etc, not especially interesting.

    It is very easy to test this matter on your own computer, why don't you do it? The you will see that not only is .NET better in this main three areas (speed, maintainability of code and productivity) but completely smokes the opposition.

    I have only one problem and that is to get any work done. Not because of this discussion but because I find myself constantly playing and admiring the pure beauty of this engineering feat, this piece of art which is the .NET, instead of getting work done.


    "Developed by a committee"

    Used to be a joke, but in your case it is the sad reality.

    "The J2EE standards have been built with input from many major parties, who each have contributed (or pushed, depending on how you see things) their "ideas." This leads to a kitchen-sink approach to a standard.."

    "Sun's stupidly tries to be everything to everyone. They whip out an API or extension, sometimes drop it, maybe replace it, perhaps grab something from somewhere else, deprecate a few things, ignore important bugs, and build up high hopes with promises they don't meet. In the end, we as developers suffer because a good concept is lost in the glare of Sun's ineptitude." nd build up high hopes with promises they don't meet. In the end, we as developers suffer because a good concept is lost in the glare of Sun's ineptitude."

    And in the meanwhile MS machinery is rolling. See you in a year or two.

    Regards
    Rolf Tollerud
  32. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    <GoodNews>This is my last post in this thread.</GoodNews>
    Good.

    <Something Envy>The discussion have degraded to "Mine is faster" "No its not", "Mine is better" "No its not" etc, not especially interesting</Something Envy>

    What else is there?

    <WasteOfTime>It is very easy to test this matter on your own computer, why don't you do it? The you will see that not only is .NET better in this main three areas (speed, maintainability of code and productivity) but completely smokes the opposition. </WasteOfTime>

    I have. No it is not. How about those developing on (not even including for) Linux or OSX?

    <Mirage>And in the meanwhile MS machinery is rolling. See you in a year or two. </Mirage>

    Not if we see you first.
    When the MS machinery has rusted.
    When you find the grass ain't greener.
    And that there is no grass.

    Shouldn't that be 'MS propoganda machinery'?

    (Sorry some of this is childish - 'Its my party and I'll cry if I want to'. I'm a little giddy. My wife is out of town for a few days. Anyone know how pick leg irons?)
  33. Rolf Tollerud wrote:

    "The discussion have degraded to "Mine is faster" "No its not", "Mine is better" "No its not" etc, not especially interesting."

    Actually this is not quite true, Rolf. Cameron brought up a point which you neglected to address:

    Cameron Purdy comment:

    "Yes, better named and more consistent. Yet useless because no intelligent preson will choose another single-vendor closed solution."

    This is the essence of the resistance to .NET, that most of us see no great advantages to .NET and absent compelling reasons see no reason to move over to a 'single-vendor closed solution'. Which is what .NET amounts to unless and until vendors other than Microsoft bring out .NET tools and App servers deployable on a range of OS'es.

    Microsoft may have opened things up a little, but frankly I'll believe it when I see commercial-grade .NET solutions deployed on non-Microsoft App Servers running OS'es other than Windows. We're a long way from that, aren't we?

    BTW, you quoted a number of passages in your post which Cameron did not write, and answered them. Straw man argument?



  34. I only want to say that I have enjoyed the discussion very much and that I have the greatest respects of my opponents, Cameron Purdy, Don Stadler, Mark Nuttall et all.

    As I said before, I don't really have problem with Java, only SUN. If SUN could give up control of Java to the only ones that can give MS real resistance, the Open Source people at the Jakarta project, then it would really be interesting.

    As more and more real programmers like Jonathan Gibbon and Jason Hunter get experience of real life projects in both .NET and Java, more facts will emerge.


    Regards
    Rolf Tollerud

    P.S.
    By the way, after two years of loosing nearly half our business we have finally decided how we will build our new version of our product, .NET on the server and Flash MX at the client
  35. Rolf Tollerud wrote:

    "As I said before, I don't really have problem with Java, only SUN. If SUN could give up control of Java to the only ones that can give MS real resistance, the Open Source people at the Jakarta project, then it would really be interesting."

    I don't really have a problem with C# or .NET per-se. If only Microsoft would give up control of C# and .NET to the people at Apache Jakarta, I'm sure virtually everyone would give it a whirl. I certainly would! It would be even better is Microsoft would give up control of .NET to a community process similar to the process governing EJB.

    Do you see the similarities in the situation? The difference is, of course, that Sun does not maintain the degee of control over many of the technologies surrounding Java and commonly used by it.

    You are bashing a company which is partly cooperative with the Open Source movement in the favor of a company which is openly fighting Open Source (Microsoft). Is this because because you believe Microsoft (aka the Borg) cannot be resisted? ;-)


  36. Some more thoughts...

    It really is coming down to culture. One is the open source - this is a pure meritocracy which huge churn and great things emerging every month or so. Some of these are so good they become defacto standards which last a year or two before the meritocracy of open source either sees them change beyond recognition or replaces them.

    Examples: Ant, Log4J, JBoss, Struts...

    Then there is Java and J2EE which is driven by Sun. Open source is encouraged by sun, and yet they compete with it. I guess this is partly career progression inside Sun. eg new log libs compete with log4j, new standard tag libs compete with aspects of struts.

    Some people really love the open source, and see it creating a future of freedom and choice. Nothing should be allowed to compromise it because it is a NEW THING in society. Communal IP which can bring down big business and give power to the proggers (people) :)

    Sun is in a strange place. Their baby is running away from them a bit, and their finances are not what they were.

    Then there is msoft. I have thought some more on them. Traditionally they concentrate on the consumer - shovelling products which do what people want. Fine they may be buggy and insecure but the average user likes them, possibly because of inertia, but thats irrelevant. So we had word which crashed far too often for the first x years of its life. We had their OS versions and death/reinstall for the first x years. But gamers and authors got products aimed at them that mostly hit the spot. During this time they never really aimed at the techies, not for big projects, not really. For the first time msoft has aimed at us techies. They are aiming their 'give em what they want' attitude at techies and infrastructure. i.e. .Net is TECHIE - aimed squarely at us, and its more than adequate (honestly).

    So we are left with culture again.

    Power to the people, free software and communal IP.
    Sun struggling with standards against a mass of free software.
    Msoft woeing us techies for the first time, but by god the free software folks must die.

    No conclusion, other than the fight is basically free software v's vendor software. Some folks are still talking performance, scaleability etc etc - but these are pretty irrelevant, just stick Oracle in and you can architect anything. So it remains a hearts and minds debate, not a technical one.
    And the free software argument hates all vendors - its just that msoft is the biggest and so gets most of the vitriol.

    Jonathan
  37. Another thought-provoking post from Jon.....

    Jonathan Gibbons wrote:

    "For the first time msoft has aimed at us techies. They are aiming their 'give em what they want' attitude at techies and infrastructure."

    'Give em what they want?'. Not completely. Microsoft could have chosen to push a version of Java (call it java++) which remained fully compatible with J2SE with Microsoft libs added. They could have continued to ship XP with a standard JVM, but didn't. That is what Java programmers wanted.

    "i.e. .Net is TECHIE - aimed squarely at us, and its more than adequate (honestly)."

    I'm fairly sure this is true. Java/J2SE/J2EE are also 'more than adequate' but more friendly to open software, and they allow us to leverage existing skills rather than trying to force or induce us to replace investments in skills which are not obsolete, as Microsoft is.

    I own a few MS.NET books but don't intend to buy more at this point, though I glance at them when I visit the bookstores. I'm curious about .NET, but invariably run into the means problem. The good books assume that I own a copy of Visual Studio .NET. Even if I join a class to get access to educational pricing, it costs a load. I am not aware of any free or lose cost offers for either the base product or what is really necessary for a serious effort, a MSDN subscription.

    Contrast Microsoft policy (and pricing) with those of their competitors. I can easily get a free developers license from BEA or IBM for most of their stuff, basically for as long as I will need it. All Sun Java stuff is freely downloadable as is the Apache Jakarta stuff. The most facist vendor in the J2SE/J2EE space is Borland, and I can ignore them and use Eclipse.

    Assuming that I have equal interest in (say) ASP.NET and Jakarta Struts, which one do I choose? The one which will cost me $1000 or the freely downloadable one?

  38. Jon Gibbons writes:

    "Msoft woeing us techies for the first time, but by god the free software folks must die."

    "No conclusion, other than the fight is basically free software v's vendor software. "

    Microsoft is wooing us techies, but demands that we give up our foul habits of creating and using free software and Linux/Unix. To that end Microsoft has mounted a richly-funded Marketing campaign to discredit open source software and Java in addition to their usual tactic of hyping their own stuff far beyond it's merits.

    The trouble is that techies are a pretty savvy and self-confident bunch, and the normal FUD-style campaign is falling flat in our ears. I don't believe Microsoft when it trashes open source, and their implicit message that my continuing employability depends solely on adopting their technology is a bloody insult! I suggest they desist and compete in the merits and on price and access, the way everyone else does.
  39. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Good morning Don,

    "and the normal FUD-style campaign is falling flat in our ears"

    Well, they have seen such campaigns work in politics. I guess they are just picking up the bad habits. :)

    The comment about you made about not being able to get vendor software products as a developer is dead on. In fact, I've had that experience over and over in my career. Someday maybe someone will explain why providing your software freely and convienently to potential developer bases for your products is not seen as an obvious thing to do. When I looked at downloading WebSphere or WebLogic a year ago, neither allowed longer than a 2 month eval. I think IBM now gives you 6 months which is workable, but I just have to ask... "why the heck don't you just offer a developer version". Macromedia does with JRun. They throttle it down, but who cares... your just trying to learn their product. If I'm at the point where I need to stress test your product, I will go ahead on download the 1 month eval on the full product. Wanting the developer community on board doesn't seem like rocket science to me, just common sense. What am I missing. Why would BEA tell the developer community to reinstall their eval application server once a month? Why shouldn't my reaction be, "shove it... I will go learn with someone that will work with me". I guess their view is their bread is buttered at the client site, but they are off base if they don't developer\consultant lobbying does not influence the process.

    I still think this argument of "which is better, .NET or J2EE may be off base". Maybe it really should be "Hey, both of the camps need to get their act together. You have yet to provide acceptable solutions to the developer base". I concede that any distributed software solution will be complicated, and as you have said, J2EE represents a large leap forward from your C++ days. I just keep expecting some 3rd solution to slide in someday and steal the show while these two camps are at battle. Until then, J2EE or bust.

    Mike

  40. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    I agree with what you say.

    The problem domain that these languages (j2ee and .net) address, has become much more complex. in any given app, we could have : email, messaging middleware, distributed transactions, multi-threaded processing and so on..

    I believe *NO* language that addresses these issues can be simple. On a relative scale, there are'nt .NET has yet to catchup with java , when it comes to implementation numbers. I have seen microsoft technology up close - and the constant adding and jettisoning of language features or component models (Jet DB, RDO, WebClasses ....) is not much better than what Sun has done with Java programming idioms. As things mature, some programming models (within the language) will be thrown away - it has happened with Java and it happened with Visual Basic very late in the game, when VB was considered a mature language.

    What may be different is that we have a new programming language built from scratch (.NET ) - 'created' in the usual Microsoft-speak.

    More stable? Better suited for the new world of networked-everything, Distributed-objects-everywhere?. Perhaps. But we dont know if grid-computing and P2P are going to be mainstay technologies 1,2-4 years into the future - then the kludges and patches will start without a doubt. Change is the only constant and that means, patches and service packs will be the only constant.

    Java is messier because it is more open than .Net. But will its own weight and complexity kill it - a possibility, however slim.
  41. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mike Jones writes:

    "When I looked at downloading WebSphere or WebLogic a year ago, neither allowed longer than a 2 month eval. I think IBM now gives you 6 months which is workable, but I just have to ask... "why the heck don't you just offer a developer version". "

    BEA announced a developers version of Weblogic some months ago. I haven't kept up with the current state is to be honets, but I seem to remember that BEA would keep renewing developer keys for the freely-downloadable Weblogic 6.1 last year so you wouldn't have to go through the hassle of doing setup again.

    Even the 2 month eval licences IBM and BEA offered last year were far more than Microsoft offers even today on Visual Studio, which is nada.

    I'm not opposed to learning .NET at all, but as a practical matter I'm not going to lay out $1000 of my own money for the privilege. I'm willing to buy one or more books and invest the time, but until Microsoft cuts the up-front investment for me there are other things I can learn which will cost me little or nothing to do.....

    From my keyboard to Bill Gate's ears?......
  42. Jonathon,

    Hey, before this thread dies off, I just wanted to say thanks for stirring up the debate. The bottom line is that developers are very low on the food chain and it is often only another developer that will ever appreciate our work. I could completely disagree with all or your points in the article (but I don't), and still understand you have more than earned your right to present your views.

    I think Duran captured how I feel about my current J2EE studies in his second fight against Sugar Ray Leonard.

    "No Mas".

    but then I get off the mat, and get ready for the next round. :)

    J2EEorBust

    Mike

  43. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    "developers are very low on the food chain"

    I should probably qualify that. Bill Gates was/is a developer. :) I should have said a typical developer working for a company, or something like that. :)
  44. 400, yeah...
  45. Well, I've had over 28500 downloads of the docn, and when I dropped off the front page it dropped from about 1000 a day down to 80. So I recon most of what can be said has been said.

    I enjoyed the debate as well. And it has definatly focused my mind on what the real competition is. So thanks, one and all.

    Jonathan
  46. I am so sick of these ".NET is great! Java is dead!" articles. Go post this crap on some other site. This site is for J2EE. Go market Microsoft software somewhere else.
  47. Hi Kevin,

    :)

    The thing is that I agree with you about folks who say java is dead. But, my point is that J2EE has loads of irrelevant 'crap' in it for these pretty large projects. And for green field sites its a massive learning curve compared to .Net.

    So, rather than shun .Net cos its from the great satan, I'm trying to be objective - as my clients will be. And in two or three years when it is well established you had better have two or three years experience under your belt. I'm not saying give up Java, it's still good. I am saying train in .Net or take a large gamble.

    Jonathan
  48. maybe .NET is superior, but until one cannot deploy on a true scalable OS, Java will remain king for middle to large applications...
    Beside that, i'm still wondering why XP does not provide some sort of mechanism that would prevent a program to grab all resources...as far as i know, under unix (or linux) one can set a dedicated set of CPUs, RAM amount, HD, IO to the OS and application per application....

    just my 2 cents (i love those stupid english phrases that propagate from forum to forum)

    In french, I would conclude by : il n'y a pas d'avenir dans le développement : nous (les développeurs) sommes tous les ouvriers spécialisés du 3ième millenaires...nous construisons la compléxité et nous faisons payer nos utilisateurs pour résoudre nos problèmes et pas les leurs.
    Enfin, en prennant un soupçon de recul, je pense que les problèmes techniques sont toujours déterministes et beaucoup moins vitaux pour les projets que les ravages causés par les luttes d'influence entre les services/fonctions/métiers des grandes entreprises.

    Laurent.
  49. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    nous construisons la compléxité et nous faisons payer nos utilisateurs pour résoudre nos problèmes et pas les leurs.


    Je ne suis pas d'accord avec toi. Most of the problems I experience are with stupid dumb ass managers who chose inappropriate technology because the salesgirl had a short skirt, or they got bought lunch or the salesperson at the demo said they could get rid of the programmers and do all the development with a 'wizard'... or was it a lizard, I forget after that nice business lunch :-).

    Developers can be a problem though, they often want to use technology to get it onto their CVs.

    Regarding C# and VS.net. C# is ok, it is basically a devil's brew of C++ and Java with the usual Microsoft habit of changing things for the sake of difference. There is too much legacy C++ cruft which will cause big problems on large projects. The good thing about Java is you had less need for tight code standards because the newbies had less dangerous stuff to play with. I found Visual Studio .Net to be incredibly toy-like. I imagine it is going to be like MFC development - loads of horrible generated CLR code that crashes for no good reason.

    XP as an OS? I've heard of lots of people, me included, who have gone back to Wk2 because of XP issues. The biggest is there is just lots of stuff that doesn't run properly on XP, Microsoft products included. With the new agressive Microsoft licensing I can only see Linux's share growing. Who wants to rent their OS and applications and then have the EULA changed with every Web update? With Palladium you won't even have the choice of using stuff beyond the 'rental' period as the certificate will expire.

    David
  50. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Yes, J2EE is too hard for many programmers. But, it's wrong to damn it (long term) for that reason. Reality is that many of the J2EE vendors are working on tools that make development accesible by other folks. Just look at BEA's workbench stuff.
  51. I agree. J2EE is more complex than J2SE. Quicksort is more complex than Bubblesort. And for a small set of records - they perform about the same.

    For small systems (~2000 users) and systems without tight transactional requirements, hey, why should I do this to me and my team?

    So, granted, .Net will be widely accepted for those kinds of systems. For enterprise apps in financial institution however, I do not believe any MS platform/app will make it any time soon. Main Reasons:
    - no trust in security (although they might build trust with .Net/XP, but the wounds still hurt)
    - no proven technology (e.g. transactions and WebServices?)

    But MS will get there, yes. And the fact that they have the best tools and above all the best marketing will probably get them there sooner as the J2EE community wants to realize.

  52. Kev, you'd be better for loosing your tunnel vision. Productivity is the key to technology mass adoption not misguided loyalty. This is a great article and raises some interesting questions. Also, bear in mind that the author is probably playing devil's advocate a little, and rightly so.

    The main thing that I think could hold .NET adoption back is integration. More and more of the applications I get involved in partly require a new user interface and new business logic but also tend to encompass more and more legacy systems as datasources in addition to the basic relational database backend. So moving forward the key to a popular technology may not just be productivity but also one that can glue heterogeneous sub-systems together. At the moment one could argue that .NET is favourite for the former, but J2EE is favourite for the latter.

    Also on the point of mapping data structures between disparate systems, the winning technology would probably need to provide productive transformation tools to enable users to visually cross-reference different schemas (maybe based on XML and XPath) plus some sort of process management tool to help visually construct the interaction between these disparate systems.
  53. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    First of all, a disclaimer: I couldn't read the original article, the site didn't respond (Maybe slashdotted? I mean, theserversided :-))

    It's pretty clear to me that none of J2EE or .Net will massively prevail. A balance will be attained, the question is just where the line will be.

    We are seeing an interesting race between two runners rushing toward a same goal.

    Microsoft started with a single-user, very tool-oriented solution and is now moving toward the enterprise space.

    J2EE started with complex (but necessary IMO) enterprise specifications and almost no tools, and all the vendors are now struggling to provide tools that enhance the developer's experience.

    But please, enough of radical epithetes such as "oblivion" or "is dead". This kind of headline tends to make me think of the author as more interested in sensationalism than trying to provide an objective view.

    --
    Cedric


  54. <Cedric>
    But please, enough of radical epithetes such as "oblivion" or "is dead". This kind of headline tends to make me think of the author as more interested in sensationalism than trying to provide an objective view.
    </Cedric>

    David Bowie said it best in his song "Fame":

    Fame, makes a man take things over
    Fame, lets him loose, hard to swallow
    Fame, puts you there where things are hollow
    Fame

    Fame, it's not your brain, it's just the flame
    That burns your change to keep you insane
    Fame
  55. <Cedric>
    Microsoft started with a single-user, very tool-oriented solution and is now moving toward the enterprise space.

    J2EE started with complex (but necessary IMO) enterprise specifications and almost no tools, and all the vendors are now struggling to provide tools that enhance the developer's experience.
    </Cedric>

    I totally agree with Cedric Beust's comments. Also Dan Dubinsky's comments are right on.

    To that I would like to add my own hope and prediction. In a short time from now, J2EE vendors will have added the tools needed to hide the complexity of J2EE, so this will no longer be a problem. By that time M$ may have made .NET sophisticated enough to deal with the kinds of complex issues that J2EE can deal with today. So in the future, these two technologies may be very similar in terms of useability and functionality. However, if MFC is any indication, the complexity in .NET will be harder to understand than the complexity of J2EE. And .NET will cost big, big bucks while you can get a superior app server for free. So I don't think J2EE is in any danger of being dead.
  56. Kevin,

    I must say that post like yours are irrelevant and nothing but a distraction. If you feel like “ostrich-ing” yourself, go ahead. However, don’t attack someone who offers an analysis of two competing solutions.

    There are many ways to solve a problem. The initial problem is picking the best solution for the problem.

    Size 10 Nikes don’t fit everyone…
  57. I realize that the author has put a lot of time and effort in his article. I just question if this is the correct web site to post it. If the author truly believes that .NET is so much better and that it will make Java irrelevant, why is he posting on this site? Why does he even read this site? I come here to read about Java, not .NET (call it &#8220;ostrich-ing&#8221; myself if you like, I call it staying on topic). There are much better sources for .NET information than TheServerSide. Whatever, it just seems like there is at least one post a week on this site claiming that Java is dead and I find those posts to be "a distraction". My point has nothing to do with the article itself and everything to do with where the article was posted. Thank you and have a good weekend.
  58. Mozilla[ Go to top ]

    Client Side and Cross platform UI

    Needs a good Java API...or does it. JavaScript (An architect from Sun told me its called that cuz it was suppoesed to be to Java what bash is to C programming) XUL, XPCOM, etc.

    IMHO thios is the UI wave of the future, and not .Net.




  59. <quote>
    If the author truly believes that .NET is so much better and that it will make Java irrelevant, why is he posting on this site?
    </quote>

    Because his points are as relevant to .Net as they are to J2EE.

    <quote>
    Why does he even read this site? I come here to read about Java, not .NET
    </quote>

    If you are a big fan of J2EE, you should also be interested in anything that might help improve it or destroy it.

    I find Jonathan's article and postings well balanced and interesting to read, even if all you are interested in is J2EE.

    You are right to point out that we sometimes see zealots post, but these people belong more to advocacy than on theserverside. So far, Floyd has done a great job at moderating this for us, and I hope it continues that way.

    --
    Cedric
  60. Interesting, if slightly scary, article.

    It probably is a good idea to be aware of .NET's capabilities, even if it's only to argue for J2EE from a position of knowledge, rather than one of FUD.

    I might buy a .NET book to read up..... anyone got any recommendations, from the point of view of a J2EE developer?
  61. I'd recommend reading up on C# first and then read about .NET. I found Jesse Liberty's "Programming C#" (O'Reilly) an excellent read.
  62. I'd have thought that C# is similar enough to java to make that step less useful. If want to learn about the .NET architecture, more than I want to learn the language(s).
  63. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    I can't seem to find info on that. Every book I've seen, except ASP.Net an ADO.NEt, has been very high level.
  64. I can see a possible C# client to J2EE server integration. Swing is too complex for the problem being solved. Sure it is OO, but the performance problems and extra programming involved (is JTable simple and easy?) does not give good ROI. Productivity in Swing means developing your own higher level components. Smaller projects cannot afford to do this.
    Maybe Eclipse toolkit is better?
  65. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    We are using Swing just fine. Is it perfect? No.

    Why I can't C# as a frontend? I have classes that are used client and server-side. I would have to re-write them for the C# client. Also, we send serialized Java objects back and forth. Won't work with C#.

    How will the C# client and Java Client communicate? Web Services you say? Unless you only pass primitives and basic types (String, Integer, etc.) this will not work in complicated systems. You will end up duplicating code. If not, you might as well do HTML clients.
  66. Swing is usable... not.[ Go to top ]

    <>We use swing just fine<>

    Then we can throw out that data point as an outlyer. Don't try to tell me Swing is usable. I know.

    Once we had Galaxy with a true resource model, springs & struts layout technology (and tools), UIs that actually worked cross platform. Java UI has gone backwards since putting Visix out of business.

    The applet is dead so now we try to jam everything into the browser. It's a sad state of affairs and the MS solution will surely not have these problems.

    Right now, Java is for the server.
  67. Me again[ Go to top ]

    Hi Java folks,

    I note the tone is becoming more negative.

    Why write the artical? Because the projects I work on are now starting to move to NT and 2000 servers. I'm currently fine because I went for java - it ports.

    But when I try and sell J2EE, thats the application server and EJB's in almost everyones mind they are all saying 'why?' And its a hard sell when up against an integrated development and client and server as sold by the .Net vision. Coupled with the fact that lots of techies WANT to get into .NET.

    Even within the J2EE community we all use J2EE to mean different things. From patterns to app servers to operating systems - the main message is that it's NOT microsoft and we don't want to run on Microsoft servers. Sometimes we get confused between java and j2ee when we make our arguments.

    I still believe java is wonderful. I have products out and users on Linux, macs and winxx. I have web sites and enterprise systems based on JSP, servlets, JDBC. Others on EJB, some on RMI. I have fat swing clients and I have applets and I have web sites. I even buy into JBOSS and the myriad other Jakarta endeavours.

    So, why am I saying its time to learn .NET. Because, for me, as an architect on mid sized global systems the many and varied J2EE techs are irrelevant in getting a working solution. Indeed the web to mid to back tier is all I need (except for integration, more later). EJB is irrelevant, JNDI is irrelevant, JAAS is irrelevant, JMS and MDB are irrelevant. Look at the complexity of this last paragraph.

    As for data integration. Java has no solution that cannot very easily become SOAP. There are loads of people writing tools for legacy systems to go to soap - because the market will be huge. Capatalism is my barameter.

    Now the other factor is that Microsoft operating systems are pretty stable and PC power is going balistic. Servers for mid sized systems (as per the artical) will not be huge Unix boxes in the long term.

    I saw HP in the early 1990's striving to drive home the total cost of ownership argument. I was on their side, I wanted to remain on unix. What were they talking about? Workstations. Unix workstations. Its now 8 years since I worked anyplace with unix on the desktop. The same argument is starting to be used for these mid sized servers. And I saw Microsoft win in the past. They did it because their tech was adaquate and they did some high level back scratching. End result, PC on the desk top.

    So, what does my paper recommend. Learning about .NET. And learning about it now, because in 2 or 3 years loads of current java/j2ee projects will be .NET. Not all, not the big ones that are still running in C++ and Corba (for instance). No one here has yet disagreed with this prognosis - except for some well argued Linux points. This is a matter of belief, and I currently believe that Microsoft servers will win over linux servers. Thats from my time spent dealing with clients, maybe your clients have a different view point.

    We shall have to wait and see.

    The other point made is that I do not currently know .NET. This is why I wrote it. I have a growing anxiety that J2EE is floundering. I thought this view point would make for an interesting read, and I wanted a debate which could prove me wrong. After all, like most of you, I have invested a huge amount of effort and time in the Java world view.

    Jonathan
  68. Me again[ Go to top ]

    I don't see J2EE as floundering at all - and I have used it in a wide variety of situation involving different aspects of the specifications - from just simple web/database solutions with a porn company to high-end balls-to-the-wall EJB2.0/JMS/JSP solutions with a more reputable company in the cable industry. I had no problem selling it at all. It offers my clients a wide array of platforms, cost structures and support options. Most of my clients won't even consider .NET at this point. Why? For the same reasons as discussed endlessly on other threads. They are well documented. I see J2EE as a very vibrant community - not doomed to despair.

    Cheers
    Ray
  69. Me again[ Go to top ]

    <quote>
    solutions with a porn company to high-end balls-to-the-wall EJB2.0/JMS/JSP solutions
    </quote>

    I suppose the balls-to-the-wall solution was for the porn company?

    --
    Cedric

  70. Me again[ Go to top ]

    <quote>
    I suppose the balls-to-the-wall solution was for the porn company?
    </quote>

    You are so bad. You'll have 5 triples before you par another hole. ;-)

    Bill
  71. I agree, the problem with the J2EE is complexity.

    However, although I'm not an expert, I think that dot net has just as much complexity as the J2EE. Only it is hidden from the developer by dot net studio in the same way VB hid the complexity of MFC. The result is that you can crank out code really quickly, but it is generally pretty bad code.

    That is part of what Microsoft does so well. They suck you by making it easy to get started, but when you try to do something in depth it becomes hard or impossible. By the time you get to the complex project, it's too late. You and everybody else is using a Microsoft solution and you can't go and say to your boss, "I made a mistake, let's switch now". For that reason alone, I think Java will be around for a bit longer at least. That and the fact that Java programmers seems to hate Microsoft just on principal.

    The real problem with the J2EE is that the folks who designed it think that the only tools you need for development are a text editor and a shell prompt.

    An example that comes to mind is with web services. The Java web services pack has something that will automatically generate classes for web service clients and servers. You need to run a command line program (first problem) which generates a bunch of strange looking classes for even a simple hello world service. Right out of the box it is overwhelming. The whole idea of web services is that it is supposed to be easy and they turned it into RMI.

    Apache has a tool called Axis. With Axis you can pretty much take any Java class, add a couple of lines of XML to a config file and it automatically becomes a web service. Writing a client takes a couple of lines of code. I'm sure it is doing the exact same thing, even using the same underlying JAX-RPC classes, but Axis hides almost everything. I think they get it.

    If all the complex J2EE stuff stuff was hidden behind a good tool you wouldn't care how complext it was because you wouldn't have to know about it. Code generators aren't the answer. Computers write really ugly code and nobody want to look at it. The complexity has to be completely hidden by the tool so you don't even know it's there. Microsoft does that well. The Java vendors don't and that's the problem.

    Take a look at the post on The JADE Open Framework or take a look at http://www.salmonllc.com/website/Jsp/vanity/Jade.jsp?nav=5 for more on this.
  72. <quote>
    If all the complex J2EE stuff stuff was hidden behind a good tool you wouldn't care how complext it was because you wouldn't have to know about it. Code generators aren't the answer. Computers write really ugly code and nobody want to look at it. The complexity has to be completely hidden by the tool so you don't even know it's there. Microsoft does that well. The Java vendors don't and that's the problem.
    </quote>

    Yes. I think the plan was for tools to play a significant part in J2EE but the people who implement J2EE aren't very tooly, so there's little help there but it should improve over time.

    For Swing, I see little tool help beyond IDEs generating code. I'm working on a tool call the Visual Resource Editor that should help people use Swing more effectively:

    http://www.geocities.com/gary_keim/vre.html

  73. Me again[ Go to top ]

    <cite>The other point made is that I do not currently know .NET.</cite>

    ... and from your article I get the overpowering impression that you don't know *nix operating systems and their current state of development/advancement neither.

    Sorry, but simply posting controversial crap without a background belongs into *.advocacy-newsgroups on the usenet. If you want to call that mess you put online a "paper", then it should hold substantial information and not only your irrelavant point of view.

    Don't feed the troll!

    Regards, Lars
  74. Me again[ Go to top ]

    Lars,

    I guess you are pro Linux then? Because it is better, and the best technology will win?

    It's a view point many here agree with.

    Do I know operating systems? Unix 16 years (Solaris,HP-UX, AIX, SCO, Susie, RedHat), wintel 15 years (win3.1, 3.3, win95, 98, NT 3.51, 4, win 2000, win XP), OS/2 (1st crap one and the really good v2 for about 2 years), VAX(but I can't remember that), and some ancient uni boxes I can barely remember.

    Ho Hum, flame flame flame.

    Jonathan
  75. Me again[ Go to top ]

    <cite>I guess you are pro Linux then? Because it is better, and the best technology will win?</cite>

    I am not pro Linux, but "pro choice". As the OS is the layer between my software and the hardware, I don't want to end up bound to one specific OS. (That's why I use Java for most of my programming work, anyway).

    <cite>Do I know operating systems?</cite>

    That's not my point. My point is, do you know which OS is best in which usecase? If so, why don't you use this knowledge in your "comparison"?

    In my posting, the OS thing was just a side issue to illustrate that you are not able to provide hard facts. You postulate, but that's it. (And what your irrelevant rantings about *nixes have got to do with J2EE remains a complete mystery to me, still.) But even when people ask for further information supporting your point of view, all you are able to do is sulk and pretend to be attacked personally ("Me again" - no, it is not you, but your article).

    Your behavior does not lead to a scientific discussion, just to the impression that you are trolling.

    Bye, Lars
  76. Me again[ Go to top ]

    Lars,

    My entire article is about the future. The choice of OS given a mid size enterprise system. These are systems that typically run with a single database server, which may also run the mid and web tiers. In my experience only corp. standards will stop them running on a single server. i.e. you have maybe 50 concurrent (that is simultaneous requests, not sessions) - so a single Unix box can cope with web and mid and db layers.

    If you have 1000 concurrent users the architecture changes. You can use web farms, but probably still have a single db box, but probably have caching etc nearer the client side. Even in a fat client say.

    So, given my scenario, of mid size global projects what are the OS choices? Currently Unix, Linux, win2K, XP...

    You would select what in these conditions?
    Now increase PC performance to 8GHz. Which is now your choice? I'm guess you would say Linux is the most appropriate, for such mid sized enterprise systems.

    I believe many corporations will in fact select wintel. No doubt you will continue to disagree, which is fine. But what argument do you have other than a dislike of Microsoft? I guess you would mention security and stability - I recon the recent Microsoft servers are good enough, and they continue to improve the server offerings. Both op systems will do the job, the cost is irrelevant to the companies I work for - as pointed out by a previous response. With wintel I get single sign on and a close coupling with user tools.

    I think we have reached a point of 'agree to disagree'. Maybe not us personally, but me v's the linux advocates.

    Jonathan
  77. J2EE Complex... Nope.[ Go to top ]

    When ever I see anything written about J2EE its always described as being too complex.

    J2EE comprises a number of different technologies, which prior to the J2EE spec would have required learning lots of different propriortory API's.

    In my mind J2EE has simplified so much of what programmers do now. In some of the projects I have worked on we have been able to have programmers with various levels of expertise working on different elements of the application without much effort at all. Senior developers were able to concentrate their efforts on the overall design of the application/scability issues/etc etc. Whilst junior developer concentrated on the client/JSP end utilising the EJB elements developed by the senior programmers.

    EJB has simplified the task of interacting with a database so much that new programmers would hardly be aware they were using one it at all.

    I think .net is a significant development, and one that has been required for a very long time. However I think that given this technology is still in its infancy and that J2ME and other technologies are becoming defacto standards it is too early to speculate that microsoft has won.

    I think Java has a very rosy future and given the amount of open source developments and other things like the ongoing microsoft trial it seem wierd to me that people are jumping ship or proclaiming javas end.

    my 2cents...
    qwam.
  78. Are you kidding?[ Go to top ]

    Johnathan

    I too am an architect for a company producing mid sized systems. Our company does both J2EE and .Net work and I do not agree with you conclusions at all.

    "So, why am I saying its time to learn .NET. Because, for me, as an architect on mid sized global systems the many and varied J2EE techs are irrelevant in getting a working solution. Indeed the web to mid to back tier is all I need (except for integration, more later). EJB is irrelevant, JNDI is irrelevant, JAAS is irrelevant, JMS and MDB are irrelevant. Look at the complexity of this last paragraph."

    Uhm, a system can be J2EE without using EJB, JAAS,JMS or MDB. JNDI is irrelevant? How? How are any of these technologies irrelevant? You make a bold statement and give no proof, or even examples. If the design and architecture of your system does not call for the use of any of the above, why would you use them? It doesn't sound like your a very good architect...

    "But when I try and sell J2EE, thats the application server and EJB's in almost everyones mind they are all saying 'why?' And its a hard sell when up against an integrated development and client and server as sold by the .Net vision. Coupled with the fact that lots of techies WANT to get into .NET. "

    Who are you trying to "sell J2EE" to? Customers? Customers generally only care that the system meets their requirements (you know about the Requirements definition phase, right?). They may only care about technolgy in that it fits into there current system and is maintainable. So a unix shop today WILL NOT become a Windows shop tommorow no matter what YOU think of the stablility of Windows (and Security of the OS is more importaint nowadays than stability). The vice-versa is pretty much true as well, although in my market a fair number of businesses and government departments are switching to *nix away from Windows because of security concerns.

    Are you selling to your own management? How is paying through the nose for an environment tied solely to one platform (and don't bring up Mono et al, they are not even close to production or a full .Net port)with NO competing products good for business?

    Integrated environments? Websphere Studio and Websphere, Webgain and HP Bluestone (used to be anyway), JDeveloper and 9iAS, Netbeans/Forte and anything, anything and JBoss? Thelist goes on. And these environments are cross-platform.

    "Techies" want to learn .Net? Well since when is this a selling point for anything in business? Besided it has been my experience at my company that the only "techies" learning .Net are old VB/Interdev hacks or Java programmers looking to "know your enemy, know yourself and in a hundred battles you shall not loose." I have never had a hard time selling various degrees of J2EE to anyone that needs selling to (JSP-Sevlet-JDO or JSP-Servlet-EJB or Swing -Session-Entity, I've done them all and their all J2EE). Again, if you don't need JAAS,EJB etc, don't use it.

    "This is a matter of belief, and I currently believe that Microsoft servers will win over linux servers. Thats from my time spent dealing with clients, maybe your clients have a different view point. "

    Your belief is based on what, exactly? Your clients do what exactly? If all my clients we small companies sucking in by the MS marketing machine or my company was an MS patner (which it is BTW) forced to tow the MS line (which it sometimes has to do), I might believe that FUD as well. But luckily, many of my clients know enough to make a choice and choose accordingly (yes, sometimes they even choose and all MS solution, becasue that's what they want or know...but at least they have had the chance to choose).

    "The other point made is that I do not currently know .NET. This is why I wrote it. I have a growing anxiety that J2EE is floundering. I thought this view point would make for an interesting read, and I wanted a debate which could prove me wrong."

    Well I think myself and others have made some good points in regard to J2EE v .Net. the reality is that they will co-exist and probably (due to web services) interoperate. I think your anxiety is missplaced. J2EE is not floundering. The skills of good requiremments gathering, analysis and design and coding practices are what is floundering. Too many so-called "architects" rely on technology and frameworks as the "quick-fix" or "silver-bullet" answer to all their problems, using them blindly without regard to proper analysis and design. And when things go wrong or don't work quite right or aren't easy in all situations, they blame the framework, no the application design. With a good design and coding practices, a developer can create a good application in almost any technology or framework.

    It is a poor worker that blames the tools.

    Mike
  79. J2EE floundering? Not according to a recent study:

    http://www.csiro.au/index.asp?type=mediaRelease&id=EnterpriseJavaBeans

    "J2EE has been widely adopted, with an annual market growth rate of around 40%".
  80. Swing is usable... not.[ Go to top ]


    >> Don't try to tell me Swing is usable.

    Funny, but we have managed to develop quite good applications in Swing (not me personally - but we have good ui developers and they like swing). While the performance is definitely not like a native app, it is very easy to program and you get a *reliable* & *maintainable* solution. Agreed - it does take more work to make it sharp and snappy, but in an environment where you have to deliver functionality quickly, its quite effective.

    In comparison:
    -MFC is a *%!@ing nightmare (I am back to writing some at the moment).
    -JFace (SWT's Swing equivilent) is just a port of Win32 (even right down to the hungarian notation that M$ are fond of! I wonder if they used a code generator.)
    -C# Winforms are a thin veneer over win32 as well (you dont have to scratch too deeply to find the smelly stuff)

    We also use Java WebStart - I think its a great tool. It means an end to SMS headaches. It has all the benefits of applets without the limitations. (and there are some good commercial implementations as well - e.g. Sitraka have Deploy Director)

    I think, that until M$ have a competitor for Java WebStart, even Java on the client has some very strong benefits. If only the performance was better - then we wouldnt even be wasting bandwidth with this sort of discussion.

    As for the serverside, .NET is a long, long way from equalling J2EE. .NET is more like J2SE at the moment - they have a managed run-time and some standard libraries but (apart from ASP.NET) thats it. Until they have a decent Appserver, you are back to writing your own servers or taking a step back into the MTS junk.

    Until they address integration issues (*real* integration - not just a dash of XML-RPC), .NET will have an uphill struggle on the serverside. Integration is *the* issue faced by most IT departments. And Non-intrusive integration is a key criteria.

    What really gets on my tits about these "J2EE is so complex" arguments is that enterprise applications are by their nature complex. Does not using J2EE and implementing everything yourself remove the complexity??? No, it just swaps learning a mature wheel for reinventing a new one!

    -Nick

  81. Swing is usable... not.[ Go to top ]



    In fact (having a 2nd bite at this), I think perhaps the problem (of this negativity and perception of over-complexity) is that we have become accustomed to Java/J2EE and are starting to take benefits for granted.

    For therapy, I would suggest trying to implement the same stuff on another platform. Its a good good experience to keep your feet on the ground.

    The reason I say this is that at this very moment, I am having to do a bit of MFC C++ programming. As painful as it has been, I think its been good for me.

    I have a renewed appreciation for what Java / J2EE gives us after wrestling with that junk. By junk, I mean C++, the pre .net M$ platform and its dearth of open-source, free implementations & tools (try finding a decent pre-.net C++ soap implementation!).

    -Nick
  82. Swing is usable... not.[ Go to top ]

    Don't try to tell me Swing is usable. I know.


    Let's see. It is usable to us and many others. It is not to you. That only leaves - you didn't know what you are doing.

    Want to MVC (and you should) in VB - not gonna happen. How about .Net? Its there but you have to do ALOT of work yourself.
  83. Swing is usable... not.[ Go to top ]

    <quote>
    >Don't try to tell me Swing is usable. I know.

    Let's see. It is usable to us and many others. It is not to you. That only leaves - you didn't know what you are doing.
    </quote>

    I don't feel the need to defend myself but I will defend my point.

    _ take a look at Sun's J2EE RI deployment tool. Note how badly it's laid out, how klunkly it looks & feels, how the data in the tables doesn't fill the available space. You'd think that if anyone could figure out Swing it would be Sun!

    _ a friend of mine who's shop was moving from MS to Java wrote me to say his guys couldn't figure out how to have a JTable with multiple column headings. I told them to change their design as they would have to waste alot of time and money trying to get it done.

    _ many others I won't bother everyone with.

    Of course throwing a textfield and a button onto a panel is easy. It's when you need more than Hello World! that things get hard.

    I'm done.

  84. Swing is usable... not.[ Go to top ]

    FUD Alert!!!!

    When I see lame postings like the following:

    >> Of course throwing a textfield and a button onto a
    >> panel is easy. It's when you need more than
    >> Hello World! that things get hard.

    that leads me to suspect that Microsoft is launching a propaganda attack against J2EE on this forum.

    Everyone who use Swing knows that it is superior to anything that Micro$oft has and Swing is easy to use.

    I have used Swing since it first came out and I know that the posting I mentioned above is an outright lie.
  85. OK, Swing is not _very_ usable.[ Go to top ]

    /* that leads me to suspect that Microsoft is launching a /* propaganda attack against J2EE on this forum.

    Just because one doesn't think everything smells of wine and roses in Swing-land doesn't imply that person is evil!

    I'm just saying that anyone who has every tried to do anything complicated in Swing has pulled out many a hair. If you have a full mane, good on 'ya, mate!

    My title line is unfair. Swing is not UNusable it's just not VERY usable. You just shouldn't have to write code to setup and manage a UI. That's what tools are for.

    Oh, yeah: J2EE is GRRREAT! ... and a little complicated. ;^)






  86. Swing is usable... not.[ Go to top ]

    Swing definitely has problems. But I disagree with people who write it off as unworkable.

    Here are three points about why rich clients may have problems, above and beyond the usability of Swing:

    1) In my (limited) experience part of the problem is resourcing: senior developers tend (usually) to prefer 'interesting' server-side work and the gui is often considered lower-status and left to junior developers.

    2) If you are not doing complex things on your user interface, there's no point using a rich client. If you are doing complex things then a good, well designed GUI is a challenge (in any language) because event-driven programming automatically means threading issues, and threading issues are always a problem. MVC helps (a lot), but doesn't solve everything. [This, btw, is my main gripe with Swing - the support for threading. Are C# clients better off?]

    3) Likewise (in my experience) client-side infrastructure is just as hard to build as server-side infrastructure. Consider, eg, logging of runtime exceptions (which may be generated in an event thread), or the need for client-side caching, or automatic enablement/disablement of components because of security. But these hard issues seem to get less attention than server-side infrastructure (because client coding has less status??? because these issues are harder??? I don't know.)

    I'd be interested to read replies from people with different experiences, especially building complex guis for rapid data entry (by complex I mean multi-modal entry, multiple views on the same data, interesting security, self-validating fields, etc).

    Sean
  87. Swing is usable... not.[ Go to top ]

    Hi Sean,

    In my experience swing is pretty easy to code in. And you can create great GUI's if you put the effort in. Javasoft kind of stopped work on it for a while because the server side infrastructures were becoming so huge.

    I have written three or four big java projects with complex clients and done my fair share of the GUI - in awt and then swing. Prior to this was X-windows/Motif and even some MFC.

    The real problem is the competition between applets and applications. Applets are brilliant as a s/w model. Centrally maintained, easily upgraded, etc etc. Problem is getting the JVM on the client, or the correct JRE. Also issues with browser version and so on. So you give up on applets and go to applications. Swing applications running on wintel did not compare well - glitching on repaint and so on were normal up until the last 12 months.

    I guess loads of people tried java applications over the last 5 years with complex guis and were not happy, so moved to web front ends. So java gui's kinda stalled.

    Taking a snap shot now I'd say the recent swing GUI's coming out of IDE vendors are very good. Will this mean java starts to get used for fat clients again, doubt it. Whats the best visual development environment?

    Jonathan
  88. Surely its the price of the available third party Swing components that goes a long way to killing the opportunity for Java GUI.

    It's quite a shock to compare the prices for equivalent GUI components in say the Delphi, VB and Java Swing GUI markets.

    Is it simply greed?

    Lack of competition and high prices equate to entry barriers that Swing needs to break down.
  89. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Yeah, free is bad.
  90. There are existing bridging technologies that it straightforward to have a C# rich client integrate with a J2EE app server. See www.jnbridge.com for an example of such a product.
  91. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    someone may have already replied to this but I found .NET Framework Essentials - an O'Reilly book by Thuan Thai and Hoang Q. Lam to be clear, concise and informative. I doesn't really compare the 2 but it gives you all the basic info, so you can draw your own conclusions.
  92. I agree with the thick GUI demands for in house business applications. Computer operators are mousy people, they operate key boards faster than naviagting a web site. They need thicker controls. J2EE could have spent time maturing Applet type technologies and mixing it with Web Services to accomplish the same type of architecture.

    UNIX still has a place in mid-sized projects. If a company has 6 mid-ranged rollouts each with a 2000 user base, running them all on one UNIX box reduces the total cost of ownership and makes administration easier. Using windows, each Application has to run on its own box.

    Web Services is meant to address application integration, not data integration. .NET currently doesn't have much of a solution to integrating with Mainframe applications. Compiling COBOL into .NET is unrealistic. Integrating with non-relational data stores such as IMS and VSAM files is still very much a reality. Integrating with CICS and MQSeries is very much a relaity and will be for a very long time.
  93. One other comment, any architect can make any language or any framework or any platform complex or simple. C# is similar to java, developers will make the same mistakes.

    .NET also includes MSMQ (JMS), MTS(EJB Container), VB.NET(which language should I use?), ASP.NEt(JSP), ADO.NET(Persistence), etc... I can probably make a pretty complex system if I designed that way.

    J2EE can be very simple if applied write. Don't confuse architecture overanalysis with platforms defiency. Visual Basic simplicity proved that real problems needed to be addressed with MFC. The layers added to J2EE stems from real world problems that needed to be solved. Specifically integration. C# will not solve problems anymore than Java, it's what you do with it.
  94. Re: Thicker clients, I agree. And Sun is addressing this need, although in a typically ham-handed manner, with Java Web Start. I'm thinking that JWS coupled with EJB's running on a J2EE server could be a decent app architecture: you get the thick client plus the benefits of server side programming.

    But I'd be lying if I said I don't have a sinking feeling that M$ is on to the thick-app problem and will have a kick-ass toolset available for it in the next few years....

    Cheers,
    carsongross
  95. Have you heard of Macromedia Flash Remoting? If there is a more attractive client than Flash I don't know what it is. I think as this product becomes more stable it will take care of the thick client side app and it integrates with Microsoft and J2EE.

    Has anyone here looked into the Apple Unix servers? I'm a long time fan of Apple and with a Unix backend I think they really have a nice combo going.
  96. .NET and integration?[ Go to top ]


    Roland Barcia said

    >>Web Services is meant to address application integration, not
    data integration. .NET currently doesn't have much of a solution
    to integrating with Mainframe applications. Compiling COBOL into
    .NET is unrealistic. Integrating with non-relational data stores
    such as IMS and VSAM files is still very much a
    reality. Integrating with CICS and MQSeries is very much a
    relaity and will be for a very long time.

    <vendor>

    At this point, the industry's collective best guess is that Web services is the interop protocol every system
    will use, in the long-term. But you rightly point out that web
    services interfaces are not yet available for most systems,
    today. So, interop via existing protocols and APIs remains an
    important requirement.

    I have examples that show .NET apps connecting to MQSeries
    queues. <a
    title="link to gotdotnet.com" href="http://www.gotdotnet.com/userarea/keywordsrch.aspx?keyword=MQ">
    The first </a> is a C# console app, it shows interop with the MQAX layer, a COM layer for
    MQ that IBM has shipped since MQ v5.1. Building this requires
    the .NET SDK (the command line tools - free d/l from <A
    href="msdn.microsoft.com/nethttp://msdn.microsoft.com/net">msdn.microsoft.com/net>,
    but you can look at the code and makefiles without the SDK.


    <a
    title="link to zipfile" href="The" rel="nofollow">http://hosting.msugs.ch/cheeso9/dl/amqsailq.NET.zip">The
    second example</a>
    is a VB.NET Windows Forms app - it is a Visual
     Studio .NET solution, and utilizes
    the p/invoke capability of .NET to call into the MQ dlls. Again
    you can view the source, but to build the thing you need
    VS.NET. This latter app was produced by taking the amqsailq
    sample that IBM ships with MQ - and running it through the
    VS.NET upgrade wizard.

    There are a few fully-managed .NET drivers for backend systems
    (the java analog to fully-managed is "100% java"): Data Direct
    has some .NET drivers for Oracle and other databases. And
    there's at least one ADO.NET stack for mySQL. (sorry I don't
    know the link) But even without a fully-managed connector, there
    are many options for connecting via interop solutions. COM
    interop and platform invocation both work and they work well -
    so you can connect to just about anything that exposes a COM
    interface. This includes CICS, TIBCO, MQ, IMS, SAP, Siebel, and
    many other systems, both large and small packaged apps.

    Even the Microsoft Commerce Server objects - they are now
    exposed via COM interop and can be used fully supported by .NET
    apps.

    There is a non-zero cost associated to interop, but it is
    o(1000) instructions, rather than o(10) instructions for fully
    managed. So the cost of the interop layer will be insignificant
    with the actual work that happens on the other end of the
    wire. Effectively unmeasurable for real apps.

    </vendor>



    and
    Paul Done said

    >>Also on the point of mapping data structures between disparate
    systems, the winning technology would probably need to provide
    productive transformation tools to enable users to visually
    cross-reference different schemas (maybe based on XML and XPath)
    plus some sort of process management tool to help visually
    construct the interaction between these disparate systems.

    <vendor>

    This more elaborate solution is the goal of Microsoft's BizTalk
    Server, and tools. It is possible to design business processes
    that interconnect with disparate external systems. There are
    100+ of "adapters" available, some from MS and some from 3rd
    parties. And the biz process itself can be exposed as a callable
    web service (callable from anywhere, eg AXIS, GLUE, .NET, or
    something else).

    </vendor>

    -dpc
  97. Hi.

    I agree that internal and work intensive applications need "thick" (or "fit") clients.

    I see a trend, and I would like to hear from others: Swing is (still) too slow and too complex. Therefore I have seen Visual Basic and Borland Delphi used as clients - communicating with a BEA WebLogic Application server through SOAP/XML. In my next project, it has been decided to use PowerBuilder 8. The performance is OK, and all the advantages from the GUI tools are preserved.

    Regards
    Glenn, Iocore Consulting
  98. Opinion: Java and thick clients[ Go to top ]

    As has been discussed - Swing works great for many. Is not slow or complex for them.

    As for using other tools as clients - you will probably end up duplicating code in each language even with web services if ... any business logic is involved, doing alot of extra work to get around it or just leaving something important/useful out.

    I've done VB frontends with Java backends and Java frontends with VB backends. I also have applications that have Java front and backends. The best one and the best use of code was the all Java one. The Java one actually uses some Applet front ends (Swing), some 'Application' front ends (Bat file/Webstart type) and a few minor JSPs (Report type - which HTML was made for). We were using all applets but we needed to use Function keys for some of them and IE decided he was going to reserve a few. So, like in an hour, we switched from Applets to 'Applications' on a few. Also, at least one of our applets uses, on the client, the exact some code all the 'applications' use on the server. And ALL the applications/applets share code between the server and client. If I did this with a C# frontend and a Java backend I would have to maintain two sets of the same code. Toss in a few JSPs and make it three.

  99. Opinion: Java and thick clients[ Go to top ]

    Glenn,

    "a little off topic, but"

    I'm curious on the details of how you use PB for the UI with a J2EE backend. Obviously the strength PB is the datawindow (what an awsome programming feat). So what is the plumbing you are using between the datawindow and the J2EE backend?

    Note: I haven't used PB since PB 6.5.

    Mike
  100. Opinion: Java and thick clients[ Go to top ]

    <quote>
    I'm curious on the details of how you use PB for the UI with a J2EE backend. Obviously the strength PB is the datawindow (what an awsome programming feat). So what is the plumbing you are using between the datawindow and the J2EE backend?
    </quote>

    Sybase's EA Server (as you would expect) coupled with functionality in Powerbuilder (esp. v 8) works pretty well. We use it for publishing powerbuilder reports (this has worked since 3.6.X) but are planning on further development work.
    Cheers
    Ray
  101. So what is the plumbing you are using between the datawindow and the J2EE backend?

    PB can "speak" CORBA.
    If you would use Sybase EAServer (Jaguar) it's very simple:
    from AppServer you convert java.sql.ResultSet to TabularResultSet (CORBA object, I believe Sybase made it OpenSource) and pass to PowerBuilder client and then convert it to datastore. Similar way to send data to AppServer from PB. just few lines of code.
    There is company Cynergy Systems wich enables PB to connect to any AppServer using WebSevices. The next version (PB9) will support WebLogic, WebSphere, WebSevices, XML etc. So PB now is not your grandfather's PB :)
  102. import java.goodpoints.*;

    I liked your article, but I think the main thing you miss
    is that most businesses are driven by COST. And from the
    operating system, thru the development and testing tools,
    the application server and to the database,
    M$ still costs an arm and a leg.

    You can build and deploy a scaleable J2EE system
    for NOTHING! Try running that past your manager when you
    next have to present a .Net architecture!
  103. Hey C Scudds,
    I think that cost factor understood as platform (J2EE or .NET), hardware or software tools (IDE) is pretty much irrelevant. Usually for enterptise scale projects it represents a miniscule percentage of overall budget. In organization I work for the small project budget is around $1e6, a typical project is $1e7. They do both J2EE and .NET projects and in high management meetings cost of software comparision is never raised.
  104. J2EE doesn't imply that you must use EJBs in order to accomplish your task nor does it imply that you must use every bit of the technology in order to deliver the solution. The key to success with any technology is knowing what is relevant for your solution and sticking to that subset of the technology. Otherwise, you end up with a complex mess of nothing more than buzzword-compliant software.

    BTW, if all you really want to do is promote .Net solutions, pick another website!
  105. I think the author is completly wrong to suggest that Thick clients in C# with J2EE as server side solution would be a way in future. Yes I agree that PC base is huge and Microsoft is trying to leverage that base but this same huge base is a problem for them against Justice Department of different States in US. Today we have one government tomorrow there will be different government in US and then they might have legal problems again. Under this scenario how many IT Managers will have stable system with C# sharp as front end and J2EE as server side option?
  106. I always try to be marketable and so MS.Net is on my list of things to learn (better).

    That being said I think you are missing some main points.

    While XP is better than previous versions, although I have heard different, it is more bloated than ever. Linux helps to avoid the "MS Tax" and that is driving acceptance. Also Linux is starting to take off. .Net is quite a ways off from being viable on Linux and enterprise apps will more than likely not be and easy conversion.

    Have you used VS.Net? I have. I've used MS Tools for years. They are cool on the surface but dig down and really try to do something - Many times Java gets the job done better and is easier. I can understand your consternation with EJBs. But what can be done with MS.Net can be done and is being done with Java. You just might have to look around. And that is usually a good thing.

    Are there cool things in MS.Net that I would like to see in Java? Sure. But the opposite is true too.

    I don't understand why you think MS.Net is going to be better at solving complex problems (It isn't). What it seems is that you need to choose better Java tools and techniques.
  107. Case in point[ Go to top ]

    http://www.ecommercetimes.com/perl/story/18404.html
  108. <Roland>
    Integrating with non-relational data stores such as IMS and VSAM files is still very much a reality. Integrating with CICS and MQSeries is very much a reality and will be for a very long time.
    </Roland>

    Excellent point.

    Integration is a very real thing that most serious developers deal with on a day to day basis. I wish my only problem was making web pages and accessing a database and some business rules as described in this white-paper.

    Where does Microsoft fit into the whole legacy integration market? Is the author of this article expecting me to put a web service in front of every system I have in my enterprise? Or even better a BizTalk server?

    Again I am reading another white paper with such a small view of the needs of the community who is using J2EE. The paper seems like another disgruntled consultant who is ready to jump ship. The paper makes no mention of JCA and other excellent Java technologies that make very REAL WORLD problems extremely manageable.

    I am not a huge supporter of EJB and agree there are many things that need to improve. But I also recognize that EJB is tackling a very complex problem that many “web developers” never deal with. (Cedric covered this in another thread.)

    If all you need to do is some web interfaces, some basic business logic that access a database go download a copy of PHP or AOLServer.

    If you need to interact with TUX, MQ, CICS, IMS, or one of the many technologies don't fool yourself and think .NET is going to solve these VERY REAL problems.

    Oh what a wonderful world it would be if all my applications were only three big square boxes with the words “WEB tier”, “Mid tier” and “Data store(s)” all connected with bi-directional arrows.
  109. <quote>
    Where does Microsoft fit into the whole legacy integration market? Is the author of this article expecting me to put a web service in front of every system I have in my enterprise? Or even better a BizTalk server?
    </quote>

    Host Integration Server does legacy integration. It supports CICS, IMS, MQSeries, etc... :
    http://www.microsoft.com/catalog/display.asp?site=10419&subid=22&pg=2

    Services For Unix (SFU) does Unix/Windows integration :
    http://www.microsoft.com/catalog/display.asp?subid=22&site=11269&x=49&y=7

    ... and, you named it, Biztalk Server 2002 does process orchestration, has lots of connectors and adapters, and supports XML Web Services :
    http://www.microsoft.com/catalog/display.asp?subid=22&site=11285&x=25&y=11

    What more do u need ?



  110. Although I don't fully agree with the conclusions presented by Mr. Gibbons, he does make at least one valid point.

    While I am a very big Java fanatic and while I don't see .NET being a Java killer (and I'm also sick of people saying that Java is dead because Microsoft doesn't support it anymore), we'd all be naive to think that Java will live forever. Hopefully it will, but realistically...

    I think that it would behoove everyone (even the .NET folks) to study topics outside of their core interests and field. As a Java developer, I spend the bulk of my self-development in Java-related technologies. But, I also recognize the value in learning other stuff (including .NET).

    So, even though I don't expect .NET to displace Java anytime soon, it certainly won't hurt any of us to pick up a .NET book and learn a little bit about it.
  111. Picking up a book on .NET and reading it would be a good thing for any senior developer/architect. After all, a good architect is supposed to be able to intelligently talk about and evaluate different platforms, languages, solutions, etc, etc and pick a combo that provides an optimal solution for the problem at hand. So on that point, I agree that even the strongest Java supporters should know something about .NET

    On the other hand, I don't think .NET will replace Java any time soon...this article sounds more like a marketing brochure than anything else....I have looked at .NET, C#...the two are not any more easier than Java and J2EE in general.
  112. <quote>
    If all you need to do is some web interfaces, some basic business logic that access a database go download a copy of PHP or AOLServer.
    </quote>

    In my opionion j2ee is perfectly suited for this kind of thing
    j2ee != ejb

    I'll would try to avoid using ejb at any cost, it just takes to much time to get things done.

    Nowadays for this type of basic stuff i use object/relational bridge's object broker because it is S-I-M-P-L-E with plain servlets/jsp using the webwork framework, wich is very easy to use aswell. I don't use ANT (just adds a lot more work / stuff to learn) and use IDEA to compile directly into the WEB-INF/classes dir. and be just about as productive as any php hacker (while producing neater / more maintable code)

    Sites like the serverside put a lot of emphasis on large enterprise systems and large developement groups, that really require EJB's, ant etc so a lot of people asume they should be using this "crap" to build their systems.

    There's a lot of nice stuff once you look past the ejb bloat
    If people don't IMHO j2ee is likely to end up like corba

  113. Why do so many people put down EJBs? Which version are you talking about? With EJB 2.0, one can utilize EJB even for smaller web applications! I'll quote from Caucho Resin's web site:

    The following is from http://www.caucho.com/resin-ee/ejb-tut/cmp-intro.xtp -->
    "CMP is for small database applications, too
    With the addition of local interfaces, EJB is now suitable for all web applications from simple weblogs to huge financial applications. The preconception that EJB is for large systems is due in part to application server vendor marketing, in part due to journalists, and in part due to the initial distributed object focus of EJB.

    Vendors and journalists are impressed with large configurations. The mega-applications are impressive: amazon.com, eBay and Schwab's web trading are a big deal. The vast majority of sites are much smaller and don't have the same requirements as the mega-sites. In particular, the most sites have no need for distributed objects. Many sites, in fact, only need a single web server.

    Since many projects fail because of overdesign, good engineers design small, elegant solutions. Since most web applications don't need distributed objects, a good engineer will avoid adding the extra complexity just because journalist writes a breathless article describing a huge distributed object solution."

    We've just started utilizing EJB 2.0 and CMP in our current web application and it is really simplifying development, due to the fact that we don't have to think in such low terms as JDBC raw calls... No PreparedStatements, ResultSets, etc. Just pure CMP Entity beans that we can manipulate on a more OO-level. We are also wrapping our CMP Entity beans with session beans, and this is working out fine. On top of all of this, we are utilizing the MVC design pattern. I don't see why people complain so much about EJBs, because it has been my experience that CMP Entity beans actually facilitate and simplify writing J2EE applications. All of my beans use local component interfaces, because this application is not going to be accessed from "remote clients". All of the components will be running within the same application server. So this is basically our architecture:

    View --> JSPs
    Model --> EJBs (Entity Beans)
    Controller --> Servlets (which in turn access Session beans that perform business logic with the entity beans).

    I mainly wanted to utilize EJB in this project to simply learn the concepts, and it has been my experience that using EJB in this particular project (which does not require distributed transactions across multiple databases, etc.) to be quite helpful. I would be interested in hearing from others about this also.

    Ryan LeCompte
  114. From the author's website:

    Jonathan Gibbons Website
    So now I have ordered .NET studio, and I'm waiting for it to arrive. I shall publish my experience with this learning excercise, I wonder if it will live up to be expectations, which are currently that it is at least as good as Java.
    Jonathan Gibbons Website

    How can you expect us to take your "professional" comments about .NET seriously? You outline several reasons for the technology's success over J2EE and you haven't even installed .NET Studio.

    You are telling us to learn .NET because Java is going to be oblivious. It really feels like you are looking for some friends to get on the ark that you are trying to build against Java/J2EE... But none of us seem to see the storm you are describing coming...
  115. I appreciate the experience of Mr. Jonathon Gibbons
    though I have just 4 yrs of experience in this field,
    but I feel he has been slightly carried away by the gimmick
    of .NET and J2EE comparisons.
    Both these technologies are here to stay.
    Dont we all remember how C++ programmers were scared about their jobs and skill set when JAVA was introduced in the market. I dont think C++ was washed of, so much that it was hyped at that point of time.
    Any new technology comes for a reason but the lack of understanding its usage creates hype.

    I dont think Mr. Gibbons has actually made an effort to think how the concept of webservices will see to it that both these technologies can coexist. Today you can search on google through email, convert files to pdf format through email webservices.

    My view is Linux is obviously here to stay, there is no need to get paranoid and look for a skill set switch.
    And ofcourse Client is the GOD, the platform he chooses, we developers got to build for them.

    Rgds,
    Balaji Iyer


  116. 1.
    in addition to previous post:
    [quote]
    So now I have ordered .NET studio, and I'm waiting for it to arrive. I shall publish my experience with this learning excercise, I wonder if it will live up to be expectations, which are currently that it is at least as good as Java.
    [/quote]

    Jonathan,

    I found myself doing the same thing when it comes to Microsoft. Their marketing and delivery are great but you shouldn't believe it until you see the whole picture. So "try it before you buy it."

    2. TCO/ROI etc: You will quickly realize that the power of .NET is going all out Microsoft: OS , RDBMS, App server, Tools. And as you can see it starts to add up in licensing fees.

    Plus, the cost of retraining legacy(VB,COBOL,RPG) developers to .NET is high.

    Plus with .NET, you are buying from the company notorious for "leveraging its market share." And to me it's like sticking your head into the gator's jaws.

    3. "Developers want to learn .NET"
    Sure, I want to learn everything new that comes out that will make my job easier and myself more productive. If I could, I'd sit around and do nothing but learn new stuff. A lot of developers are dabbling with C# but it doesn't make business sense to redo your legacy (VB,C++) apps in it. Plus if you are hard core VB developer, you've already been transitioning in to VB.NET but not C# just beacuse of the learning curve. So look at it from the managers point of view in the shop thats already sold on DNA/.NET:"I can jump on .NET wagon and upgrade my developers to VB.NET rather than wait a couple of years unitl they are proficient in C#"

    As you are seeing the move to 2000/XP - .NET, I'm seeing the move to Linux/J2EE. With the latter, you invest into your business saving licensing fees and fostering your developers.
  117. I would like to apply the 90/10 rule here WRT choosing J2EE vs .NET: i.e., 90% of all projects are medium to small in scale and they don't need J2EE if the developer teams do not have the necessary skills. The other 10% are large, enterprise-level, transaction-oriented, legacy-system- interfacing (only needed by Global 100 financial services and telecom companies), and J2EE is a much better solution there.

    I doubt we will come to a conclusion in this discussion because each of us have a unique background and therefore perspective. The J2EE gurus here are obviously those who have been working for companies like Wall Street firms for > 10 years, and to them J2EE is not complex at all (when you start to think about other alternatives). For the majority of the "serversiders" whom I believe fall under the junior to intermediate-level developer categories (probably another 90/10 split here) and who are working for small cap companies or smaller projects inside big companies, J2EE looks complex and M$FT's technologies look attractive and competitive. So who do you listen to? We need experienced, unbiased software architects who can make wise recommendations and managers who are ready to listen and can make decisions based on technical merits, not politics.

  118. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Given the problems associated with software distribution, I still don't see how a thick-client paradigm could fly with large-scale systems. Regarding MS stability, there still are a large number of decision makers who grew up seeing an instable Windows OS. I'd be surprised if MS can convince them to switch from Unix based systems. Even if they do, .NET needs to prove itself beyond the advantages of pretty GUIs and low developer-skill-level.
  119. Hi,

    When .NET was in later beta and in the RC stages I tried it out to see how it compared to Java/JSP for building smallish applications. I actually rebuilt a Java/JSP/Bean based web-app with ASP.net and C#.

    My intial impressions where very favorable to ASP.net and C# and the whole .NET offering. VisualStudio.NET is a very nice IDE and code editor. I found that the web gui tools, state persistence mechanisms and other aspect of ASP.net to be nice and saved time. Their use of a 'code-behind' files to keep the gui and the logic apart was also kinda nice. In the end I realised that all those nice things that I liked in ASP.net are easily reproduced in Java/JSP without the vendor lock.

    In the end, to build the same application with ASP.net did not offer any major speed advantage over JSP/Java dispite the fact thar VS.net can probably prepare sushi for you. (I think it is in one of the wizards?)

    But I did pick up some ideas from VS.net and Asp.net having implemented them into my JSP work. Ok, it took me a day to do it but now I have the components that I just drop into my projects.

    I only develop smallish web-apps and have no experience with Enterprise level projects. I don't think C# based thick clients are going to kill for at least a little while. I have seen at least a couple major banks that still run Nt4 - service pack4 and have no plans of upgrading. I somehow doubt that their network guys (who avoid work like the plague)will want to install the .NET runtime on the workstations so as to be able to run C# thick clients.

    Anyway, for many applications the webbrowser works fine.

    Stef

  120. Have to say the user has no idea about Java. In real world .Net is dead. Try Java and it will open your eyes. .Net is more piece of crap like VB and hell ya >net damn confusing like hell.
  121. One thing I have started to suspect is that Microsoft's huge $$ may be applied to more insidious marketing channels than we may at first recognize.

    Not all .NET advertising will come from slick magazine ads. Some will come from individuals we respect that may have been paid to evangelize from a channel we don't expect - like a post to theserverside.com. In a similar vein, I've seen bad Java book reviews in the magazine "Software Development" the page following a huge .NET multi-page ad.

    A PDF detailing why a Java developer is giving up and going to .NET? I sure wouldn't bother.

    Stick together Java dudes! Fight the FUD!

    http://www.pbs.org/cringely/pulpit/pulpit20020627.html


  122. i dont think it's entirely implausable that all this is just a mircosoft ploy. Afterall this is the company that send out phony concerned-citicense letters to congress
  123. Posted by sarwar mansoor 2002-06-28 16:50:43.0:
    Have to say the user has no idea about Java. In real world .Net is dead. Try Java and it will open your eyes.

    I don't need software to open my eyes.
    Shouldn't this be a technical discussion?
  124. Few comments on this topic.....

    1> There is an opportunity for J2EE vendors and entrepreneurs to build tools on top of stable, scalable J2EE architectures to hide many of the complexities perceived by some. Then tools can satisfy your novice technologist, while hard-core techies can still get into the code they wish to touch. However, these tools are not there yet......

    2> A key contributor to the growth of Java & J2EE in the recent years amongst new developers has been OpenSource (e.g., JBoss, Apache, Struts, others…). This has allowed garage developers with low budgets or developers in other technical arenas to learn and use Java / J2EE with minimal monetary commitments. If M$/.NET were to follow a similar approach (e.g. OpenSource), then the argument could be stronger for M$/.NET and barriers to entry would be facilitated. If ever there will be a winner between these two technologies (i doubt it), one key factor will be because of the largest developer support/knowledge base. Free/stable from a developers standpoint is winning over Expensive/easy.

    -liquid
  125. I dont have a major point to make. I think the article was interesting and made some good points but a lot of its points are speculation.

    I already have learnt C# and used .Net (A .Net Remoting SOAP Server), I prefer java. .Net like all Microsoft products is easier to pick and run with and for uncomplicated solutions is far easier to produce a system.

    I was admitly writing in Beta 2 but I spotted a number of limitations. WebServices for example are fantastic for small examples but try to build a whole system on them and you will find you cant, or try .Net Remoting and you will need a load of quite complicated undocumentated generated code in the background which you cant control to do all the work for you. Good in theory but the generation tools i used at the time didnt quite get it right and i had to fix it and have to manually maintain the code.
  126. Folks,

    It may be worth to learn Microsoft.net and C# down the road. But you do not have to rush. Learning Microsoft stuff is easy. My son learned VB when he was 11.

    The reasons I like Java/J2EE are the following:

    1) I can develop applications using both Linux and Windows. Java/J2EE/Linux is like a stick shift car while C#/.Net/Windows is like an automatic car. I can drive my wife's car while my wife can not drive mine.

    2) Many Java tools, application servers and even databases such as Eclipse, Ant, XDoclet, Apache, Tomcat, Turbine, JBoss, MySQL and PostgreSQL are free. If you visit sourceforge.net, you can find many open source projects which are even better than commericial ones.

    3) My application can run on Mac OS X, the best of both worlds of Linux/Unix and windows.

    I think Microsoft will have a tough time to compete with the free world. IBM, HP/Compaq, Sun and Oracle are taking advantages of the free world.

    Companies come and go. The free world will be here and stay.

    Jerry



      

     

     
  127. It's becoming Coke and Pepsi. As J2EE and .Net become more and more alike I think they will be differentiated as open source vs. proprietary which will play a key role in future decision making. Mindshare in corprorate (5000+ users sytems) and academic circles is with Java right now. It will be hard to compete long term against free, especially when it becomes free and easy. Linux/Clustered JBoss/Apache IS getting easier.

    In terms of complexity, the jump to distributed is a big one. JSP/JDBC will do the trick for easy for now.

    I think the real play is with tools. Look at what you are doing with code generators. Check out the latest TogetherJ, Rational XDE or Websphere Studio Application Developer to see faster coding whee you can learn as you go.
  128. Hi,

    I think the document tends to lean to much towards the idea that if you are using J2EE you have to use all of the J2EE APIs and therefore J2EE is very complex.

    Getting a simple J2EE application up and running using JSP/Servlet/JDBC is very simple. Open source also means that you don't have to spend a penny in the process.

    Swing/AWT is also not that complex at a basic level.

    As for the complexity of the other J2EE APIs (EJB, JMS, JCA)? Well I'm afraid component, distributed architectures are complex so I don't see what else you would expect. Does .NET have a magic bullet for these issues?

    I think the real danger is not directly from .NET but the fact that Java's public image has suffered a great deal by the over architecting of systems through the dot com era. Too many companies have spent large amounts of $$ building distributed component architectures with XML all over the place for no other reason than it looked good on paper.

    However this is not the technologies fault and it is up to us to educate people to what really happened.

    I do worry as well that the new Web Services specifications are going to cause more harm than good with people using XML where it does not belong.

    David
  129. Hi

    these inflammatory threads always have so many more replies.


    Not all the developers find J2EE easy to work with , but then those developers don't find ASP and com that easy either. I think we have to accept that some of the discussions here are a little bit 'ivory tower'.

    I have friends who work in development shops who even now have managers who are still discussing whether there is any
    point using classes in VB. I have seen under the covers of perfectly disgusting ASP systems littered with unmaintainable SQL, that run web systems that would collapse under the weight of more than 50 users but survive quite happily because they should be so lucky to get that many users.

    So let's not pretend that the majority of developers are brilliant individuals who work on cutting edge projects. I think that .NET or J2EE presents the same challenge to the majority of middle of the road developers.


    I haven't seen any figures but I'm pretty sure that Microsoft will find it quite hard to wean users away from VB6,ASP etc and I would be very surprised if any of those developers would willingly move to Java either.
    The problem for Microsoft is that they need to bring those developers with them, they've already lost the Java developers.


    The real argument here is one of cash. The thinking goes like this :

     If I have a relatively rare/new skill I will get paid more for a while , at least until the skils gap is filled. There are now quite a few Java developers which means the price has gone down so people are looking for big rewards elsewhere. The brutal truth is that the bubble has burst and pay levels have fallen back to earth.

    By all means learn .NET if you want to , personally I enjoy working with Java and can't really see the need to convert. I suppose if only money motivated me I could gen up on c# and go looking for gold in the hills, but I suspect that the gold is illusory and meanwhile Java solves pretty much all of the problems that I need to solve.

    Nick
  130. You would never read this type of article on a .net site, so why is it on theserverside. TheServerSide is a J2EE community last time I checked. We can discuss a stupid article like that but not post it.
  131. One of the things that I constantly hear in defense of .NET is that VS.NET makes it even easier to develop rich client applications with C#, and since rich clients are necessary for companies on internal application, that this fact will eventually make J2EE irrelevant.
    I disagree, primarily because I think it is easy to forget the genius of browser technology. HTML and JavaScript make it possible to implement extremely attractive and functional interfaces with a flexible development environment. The fact that you can access any web-enabled application just by typing in a URL, and this UI can be easily personalized to each user, modified and generated on the fly based on any number of conditions, etc. is incredible. I don't care how nice it is to work with snappy interfaces on my desktop that have pretty tabbed panes, a well designed web app UI is infinitely more flexible, and is much more attractive in my opinion. Of course, some of this is subjective.
    What I would really like to see is an evolution of the HTML standard (XHTML or whatever form it would need to take) to specify the kind of advanced controls that we like on our desktop systems. The controls that we call with HTML tags (text area, checkbox, select boxes, etc.) are just browser implentations of the HTML spec. All of those (of course) are running on the client box. There is no reason why the spec could not call out for a tabbed pane tag, a tree model tag, etc. Furthermore, there is no reason why it could not be extended to allow customized widgets and controls to be created (at least I don't see one) and still work on any browser that implements the standard. This alone would cut out most of the browser compatibility issues.
    The browser is an incredible medium, and every time I hear people complaining about how thick clients are better it's like a throwback to the early 90's. Make the browser implementations better.
    One last point... I am somewhat surprised that the large companies pushing J2EE (IBM, Sun, etc.) have not put forth such an effort as described above. Mozilla finally has potential, but without large companies that stand to gain from MS not having a monopoly in the browser space supporting it, IE will remain the de facto standard.
  132. 200 By Monday or Beust!^h^h^h^h^hust!

    Yes, the browser is a perfectly acceptable client platform... for SOME applications. Not all, by any stretch. I'd say that the browser is best for database apps. Any app whose data model is more sophisticated than a RowSet probably shouldn't be browser-based. Any app that needs to save files on the user's behalf, shouldn't be browser-based.

    Yes, the browsers could support a more Swing-like model. That would be good but it still doesn't mean that a complex semiconductor design application should be browser-based.

    MS has/will make UI development, both web and thick, easier than JSP/Swing. One of Java's UI problem is that everything is code. Resources are code. That ain't right. The way people write Swing, a little tweak requires a complete update. Only the resource file should need updating in this case.

    And of course, the Applet is a great idea that never panned out. Sun should do all they can to bring it back to life. But you have to use Swing.... damn!


  133. Good article. I can see that a lot thought has gone into your paper.

    My 2 cents:

    Thin Client is good - Vs - fat client is good.

    Layering of software separates presentation from logic - Vs - too much layering complicates the system.

    Only business logic should be coded, everything else should be declared - Vs - Too much declarative development depends on too many tools, I can write it myself in a simple way.

    Multi-tiered applications lead to flexible, manageable software - Vs - "I just want to see and edit and save some data - why complicate it?

    I am sure this is not the first time such topics are debated. People will go back and forth on all these issues. There is merit to both kinds of arguments. Some companies will move from J2EE to .Net. The other way around will also happen.

    In fact, from my experience, giving technical arguments in favor of J2EE or .Net is irrelevant as non-technical people in management and marketing end up making that decision anyway.
  134. the best test that can be done, is to grab the best .net developers and the best j2ee developers in your company and get them to develop and maintain the same test applications developed in both technologies and see the results.

    I am not interested in religious wars, but strongly believe the best technology available at the time the project is done should be used if it produces the code faster, and with the least cost = more profit. I'm sure you are all aware that nowadays, the magic words are "bigger profits and faster" for every business out there.

    Sure some are going to argue about security, in my opinion, all systems have security issues. some have more, some have less, but it takes only one bullet to kill one man.
    and don't forget, we can build the most secure IT system,
    and yet at the end of the day, be shortcircuited by end users (even high level) sharing their passwords or even wrting their passwords on sticky notes, inviting your Joe no blow thief to break into your system effortlessly.

     
  135. The only thing that I can think to say is what a #$A%^&@^ idiot. The breadth of J2EE is there to give an informed and skilled architect powerful tools to CHOOSE from. You do not need to use or even understand them all.
  136. Forgive me for stating my opinion this frankly:

    This is pure marketing and technical bullshit.

    Go through the text again. Notice how the author tries to worry you about not being employable at the beginning of the text. What has this to do with a technical .NET/J2EE comparison ?

    He then makes up some "principles" (read XP for real stuff) that will justify his later conclusion.

    He made you worry, he tries to look pseudo academic ("pseudo" because there are nearly no reasons given for his claims) and then tries to convince the reader "that he knows what he is talking about" and is "one of us" on page 2.

    Page 3 reads like a mixture of .NET advertisment and J2EE/open source bashing.

    Page 4 concludes with some stuff about the future he gives absolutly no reasoning for. At the end he restates the only purpose of this paper: "Start training M$ .NET now".

    This makes it very clear to me that this is a pure marketing paper and should not be "featured" as such on TSS.

    Ciao,
    Tobias
  137. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Interesting article indeed. My take on it:

    IT'S BOOOOOOOOLLLSHEEEEEEEEET!
  138. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Looks like a common marketing trick of injecting fear uncertainty and doubt (FUD). Perhaps .Net is desperate to get developer so they resort underhanded techniques.

    Go market your inferior solution somewhere else.

    J2EE is a scalable architecture that has a rich mature set of API that is compatible across all platforms -- Ideal for enterprise developent. On top of that, there exists multiple open source implementations of all the technology. Not sure if Micro$oft can match that.

    For the mom and pop operations, they could use the simpler Servlet, JSP, and JDBC API for their solutions. As their business grow, they can migrate to EJB for the scalability.
  139. I have been wondering how easy is to port business
    logic written in Jsp/servlet/jdbc to ejb.
    Is there any easy strategy to do that?
    ...Muthu
  140. There is no need to worry if you're a half decent developer. If .NET is going to dominate and J2EE is going to die, fine, I'll just switch to .NET when that day comes. Big deal, it'll take what, couple books and couple months to learn a semi-new language like C#? You make it sound like everything we have ever learned will go down the toilet and we'll have to go back to high school or something and start all over. I think your article should be targeted at IT managers who are easily swayed by your technical babble. Most of the Java developers here knows what's going on and are smart enough to act in the best self-interest. Your article simply does not serve any useful purpose here.


    Peace...
  141. Jonathan:

    It is an interesting article, but I only agree about
    50% of it.

    You said you have 7 years java experience including 2
    or 3 years J2EE experence, but how many years .NET
    experience do you have before you can jump into the
    conclusion? Since you used a humble tone when you
    talked about Message driven bean and JMS, why you can't
    use the same tone before you made your prediction of
    .NET's future?

    In my opinion, I agree J2EE is becoming more and more
    complex, but sooner or later, .NET will be similarly
    complex, just like current J2EE. It is simply because
    J2EE is more mature then .NET. Do you guys still remember
    how simple JDK1.0 and J2EE 1.0 were?

    Maybe several years later, .NET finally win the majority
    of market share, but I guess IT developers' job will be
    so boring, cheap, and lack of mental challenges, like
    no-brainer's job. Because by doing several clicks and
    drags/drops, even though you have no idea what got generated underneath, the project is almost done!
  142. I have definitive proof that the article is FUD.

    I did a nation wide search for jobs at monster.com and came up with the following results:

    108 C# Jobs

    3839 Java Jobs
  143. Oh come on everybody, the real issue here is not which language to use or which o/s to develop apps on... the issue at stake here is who is going to run the universal standard of programming.
    Java/J2EE is more than just a language, it's a way of thinking. .NET just addresses the syntax, not the practice.
    And yes, it is not terribly easy to think and program in J2ee, but if it was, then we'd ALL BE OUT OF A JOB, and isn't that the point that the article is trying to drive home??? Isn't that why we consider ourselves "professionals"? All this foo about "my language is better than your language" is getting tiresome and irrelevant. IT software development deals with all kinds of issues, not just which language is more convenient to use.
    The smartest thing I have heard thus far is the analogy to .NET and J2EE being like Coke and Pepsi. Try as you might, some people just won't drink Pepsi. Does that mean that Coke is an awful soda pop? No, it doesn't, and no amount of Vanilla flavor will change my opinion.

    Basil.
  144. Hi folks,

    I'd just like to state that I have no affiliation with Microsoft, and never had.

    If you see it as FUD, thats because .NET is causing FUD. It is a real challange, and not because of its technology. Because PC power is exploding and Unix servers are currently not fighting back.

    As I mentioned before, Linux may tip it. But so far I have not seen this.

    I also like the comments about free software. This could be the best counter argument. Lots of programmers cannot aford the msoft tools and environments, so perhaps they can sustain a free software platform through evangelism. I'm not sure what that does to a software driven echonomy, but thats a wider issue.

    Jonathan
  145. <quote>
    I'd just like to state that I have no affiliation with Microsoft, and never had.
    </quote>

    That's good to know. Not to sound cynical, but somehow I feel I won't be too surprised to find out one day that MS is behind this 'opinion' one way or another.

    My main regret is for the community's wasted time, since Java/J2EE/EJB/Jwhatever vs .Net topics have been covered quite extensively on this very site. IMHO, this article adds very little to previous debates, if anything.

    One funny thing though ... In conclusion the author predicts the return of fat clients, triumph of .Net (death of UNIX/J2EE respectively) and pleads to start training on .Net now. Interestingly enough he still plans to "stay a Java architect". Hmm ... ;-)

    When it comes to predicting the future ... let&#8217;s say the next two years:

    1) 90% of Unix shops will continue to run Unix or will convert to Linux

    2) IT shops that convert to Linux, will also convert to Linux % of their existing MS servers (I'd say about 25% on average)

    3) MS will loose customers (partially due to increased license fees)

    4) Linux will continue to gain server and client market share

    5) Faced with increased fees, dissatisfaction with MS and proliferation of Linux, IT managers will be even more reluctant to consider .Net as an enterprise solution

    6) All of the above will put pressure on MS's earnings and stock (possibly leading to another round of fee hikes).

    -- Igor
  146. Hi Igor,

    I love your predictions. But don't believe them.

    The linux boys have been beating the drum for some time now. And when they started the Windows operating systems were pretty bad. They are better now - good enough.

    I agree most unix shops will stay unix. But I recon loads of green field projects for 1000 to 2000 users will start using .Net servers.

    If you don't work on these systems ignore me. If you do then counter argue.

    As I mentioned last time, the free software argument and coder evangelism is an interesting counter.

    As for the 'microsoft sponsored' me attitude. I laugh at all of your blinkers. You seem to think technology from microsoft is bad because it is from microsoft. I've been using their OLAP product and it is fantastic - guess what, they bought the company. Take a look at any OLAP independant reports and they are all saying microsoft technology in this arena is THE BEST.

    So forget the Microsoft brand. Instead think of a PC server costing 14K, with a 2K O/S and a 18K database. Purchase cost 34K all in. Now support, for a server system, no different than for Unix in terms of man power. OK, what of Linux....can't argue, except that drum beat hasn't worked for the last 6 years and I see no reason for it to start now. Others disagree, which is GOOD. The entire point of debate is to expose counter arguments.

    I've seen multiple apps hosted on a single wintel server with no problems. Teams don't like it though as they lose control. I guess its exactly the same argument as for Unix servers, except the Unix community is more accepting of shared resources.

    I am still unconvinced by the counter arguments. Most of the world does not give a dang about Jakarta or JBoss or Linux. We are unusual in that we do.

    Jonathan
  147. <jgibbons>
    I am still unconvinced by the counter arguments. Most of the world does not give a dang about Jakarta or JBoss or Linux. We are unusual in that we do.
    </jgibbons>

    yeah thats correct, but its changing right now. Go to the mid-sized companies where the technology level is not allways on top. Even they have linux in mind when chosing among servers to buy. 4-5 Years ago, this was not the case for the normal IT-Manager.

    BTW IBM is selling their 390 Host system very good this year .. why? Customers can partition linux systems on them. So its not the end of the hype, its the serious usage of an operating system.

    But what does all that mean for Java? There is no alternative when doing serious integration work. When you want to access resources or data on systems like iSeries (AS400), pSeries (rs6000) or some others, Java is the way to go. Its not because of the language itself, its because of the industry support.

    M$ is doing good stuff and i dont want to say that all they do is shit, in fact, most things work ok. But the platform lock is the most negative issue. Even when they would produce a slightly better framework, i would stay on java, because customers want to be independent of companies.

    The other point is, i really like the spirit of the java community which is driven by organisations like the apache group. They produce excellent developer tools and help in transfering knowledge. You never get this kind of support in any M$ environment, because i believe (dont flame me on that) that sharing knowledge and software is not very hip there...

    But they make some good Single User Software like Visio or Word ;)

    m.
  148. I think the lines are pretty much drawn. (At least for the next couple of years). If you need a Unix backend for whatever reason ( scalability, security, transactions etc...) You will be using J2EE.

    I personally don't know ANYONE who is deploying on NT and using J2EE.

    If your servers are NT than You MAY be using J2EE but I believe this market will sooner or later move to .NET.

    I believe the SERVER CHOICE is the overriding factor.
    I believe the orginal premise of this thread about simplicity, productivity etc... is not of real value. The level of tools available today is good enough such that the real barrier to productivity is software design, development approaches, and Project Management. I think those items affect productivity more than the tools.

    Now, I HAVE looked at .net and the simpliciy that the original author is talking is 60% myth.

    Data access is just as hard ( most of the object MS provides are USELESS as the don't scale, nor do the integrate will with REAL applications ).

    The ASP.NET HTML programming model/TOOL integration is vastly superior to anything I have seen for Java. If you compare it with STruts, you will find that struts does not have a component model. Tapestry while conceptually good needs a tool. The same is true for the Wings product.

    When people talk about simple programming models ( such as that stupid MS petstore ), if you carefully examine an apples to apples comparison (e.g. modle 1 style programming with no real middle tier, just servlets/JSPs talking to the database) you will find that both technologies are capable of creating very simple solutions.









  149. Tapestry has the Spindle plugin for Eclipse; so the best framework has the best plugin for the best IDE.

    Tapestry is designed for RAD as well; most RAD features that require code generation can, instead, be accomplished in Tapestry by creating and editting the XML component specification (in an idea borrowed partially from ATG, you can define behavior in terms of JavaBeans attached to your component, rather than exclusively in terms of subclassing).
  150. Hi Jonathan,

    I read your paper, interesting views. Here some of mine:

    LINUX

    1. Linux on the enterprise side is not there yet, and can’t compare with Solaris and HP-UX in terms of power and list of enterprise software. But it’s moving up fast, oracle is moving most if not all their software offerings to Linux. IBM jumped right in because it was the OS that glued all there platforms together. Even Sun is starting there own version of Linux distribution.

    2. Linux on the client side is still in the early stages, I’d say it’s comparable to the windows 3.1 days in terms of easy of use for a novice. Given the amount of efforts that’s put in to KDE and GNOME, hopefully that will change soon. Even Redhat has recently changed there view on Linux on the desktop.

    3. Linux distribution consolidation. Just like early days of any booming technology there will be many offerings in the beginning, followed by a wave of consolidation, follow by the maturity of the technology. We are seeing signs of that right now - United Linux.

    Once the desktop, enterprise and Linux companies are mature, then it will be a true threat to Microsoft and .NET. It does seem like it’s going that way.

    JAVA

    1. The open source and free software. A 1000 – 2000 clients application using java and open source Vs. Microsoft.

    FREE: (Platform) JBoss/Jetty, Tomcat, Apache (Components) Jakarta, Apache XML, Exolab, The Object Refinery, etc. (IDEs) – Netbeans, JEdit (OS) – Linux

    MS: VS.NET, Win*, and third party vendors (haven’t found a Apache foundation equivalent that have C#, VB, VC offering yet)

    2. The support of big companies. For companies like Sun, Oracle, IBM, HP etc, to put it lightly, I think they really rather not do .NET unless they have to. I don’t they will stand still or start to abandon java because .NET is gaining visibility.

    It’s competition that makes a product or technology better. If .NET truly simpler than J2EE yet offers the same power and productivity, you don’t think java given its maturity advantage can incorporate some of those ideas before .NET becomes more usable?

    FUD

    Yes, J2EE is complicated, but so is .NET. Grass always seems greener on the other side. Do you really think .NET will be better given the support of only Microsoft VS Java/J2EE that has the support of rest of the industry and the open source community??

    The reason .NET is gaining ground is because,
    1. For java developers - Fear
    2. Existing MS only developers - obvious choice
    3. Management - Microsoft marketing and Fear

    If Fear is not contained, the fear of
      microsoft.NET java > /dev/null
    will be a self fulfilling prophecy.
  151. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Hi Jonathan

    How long we have to put up with you. You have been bagging Java, Linux, Jakarta & Free software. If you like .NET so much, why don't you start working on .NET and shutup.
  152. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Dear Sam,

    yours is an attitude that many software folks have. It is a very robust view of java etal. One that denies debate because it is so obvious that java et al is superior.

    I want a more thoughtful debate than folks like you are willing to provide. Predicting the way the market is going is vastly important to me and many others. And theserverside is the place to do it, because of the quality of most of the opinion.

    Jonathan
  153. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    <quote>
    How long we have to put up with you. You have been bagging Java, Linux, Jakarta & Free software. If you like .NET so much, why don't you start working on .NET and shutup.
    </quote>

    LOL. I am a 24 year old java/linux web application developer. I have a seriously bad taste in my mouth when it comes to Microsoft, especially when it comes to their licensing and business practices.

     That said, I think that the people here throwing the barbs at Johnathan are the real idiots. He wrote a thought provoking article. Yes, it seemed like some stealth FUD to me but it had good points.

     The bottom line is that I expected the developer community to be a bit more...intellectual? You can tell the smart people from the morons. The smart ones debate the points on an intellectual level. The morons assume everything is a holy war and start making insults. Regardless of whether or not Johnathan's paper is FUD, it challenges you to think about the merits of .NET vs. J2EE. Lets remember that Microsoft employs some of the smartest people in the *world*. Just because the marketing guys make them push products out before they're ready doesn't mean they can come up with a gem or two every once in a while ;)

     So I summarize by saying...take your holy war antics elsewhere, this is a forum for intellectual conversation and thoughtful debate.

     Matt
     Specialized Business Software
  154. I got only one question to ask .Does j2ee solve most developers problems?. Sure it does and most importantly it does it properly and if .Net solves these problems, too
    why J2ee has to go oblivion?
    Faisal
    UK
  155. I have seen far too many people here discuss things like cost and MS vs DOJ. Yes, these things matter, I will never dispute that. But's let's just focus on one thing at a time :P

    Yes - J2EE is complex. Ever consider WHY it is so complex? (no, not that you have to have a home object, remote interface, deployment descriptor, blah blah blah, this is HOW is it complex).

    The J2EE standards have been built with input from many major parties, who each have contributed (or pushed, depending on how you see things) their "ideas." This leads to a kitchen-sink approach to a standard, which makes it large and complex, which is clearly the downside. Sun should make sure that as much of the ancillary complexity in implementation is reduced in future versions of J2EE, possibly at the expense of J2EE vendors. And yes, the tools for J2EE could be better.

    Now for the upside; this same complexity allows you, the programmer/architect, to model and implement solutions to real-world problems in a structured fashion. Real-world problem are often very complex, hence you will need an advanced, diverse, and involved framework. Can .NET readily be used for a myriad of real-world problems? Can you developer/architect/manager effectively (and quickly) move from one .NET project to another which solves a completely different problem? (I have not work enough with .NET to answer these questions) I can say that Java _does_, which makes it a viable investment of my time and enery in learning.

    prp
    PS AND Java runs on Solaris, Linux, FreeBSD, MacOSX, and even various flavors of Windows.
  156. Matthew,

        I agree that the moronic comments don't help matters, and also that this debate in particular is extremely interesting and if only we could all behave ourselves.
         The problem is that the source of this thread, the article ( and especially the title of it ), is meant to antagonize and give birth to exactly the type of comments you despise.
        Jonathon Gibbons is right to believe that there are many intellectuals on this message board that could provide good fodder for argument, the problem is that he did not approach them at the level they need to be engaged at. For example, not having any experience with asynchronous messaging systems was probably a big hit to his credibility, especially when the biggest draw to .NET is the smooth implementation of Web Services, which is a technology that can be viewed as an asynchronous messaging system in many ways.
        Also, his advice to seasoned professionals who have placed their time, money, blood & sweat into Java to suddenly get ready for J2EE Armageddon was, to be frank, quite an immature remark that will undoubtedly attract Java zealots or even make zealots out of people who would not normally consider themselves one.
        Bottom line: In order to generate intelligent debate, the topic that you are debating must be intelligent in nature. And if that is a bit shady, then at least the person who brought it up should be credible, and all I see in Jonathon is somebody who takes offense at remarks that he himself asked for.

    Basil.
  157.     And speaking of that, I would absolutely LOVE to dedicate an ENTIRE THREAD on the Server Side to Mr.Beust (sp? ) from WebLogic and whoever the main architect from the .NET side is.
        Imagine the quality of THAT debate... also, it would be extremely educational to both .NET developers and J2EE developers.
        How about it? Where's the petition that we should sign?

    Basil.
  158. Basil,

    "For example, not having any experience with asynchronous messaging systems was probably a big hit to his credibility,"

    Sorry, I guessed when writing it that my stated background in telecomms would be enough. Obviously not. I spent 6 years implementing ISDN protocol stacks and others for different global role outs. This was all async. I then contributed to the protocol stack of an ORB. I also wrote a distributed messaging infrastructure with network split and rejoin. I also wrote part of ab object replication system for data persistance. I have 6 years solid async in a mix of assembler, c and c++.

    In java, I've done webservers, ftp client/server, spiders, messaging infrastructures. All of this prior to JMS & MDB. I've only done a couple of months prototyping with JMS. So thought I'd not pretend to be a guru.

    I hope that is adequate asynch credentials for you.

    "his advice to seasoned professionals who have placed their time, money, blood & sweat into Java to suddenly get ready for J2EE Armageddon was, to be frank, quite an immature remark.."

    You seem to have misunderstood my entire paper. Which is that J2EE has lots of features irrelevant to most projects. The rise in hardware performance will see PC servers increase as the platform. c# and .Net is already rising as a skill for fat clients - and I am seeing marketing and project sponsers asking for fat clients again. All this is a direct threat to the Java/J2EE world. Result, start training. Not 'give up java', but 'start training'. I personally believe it will put a huge dent in the J2EE project market sometime in the next two years. Some folks in this thread have actually come up with alternatives which focus on free software for this type of project. You didn't actually come up with an alternative, other than the status quo, which does not exist in this industry.

    As for the title? Controversy gets readers, readers gets me some informed debate. I want to know what your alternative is given the increase in PC hardware performance. Most here are pegging Linux running on PC hardware. Perhaps one or two have mentioned BEA, Oracle, IBM, HP, Sun, JavaSoft.. no one has mentioned Macromedia, or the influence of mobile or XSLT rendering engines, or even C++ and other languages.

    I do not pretend there will be one final tech that is used 100%, but I do say that J2EE will not be the dominant architecture for global systems with 1000 to 2000 users (to 5000, 25000 etc depending on hardware) when the next 2 years are up. J2EE is young, and look what it has achieved. Imagine what can be created from scratch by people who copy it, and fix the rubbish bits.

    "all I see in Jonathon is somebody who takes offense at remarks that he himself asked"

    I try not to take offense, but I guess you misinterpret the tone of my posts. The wonders of electronic communication.

    Jonathan

  159. "but I do say that J2EE will not be the dominant architecture for global systems"

    On rereading that, it's too harsh. It should be :
    "but I do say that J2EE in anything like its current form, will not be the dominant architecture for global systems"

    Basically, the current version of J2EE asks for too much and gives too little for the projects in the scope of my article, given the emerging competition.

    I'm starting to have to restate the entire argument with every come back now. When we get to 200 maybe I'll give up.

    Jonathan
  160.    Jonathon, I've worked several J2EE projects now, using EJBs on two of them and servlets on the other 2; maybe I'm not as experienced as you are with all the "stack" implementations you have worked on in the telecom industry, and I don't mean to affront you atall, but I cannot recall a single complaint from anyone in the 3-4 years that I did this kind of work in which your FUD is addressing.
       Yes, the J2EE work was very difficult. That's why they pay us the big bucks, though.
       Yes, there were so many different pathways that I could've chose, but that just added an extra tang of variety and excitement to my work.
        In my last job, we had a ASP/NT front end and the entire B2B middleware was Java/UNIX. They coexisted perfectly, and my company had no intention of going completely one way or the other. They revamped the front end so that it used ASP.Net and I implemented a J2EE infrastructure to handle all the subsequent data. Why on earth are you suggesting that within two years, companies will start throwing out hundreds of millions of dollars worth of servers, software, and technology?!?!? It sounds like you are trying to time-warp us back into the late 90s with all this fanfare about the Next Big Thing.
        The reality is that MS will NEVER completely implement a vertical monopoly in the market place, no matter if their .NET system is this or that over J2EE or not. Get a sound business expert to look over your article and tell you why.
        When technology rationale beats out business rationale, that is called b*llsh*t.

    Basil.
  161. This thread is completely ridiculous.

    Someone writes a pdf document, claims to be a "senior architect", speculates on the failure of J2EE based on its complexity and concludes that .NET will dominate simply because, well its microsoft.

    No strong arguments were introduced in the document, nothing conclusive other than microsoft shops will use microsoft technologies. He then makes a completely absurd recommendation, that is, to spend valuable time learning .NET. Time better spent familiarizing one self of all the new API's streaming out everyday from JCP and the open source community.

    So, can anyone restate what the compelling arguments were to start "training" on .NET? I seem to have completely missed it.
  162. Carlos,

    I agree with you, the document should have pointed out technical arguments clearly underlining the superior aspects of .NET towards J2EE.

    Instead of trying to sell .NET to a J2EE community, all I'd suggest is _knowing your competition_ instead of ignoring it and resorting to widespread myths (which clearly help nobody). Getting to know the "enemy's weapon" doesn't make you a renegade, at last it will make you a better J2EE architect...

    Horst
    netarray

  163. Horst.

    "the document should have pointed out technical arguments clearly underlining the superior aspects of .NET towards J2EE"

    This reminds me of an incident in Denmark 1996. A "prophet" with quite a large group of followers had predicted that the world would go under the last of January. The date comes, but nothing happens. Then you would think that the followers would give up on him or least protest in some way, but no, everything goes on as usual.

    The technical arguments have been given in the Pet Shop benchmark. Ten times faster, four times less code. And by the way, the Petshop is not a "toy application", rather a
    perfect example on the middleware Jonathan is speaking about, the original example from Oracle consist of 700 files. Hardly a trivial application.

    And as for the credibility of Jonathan and his claim to be a "senior architect", why don't they go to his website http://www.tallsoftware.com?

    In a recent survey Borland conducted of "C-level executives," i.e., top corporate officers, the predominant response from those surveyed was "Java is over."
    http://www.nwfusion.com/news/2002/0625javaweb.html

    But I am waising my time. No amount of proof, benchmarks or reasoning can make those religious Java zealots change their minds.


    Regards
    Rolf Tollerud
  164. Other quotes from the night side.

    "Getting to know the "enemy's weapon" doesn't make you a renegade"

    What enemy? Oh I see. I hadn't realised they were an enemy. So you point is that we should learn their technology. OK, I agree.

    Project mono comments from Horst were superb, thank you for that. And I loved the way they were attacked as doomed to failure, even though they embrace the exact spirit that creates such power for the J2EE environment. Having said that Igor put up some good quotes. It all feeds into:

    Micorsoft licensing & legal. This is a really really huge issue in my mind. I have often been put off MS stuff because of the rate of churn, and their practice of dropping old products. I hated the way they bundled fax s/w and destroyed many ISV's. But consumers don't care. Anyway, back on topic. Microsoft licensing. Puts the fear of god into me as well. Its a trust thing... I'm giving it a try, and I may get burnt. But on the whole I doubt it. Because microsoft wants to win, and will support stuff that makes them win.

    And, thanks for the links to rumble in the jungle. Its reading things like that which make me think its time to learn c# & .Net - and so to write the article in the first place.

    Jonathan

  165. The most important argument for learning .NET is that it is clearly going to be an important part of the total market.

    Hey why not? Particularly if you are deploying Web Services and want to know what the client-side is doing.

    A secondary argument is that anyone doing this will be somewhat covered when Java (SUN?) collapses and Bill Gates makes his final move to swallow the universe.

    After all, we have it from Mighty Ballmer's own lips: Open Source is Evil!

    QED it will not be Tolerated?!!!
  166. Here is an interesting comment from Network Computing.
    (I hope this quote qualifies as fair use)

    Interoperability is another big issue. Microsoft has led too many customers down development paths only to change course, hoping to capitalize on some new market trend. Life Time Fitness, the subject of our On Location case study this issue, switched from Microsoft to Java precisely because its IT organization didn't trust Redmond's commitment to open Web standards.

    Here's the URL: http://www.networkcomputing.com/1314/1314f1.html

    There are too many issues outside of the purely technical for people to go to .NET. There are a lot of them.

    -Newt
  167. TheServerSide is a j2ee community. Those who need to know/promote .Net should got Microsoft.com!.
  168. Has the battle been won? Check this interview with Jonathan
    Schwartz, chief Strategy Officer for Sun at http://www.infoworld.com/articles/hn/xml/02/05/24/020524hnsun.xml

  169. try to be open to other technology for just the discussion .. no one is forcing u to use any thing msft makes... cool it man ..
  170. <JG>
     J2EE is young, and look what it has achieved. Imagine what can be created from scratch by people who copy it, and fix the rubbish bits.
    </JG>

    Rather unsubstantiated claims.
    From scratch? No, from COM etc. and from "user friendly" development environments such as VB.
    Fix the rubbish bits? By removing complex stuff?

    <JG>
    Some folks in this thread have actually come up with alternatives which focus on free software for this type of project. You didn't actually come up with an alternative, other than the status quo, which does not exist in this industry.
    </JG>

    How can one come up with the status quo, if it does not exist?
    Perhaps this semantically challenged paragraph means that free software is a priori unacceptable?
  171. <quote>
    Java/J2EE is more than just a language, it's a way of thinking. .NET just addresses the syntax, not the practice.
    </quote>

    Wow.

    I predict (like Forrester Research or Giga) that this therad will exceed 200 silly comments by Monday the latest ;-)

    --
    Dimitri
  172. hahah obviously, that quote struck a chord. So Dimitri, you don't think that, for example, the Design Patterns for J2EE provide a way of thinking for the Java community? Or the open forums that they encapsulate? Better yet, what part of the .NET architecture do you feel provides the same abstract things for a development community? And I ask this with complete sincerity.

    Basil
  173. <quote>
    hahah obviously, that quote struck a chord.
    </quote>

    Yes, because it sounded excatly like a comment from a member of 'Team OS/2' (if I remember it's name correctly) from good old OS/2 advocacy threads - those guys were quite passionate.

    Anyway, design patterns have nothing to do with J2EE or .NET. Or Fortran or Macro Assembler for that matter.

    "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it in the same way twice." - Chistopher Alexander, 1977. He is an architect, but not the J2EE (or .NET) type ;-).

    --
    Dimitri
  174. Dima: "I predict (like Forrester Research or Giga) that this therad will exceed 200 silly comments by Monday the latest ;-)"

    Anything I can do to help?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  175. J2EE vs .NET Job Market[ Go to top ]

    Peter English wrote:

    >> 108 C# Jobs

    >> 3839 Java Jobs

    Unfortunately this is the wrong comparison. C# is not
    catching on as well as the other .NET languages like VB are.

    C# is a drug on the mart, but VB is doing very well thank you, as is C++. ASP is still beating chunks out of JSP, but J2EE is outpointing .NET about 60-40. MSMQ and JMS are about even in messaging but both far trail Tibco and IBM MQ Series, the traditional market leaders. And EJB leads in remote object access, Web Services #2, and COM+/DCOM about even with CORBA. ADO and JDBC are about even in data access.

    The story is that .NET gives VB programmers tools which only Java and possibly C++ programmers have had before. Chances are that C# won't take off unless J2EE starts to stall out and Java programmers desert to .NET in droves.

    The downside of .NET is that there is complexity in that architecture, even for those using VB.NET. The chances are that not all of the existing base of VB programmers will want to make the leap to the next level. But many of them will. VB.NET looks to be the winning entry in the .NET language competition.

    Microsoft has a record of marketing their wares as the obvious winner (NT for web services for example). So I am naturally reluctant to take their word for it. Moreover it costs a good bit to get into the Microsoft game whereas it does not cost anything to learn most Java technologies. This is a major plus for Java/J2EE.

    My conclusion is that the market right now is roughly 60-40 Java/J2EE versus .NET.

    1709 Java
    137 C#
    1408 VB
    365 VC++
    2071 C++

    Architectures:

    435 J2EE
    342 .NET

    Data Access
    84 ADO
    78 JDBC
    0 SQLJ

    Server Pages & Servlets
    662 ASP
    239 JSP
    137 servlets

    Messaging
    23 MSMQ
    42 JMS
    164 Tibco
    183 MQ Series

    Remote Access
    160 CORBA
    12 RMI
    132 DCOM
    139 COM+
    269 EJB
    12 RMI
    54 SOAP
    187 Web Services

  176. I don't think there is any reason to worry about missing the .NET boat. Say you've been doing this stuff for a while. I've transitioned from C to C++ to Java to Server side Java.

    Aside from the transition from structured programming in C to objects in C++ everything else has been pretty easy to learn. All of the knowledge that you have creating J2EE apps directly translates into whatever .NET turns into.

    The longer you do this stuff for a living the more that you realise that basically it's all the same.

  177. I don't agree with your statements on development sopposed to be really easy. I mean, a true 3-tiered system is fairly complex. In order to build in incredible scalability, you must have design tradeoffs. These tradeoffs in j2ee are the added layers. Although I agree that connectivity between .NET and j2ee must exist in the future (I have actually tried to build some software that does this just to see how nicely I can get it to work), but the fact remains, j2ee and even the new upcoming standards for java are still better than what .net has to offer and j2ee is not going to simply fade away. .NET will get used. It's a great technology. But it will only get used over java/j2ee if your 5 assumptions in the future are meet in the next 2 years. It's a complicated problem and I don't think we'll be seeing a solution any time soon.
  178. I didn't read you article, and it seems I'll never do.
    Simply, I'm fed up of such articles on how .NET from microsoft is gonna kill all Java developers.

    The thing is not about Sun and Microsoft, but IMHO about Microsoft and Open Source...

    Using Java, I have the power of a lot of amazing tools from Open Source, built upon J2EE. And I'm having wonderfull results with it, both in performance and developing time/cost.

    JBoss, Cocoon, Tomcat to name a few... these great tools on Linux are great...

    And please, Nobody tells me that Winxp is something to talk about... Windows is crap, and winxp is no different at all.

    Just my 2 cents
  179. The thing about noone really caring about Jakarta, JBoss etc just isn't true. I talk to people all the time using these tools _in production_. I've just gone into production with a major system for the US government running with Struts, Tomcat, Log4j, and some other open source stuff. And it's bigger than the 2000 - 4000 user apps your talking about.

    My company uses JBoss in production for our issue tracking system (JIRA).

    I have simply talked to too many people using this stuff to dismiss it that easily.

    -Newt
  180. Hi,

    I am getting a clearer picture of the server sides perceived competition to .Net, and its not J2EE.

    It is Linux and free software tools. Lots of stuff gaining ground has little to do with J2EE, lots to do with Java. Its the Jakarta stuff which is quoted most often. Admitely some of these are implementing J2EE and java standards, but others are simply making stuff up, cos they like doing that, and they have some great ideas.

    It is this massive churn of ideas and effort within the free software community which everyone who disagrees with me is stating as the real competion. And the obvious platform is Linux.

    So its .Net v's a Linux hosted free software platform, mainly adhering to J2EE, but with loads of add ons as selected by the project.

    I found myself rereading this, and the problem is the "v's". What I should have written is:

    So its .Net and a Linux hosted free software platform, mainly adhering to J2EE, but with loads of add ons as selected by the project. This will become the corp standard for mid size enterprise systems. hmmmm. maybe, I still think not for my clients.

    The problem with the above is that .Net is a finite brand, whereas the open software community and Linux cannot be predicted. Which is of course their power.

    I also note that some of the better posts in this thread are from people who have already done the .Net training that I recommend. So I stand by my recommendation that training (in .NET), and training now is demanded of us all.

    Jonathan

  181. Jonathan Gibbons writes:

    "I am getting a clearer picture of the server sides perceived competition to .Net, and its not J2EE."

    No, J2EE is a part of a much bigger picture including J2SE, Apapche Jakarta, and SourceForge. It is also about more or less complete portability.

    I work in a systems integration shop these days and whenever a new interface to do comes along I tend to look for a Java API first thing. The classic SI problem has long been to get information about and/or access to the client software environment early enough to get a running start on the project. With Java I usually do not have to worry what the OS is and which libaries are supported. I can just blast ahead using J2SE API's knowing they will be supportable on whatever OS is out there. Later on when I get more information I can design in any JNI I will need to get things running. In 2 or 3 month projects you would be AMAZED how big a difference that can make!

    Until recently Micro$oft wasn't even a consideration in much enterprise SI work, because NT was not stable enough to run an enterprise server on. Nor were NT-based servers easy to administer remotely. Another problem was the noninteroperability of COM+/DCOM with CORBA/IIOP. With XP the OS stability seems to be better (but good enough?) and with Web Services decent interoperability seems to be possible, so I expect this to change. But this still doesn't make VB or C# portable to Unix/Linux for example, a genuine problem.

    "It is Linux and free software tools."

    Actually it is the free tools, not Linux. Linux is nice but the two major OS I encounter these days still are NT/2000/XP Pro and Solaris.

    "Lots of stuff gaining ground has little to do with J2EE, lots to do with Java."

    Absolutely true. The Sun stuff isn't properly open source, nor is Sun as open to outside influences in designing J2EE as it ought to be. But the Sun J2EE stuff is freely downloadable and is much more open to the outside than anything M$ does is! Apache Jakarta and SourceForge add value to Java and J2EE but not .NET. Nor has Micro$oft provided an easy (and free) learning path to any of the .NET
    technologies as far as I know.

    As imperfect as Sun is, Java/J2EE is a vital part of a much wider community than .NET can ever be!

    "Its the Jakarta stuff which is quoted most often. Admitely some of these are implementing J2EE and java standards, but others are simply making stuff up, cos they like doing that, and they have some great ideas."

    Like the JUnit testing tools and Ant initiatives for example. Wonderful stuff and all free. Look at your own Lowroad and Xdoclet for other examples. Axis. Where are their like for M$.NET?

    I've been looking for a cheap way to explore .NET. Studio
    costs a minimum of $1000 commercially and VB.NET and C#.NET Standard seem very clientish to me. I want the whole thing including ADO.NET and ASP.NET. For a decent cost. Anyone have a suggestion?
  182. Jonathan,

    Great article and an interesting read. Nice to see some ‘meat’ in a posting! Apologies for the length of my reply…

    “J2EE server side projects will have to integrate with C# front ends.”

    This may be so, but if a multi-tier application system is designed correctly, the bulk of the grunt work that an enterprise application needs to perform is situated within the Business logic and Enterprise systems tiers. The choice of language used for presenting the application to users is largely irrelevant and only dependent upon an organisation’s commitment to a particular client technology. If my clients are 100% Windows clients and will remain so, then why bother developing a Swing front-end?

    “Marketing and business sponsors will start to promote fat clients over web GUI’s again.”

    Why? The fat-client model is a system administrator’s nightmare. What about the cost of deployment and roll-out of the application software? If I have several thousand distributed clients and I want to make a GUI tweak to my application, then that’s a lot of effort involved in rolling out a new release to a lot of fat-clients. OK, you could use specialised network tools for maintaining application distribution, or centralised servers hosting the application software. But hang on, why buy a powerful PC that will become obsolete in 6 months if it is not going to host the application software anyway?

    I’m afraid that the fat-client model is gone, it costs too much to maintain and requires heavyweight hardware. To be quite honest, thin-client technology solutions such as Citrix, Tarantella, Sun’s SunRay, and/or good old web clients all offer cheaper cost of ownership and easier application management for an organisation.

    “Programmers will switch on mass towards C# for GUI’s.”

    They may well do, but it will not impact upon Java technology nor J2EE one bit! Java has found its niche as a technology for middleware (J2EE!), not as a fat-client GUI development tool. So if C# does the job, then fine, as long as it is open enough to talk to J2EE (ie. Using XML, SOAP etc etc).

    “Architects will seriously start to consider Microsoft server solutions, and stop worrying so much about J2EE as the solution.”

    Again, it’s a case of ‘horses for courses’. If you are a Microsoft shop then you will stick with Microsoft technology. If you have invested in J2EE, then you will stick with that. The point is, many organisations have a mix of technologies and hardware environments out there. An organisation is solely concerned with reliability, availability, scalability, and value for money from its application systems. Organisations want choice, not vendor lock-in, and they want to be able to easily migrate application software from one software architecture model or hardware vendor to another if need be.

    We may be talking Web Services right now, but what about P2P when it arrives? Will .Net be ‘open’ enough to accommodate future technologies without major re-engineering exercises? I feel J2EE will, because it is Java based, and Java is inherently open.

    “Architects will push soap as the corporate glue, allowing them to have .Net projects and J2EE projects which can communicate.”

    It may be SOAP, it may not be. I think it’s more accurate to say that XML is the basic glue that will bind application systems together, the actual protocols used will undoubtedly change (it could be ebXML, SOAP, or another protocol yet to be invented). But, will .Net be open and flexible enough to adapt to the next latest and greatest XML protocol when it arrives? By choosing a technology developed by the IT industry itself (ie. J2EE) you are reasonably future-proofed against forthcoming XML protocols (which tend to be developed by IT industry anyway), rather than a technology developed by one vendor alone.

    “Managers will listen to and agree with the .NET marketing, sometimes forcing this to be the solution based upon cost and ‘hype’.”

    This, unfortunately could happen. Microsoft are masters of marketing and have the $ to do so. But, J2EE is very well established now, and it would be financially suicidal to rip out a reliable, scalable, application system that an organisation had spent money on, ‘just because the Microsoft IDE looks flashier’. I think not, “if it aint broke, don’t fix it”. The industry will NOT be switching their server systems over to Wintel platforms because of .Net! The only switch that may happen could be the move of mid-sized systems to Linux on Intel as opposed to NT/W2K purely on cost grounds.

    “The Unix vendors must come up with products that work on Microsoft, or come up with a very good argument for rolling out Unix based systems which are not simply based on performance, robustness and clustering. If they don’t then they will lose even more market share. As Unix severs lose ground, so the J2EE architecture loses one of its prime advantages – that it is supported by cross platform application servers. .NET continues to grow in this environment.”

    OK, we are switching to discussing operating environments here. The point is, we have XML around now. The UNIX vendors don’t have to adapt their products to work with Microsoft, they merely adapt their products to work with open protocols like XML. Microsoft must ensure that THEY make their products open enough to do the same. The days of the one vendor, one hardware, one operating environment are long gone. Microsoft have to ensure that they can mix it with everybody else.

    I’m sorry to say this (you referred to “ridiculing their operating systems (blue screen of death)” ), but Microsoft’s operating system offerings (whether its W2K Data Centre Server or XP Pro), simply do not scale, perform, or offer the reliability that is the bread and butter of UNIX (and Linux) servers.

    The point is (again) that J2EE is OPEN, you don’t have to run it on UNIX! You can run it on OS/390, and yes, even Windows. You have choice of software architecture, choice of hardware, choice of operating environment, and choice of vendor. J2EE has no prime advantage of being on a UNIX server, apart from if you want a truly enterprise scale application system to survive without frequent rebooting. .Net MUST run upon a Wintel platform and on no other platform. Where’s the choice there?

    As IT professionals, it is always good to be aware of the different tools out there that one can use to solve problems, whether its J2EE or .Net. Yes, go ahead and learn .Net (it will make you more marketable to say the least!), but realise that .Net will not take over the world, as neither J2EE will. They will both be around and will both live side by side for a long time to come until the next big thing arrives (P2P?).
  183. Andy,

    thanks for the post, I missed it before I got my last reply in. Fine points.

    Jonathan
  184. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    The thing that is hard to trust about MS is their obsessive interest in controlling the whole vertical from tools, to hardware, to client OS, to server OS, to app servers, to "biz services", to databases. While organizations have tended to "go with a platform", I think many are getting more concerned about the too many eggs in one basket liabilites when it comes to security and licensing and even the core framework.

    It is kind-of the loose coupling vs tight coupling consideration with regards to a vendor. So, I am just saying that working with MS has been more of a tight coupling relationship, which has its own strengths and weaknesses, and Java (for me at least) has been more of a loose coupling relationship, which has its own strengths and weaknesses.

    Companies like Oracle and IBM have similar interests in the vertical as MS, and it is cool to see how their adoption of J2EE has loosened them up in some ways. Sybase has gone really far in assuming their products have to interoperate with others.

    So, maybe .Net is the "open" MS in the future? It does allow different languages to be used and who knows what else with its web services promise. But, it is hard to imagine this ending up "open" when looking at MS strategies all around (check out what they are doing to compete with Java cell phones).

    I want to make sure we get to that 200 silly posts before Monday, so my predictions for the future:

    1. loosely coupled distributed networks applications will rule

    2. the majority of those applications will run on many very vanilla cheap servers AND clients (think appliances) running Apache, JBoss, Tomcat and other free or inexpensive app servers/frameworks

    3. To the degree MS creates software / devices that interoperate in this environment, they remain a major force

    4. the merits of higher level APIs and services become more the focus of debate than underlying app servers, architectures, or their vendors

    j f
  185. It's not about that[ Go to top ]

    Jonathon,

       Your article is valuable in the sense that it indicates the realities of this issue; that is, you have been working with Java technologies over the past few years and so therefore the context of your opinion can be taken as not against this company or that company, but as an observant participant in the industry in general.
       I completely disagree with your line on fat clients, but I do agree with your thinking that one day in the near future, the MicroSoft operating system will be stable enough to replace solid UNIX-based systems.
       The industry is coming to a critical juncture in terms of the usage of development platforms. While Web Services have effectively made irrelevant the issue of integration within EXISTING systems, the issue of what system/platform to actually buy remains active. That is, .NET and J2EE will happily co-exist for quite some time together in my opinion thanks to Web Services, but your paper is more of an opinion that concerns the long term, when businesses are ready to spend their money on NEW systems.
       Will Windows ever reach a point where the o/s can be "good enough" so that in the future less and less UNIX-based systems are purchased while the money goes to Windows? There are only two possible scenarios:

    1) Windows will never be as good as UNIX or LINUX. No matter if the greatest minds of the technical world go to work for MicroSoft or not, SUN will always have the market cornered on server side hardware. This is as riduculous as it sounds.

    2) Windows will not only be as good as UNIX on the server side one day, but it will become a sound business decision for companies as MicroSoft will not abuse its monopoly on the entire vertical grip that it will, as your paper predicts, one day earn. This, too, is as riduculous as it sounds.

    We are back at square one. Whether or not C# and the .NET platform become just as efficient to use as Java and J2EE, your article still does not address the NON-TECHNICAL factor --- namely, which business in its rational mind would use one single company's solutions and willingly walk into such a dependant relationship with its software/hardware supplier?!?!?
    We already know that the business industry has the capability to bring MicroSoft to court in order to get its way. A much easier and effective way of keeping MicroSoft in line is to choose Java-J2EE technologies over C#-.NET technologies even if it is irrelevant.
    So not only do I NOT see the Java boat sinking, I see it as actually getting stronger as MicroSoft makes its case for choosing .NET even more convincing. Apologies for bringing this non-technical point up in a thread that seems to be about development platforms and languages, but MicroSoft has put itself in a position such that this argument cannot be ignored.
    Your comments, please.
  186. I've spent the past 6 months working on a .NET web-based system, and have just signed on for a project to do a thick-client app in .NET. This is after working for several years on server-side Java work. I feel I have a few comments to add:
    1) Jonathan wrote that he saw Linux/Open Source being the real challenge to .NET, not J2EE. Without J2EE and the standards and interfaces supplied in it, the open source Java software wouldn't be nearly as useful as it it. J2EE provides a "lingua franca" that allows developers to pick and choose among the open source (or commercial) products that they need to develop their solutions.
    2) J2EE is complex taken as a whole. So is .NET. A .NET programmer working on ASP.NET talking to VB.NET classes has no easier a time than a Java developer using simple JavaBeans and JSP. They're pretty much identical in complexity. Some of the J2EE technologies are more complicated but that's because they're usually addressing complicated problems. Nonetheless, that complexity doesn't hurt the JavaBean/JSP programmer in any way, shape or form.
    3) .NET has close to nothing to offer in the integration space. Most of the commercial integration platforms are Java based because of the cross-platform nature of the language. You can run an adapter to a resource directly on the resource, pretty much no matter what the platform. Also, asynchronous messaging is extremely important in integration, and MSMQ doesn't address this nearly as well as JMS or the numerous commercial messaging products do (TIBCO, Vitria, webMethods, MQ, etc.). At least that's my experience with it's last version, and I don't think it's changed much in .NET. Even if it is better than before, I would not want to risk running a heavy-load message-based app on it when I have so many other proven options.
    4) Has anyone used .NET remoting yet? I haven't but am interested to see how it compares to EJB remoting. My impression is that it's more akin to RMI than EJBs. While EJBs are overkill for most people, when you need to do remoting, they're a better solution than vanilla RMI (and, by extension, .NET remoting).
    5) .NET doesn't address deployment nearly as well as J2EE does. This point can't be emphasized enough. Every application that goes live has to be deployed at some point, and usually many times over and in many different environments (moving from dev to test to production). The combination of well-documented XML configurations combined with Java properties and resource bundles are a deployer's dream. Ant helps a lot, too. It is much easier to switch between servers and environments using these tools than using .NET tools. I know because I've done both. While .NET does offer an improvement over old MS tech with its .config files, they are not nearly as complete and detailed as the J2EE-specified xml files one the one hand, and on the other, they are much more difficult to use for custom configuration than simple Java properties or resource files.
    6) Most Microsoft houses will go .NET. It's so much better than the old MS technology in every way that they'd be foolish not to. So there's a sizable market segment for MS right there.
    7) Many companies, including the client I'm working for now that has chose to go the .NET route, feel a little leery of .NET simply because it's still a 1.0 release. I hear a lot of "You know how Microsoft 1.0 releases are; it takes them until 3.0 to get it right." Will this scare away companies deciding between J2EE and .NET? Maybe in the short term. But it won't affect those who already know they want to go one way or the other. I've already tried to calm some clients down and assure them that .NET is a safe choice, mainly because the alternative is being forced to develop for them using VS6!
    8) I disagree strongly with the people who say this article has no place in these boards. This kind of debate is extremely useful. Most people have to work in more than one technology so it's good to see constructive debate go back and forth about the relative merits of each. Also, for the conspiracy theorists out there, I find it highly unlikely that Microsoft would target a guy who developed a J2EE code generator as their mouthpiece for the merits of .NET. If someone supports a technology, it doesn't mean they're being paid off.

    Just my 20 cents.
  187. Hi Drew,

    thanks for the real world experience of .Net and for telling us about it.

    Jonathan
  188. I read the article the author has posted, its a nice article to read and from the looks of it the author seems to be an educated guy rather than the usual "Java is going to die in 2 days" zealots, who are dime a dozen and post every 2 days on this site.

    Having said that, in my humble opinion there is a fundamental flaw in the author's perception, which many of the previous posters might have pointed out (since I didn't read the complete thread of messages, I am not aware of it), the flaw is the author is comparing 2 technologies one of which he is an expert @ (J2EE) the other (.NET) he is begining to train himself on, since he is an expert @ J2EE he knows the complexities associated with it(it is true J2EE is complex) but since he is training himself on .NET architectures (presumption here, that he hasn't deployed a full scale real world complex application based on a .NET solution yet, cause I didn't see anything in the article that says otherwise). There is no way he can know, at least for today, the complexities associated with deploying a real world complex .NET solution.

    Its like me trying to compare, Java (On which I have been working for 6 years now) and C# (which I haven't even started training yet) and then saying C# is better than Java.

    The other point is nowhere in the article does the author point out what makes him think that .NET solutions, will be easy to deploy and maintain over J2EE, except for the statement where he says that there are too many things (tools) that a J2EE developer has to learn (which is true) over .NET where everything right from the IDE to the DB and OS are M$ based. I ask myself this question "Should that be the only criteria on which I should believe the author and think J2EE will be obliterated??". My perception was the article would contain more fine grained differences between .NET and J2EE (like @ the code level or @ the deployment or more @ the stability/maintenance level) and give me a more better reason then the one stated above to think that J2EE will be blown to an oblivion.

    As the author states, M$ is improving its product line making it more stabler, so is J2EE (yes there are too many tools to learn) and its evolving. Moreover the important thing this article I think skipped is the $$$ that the client is willing to spend, there are J2EE compliant EJBServers (like Jboss for one) which are completely free and are pretty stable to be used in production systems. I see the competition between J2EE and .NET to be an evolving one rather than a *Fall of the republic, Rise of the Empire* :-)
  189. Well said Krishna, and the reason why the author does not go into detail as to *exactly* why you should go with a .NET solution is because of the same old argument from MicroSoft.
    Since Windows is EVERYWHERE, it only makes sense that eventually all things will be windows-based IF AND ONLY IF MicroSoft can produce technology as good as its competition. And as with past arguments, this is his point: that .NET is as good as J2EE, so why should we choose Java?
    Once again, if you start pointing out the failings of .NET architecture, the counter argument will be "Well, it makes sense to use .NET since Windows is EVERYWHERE". And if you point out the false rationale behind vendor lock-in by using one vendor's products, then the counter argument will be "Well, the .NET architecture is better." Which brings us back to criticism of the failings of the .NET architecture and blah blah blah blah...
    And thus the circular argument that will span hundreds of posts that never seem to come to any conclusion is once again upon us. In the end, the only thing that becomes apparent is all the fear and uncertainty in the air.
    Look now.. nothing's changed.
  190. Thanks Ted. I agree with your statement entirely, but I would have assumed the author, a man of 20 years of experience, to give me (a man of 6 years experience) more than the statement "Windows will be better than anything else in the next couple of years hence J2EE will die" when he is posting a thread called "Opinion: Java to J2EE to Oblivion?".

    The good thing is he does provide a theory for his conclusions, but at least for me the theory didn't go bang on target with his conclusions. I am not saying people shouldn't train themselves in other area's too. But...I think I will leave it here.
  191. Don't be fooled folks.

    Microsoft has an aggresive campaign try to get Java programmers to switch to C#.

    J2EE is here and available now. It works. It is widely accepted. It scales. It is cross platform. It has a rich mature API. There are tons of J2EE vendors. The implementations can be obtained for free.

    Applications can be distributed and transparently updated on the client side via Java Web Start.

    Applications can be successfully implemented as an applets with the Java plugin from JavaSoft.

    Don't be distracted by an inferior and immature proprietary technology. Don't let M$ dupe you into believing their FUD.

    Don't waste you time with C# when you can more productively spend your time using the Java/J2EE APIs?
  192. (1) I buy the argument that EJB is overly complex

    however

    The argument that .NET will prosper at the expense of J2EE simply because Windows is everywhere is invalidated by history. Java has grown to become the de-facto enterprise development environment INSPITE of microsoft's dominance. If his arguments were valid that the current state of affairs should not be true. We would all be programming in Microsoft technologies. During the period of java's growth did microsoft stop shipping development tools with ease of use features?

    Furthermore the statement "If you have a C# client then a C# server makes sense" flies complete against todays realties. The Web has taught us that you have to build your applications to support multiple kinds of clients, HTML, XML based, Wireless WAP, fat client, thin client etc.

    The article in fact is completely lacking in solid arguments for and against java. In fact the arguments for .NET don't even cover a quarter of one of the pages. I'm compiling a list of arguments from the technical, strategic and financial point of view, and I must say the list is orders of magnitude larger than his arguments.

  193. Hi Carlos,

    You say:
    >The argument that .NET will prosper at the expense of J2EE >simply because Windows is everywhere is invalidated by >history. Java has grown to become the de-facto enterprise >development environment INSPITE of microsoft's dominance. >If his arguments were valid that the current state of >affairs should not be true. We would all be programming in >Microsoft technologies. During the period of java's growth >did microsoft stop shipping development tools with ease of >use features?
    >
    >Furthermore the statement "If you have a C# client then a >C# server makes sense" flies complete against todays >realties. The Web has taught us that you have to build your >applications to support multiple kinds of clients, HTML, >XML based, Wireless WAP, fat client, thin client etc.

    My point is that things are now at a point of change driven by the massive performance increase of PC hardware. 1G to 2Ghz PC's was good, games run quick. 2GHz to 4 Ghz PC's... what do I need the extra 2GHz for? For running servers, what about 8GHz in a year or so... maybe 25GHz.

    So with PC performance going critical which OS will be the one. Many folks here think Linux, I personally recon XP and followups will dominate. Because of office products and games, and because their OS's are now OK. This is what is going to force the architectural and language choices over the next 2 years - the fact that many enterprise systems will run off a PC hardware spec. I looks like Linux v's windows will be the battle, and on the back of these Java/J2EE v's .NET. Hopefully it will be a two horse race and they will evolve in step.

    As I said yesterday, many here see Linux, J2EE and the many free software products winning. I don't for business and financial reasons I recon microsoft will wipe out Linux as the widely used mid size server OS. And I wanted some well informed opinion to stand against me, and I have had some.

    I form my future visions through argument - hopefully with good techies who also understand the wider complexities. And there are many of you here in theserverside.

    Jonathan
  194. Jonathan,

    I am now begining to doubt your claim that you are a "senior architect/developer". Your arguments seems to go against the face of reality. I made the argument that your arguments go against what has happened. You however argue back that now everything is different because hardware is now better. Quoted from you "My point is that things are now at a point of change driven by the massive performance increase of PC hardware."

    The much higher processor speeds and larger memory makes Java even proposition against Microsoft's technologies. It is known that java uses more memory than C++ code, however now that it is so cheap then the concern is marginalized.

    Let's look however at what you may be hinting at, that is, x386-based platforms are now becoming faster and cheaper than RISC platforms. However, their are multiple OSs that support these Windows, Linux and Solaris. Furthermore, again there is a fragmentation of the market, Pentium, AMD's 64 bit Hammer and Itanium. Furthermore, things like PDA use mostly ARM and MIPS based processors not x386 based. The world is in fact more fragmented than you assert, this is all in favor of Java as a solution.

    I can buy a x386 based pc based on say AMD's hammers new 8 way multi-processor and I am assured that I can run today's java based servers. I don't have the same assurance with microsoft's technologies. Do you think all the C++/COM based code will be ported overnight to Itanium or AMD's hammer?

    Truth, .NET is a dead end, just like DCOM before it.
  195. I think the most likely reasons for .net to place a serious dent in J2EE market share are not technical. Historically, Microsoft has brushed aside technically superior products due to their much more successful "business practices". As anyone with any real world experience will tell you, technical considerations do not always win.


    From a technical point of view, you will find some circumstances where J2EE is a better fit than .net, others where .net is better, and others where there is no clear advantage either way.

    Know both, use them wisely.
  196. FUD, FUD, FUD.

    Dear Jonathan Gibbons - please leave and return to the Microsoft school of information manipulation from whence you came.

    You psychops have no place here.
  197. One word: Spellchecker. (It's F7 in Microsoft Word.)
  198. Join the Dark Side[ Go to top ]

    One of the issues here seems to involve the complexity of J2EE. So much to learn, so difficult to use. And IMHO, this complexity is inherent in J2EE:-

    Sure, enterprise applications are complex whether they use J2EE or .NET. But J2EE has additional complexity because it has so many specifications, and so many implementations for each of these specifications, while MS has only one implementation.
    The lack of GUI development tools in J2EE is the result, and not the reason, of this complexity. But then, wouldn't we be needing a specification and lots of implementations for a GUI tool, too?

    This specification-implementation split is the reason why there are some 10 mediocre implementations for each of the specifications(don't get me wrong, all I'm saying is they
    lack friendliness and ease of use), while MS, with just one product for each area to focus, develops it to somewhat state-of-the-art level, with an almost artificial intelligent GUI.

    So we have on one side, the divided and corrupt
    Republic of J2EE and the Open Source - each
    vendor with different interests, limited by whole
    bunch of burocratic specifications they created
    through noisy arguments in the senate.
    On the other side, is the powerful .NET Empire.
    Efficient, no doubt, but dictated by the Lord
    whose misuse of power cannot be stopped.

    Should we join the dark side?
  199. Jonathan,

    Having read your thought provoking article (well you just wanted to be controversial for the sake of it did'nt you ?). I am trying as hard as possible not to call you a competent IDIOT. Why consider it ? you ask. Well boy you claim to be a 'senior java architect' but presto you don't even have experience of Java messaging. Read your assertion as below and consider how dumb it will make any architect sound. To make matters worse, you have not even used .NET !. Man what the heck are you smoking. As a mere java / j2ee developer (I'll stay modest, why bestow myself with a lofty title I cannot quantify ?) who has worked in mission critical projects for large UK based financial institutions, I find your article nothing more than a load of bollocks and a waste of time. I dont agree that you have conspired with M$oft on this one (M$ is not that stupid to choose a dumb architect like you) I am desperately diappointed with TSS for posting this time wasting junk - in fact TSS has gone down in my estimation here.

    One final advice, maybe you should consider using these technologies to the extent that behooves your title then return with a more rational article. Till then, may the Javalites keep jiving.


    You're the WEAKEST LINK and you're out - GOODBYE !

    <Jonathan>
    I won&#8217;t wonder into the territory of asynchronous
    communications and real time projects. I think
    Message Driven Beans (MDB) and JMS are
    great, and yet, even though my first career was in
    telecommunications I&#8217;ve not had to use either as
    a major component of a project for the last six
    years.
    So I will not comment, not because they
    are irrelevant, but because I have limited
    personal experience of them, and frankly doubt I
    will need either in my next projects.
    </jonathan>
    tier
    Mid
    tier
    Data
    store(s)
  200. Dear Chijindu Nwa,

    Nice try. I started in telecomms implementing full protocol stacks. I have implemented failover and sparing software at the protocol layer. I have coded async comms with network split at rejoin with all sorts of complexity which is now hidden within the j2ee framework.

    JMS aint hard. I used it in proof of concept. Its very very simple to use. Which is good. But most systems are not async. I find it amusing that the soap evangelists recon that async web serveces will be a panacia.

    Good luck with your career.

    Jonathan
  201. JMS is just another tool in your toolbox.

    Saying "most systems are not async" implies that the whole system has to be synchronous or async.

    Every system I have worked on has benefitted from being async in some places and sync in others.

    I don't think anyone is proposing that JMS (or another messaging system) should be used INSTEAD of normal synchronous calls - again, it's just another tool to be used where appropriate.

    Comments like yours, makes me wonder just how much experience of Enterprise Java you really have.
  202. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Another factor is the cost factor.

    Our core business systems run on a stack that (apart from the database) is almost free.

    Our company has had to get to where it is with very limited funds.

    If J2EE and Linux didn't exist we simply would not have been able to afford Microsoft products - consequently our company would not be here.

    It seems that it's only the big American and European corporations that are willing/able to spend their money on MS.

    What about the developing world? Africa, South America, most of Asia - do you think they can afford MS? Of course not.

    What about the schools? Of course not. That's why they're switching to Linux.

    Governments across Europe are turning off MS and turning on Java and Linux.

    And... don't forget China - do you really think they're going pay MS for several hundred million .NET licenses?

    LOL!

    Do not underestimate the rest of the world.
  203. Opinion: Java to J2EE to Oblivion?[ Go to top ]


    Microsoft had three years, one billion dollar, and some of the best programmers and software architects in the world available when they made the .NET. and in addition they could draw of experience from Java. It would be very strange indeed if the result was not any better than the aging six year old Java. And in my opinion the result is absolutely fantastic, astonishing, and surpassed anything I could have expected, a milestone in Computer Science history, more than a computer language, an operating system for the Web.

    Somebody that say that MS have no plans for .NET on Unix, I wonder how it is then, that everywhere in MS own examples they have expressions like this: Environment.NewLine.

    And they are not standing still either; right now hundreds of programmers are working on new business applications like CRM and others to run on top of the .NET operating system. Not the snail pace of JCP, driving in the fast lane.

    After reading the comments here, I understand better the saying "most people are dragged kicking and screaming into the future".

    RT
  204. Rolf,

    Neither Java nor J2EE are standing still either. While MS isn't encumbered with any sort of collaborative process similar to the JCP or pesky .NET vendors around the world offering competative products, they have a long way to go in reaching the level of product that J2EE offers. Both the Java language and the J2EE specification are continually evolving and will continue to do so. J2EE as a platform for EAI is one of the many areas where they will continue to dominate .NET as the initiatives in this area continue to evolve (Java Metadata Interface, for instance).

    Should MS actually drive an initiative for .NET on Unix (which I would be hard-pressed to believe until I actually see it), they would be well behind the competition (J2EE). My own experience, for what it's worth, has shown that Linux as well as other Unix platforms are not dead, nor are they dying. Mr Gibbons thinks that because of the speed of intel based hardware, coupled with MS office products and games, that MS O/S products will dominate (XP, etc). That obviously isn't an argument for running enterprise servers - maybe on the client side (like it is now, for instance, most corporations run MS as their main OS for the office worker). And it is certainly not an argument for wiping out Linux as a mid size server OS. Most architects, developers and networking staff that I know aren't sitting around waiting for the day that they can finally get off of Linux and get on to a Microsoft OS for midsize apps - there is no compelling technical or business reason to do so (that I can think of).

    I'm sure there will be plenty of people who move to .NET - especially those companies who are all Microsoft, all the time. More power to them. Luckily, there will still be one, maybe two companies that will stick with J2EE and I will hopefully still have a job.



    Cheers
    Ray



  205. Ray,

    Unlike Jonathan I think that Unix, and especially Linux have a strong future as servers. Unlike you, I see the .NET already far ahead of J2EE in every way.

    But, without having a presence at the Unix/Linux side, it doesn’t matter how good it is. So, IMO, everything depends on this issue.

    Funny, many in the Java community advocate that MS should be split. That is the absolutely best way to kill Java. Immediately the company that would be in the possession of the .NET technology, not longer burdened with Windows, could port to Unix/Linux.


    Regards
    Rolf Tollerud
  206. In my experience programmers like sync and will demand
    it when given only async. Why i am not exactly sure.
    Maybe async is just too different. Of course under the
    sheets it is all async and only a simple semaphore is
    required to make it sync, but conceptually the divide
    is wide.
  207. Jonathan,

    In your assesment on the fate of J2EE (doom and gloom in the face of the mighty .NET) you fail to acknowlege the community that is behind J2EE or rather the more market like nature of J2EE.

    Have you really thought about the jakarta effect ?. Do you know that many comp sci students are increasingly basing their research and or experiements on open source initiatives like jakarta ?. How would you compare this to the uni-lateral vendor only approach of Microsoft?.

    Now think about this as you go about re-writing what (if you are a quintessential English man) even yourself will now admit is a very flawed article which fails to stand 'Tall' amongst the ever crowded .NET / J2EE opinion stakes.

    I dont think you have actually evaluated the Jakarta effect and its growing momentum - well with all that amazing software that they churn out day in day out - mostly for the benefit of the J2EE community. So I'll give you the benefit of the doubt and withdraw my previous flame bait. So come on son - you've got another bite at the cherry.
  208. Hi Chijindu Nwa,

    "Now think about this as you go about re-writing what (if you are a quintessential English man) even yourself will now admit is a very flawed article which fails to stand 'Tall' amongst the ever crowded .NET / J2EE opinion stakes. "

    I found this the most silly reply yet in the thread. You say I must see my own artical as flawed. I laugh at you from a great height. You attack me based upon by nationality - get a life.

    I stand by it.

    Jonathan
  209. <quote>
    You say I must see my own artical as flawed. I laugh at you from a great height. You attack me based upon by nationality - get a life.
    </quote>

    Ho Ho Ho,

    Jonathan,

    Dont be silly, I was not attacking you from the point of your nationality. I guess you need to take some comprehensive lessons in your own language.

    You are the one that really needs to get a life for claiming to be what you're not and spending what I suppose was a saturday night coming up with an article that lacks any credibility whatsoever. For lack of anything doing, you have come up with a thought provoking article that does no more than 'make you a bit popular' (was that your aim?) with the community and promote what I would consider a dodgy consultancy (Tall software ? come on how daft).

    You still have'nt addressed the issue here, consider the community nature of J2EE and the jakarta effect and re-evaluate how it stacks up to .NET. Stop trying to avoid or spin away from it.

    Maybe my 'silly' comments will stop you coming up with such irrational articles in the future.

    Au reviour !
  210. Hi Chijindu,

    Nice counter, as you say, good bye.

    Jonathan
  211. There is always enough space for diversity in the world. There will never be only one operation system or application framework. Competition between .NET and J2EE is useful for both technologies. It’s obvious that .NET will poses certain segment on the market and many Java programmers switch to .NET but not all of them. J2EE has future living together with .NET, no worries about it. .NET wont kill but make J2EE better.
  212. Before I read the article I was expecting to read an in depth analysis of exactly how .Net is superior to J2EE and concrete examples of how .Net is simpler than Java. What I read was a holistic opinion that seemed to come from some magical crystal ball. First, lets talk about the company that everyone should flock to.

    Monopoly
    Microsoft has been found to be a monopoly in court. After reading the case, http://www.usdoj.gov/atr/cases/f3800/msjudgex.htm It is quite evident that they engaged in anticompetitive tactics aimed to reduce competition and assault the principles of a free market. They have been found to have exploited their powers in a particular market to dictate their will to dependent companies. Now, can anyone suggest with a straight face that they should put all their eggs in the microsoft basket and hope for the best? What about microsofts new licensing scheme, where people don't actually own any microsoft software, they just lease it from them. Every two years their customers are forced to upgrade willing or not at a price microsoft arbitarily chooses. If .Net does become the defacto standard for all software developement (an upsurd statement), are we to believe that they will continue to inovate or use their resources to attack any upcoming threat to their monopoly as they have done with java in the past?

    .Net licensing

    First, the whole .Net platform has not been released to a standard board, only C#. Since most of .Net is only a CLR facade to existing microsoft services such as MTS and COM and not a complete rewrite porting .Net to another platform would be a daunting if not impossible task. The only reason microsoft is supporting platform independence and web services is to cater to the desires of enterprises enchanted with Java. If in ten years there is only microsoft then we certainly will not see any openness of technology, only submission to microsoft. As any faithful reader of slashdot could tell you, microsoft always pushes the bounds with their EULA, most notably with the new windows media player stating that you must accept use of their digital media rights software and that software can deactivate any other software on your computer that "may" disable it. If your company spent thousands if not millions of dollars on .Net technology effectively locking you into microsoft, would you have any other choice but to accept such an absurd license and suffer the consequences?


    Difficulty of J2EE vs .Net

    I will first state that I am in no ways a .Net expert, nor have I coded any real .Net applications. However, I have read several articles on .Net and picked up the Wrox book and read some of it. My cursory impression was that it was near identical to Java syntax and offered no real quantum leap of technology. When the article stated that J2EE is to complex, I found it to be a vaugue statement. Servlets, JSP's, JNDI, and JMS are all easy to understand API's that are no more difficult than the standard Java API's. EJB's and connectors can be difficult at times to manage but I don't see how the they could have been made any easier. All of the concepts mentioned in the article exist in the .Net realm as well, if only by another name. As mentioned many, many, many times at this site, use the right tools for the right job. If you do not need EJB's and servlets and HTML templates work fine, by all means use the simpler method. After understanding the concepts of of scalability, failover, transactions and security, I am highly sceptical that any tool can take any arbitary piece of code and with the magical word abracadabra and make a managed component out of it. Of course, I am assuming all developement being done in Java and the .Net languages is with a text editor and ant and not an IDE, since Visual Studios .Net costs a few grand and for that price you could get a Java IDE like SunONE studio or Jbuilder. As a matter of fact, if removing the complexity of J2EE is of paramount one could use AltoWeb or BEA weblogic workbench.


    .Net moves forward, Java stands still
    Java is governed by the open JCP process. If there are things people don't like about java API's, they can read the spec and suggest enhancements to the specification leads. .Net is driven by developers at microsoft who have no real acountability to the end developers. .Net is sold as is, like it or not. As we have seen with .Net, when one side has a good idea the other side will try to mimic as much as possible and extend it, a virtue of competition in a free market. To say that .Net has and always will be easier than Java is an impossible statement to enforce. I am sure Sun has an ACE up their sleave and BEA, IBM, and Oracle will not haplessly sit on their laurels and lose marketshare.


    The Rumors of Unix's demise have been greatly exaggerated
    Yet another arguement that there can only be one operating system in existance and microsoft windows is that chosen one. Unix has been around since near the times of the computer inception and will contiue to be around. Why? because of it's simpleness and standard interface. Tell me, could a sysadmin from fifteen years ago using the microsoft OS of the time hop into a time machine and have the same proficency that a unix admin from the same time period could have on today's unix box? I find it difficult to believe that one could find the new technologies added to J2EE to be too insurmountable to learn but in turn believe that all the new bells and whistles and functionality of the hundreds of applications embedded into windows in each new release is to grasp and manage. Again we here the arguement that PC prices are so much better than server prices and that in turn all corporate computing will be done on PCs. This of course is a fallacy, since PC computers and Server computers are fundamentally different and geared at different types of computing. PCs are good at running interactive multimedia applications and servers excel at high bandwith and IO operations. A two ton Ford truck may be faster and get better gas millage than a Mack truck, but I would not want try try to pull a twenty ton trailer with one. The belief that in the future one will be able to expand their corportate enterprise computing by going to compusa and buying the parts is truely fantasy. There will allways be a server room for centralized management which will contain server racks, storage arrays, and server class computers at business class prices. With almost all flavors of linux supporting RPM's for installations and each with their own automated management systems and support, why would anyone pay thousands of dollars for microsoft server?

    I am not trying to bash .Net and say it is not a valid alternative to Java. Again, use the right tools for the right job and if a company is a microsoft shop and are content then by all means use .Net. I am against the lemming attitude mentioned in the article:

    "Managers will listen to and agree with the .NET marketing, sometimes forcing this to
    be the solution based upon cost and &#8216;hype&#8217;."

    All decisions should be made with the all the facts on the table and knowledge of the consequences for each choice.
  213. <quote>
    First, the whole .Net platform has not been released to a standard board, only C#. Since most of .Net is only a CLR facade to existing microsoft services such as MTS and COM and not a complete rewrite porting .Net to another platform would be a daunting if not impossible task.
    </quote>

    Just to be fair, the whole architecture powering .NET, not only C# as a language, has been standartised at ECMA. The Common Language Infrastructure (CLI) standard specifies the .NET VM (in Java terms) including a common class library, assembly file format, type system, bytecode, and metadata facility.
    In .NET, COM and MTS are being considered as legacy technologies and are not an integral part. Of course, for backward compatibility, COM and MTS are still supported, their support is tightly integrated in the class library but clearly they are not required.
    COM+ however is, as you say, an integral part of .NET, ".NET components" to be exact, the equivalent of EJB. The COM+ class library interfaces are abstract enough though not to require an actual COM+ implementation on other platforms, a .NET implementation on non-Windows platforms could even be implemented with an EJB container serving .NET components (just theoretically of course).

    As for porting .NET, it has already been done, successfully. The Mono project represents a fully-fledged Linux (more platforms to follow) implementation of the CLI and .NET-specific functionality, so the portability of .NET / the CLI cannot be questioned anymore with a clear conscience.
    Furthermore, an MS/Corel Implementation for FreeBSD is also available, as most of you probably know. The practical value of that one can be questioned though...

    Don't get me wrong, I'm pro J2EE and think it represents a huge step in the right direction, nevertheless certain fact should neither be ignored, nor perverted...

    Horst
    netarray
  214. <quote>
    As for porting .NET, it has already been done, successfully. The Mono project represents a fully-fledged Linux (more platforms to follow) implementation of the CLI and .NET-specific functionality, so the portability of .NET / the CLI cannot be questioned anymore with a clear conscience.
    </quote>

    A lot depends on how one defines success ;-) I would not call release 0.12 with many classes implemented at <= 50% a 'success'.

    Future of open source .Net on Linux can be extrapolated from these statements:

    Steve Ballmer, Microsoft's CEO:
      "Linux Is Top Threat To Windows"
      "[Linux is] a cancer that attaches itself in an intellectual-property sense to everything it touches."

    Jim Allchin, Microsoft's Group VP (Windows OS chief)
      "Open source is an intellectual-property destroyer, I can't imagine something that could be worse than this for the software business and the intellectual-property business."
  215. Just released! A good comparison of J2EE and .NET from JavaWorld:

    http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-j2eevsnet.html

    Ryan
  216. <quote>
    A lot depends on how one defines success ;-) I would not call release 0.12 with many classes implemented at <= 50% a 'success'.
    </quote>

    Well, it definitely IS a success. The CLI excluding the class library itself has been fully implemented, that was the major hurdle. The rest, while not being trivial to implement, is simply a matter of time, months. Don't forget, the project started only around a year ago and the .NET class library is voluminous...

    <quote>
    Future of open source .Net on Linux can be extrapolated from these statements:
    </quote>

    Isn't it logical that a commercial software vendor, more importantly an operating system vendor like Microsoft tries to battle against Linux and the open source industry in general? Do you expect them to welcome the competition, open source definitely is a major threat for them.

    I don't think that MS's attitude can stop the spread of .NET on non-Windows platforms. Major vendors are actively contributing to and supporting Mono, including Intel and HP. Microsoft would have a hard time stopping the efforts of the Mono project...

    Horst
    netarray
  217. <quote>
    Well, it definitely IS a success.
    </quote>
    Release 0.12? A definite success? I guess we have to agree that our definitions of success differ ;-)

    <quote>
    I don't think that MS's attitude can stop the spread of .NET on non-Windows platforms.
    </quote>

    Well, .Net is not yet ready even on Windows so other platforms are not a concern at this point. However, MS clearly has the power to stop it when it decides to do so (read again the above comments from MS execs and take a look at recent MS's move to stop CIFS/SAMBA).

    -- Igor
  218. Again, please re-read my argumentation, the VM itself is ready which is the heart of .NET, the most complex part of it. The class library is in the works and is getting more complete every day, actually most important parts of it are there and ready for use. Don't pick on the version number, that's clearly not an argument, 1.0 can follow 0.12 faster than you might expect...

    Firstly, .NET on Windows is a reality, it's there - neither BETA software nor anything else. It's here, please face the facts.
    I'm not trying to unsell J2EE, I'm just trying to clear up the myths around .NET and it's readyness / portability. Some people seem to be using them as kind of a self-protection utility, in order not to have to admit that .NET could very well compete with J2EE, even already today.

    The Mono project is protected by the CLI standard, which covers the complete runtime environment and some aspects of the class library. Microsoft cannot sue Ximian or other Mono contributers for patent infringement, access to any Microsoft patent covering an aspect of the CLI is implicitely granted to anyone as a result of the standartisation process, a clause defined by the ECMA. So, the CLI implementation 'Mono' can hardly be influenced by patent threats.
    The only potential field for attacks from the MS side is the non-CLI part of Mono, which is admittedly a major part of the class library and the .NET native interface P/Invoke. But, as the actual implementation can be done in a variety of ways without modifying behavior, MS will have a hard time finding a patent which is directly violated by Mono. Remember, interfaces cannot be patented...

    Horst
    netarray
  219. <quote>
    Firstly, .NET on Windows is a reality, it's there - neither BETA software nor anything else.
    </quote>

    Too bad MS does not know about that ;-) MS site still says it's ".Net Server Beta 3"

    <quote>
    The only potential field for attacks from the MS side is the non-CLI part of Mono, which is admittedly a major part of the class library and the .NET native interface P/Invoke.
    </quote>

    Would any responsible CIO be comfortable committing possibly millions of dollars to the platform that may be a subject of MS's future legal attacks? I highly doubt it.

    Anyway, good luck.
  220. Igor,

    <quote>
    Too bad MS does not know about that ;-) MS site still says it's ".Net Server Beta 3"
    </quote>

    That line has shown me that you haven't digged deeper into the .NET platform yet. The VM (including the complete class library) if you will is of production quality and ready for use. .NET Servers (alias SQL Server, Exchange Server) are products, you can compare them to Sun ONE servers (alias iPlanet, ...; please notice the analogy BTW) for example. So, the readyness of proprietary products surrounding .NET but not being part of .NET or the CLI have nothing to do with the readyness of the .NET platform.

    As for the risk, well, HP and Intel both must be crazy then actively contributing code to the Mono project. You can be sure that this is motivated by serious business interests, not just the fun of it...
    Borland, to name another player, will move all their development tools over to .NET, including the Linux development environment Kylix. Now, please guess how they'll enable .NET on Linux? Exactly...

    So, actually, I doubt that Microsoft can and will take action against the non-Windows .NET implementations. The more non-Windows centric vendors commit to .NET, the lower the risk...

    Coming back to J2EE, I don't think .NET will overtake J2EE anytime soon. The availability of production-quality non-Windows .NET implementations will be key to the acceptance of that platform. Mono will break ground in this area, though nobody can tell how developers will react...

    Horst
    netarray
  221. <quote>
    That line has shown me that you haven't digged deeper into the .NET platform yet.
    </quote>

    That is true, nor I have any plans to do so. Does "Jack of all trades, master of none" ring a bell?

    <quote>
    As for the risk, well, HP and Intel both must be crazy then actively contributing code to the Mono project.
    </quote>

    They are not crazy but they are very concerned. Here's what Bruce Perens, HP's Linux strategist said regarding Mono and Samba:

    "If we don't get that agreement [with MS], I'll be happy to see Ximian implement this stuff, but I'm not sure I'll touch it."

    "This means you cannot make a compatible implementation without potentially infringing on a Microsoft patent. We went ahead and did it anyway, and Microsoft hasn't enforced that patent, but it doesn't mean they never will. This is a telling case as they've taken what was an open protocol and deliberately put in a patent to close it and then introduced the patented feature in all new systems."

    <quote>
    So, actually, I doubt that Microsoft can and will take action against the non-Windows .NET implementations.
    </quote>

    I'd be cautious to rely on your legal advice ;-)

    -- Igor
  222. This is a much better article comparing the two technologies,

    http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-j2eevsnet.html
  223. <quote>
    That line has shown me that you haven't digged deeper into the .NET platform yet.
    </quote>

    That is true, nor I have any plans to do so. Does "Jack of all trades, master of none" ring a bell?

    <quote>
    As for the risk, well, HP and Intel both must be crazy then actively contributing code to the Mono project.
    </quote>

    They are not crazy but they are very concerned. Here's what Bruce Perens, HP's Linux strategist said regarding Mono and Samba:

    "If we don't get that agreement [with MS], I'll be happy to see Ximian implement this stuff, but I'm not sure I'll touch it."

    "This means you cannot make a compatible implementation without potentially infringing on a Microsoft patent. We went ahead and did it anyway, and Microsoft hasn't enforced that patent, but it doesn't mean they never will. This is a telling case as they've taken what was an open protocol and deliberately put in a patent to close it and then introduced the patented feature in all new systems."

    <quote>
    So, actually, I doubt that Microsoft can and will take action against the non-Windows .NET implementations.
    </quote>

    I'd be cautious to rely on your legal advice ;-)

    -- Igor
  224. Let's compare apples to apples. The basic .Net core CLR and C# are indeed standards, but what is a language without libraries? I see that the basic fundamental libraries are there, but what about the GUI, Database, and distributed component packages? Obviously microsoft owns their own implementations, but I have not seen anywhere where they have released the enterprise .Net library API's. This begs the question, is it legal for any open source implementation to use the microsoft API specifications or even the same syntax?
  225. More please...[ Go to top ]

    Hi Jonathan,

    Since you clearly emblazened the word "opinion" on your article, I treated it as I would an OpEd piece in one of my co-worker's "liberal" newspapers. I just rolled my eyes and went on about my work.

    I and others wouldn't mind engaging you in a serious, professional debate about this contentious subject. But you need more meat here and less fluff. Everyone and their mother has an opinion on this subject, and frankly, I grow weary of all this useless banter. Why don't you drop the opinion and present some well reasearched data?

    You can start by simply listing what J2EE components you find useless and why (hint: JMS is a bad example). And make sure you are talking about enterprise apps, because that is what J2EE targets. You can follow that by presenting a well-reasoned argument as to why you expect .Net to have a much lower learning curve. After all, there are plenty of new acronyms there to learn as well.

    If your only goal is to get everyone worked up, then you have done just that. If your goal is to expose the truth about these competing platforms, then I would suggest a different tact. Share your experiences and question others in the community. Brush away snide remarks with your tough skin and look for well-reasoned (there's that phrase again) remarks that come from experience that is rooted in fact.

    I think you have accidentally prompted a few interesting responses, which is why I am still here. But alas, it is like mining for gold in a river bed.

    I would *really* like to hear more about how .Net stacks up against Java/J2EE. Anyway, I respectfully wish you the best Jonathan...

    Regards,
    Bill
  226. <quote from the Tall Software site>

    Tall Software has been working in Java since 1996, producing on-line games, applets and API's. The content of the site ranges from the fun (space invaders) to the developer tools (LowRoad and the now retired Thong).

    </quote from the Tall Software site>

    Now please read that quote again and guess what I think. As a boy I learnt Basic on the Apple II in two hours and I liked it. When I studied I learnt Pascal on a PC and I was very fond of it. It could do all I wanted! After that I got a job and learnt Dibol (an obscure but powerful Cobol variant by DEC) on a mainframe and I found out that language was far more suited to write real business applications, what I was paid for. We made fast, secure, scalable and reliable applications and when our language ran out of possibilities in only a few situations there always was assembler for the odd hacker. Some of my now fifteen years old applications still run... After that I learnt many other languages and environments and I was never as happy about them as when I learnt Basic. That is experience, I learnt to see problems instead of possibilities. So I became a systems architect. Now I see future in .NET and in J2EE for different jobs.

    Jonathan, you have been building games, applets and api´s, not business applications. Your work probably is a lot of fun in .NET, maybe you should have never used Java for that although I think it is well suited for that and it is handy to just have to learn one language. I don´t really think your experience gives you the right to make the claims you do. Each development environment has it´s own strengths and I think you have not yet needed to exploit the ones available in J2EE. You also miss the point about what is important to businesses. .NET has offerings and J2EE as well. Choose whichever appropriate but be clever enough not to call either one dead as they both are alive and kicking!

    Hans van Buuren
    Senior Systems Architect
    Amsterdam Police Force
  227. Hi Hans,

    yours is another post attacking the author. You take a quote saying I write a few games. This is the stuff I do outside the day job, kind of hobby training.

    The day job is the enterprise stuff as a consultant. And its global, and its for tier one financials, and its for info feed providers.. blah blah. I have indeed been walking the walk as well as talking the talk.

    Unlike yourself, who loved basic the best and so gave up coding to be an architect, I love Java the best and still code like mad, as well as do architecture.

    Why do folks like to attack me, rather than provide robust alternatives to the vision? .Net v's Linux was the state of the debate over the weekend. I'd love to pursue that, with someone saying why its not .Net v's solaris or one of the other big established unix vendors. And no one even cites BEA - you all recon they are doomed by Jonas & Jboss? Open up the debate... does anyone have any thoughts on how mobile platforms effect the choice - because they are going to go massive as well.

    Jonathan
  228. Hi Jonathan,

    I did not really stop coding! Would be hard to do (for my work but also for my personal feeling), just don´t tell the rest of the management. Other than that I did not like Basic best, learning it as my first language gave me the biggest thrill. As a programmaming language it is rather poor though it usually depends on what you do with it. I am sure I can code better and more structured Basic (have not used it for over twenty years) than some other people can code Java. Anyway, at the moment I have a feeling for J2EE. And as a job I do architecture and I must say, it takes all the time I have. Looking at the broader picture and talking about it to both developers and management. And other than most messages in this thread I think 2,000 interactive users for an application is well over .NET´s capabilities, I would surely stop at 200 or so.

    People like to attack you because they have an instant feeling what you say must be wrong somewhere and every reply that attacks you goes into one of those feelings. You must see they have a right to these feelings. Not having installed .NET Studio hardly gives you a chance on having a good meaning about it. Your experience I quoted from your site.

    Anyway, this topic gives me a lot a good opinions!

    Your question about mobile, I think the way to go is probably best described in the very good document J2EE and XML which is downloadable from TheServerside. In fact this solution with XSLT can be built in both development tools.

    Hans
  229. I think Jonathan’s point here is that lots of stuff we do in J2EE is interesting and keeps us all amused but is it getting easier for the average developer to deliver apps? Sure if you use all of the disciplines of J2EE correctly you’ll end up with a rock solid app. However you’ve got to work very hard to achieve it.

    Whilst I am no guru on C# and .NET what stuck me was that features such as exception handling and connection pooling seemed to have been designed so that regular developers, not knowing exactly what they are doing, will end up doing stuff that has a chance of working. Exceptions that aren’t caught and logged won’t end up disappearing on some console that no one looks at and connection pools will be created for developers that have no idea of the concept and why its important. Sure we can dismiss all this because we are all very smart and know what we are doing…. However how many of us can relate to the stories in Bitter Java?

    I am not saying that J2EE is dead but lets not fool ourselves about its complexity. Most organisations cannot afford to employ a team of guru’s. We need to have technologies that enable regular developers to achieve exceptional things. Without this development will increasingly be priced out of Europe and North America…

    So many times we ignore good ideas because we don’t like the company that came up with them. When you stand back and think about this that isn’t the smartest way to react.

    Quentin
  230. There are a series of articles on language evolution, especially related to Java and C#. If you're a senior architect I recommend reading them.

    A conclusion of these articles is that Java needs to evolve both component and domain oriented features.

    Another conclusion drawn is that .NET is vunerable, because it hasn't evolved domain oriented features.

    As a footnote the ACE project from Sun creates a domain oriented version of Java. Goslings avoidance of J2EE may well prove a political master stroke.

    The articles are in the following order:

    http://www.softwarereality.com/programming/language_lifecycles.jsp

    http://www.softwarereality.com/programming/component_oriented.jsp

    http://www.softwarereality.com/programming/component_thinking.jsp

    http://www.softwarereality.com/lifecycle/roi.jspsign/domain_oriented.jsp

    http://www.softwarereality.com/lifecycle/roi.jsp
  231. It's always the same things with microsoft against the rest,
    Microsoft does make some simple products, that are easy to use and doesn't need to much knowledge. .net is the simple answer to j2ee but it will be less configurable less robust and adapted only to small systems, like NT against Unix, like IIS against apache.

    There's room for both technology, windows did help people using a pc like .net will help part of the industry to use ditributed server.
  232. Hi folks,

    I did not see much real world comments about this so here is a summary of my experiences in both .NET and J2EE.

    About a year ago, the company I work for built the first .NET website in France. I was part of the project. My background was mostly Java based since that is what I learned at school.

    Now, although I knew *nothing* about .NET, C# or ASP.NET, I picked it up while it was still in its early stages (VS.Net Beta 1 I think). I learned how to use it in a matter of days and got better really fast as days went by. We built the entire website with all the bells and whistles using a n-tier architecture, fully dynamic backoffice, UML to C# code generation, (insert favorite buzzword) in no time.

    On to Java now. The current market trend, at least in France, is in favor of Java. Therefore people need Java/J2EE developpers. So I started learning J2EE just as I learned .NET. As I said I had a Java background so I just needed J2EE. I never thought it would be that difficult.

    Where most of the .net tasks needed only a few clicks I found myself drowned trying to get these application servers working correctly, configuring webservers, trying to get the IDE working as I wanted (tried netbeans, eclipse, jbuilder ... still not satisfied). I spent most of my time on the environment and not on the code. Making 4 or more applications designed by different groups or companies working together is a very painful process.

    The technologies in themselves are similar to the ones in .NET, that is for sure. But I think the java tools are not up to par with MS tools, in terms of ease of use, integration, fast access to relevant documentation etc etc. (I can go on forever on that topic ... ;)

    Overly difficult to learn. That's my view on J2EE. It works, it gets the job done but the learning curve is clearly in favour of .NET. The technologies are easy to learn. How to use them is not. Where is the J2EE documentation ? Everywhere and nowhere is the answer, somewhere on the net there is the piece of info you need. But it takes minutes (or hours) to find it. MSDN may be a huge pile of info but if you need something it's in there and it's quite simple to find it.

    Now about the technologies themselves. Well ASP.NET has good visual designers which IMHO is a good point. The jsp designers I saw were ridiculous in comparison. ASP.NET has a nice and extensible component model that makes reuse quite easy. Clean code separation is a good feature too.

    ADO.Net and JDBC are very very similar.

    C# is really like Java cleaned up a bit, it has IMHO a better event mechanism, real properties (not only accessors) and attributes are a quite powerful thing but overall it is almost the same.

    The .NET framework is simple and elegant, most classes are at the right place, provide relevant services and their use is very straightforward (most of the time you need no documentation at all). I found myself struggling many times with the java API because it lacks this "intuitive" feeling.

    .NET XML documentation works like javadoc but it's better integrated. You type in the documentation for your class, method, whatever, next time you use Intellisense, the documentation shows up. Nice and easy.

    I tried to keep a developper point of view without getting caught in the "MS is evil" thing or messing with the business side of the problem. I made my judgement based on experience so take it for what it is. I am far more productive in a .net environment and I think this will be true for newcomers aswell. Now a J2EE guru may argue that he can do anything .NET does using java technologies and he will be right. It just happens that the .NET way will most probably end up being less time-consuming, at least for newcomers.

    I think .net will slowly take market share until a balance is found (somewhere in the 50/50 or 60/40). Don't worry this is good for the industry. Competition always is. J2EE is not perfect, .NET is not perfect. Let them fight, we get the benefits anyway. Learn both if you can. .NET is easy to learn anyway, especially if you already master J2EE, so why not give it a shot ?

    By understanding how .net is better than J2EE on some points and how java is better on others you will create a need in the java world that will be answered with better java solutions. I do not believe you absolutely HAVE to learn it, just that it would be a good thing.

      Julien Adam
  233. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    I guess if Java would *only* run on Solaris, SUN *could* have the same 'integrated' toolset for J2EE by now....

    Aside from the J2EE vs. Net issue, I still like developing Java code much more because of all the great tools that *do* exist. Not the least of them being OpenSource !

    And also, is there a thing like the JCP in .Net ?
  234. There are some valid points and I think we should be a little bit more open to .net and what the Java Community can do better.

    I think these artictles do have a place of the site.

    The recent javaworld article:

    http://javaworld.com/javaworld/jw-06-2002/jw-0628-j2eevsnet_p.html is both better written and more balanced.

    John
  235. I disagree with this article in many ways. The main problem I find with it is that it makes a prediction about what CIOs and CTOs will do based on the considerations of a lowly software architect. Regrettably, this approach is flawed. Executives will pick Java or MS depending on their own past experience. Some probably have always worked with MS and would never choose anything else. Others know MS and will go with Java so as not to get stuck.

    The one prediction Mr. Gibbons fails to make is quite how far Linux will spread. To me, the fact that Linux has become an enterprise OS at all, and with such speed, clearly indicates that Linux will become the obvious choice for all computer systems that are not already married to MS. I also think that Solaris, AIX and HP-UX will almost disappear in favor of Linux, but it will take many years.

    But I agree that while Java is simple, J2EE is not. The spec is full of problems, and it is evolving far too slowly. But to me this just means that Java has outgrown Sun, not that it's going into oblivion.

  236. I don't know about you, but no matter how good MS technology is on Windows it is still a vendor lock. Do I need to tell you why thats bad?

    CIO's, Architects and Team Leads owe it to their company to encourage not only interoperability which .Net and SOAP may allow, but platform independence (.Net does not run on anything but Windows).

    If MS ever allows companies to create supportable cross platform versions maybe there is something to talk about. If MS can reduce development time a little thats great, but won't make up for the cost of using Win2k vs. Linux or buying VS .Net instead of using emacs and J2EE with open source and free technologies.

    Rich
  237. Interesting, however a few things:<br><br>
    1. cost. as m$ wratchets up its licensing fees (and other questionable behavior), expect more people to look elsewhere.<br><br>
    2. j2ee itself. you don't *have* to use ejb or all the other technologies in j2ee. one of the biggest strengths of j2ee is being able to mix and match various api's.<br>,br>
    3. scalability. not just server scalability, but project scalability. i'm working on something now scripted via iis and the more people that join the project, the harder it will be to scale it. m$ pushes scripting as an acceptable means to write a project, but after a while it becomes unmanagable. people get burned and hopefully learn, as i have. you can 'script' with jsp, but in jsp/j2ee mvc is promoted much more and facilitated better than in .net.<br><br>
    4. marketing hype != real world. a lot of companies still have not migrated to XP. why would they all the sudden migrate to .net and the upgrade fees just because? it is assumed that .net is a shoe in, but with the economy in the dumpster right now, it makes sense for IT departments to be conservative and not change anything unless they have to. so if you wanna believe the marketing, go right ahead.
    5. linux. i think linux will do fine in the midrange market.
  238. Is this yet another J2EE vs .Net debate? I read the article and there are no compelling arguments in it other how m$soft dumbed it's .Net API with GUI tools.
    See ya, I've got work to do.
  239. I think I am getting tired of MS marketing sales pitch.

    First they said Java is not a good language and it is too slow. Now after 5 years when every one is developing application in Java (80% of the market) they are saying it is too complicated. Well in my opnion a person who has not looked at .Net can say the same of .Net is as complicated as ever(dll hell). MS best marketing pitch is that VB is gonna be fixed in next release ....well was it ever fixed ? Now they are singing the same song .Net is gonna get better on the next release just wait well the Business cannot wait for MS releases. I have seen all the 5 year old VB code had to be rewritten as the compiler changes so much with each MS releases. Where as my old Java code 5 years ago has very little changes why because Java Framework like UNIX is solid. We can wish for the Moon with .Net but Java is here to stay and it will keep on growing. I am kind of awed when the author thinks J2EE is confusing not sure what he has been doing but reading MS marketing pitchs. The reality is Java is here for good and please donot post these kind of marketing cr*p at server side.
  240. Good stuff except:

    "Marketing and business sponsors will start to
    promote fat clients over web GUI&#8217;s again."

    I'm not a believer that the fat clients are going to pull a phoenix move an replace web GUIs. Just becuase there is a shakeout with all the dot-com failures doesn't mean that the web paradigm is a failure...who wants to maintain fat clients these days.




  241. >>who wants to maintain fat clients these days.

    Users. In some cases they will force us to.

    The reality is that web interfaces are only good for certain kinds of applications. If you want something more than a trivial degree of client-side functionality, a browser-based client isnt suitable. Heavy usage of javascript/DHTML results in stuff that is not only difficult to maintain, but its also flakey.
    In my mind, its conceptually wrong to try and replicate the desktop environment in the browser. There are some impressive projects (webos.com) that have tried, but havent succeded.

    While Applets have lost favour, it really amazes me that not too many people see the benefits of JNLP (in fact a lot of posts here seem to think that applets are the *only* java option). Java WebStart (and other JNLP implementations) give you the same maintenance/security/etc benefits as applets - with none of the restrictions. JWS can even auto-download JVM's if your client app requires a particular JVM version. (Other implementations give you auditing, centralised logging etc - the sort of thing that are important in financials, John)

    JavaWebstart is a very powerful tool for us (though granted, we are not writing apps for a mass market). Its free. It gives us the ability to deploy serverside applications - and with an unrestricted client-side environment. And now with JVM1.4, its ubiqitous.

    Java Webstart & Applets: Same-same-but-different.

    -Nick

    (slightly tangential argument - but anyway)
  242. who wants to maintain fat clients these days.

    >
    >Users. In some cases they will force us to.

    Good point Nick, that's exactly what I've seen with some of my
    customers.
    The browser is simply not suitable for all client functionality.

    Incidently, PriceWaterhouseCoopers' technology forecast:
    2002-2004 lists
    "A Return to Non-Browser Clients" as one of their significant trends
    in Software.
  243. Just my $0.02 regarding this swing and j2ee complexity debate:

    - You can do wonders with Swing of course, but to do that you need a senior swing developer. The truth is that typical work force of this industry is %90 junior developers/%10 senior developers really. The pace of change and the team environments/etc all help create this junior developers army.
    - The same is true about J2EE's complexity too. There's no debate that for complex problems there's no other solution than a complex solution. But these complex problems are less than %10 of all projects. For the rest of the projects the biggest influential factor is money/time/workforce and J2EE is weak there. It's complex because: it's older than .Net for example, the tools are not that good really specially for novice developers, and some APIs are simply flawed imho (what comes to your mind first? Entity beans as usual!).
    Another interesting note: sure you don't have to use all bells and whistles of J2EE (EJB or JMS for example) but this industry follows fashions aggressively, just look at the webservices hype for example, and EJB is a hype, if you don't use it you'll be questioned by your manager or coworkers who think the article they've read the next day at Sun or IBM's site means EJB is great and you'd better use it. So this hidden fashion factor even impacts and leads to many many projects using the wrong APIs for their task in hand.

    Ara.
  244. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    reply to Ara -

    One doesn't need a senior swing developer. You can do databound controls and such with Java IDEs too. To do good Swing GUI you may need a more experienced developer or a good book. The same is true for MS.Net. One can easily continue to do the same old thing (databound controls or get data from recordset and add to control) in MS.Net or struggle try to figure out how to do MVC.

    The problem is that we have too many people who don't know what they are doing, doing this type of work or being involved somehow. (Watch "The Sixth Sense") So now we have to cater to these people. Can some of it be simplified? Sure.

    J2EE as a whole may be complex (I would say 99% otherwise). The problem is that doing J2EE doesn't require JSPs and/or EJBs. And if one uses a good tool, creating, maintaining and deploying EJBs is not that difficult. Of course you might run into the same problems you would with .Net but one needs to compare apples with apples. And for simple apps, you probably should use little if any of J2EE, which would bring one closer to what is available in the MS.Net toolset.

    As for the industry following hype - see my above comment.
  245. The concensus seems to be (from the junior programmers anyway)that the junior programmers can't do a bloody thing unless they have all of the drag-n-drool GUI tools and that J2EE is just too complex to learn. Which is scary because it certainly isn't rocket science. And you use what you need of J2EE for the scope and scale of your project. Apply your brain et Voila!

    I also feel that the speed of PCs is not relevant to the adopting of .NET and an all Microsoft stack. In fact, I believe (and seem to see in practice) that cheaper PCs mean an upsurge in use for Linux on much more high-end servers than had previously been used. Or if people are building Windows 2k servers, they are putting J2EE app servers on them, not running en masse to .NET. That's just the trend I have seen in my own life.

    I've also seen a few arguments as regards web services and how .NET is so good at allowing the development of said services. Maybe - but web services are only a fraction of what you need enterprise-class applications for - and despite MS's wishes, aren't the end of the story by any stretch.

    J2EE is maturing quite nicely. Yes, since it's a semi-collaborative process, it takes longer than the top-down approach that works so nicely for Microsoft. The tools base is getting better all the time. I'm a big fan of JDeveloper from Oracle (some like it, some hate it). And I love the competition amongst the app servers. I cut my teeth on Orion and while it had a somewhat steep learning curve I can move among the different vendor's products with relative ease with the knowledge I gained from that experience, with added benefit that I can also tack Oracle's j2ee stack on my resume as well (as long as I keep up with the changes to Orion's code-base).

    Thus, I can say that there hasn't been one compelling argument to move to .NET when J2EE itself is such a solid solution on any platform, including Windows. "This one goes to 11." (N.T - This is Spinal Tap).


    Cheers
    Ray
  246. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Just to support Ray's usage of Java App Servers on Windows. We are using it just fine too. Other than Windows OS and Windows networking and security issues. Why Windows? That is what servers the had. We are looking at Linux. Both server and client. And on the server - Intel and Mainframe. It will be no problem to move our apps, client and server, to Linux.

  247. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Who wants to maintain 'Web apps'? There are a few techniques for deploying 'fat clients' with Java. All not that difficult. And I can switch easily between any of them for the right situation and mix.

    I agree that the shakeout has nothing to do with it.
  248. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    "Who wants to maintain 'Web apps'?"...

    people who don't want to spend time and money having to deal with the headaches that are inherent with having to worry about client configurations, installation, versions, security, communication, administration, and evolution.

    That is an incurred cost both upfront in conception, design and implementation as well down the road.
  249. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    people who don't want to spend time and money having to >eal with the headaches that are inherent with having to >worry about client configurations


    You don't with non'webapps' if done right. So with web apps you don't have to worry if the client has the right browser and the right version and the right settings ...

    >installation
    I can do fat clients by installing NOTHING on the client.
     
    >versions
    Problem solve by, at least, the above,

    > security
    No less an issue in the browser - and maybe more so.

    > communication
    For a 'web app' to work, the user must be connected. A fat client doesn't. And the communication choices are wider.

    > administration
    How is this easier in a web app?

    > and evolution.
    Not easier in a 'web app'. Is very difficult to maintain separation of UI and business logic within a Web App with any sort of complex UI.

    I would say Web apps cost more all around if the right deployment technique is used with the 'fat client'. And the fat client is more flexible and evolvable.




  250. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    installation

    How are you not installing anything on your clients? We're talking about fat clients right? Are you referring to applets or such?

    >versioning
    Well if your not installing something but you are in fact relying on the downloading of application data to be executed on the client machine then you have to worry about what's running on the client machine (i.e. jvm) and you further have to worry about if they even have the required binaries.

    >security
    You have a point if we are discussing encryption. But in addition to this I'm thinking that if your not writing this fat client to run on identical system and networks then you have to deal with corporate policies regarding port availability and protocols accepted.

    >communication
    Related to the issue above. On the face of it, it does appear that your options are wider but depending again on where the clients are to be deployed you options may in fact be severely limited.

    >administration
    Here I was thinking that in a highly configurable system your able parameterize and declare system attributes. Which you are able to switch at runtime, these go into effect the next time that piece of code is executed. While in a fat client where most of the processing is happening on the client, it&#8217;s working autonomously for a good portion of the time.

    >evolution
    In a situation where architectures are equally well defined, say using the well know mvc pattern. Then it's going to come down to logistics. For example, a simple change in a gui like applying new makeup is easy using a web gui. Something that may be accomplished by a low-cost html or jsp/asp/php whatever programmer. This would require someone more substantially experience with the fat client approach.

    With that said I want to add that I'm not blind to the fact that you simple just use a web based thin client/server in all circumstances. Like where I was recently involved with a project that needed to transfer hundreds of thousands of records for data integration.
  251. OK guys,

    Lets face it Java+J2EE and .NET are equal by
    - intent;
    - targeted auditory;
    - architecture (from high perspective);
    Implementations and base theories may vary.

    Complex problem CANNOT have simple solution, so J2EE and .NET must be complex ones.

    Java/J2EE - .NET / Unix &#8211; Win / SQL &#8211; Querry builder/ etc.
    There is a pattern:
    Knowledge driven solution we must tailor for ourselves &#8211; Prepackaged fast-food.

    Initial learning curve- easy long run / easy start &#8211; fighting shortcomings later down the road.

    There is always much more room for fast-food than for high quality products.

    Another thing to remember: fool with a tool is still a fool. But with prepackaged solutions that fool looks better because he applies that was prepared for him by some smart person. MS products are not bad; they are just targeted toward prepackaged typical solutions, which is fine. We are trying to avoid duplication of efforts :-), aren&#8217;t we?
    Just look at any pattern catalog (Core J2EE patterns).

    I value prepackaged solutions and study patterns, but I do not like MS solutions. Why?
    Because they go too far and usually consider me to be a complete idiot which has no right to think differently than tool developers. (We often carry the same attitude towards end users. Do we?)

    Yes, I should admit that in 99% cases I may be wrong and developers, who fight a certain problem know all hidden problems and solutions better (I will never try to code RDBMS myself), BUT I know my problem better then they do. I study patterns to be able to differentiate between true unique problem and lack of knowledge about typical solution.

    Another reasons for the discussion to be hot:

    - There is less and less room for creativity in programming (who will start to code new text editor tomorrow?)
    - Prepackaged solutions are good enough in most cases (how many of us ordered custom built car?)
    - There are less and less limitations from technologies and more from our mindsets.

    I would say that talented person who knows any given technology very well is able to produce much better results, than that person with excellent tools and theories but without abilities.


    About Swing: don&#8217;t even tell me that Swing is less capable than HTML. There are better GUI API are possible, Swing&#8217;s one is not bad. Just take a time and comprehend intent and theory behind the framework. I would create quite complex Swing GUI(and maintain!) without worrying about ANY gui-builder just because I decided to learn how layout managers work some day.
    Do I consider it to be best approach? No, coding in Delphi for some time I did not see anything comes close to Delphi in terms of GUI power/simplicity. BUT my hand coding GUI is way simpler to develop and maintain than MFC/ActiveX based frontends, which are built with MS VisualStudio.
    Try to convince me that Swing API is more complex than JSP/Servlet/HTML/JavaScript/Applet mess. Any attempt?

    Summary: learn, study, apply, then think, then study and so on. Do not bash competitors blindly, try to understand why things work in certain way.

    Intent: focus the discussion (start a new one?) on real needs of developers and why one approach is better than another.

    Nobody should die, just make own informed decision, share thoughts and concerns and do not try to earn all money: it is not possible anyway and money are not eatable after all :-).


    Just for info:
    I have MS free home and I admit and tolerate some inconveniences in Linux. That is my free will.
    I do work with Win and Unices and architect solutions to bring strength of both worlds together, sometimes they are more Win tech based, sometimes not.
  252. Jonathan,

    First things first, you need to go back to school and learn how to spell or you can use the .NOT spell checker! As for .NOT, I've been on the MS Treadmill before and I'm not going back! Competition is great and I agree that MS is forcing Sun to dig deep and offer superior development products / tools. This is a GOOD Thing! I'm not convinced that people want to run back to MS and use proprietary software API’s and/or Win32 API's. .Not does not offer interoperability, you are forced to run the MS O/S of choice, whether it is NT, XP or tomorrows XYZ. I think there will be some co-existence between Java and .Net, but I am a firm believer that .NET will not be as popular as proclaimed. Look at the huge amounts of Marketing Hype that MS is touting, they are trying to convince people to come over to the DARK SIDE. Isn’t freedom of choice a much better solution? … followed by Open Source projects that will run on any platform? As time progresses, you’ll see that .NET will look a lot like Mike Tyson in his most recent fight! ... THE LOSER!
  253. What an annoying post :-(. Poor arguments, poor conclusions

    Let's hope Jonathan and all MS Lovers who post on the server side go to Oblivion ...
  254.     I agree with you to some extent as to the complexity of J2EE and sometime some stupid java developers try to complicate things for no reason. Most of the projects can be done without going into too much deep shit of CMP, using weird transaction settings, then struggiling whole life to to configure and maintain it. Also the way new J2EE specs,Servlets-JSP specs, other java tech is coming up in market, it confuses more than to help sometimes and very hard to keep up with.
      But as for .NET, i still think it has to mature. People think its fast development, but its also MAINTAIN forever systems. MSFT will definately stabilize in near future, but then I havent seen many .NET developers using any real OO programming skills yet. they stil have the old procedural way of writing code....start to end on one page

      Regarding UNIX, I think LINUX is going to take its market over pretty soon, unless companies like sun make their servers - Solaris 8 very cheap and improve on customer service. Right now SUNW has oneof the worst customer service.
      Regarding future, I m not sure who is gonna be where. But SOAP, Web services , XML is definatly the future of the industry. Then its upto us to use it with .NET or JAVA. ...
       
      
     
      

       
  255. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    One thing that I notice in my relatively limited experience is that Java seems to force more architecture thinking / planning up front than the MS environments. I don't know how much .Net inherently changes this, but my general perception is that everyone I know doing Java is always talking about architecture as the conceptual framework for a project and everyone I know working with MS is always talking about coding as the framework.

    OK, over generalization. But, I wanted to suggest that Java and J2EE specifically would benefit in its competition to .Net with tools and especially consolidated information that helps junior programmers get things done faster and better the first time.

    I think the MS disadvantage, that has been pointed out here, is that lots of junior people getting things done faster the first time doesn't mean these same people are inherently going to be better at realizing more elaborate enterprise architectures. MS seems mediocre as things get the enterprise issues get more elaborate, and I think J2EE has the lead in many ways with regards to this.

    But, the flexibility (or, too many options) of Java and j2ee is part of the problem with getting rolling on lots of projects that start with less elaborate issues. I personally have seen a number of projects where junior Java developers having to code without a final architecture or senior Java architects not getting the architecture done in time were what made the project fail.

    Java really makes a promise of scalable, enterprise architecture, but one needs to make a lot of decisions up front about how to get there.

    I am talking specifically about web apps (with multiple client types), and specifically about what is beyond JSP with embedded SQL and beyond JSP with classes / beans with embedded SQL. At this point, we get into things like:

    EJB vs JDO
    2-tier Object/Relational Mapping tools
    3-tier Object/Relational Mapping tools (e.g., ObjectBridge)
    CMP vs BMP
    CMR
    Stateless Session Beans vs Entity Beans vs Both
    MDB
    Webserver embedded in Appserver vs separate

    I am not suggesting there is a one size fits all tool / technique that is going to encompass all of this, but I think it would be helpful if we had some more singular resource for tools that helped people get a lot of basic projects done fast with J2EE that also have real promise of enterprise scalability.

    So, I know things like this exist, but I am suggesting the Java community is not doing well competing with MS when it comes to promoting J2EE tools in the "see, it is fast and easy to get j2ee projects done" category.

    To me, Jakarta is the thing that comes closest to this "get rolling fast with Java" brand, but it needs more enterprise architecture tools (like maybe an EJB enabled Torque?). Jakarta and other OpenSource Java offerings opens tremendous means for new and junior programmers go to far with Java fast, but I think a better path from this to at least the EJB and O/R persistence aspects of enterprise applications would promote Java further.

    j f
  256. As someone who insist on focusing on the future, the author certainly makes some pretty radical assumptions. He assumes that in the future most enterprise development will remain slapping a web or fat client interface on top of some RDBMS (in which case the full stack of J2EE is certainly an overkill, a servlet+java bean+jdbc suffice), or that a midsize enterprise project will still entail supporting 1000-5000 users (despite the recession, many small mom&pop e-tail shop had grown, in the past year, to getting 1k+ unique hits a day, excluding those from bots), or that license cost will still be irrelevant for his future employers.

    Forget mCommerce, or integration of geographically disperse data sources, or interop with legacy/mainframe applications.... I am sure M$ will have answer for all of these, but it's far from clear that they will be as simple as ASP.Net, some are not yet available in the current .Net SDK (which perculiarly, the author has yet to install and evaluate, before he makes this sweeping conclusion).

    As for complexity, it's the job of an architect to establish patterns, frameworks, and core organization wide API's, so that programmers can get the benefit of a subset of whichever technology the organization adopts. It's certainly not as simple as point and click, but once the core infrastructure is in place, a few line of code can produce a concrete object that leverages the plumbing that's already in place.

    The reality is that the so-called "Simplicity" comes with a price. In addition to vendor locked in, large amount of machine generated code set can potentially cause maintainence troubles. How are the database connections made, when is it using SOAP, and when is it doing .Net Remoting, where is it encrypting XMLs? Chasing down these details may end up taking majority of developer's time when one needs to plug a security hole, perform optimization, or loade and behold migrating to the next IT fad. Maybe these issues will magically go away in the future, but they're important to me today, and I'm willing to bet that they will be in the future.
  257. THATS JUST PLAIN SILLY![ Go to top ]

    No offense here...but are'nt you suppose to be showing support for things that you are part of (intentionally that is)??? I just cant see why someone doing a living on something (JAVA in this case) can be so pessimistic on what his doing! I'm not saying that i disapprove of all that what you've written. Although as i see it most are largely unfounded. But one thing you mentioned i 100% agree is that J2EE is getting to complex...

    Just one word of advise..when your house is on fire try to rally them around to help put out the fire..instead of telling them that their houses are next...and they should evacuate....THATS JUST PLAIN SILLY!
  258. THATS JUST PLAIN SILLY![ Go to top ]

    Hi Mike,

    I have been fighting the fire with the rest of the Java community for the last 5 years. I kept hammering on that applets are good - use the plug-in, its a standard jvm. Meanwhile javasoft dumps me with buggy swing while they go all server side.

    OK, switch to server side. Start memorising all these pattern names which someone is making up. Oh, hang no, sorry, remote EJB's are the pile of cack that everyone thinks, so we are now going to use local interfaces. All those design patterns you used are now BAD PRACTICE. Use some new ones we want to make up. And they will keep doing this, and people will keep writing books to make money from us.

    This process is accelerating, because Jakarta (bow down and worship - why?) are now hammering out new 'standards' faster than developers can learn them. They are pushing their libs over the new core ones now - fragmenting the entire j2se, never mind jsee.

    But get back to J2EE, JNDI for everything - why? EJB and distributed data caches - why? JMS and MDB - pretty cool actually:-) JSP - crap, makes for v v bad maintenance, its based on asp and it shows. tag libs - ho ho. Project macro languages are ever a nightmare, no one documents them correctly and if you ever resurrect a dormant project they are horrendous.

    But, I love: JBoss, Ant, tomcat (yes, really), Idea, and the core J2SE libs - there is much power there.

    So what to do, given that Jakarta is now competing with Javasoft? Do I truly believe this is good for java or the java platform? No. Do I believe that the death of BEA and other app servers in favour of JBoss will create a better industry for java developers...not really. Big clients like to buy from big names.

    I have decided that given all this, and the fact that I know J2EE and loathe much of it, and the fact that there is a new kid on the block who has learnt from all Java's wisdom, and XML, and distributed computing that I really really have to know it well.

    But the real killer in my mind is the rise of PC performance. For all we harp on about Microsoft they embrace the biggest open standard in IT. And that is the tin that they run on. Anyone can make it, and start shipping PC's. It is the increase in performance that even allowed Java a say so against faster techs.

    Obviously you can now all raise individual situations where my points above are complete rubbish. Certain systems do benefit from certain of the techs I call rubbish. But most mid-size, global systems do not. Most have no need of them, the emperor is truly naked and lots of us know it but are keeping silent in the hope that the competition doesn't start pointing and laughing.

    Will I stop developing in java ? no, I can?t, I have products out. Will I start developing in C#, yes. I?m at page 50 in the c# book and it has some nice stuff, a pity about the goto though.

    Jonathan

  259. Download for free[ Go to top ]

    I claim post 200!

    Anyway, I'll bow out now and let you all flame me.

    The last thing that I did not know is you can get the sdk for free from

    http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml

    So although visual studio is going to be a required skill you can play with the language etc without it.

    Jonathan
  260. THATS JUST PLAIN SILLY![ Go to top ]

    <quote>
    I have decided that given all this, and the fact that I know J2EE and loathe much of it, and the fact that there is a new kid on the block who has learnt from all Java's wisdom, and XML, and distributed computing that I really really have to know it well.
    <qoute>

    I really hope that TSS has learnt from this disturbing episode. This website should not be allowed to be used as a platform on which individuals like Jonathan can air their unsubstantiated views as it does no more than mar what is indeed a brilliant resource for budding and expert J2EE personnel alike.

    Guys lets get on with it. Building superb J2EE applications and learning from each other in the process.
  261. Oh blast, one last post. For those who want some detail about c# from a delphi man... then:

    http://www.genamics.com/developer/csharp_comparative.htm

    Jonathan
  262. To the author:

    You have missed a few points
    - Building a system Faster is not nesscecarily building a system better, if you want scalability and flexibility .Net doesn't have hope
    - .Net and J2EE have the same fundamental approach to solving problems .Net does however have a powerfull development tool set.
    - Linux is growing quicker in the server space than you might think
  263. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Java does powerful developement tools too.
  264. My humble opinion and experience with Java:

    I second the opinion that Java has become far too complex (it began as a simple language for applets). Actually facing the unneeded complexities of Java every day makes me hate my job as a java programmer far too often. Are Java (EJB) applications the maintenance nightmare of tomorrow (compare to mainframes)?

    Working with .Net makes me remember the good old days when writing software using smart tools and well thought-out libraries was real fun. The times when I was able to say "It's a good time to be a programmer".

    Actually I begin to believe that java is very unfriendly to junior programmers, who begin to copy & paste java code and are getting completely lost when having to create new java code. This leads to companies having only expensive senior programmers working long hours, but this is not a good and successful business model IMO.

    I have very high hopes for .Net, and some recent signs are also very promising (the free Web Matrix Development Tool for example). But maybe Eclipse can save Java.

    Bernhard
  265. Bernard,

        If you are finding yourself hating Java, perhaps it *is* time to move on to something else.
         I remember the days not so long ago when I would cut and paste Java code endlessly, and just simply study the objects that more experienced developers had created. That is called "learning". It's something you do when you want something really bad and the payoff is good.
        Your sound to me like someone who wants something for nothing all the time. The applications that Java is being used for are the most complex in the industry, that's why it's hard for you. What's next, are you going to petition that your manager leave the company because he works you too hard?

    Basil
  266. Basil I think you are being a little too hard on poor Bernard. The fact is that Java is an enormous monster and growing every day even without factoring in Apache Jakarta and SourceForge.

    The wave front of creativity is the strength of Java but also it's achilles heel. We need a better way to index the information created by the Java movement generally. Perhaps we should focus on making better examples and usage of existing tools such as Xdoclet. An Xdoclet example showing the deployment of simple examples of each kind of EJB to all of the major EJB platforms would be a great resource. It probably exists for all I know, but I haven't found it yet! Indexing.

    That said, there are resources available for people to use
    such as the Java Almanac which can help the less experienced get started on a problem. I bought volume 1 last month and am watching for Volume 2 (about Swing, which is not my strength).
  267. Don,

       Yes, you are right I probably was overreacting. Hearing an argument that J2EE is a horrible technology because it's "too hard to learn" always makes me say things like that. Obviously enough people find that Java is not so difficult to learn, I don't have to give evidence on that do I?
       The real issue is that some people want J2EE to be all things to them and nothing ever is.
       The complaints about Entity Java Beans is warranted for what seems like *most* applications. OK, fine, so don't use them, use a simple Servlet-JDBC thing-a-ma-bobby that your creative mind can think up itself. All the power to you. Whatever you choose to do, just don't apply this disregard to the whole spec, that's just being ridiculous. And that's why I find it hard to follow Jonathon's flute music alongside all the other rats in the community, because his main argument is that J2EE does not do for the IT world what .NET does.
       Am I wrong to say that there is no "best" solution, but the best choice would be to go with a standardized one that developers are free to modify? An architecture that encourages free and open development with software/hardware that has spawned from that original notion?
       If MicroSoft can do ALL that, then yes, we would obviously be at a true crossroads, but if MicroSoft DID do all that, well then they wouldn't be the same MicroSoft that exists today, would it?

    Basil.
  268. Some replies to this and other messages:
    1) Java started out as a simpler OO language than C++ with more type safety that could run on any platform. Not as a simple applet writing language. You may be thinking of JavaScript. Applets were simply the first deployment mechanism for Java. It may have gotten more complex since then but that's like saying that humans got more complex than apes. It's true, but that's not a bad thing.

    2) For those decrying J2EE for not offering the simplicity of ASP.NET because MVC patterns introduce 1000-line servlets, I would suggest building a small Struts app as an experiment. When you do, you'll see that you don't have to write a servlet at all. And that the code on your pages will follow essentially the same pattern that you see on ASP.NET pages. ASP.NET borrows a lot from JSP and MVC patterns. It can produce code as simple or as complicated as the developer chooses, just like J2EE and something like struts. I would venture to say that at least with Struts, changing where things point to is a matter of configuration rather than recompilation, which makes a big difference in a real-world development environment where you move from dev to test to production on a frequent basis.

    3) For those decrying the poor ORM capabilities of EJBs, I would say that they may be right in some ways, but what ORM capability does .NET offer? Absolutely NONE. This is an important facility that the J2EE environment offers by definition. If you don't like EJB, you can go to JDO OR to one of many different open source or commercial ORM products. Examples are CocoBase, TopLink, castor, etc. I know because I'm looking into ORM now for a project that's too small for EJBs. This is a well-developed segment of the J2EE add-on market and right now, a glaring deficiency of the .NET platform.
  269. <Drew McAuliffe>
    3) For those decrying the poor ORM capabilities of EJBs, I would say that they may be right in some ways, but what ORM capability does .NET offer? Absolutely NONE. This is an important facility that the J2EE environment offers by definition.
    </Drew McAuliffe>

    I've read somewhere that MS is working on an OR mapping framework/product called ObjectSpaces IIRC. So they are trying to catch up. And I predict it should be cool, it won't be like EJB because they've always critisized EJBs. Should be something similiar to Apple webobjects' persistance mechanism imho, because they copy many things from Apple and webobjects' ORM framework is great. Imho we should concentrate on JDO and if something is wrong with it (as some vendors claimed) it should be fixed.

    <Anthony Bielobockie>
    The schema that I'm working with doesn't really relate to the object model that I'm using. For example, for me to add a new customer to the database I have to query a handful of tables, manipulate a few others, and insert to a few others. Depending on the type of customer, his type of account, and a whole host of other business rules different things have to happen to different tables in different order. I can't see any way to apply these rules using either EJB CMP or any of the O-R mappers. (I posted the same thing on the Castor message group and no one could help me) Both EJB-CMP and the mappers seem to have an overly simplistic concept of what people do with databases, or at least big messy existing ones.
    </Anthony Bielobockie>

    I'm fighting with the same enemy too. Imho what cmp entity beans imply is that you'd better create a 1-1 mapping between entity beans and tables. Even if the schema might be a legacy for you but in some other cases I beleive it's a wise decision to design the model and the schema according to the patterns of each one and not force OO rules on your DB schema because you want to come up with a direct mapping. They are two different beasts really, you gotta treat each one differently.

    Just another note regarding this C#/VB.Net frontend -> java backend scenario: coding a big app this way is way harder than you imagine. First there are common business logic on both sides, and it's getting real hard to keep two sides implemented in two languages in two different frameworks in sync/uptodate/refactored/etc, so you'd better use a single language/platform. Second, you have to minimize the networking overhead anyway, and it's more intense with this architecture. Just throwing in SOAP doesn't help (SOAP is great imho, just wrestle with a RMI/CORBA-based thick client and you'll know what I mean). Imho a smart layer over the SOAP/whatever transport layer should implement some tricks to help the transport layer (pass only changed fields, relations, etc for example, do smart caching and so on). So even with SOAP/webservices for big thick client apps you still have a big job to minimize the network overhead. Security is also a big headache, in web apps it's real easy while for thick clients it's very harder even with JAAS/etc. Deployment/versioing is easy with webstart though. But anyway with all those problems I agree with those who think thick clients will become more common with .Net.

    Ara.
  270. About MVC:
    Actually I'm very happy that ASP.Net breaks with MVC (or Model II). In my experience this pattern does *not* make sense in this environment, leads to much more code, worse performance and creates a maintenance nightmare (eg. 1000-lines-Servlets). JSP and JSP alternatives (Tapestry, Struts, etc.) are all a far cry away from the striking simplicity ASP.Net offers.
  271. In case you haven't figured out, Microsoft, by offering ASP and bloated nasty APIs such as MFC, doesn't want you to write maintainable, scalable, nicely structured apps. They don't want anyone coming along and writing another Excel. Why is SOAP so bloated and nasty? Same reason. In the same vein, all future .NET apps will be on top of several layers of APIs which slow it down (yes, even more so than Java) so all you can write are internal toys and small apps that only small companies can sell.

    Steve
  272. <quote>
    Actually I'm very happy that ASP.Net breaks with MVC (or Model II). In my experience this pattern does *not* make sense in this environment, leads to much more code, worse performance and creates a maintenance nightmare (eg. 1000-lines-Servlets). JSP and JSP alternatives (Tapestry, Struts, etc.) are all a far cry away from the striking simplicity ASP.Net offers.
    </quote>

    Well, if you're writing 1000 line servlets then you're doing it wrong.
    Much more frequently I've seen unmaintainable 1000 line asp pages.
    And yes, on your final point I must agree with you that asp offers a striking simplicity, in the same way a large bowl of spaghetti is "strikingly simple".
    So, before you post any more uneducated FUD, I suggest you learn a little more about architecture.
  273. Tim,

    I'm not writing 1000 line servlets, but I have seen many programmers doing so. Actually I think this is very common (see the Java anti-pattern book). And no, I was not talking about ASP, I was talking about ASP.Net. For the near future I will be doing Java, as it is a reality in todays business, and I hope Java Server Faces will pick up many ideas from ASP.Net (e.g. Events) and that it will be available soon.

    Bernhard
  274. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    and I hope Java Server Faces will pick up many ideas from >ASP.Net (e.g. Events) and that it will be available soon.



    Check out Echo. Haven't used it yet but I have used ASP.Net and it seems to be better than ASP.Net. If you have used for it, give it a whirl and let us know.

    I tried to do a complex (ok - not even really that complex) ASP.Net page. Would have been alot simpler in Java. Heck, I could have used existing GUI components instead of rolling my own. ASP.Net is ok for simple, easy things. But you still end up having to deal with the paging issue.
  275. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mark,

    where can I find Echo?
    I can't see how Java can be simpler than Asp.Net. E.g. writing a tag library in .Net means writing one C# File (the tag getter/setters and attributes, a render function, optionally attributes for editors, designers), in Java you have to author the Java Sources (implement some weird functions) and an XML descriptor, or use something like XDoclet, or use proprietary technology (e.g. in JRun you can write tag libraries using JSP). But help is underway AFAIK (JSP 2.0).

    Regards
    Bernhard
  276. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    http://www.nextapp.com/products/echo/

    As for the other stuff - I don't know. I avoid JSP's, ASP and the like for many reasons. Mainly, because I can develop a front end once and deploy it any way I desire without dealing with the Browser and it paradigm (sorry for using that word).
  277. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mark,

    thanks for the link to Echo. It seems to be another project where people seem to have put a lot of effort into. But for my business it is not useful because we have web designers designing HTML pages, and in Echo (as I understand it) the programmer is creating Windows and stuff in Java. But it has events, so at least this aspect is interesting.

    Other HTML template engines do not really make me 100% happy, so we will see what the future brings (e.g. Struts seems to be more on the heavy side to say it nicely, Tapestry seems to have a steep learning curve, Velocity might be too simple, etc.).

    Regards
    Bernhard
  278. All these so called programmers/architects whining about Java/J2EE is being too hard reminds me of a scene from the movie Amadeus where the King of Austria complains to Mozart that his latest opera is no good because it contains too many notes.

    Instead of trying to argue with them about superiority of J2EE vs. .NET we should encourage them to go to .Net. The more of these mediocrities leave Java world the more professional our field will look. May be that will bring even more respect to Java programmers from the industry together with higher salaries.


  279. Here in my opinion is the weak spot in J2EE. Persisting object based application data into a relational database. EJBs are crummy. The amount of work that you have to go though to use EJBs on a complex data model is absurd. JDO in my opinion is no better. Try to apply that thing to a large existing corporate database. Good luck. Scale much past the J2EE petstore application and you're doomed.
  280. Uh, you can use JDO in J2EE instead of EJBs. You will still be doing J2EE.

    So, then use JDBC or any of the other tools. You think ADO.Net is any better? It isn't.
  281. Oh yeah, and maybe the weak spot is the database, not the persistance tool. I believe it is.
  282. Well in the real world we have relational databases, the fact that there really isn't a good persistance model for J2EE that works with real world corporate databases is a problem. EJBs suck out loud and JDO has just introduced new problems.
  283. Well in the real world we have relational databases


    Yes we do. And that makes doing good OO with ANY tool difficult - but not impossible. Again this is not a failing of OO but of of the unwillingless of management, users and developers to change their paradigm. Not even for 20 cents.
  284. <quote>
    Here in my opinion is the weak spot in J2EE. Persisting object based application data into a relational database. EJBs are crummy. The amount of work that you have to go though to use EJBs on a complex data model is absurd. JDO in my opinion is no better. Try to apply that thing to a large existing corporate database. Good luck. Scale much past the J2EE petstore application and you're doomed.
    </quote>

    The object-relational mismatch is a difficult problem.
    1.1 CMP was crap, 2.0 is (almost) there.

    Your point about about scaling is absolute nonsense.
    Many, many companies use ejb on "proper" corporate databases. It is tried and tested and it works.

    And what the hell are you talking about "The amount of work that you have to go though to use EJBs on a complex data model is absurd" ???

    Object myObject = myHome.findByPrimaryKey(23);
    myObject.setSomeAttribute("hello");
    Collection children = myObject.getChildren();

    What's so hard about that?

    In fact, I couldn't even think of a semantically simpler way even if I tried.

    If you're going to spout crap then I suggest you back it up with some facts.

    Can you tell me how microsoft attacks the O-R mapping problem in a better, more scaleable way?
  285. You know all of these O-R mapping layers, Castor, EJB CMP, Toplink all work great with simple toy data models. I understand EJBs inside and out and I find it overly difficult to work between software objects and the underlieing data model. I will give you an example; I have to do a three table join plus two where conditions to fill a listbox on a webapp. The first answer is always, "well your database is poorly designed." That may be, but it's outside of my control. Welcome to the real world. The fact is when you're working with existing large corporate databases you have to do all kinds of ugly things to get data into and out of them and none of those hacks really works well with elegant O-R mappers. Aside from straight up JDBC EJB BMP is about the only thing that works. EJB BMP is just an RMI wrapper in JDBC anyway.

    Second, stop being rude just because you are hiding behind a keyboard. It's really the most pathetic form of a coward.

    Lastly, my bread is buttered with Java running on Solaris and Oracle on HP-UX. How you could assume that I'm supporting M$ (as much as I respect their business acumen) I have no idea.




    > Object myObject = myHome.findByPrimaryKey(23);
    > myObject.setSomeAttribute("hello");
    > Collection children = myObject.getChildren();

    > What's so hard about that?

    > In fact, I couldn't even think of a semantically simpler > way even if I tried.

    > If you're going to spout crap then I suggest you back it > up with some facts.

    > Can you tell me how microsoft attacks the O-R mapping
    > problem in a better, more scaleable way?
  286. <quote>
    You know all of these O-R mapping layers, Castor, EJB CMP, Toplink all work great with simple toy data models.
    </quote>

    I've used Castor on a legacy (pre-system) database system, that I can assure you is anything other than "toy".

    I'm currently using mvcsoft (implementation of EJB2.0 CMP), and I can assure you it is a dream - and this is not hello world.

    EJB-QL can easily join over just as many tables as you want, as long as you map them correctly.

    Whats more, it's perfectly acceptable and a recognised pattern to use JDBC directly if you want, for performance reasons or whatever.

    Having said there's no reason why a EJB-QL parser can't produce joins as good as you can write.

    I'm fed up with patronising people like yourself who make sweeping statements like CMP can't be used with real world databases - the facts prove you wrong.

    Many, many production systems, use this technology and work fine.

    <quote>
    Second, stop being rude just because you are hiding behind a keyboard. It's really the most pathetic form of a coward.
    </quote>

    No, I'm not a coward, I would happily say it to your face if you were nearby.
    If you come onto this forum and speak rubbish, expect replies.
    We've no need for your FUD around here.

  287. After 15 years of doing this stuff and seeing everything from MS-DOS 2.0 to Solaris and everything in between I find the technology field this side of sales to be more chocked full of con-artists and bullshitters than any other. (I don't know airconditioning repair guys are pretty bad too) The reason being is that anyone can learn a bunch of disjointed buzzwords and babble while confusing people not in the buzzword loop and making themselfs seem (temporarally) smarter. The companies that produce most of this stuff are no better.

    I also usually find that people that are randomly rude in anon circumstances have two things in common. #1) Grade and Middle school handed them an endless string of ass kickings #2) They usually have very little that backs up their bullshit. I think a large percentage of the people in forums on the internet are basically involved in a digital "I'm smarter than you" circle jerk. Which is of course a complete waste of time.

    Typically informed people don't have to hide behind the facade (it's a pattern!) of rudeness and bravado. You might consider that next time you post in a pre-pubecent manner.

    Now with that said, my specific problem is this; (if you have an informed opinion on this I'd love a new perspective)

    The schema that I'm working with doesn't really relate to the object model that I'm using. For example, for me to add a new customer to the database I have to query a handful of tables, manipulate a few others, and insert to a few others. Depending on the type of customer, his type of account, and a whole host of other business rules different things have to happen to different tables in different order. I can't see any way to apply these rules using either EJB CMP or any of the O-R mappers. (I posted the same thing on the Castor message group and no one could help me) Both EJB-CMP and the mappers seem to have an overly simplistic concept of what people do with databases, or at least big messy existing ones.








    > No, I'm not a coward, I would happily say it to your
    > face if you were nearby.
    > If you come onto this forum and speak rubbish, expect
    > replies. We've no need for your FUD around here.
  288. Agreed, a good portion of the time, the tools that are supposed to make our lives easier don't do all that they promise. I found the same experience using EAI tools that were supposed to integrate your systems seamlessly without writing a single line of code (cough Vitria cough). Lies and damn lies.

    Nonetheless, there are systems for which the ORM tools do provide some benefit, and these systems range from small to extremely large. I know of one pretty massive telecom management system that uses TopLink as its ORM mechanism and it is designed to (and does) scale tremendously. In fact, there is a good argument that some sort of ORM system that implements caching is almost necessary once you scale to a certain size; otherwise your database becomes a bottleneck.

    My original point in bringing up these tools is that they have no equivalent in the .NET world. While people may have problems with them or find that they don't suit their needs 100%, you can't really bash J2EE for them in a comparison to .NET because your only alternative in .NET is to write the functionality yourself. As the high prices for TopLink and Cocobase attest, that's not a trivial task.
  289. I know there are some jam up apps running on top of toplink and the like. We have a CRM app here I can't remember the name of the vendor. Some little CRM shop in Charlotte NC, YouCentric? Anyway, it's a well architected system, Oracle backend, WebSphere in the middle. Persistance is all Toplink running though an EJB session bean facade (I think). It's lightning fast and in my opinion a good app. But they are running against a schema that was designed from the ground up assuming TopLink was going to be in the mix. I'm speculating (because I don't have a lot of experience with O-R mappers) that it was successful because they probably tied the data model closely with the object model.

    I think with the schema mess that some of us deal with in corporate america (banks, brokerages, insurance companies and the like) where the thing was designed long before objects were around in large numbers and are now being used with object based apps running on top of them that these O-R mapping layers might not really be worth the time because they will actually add complexity.

    My is plan is this; write well optimised SQL in stored procs and prep statements. Totally abstract the hand written data layer from the presentation layer, probably facade the thing using a session bean and call it a day. New development where I have some control over the schema maybe go the O-R (Castor?) route?

    If anyone out there has some more experience than me and thinks I have my head up my ass please let me know. I want to make sure I take the right path.



    <Q>
    Nonetheless, there are systems for which the ORM tools do provide some benefit, and these systems range from small to extremely large. I know of one pretty massive telecom management system that uses TopLink as its ORM mechanism and it is designed to (and does) scale tremendously. In fact, there is a good argument that some sort of ORM system that implements caching is almost necessary once you scale to a certain size; otherwise your database becomes a bottleneck.
    </Q>
  290. write well optimised SQL in stored procs and prep >statements


    >If anyone out there has some more experience than me and >thinks I have my head up my ass please let me know. I want >to make sure I take the right path.


    Avoid stored procs at all costs. They will compound your problem. They are database specific and become more of a maintenance issue than SQL in 'objects' or common code.

    If you want to see the problem first hand check out the http://sourceforge.net/projects/compiere and look at the forums.



    Also, for another mapping tool checkout Hybernate http://java.foundries.sourceforge.net/search.pl?section=&query=hybernate . It might be more flexible and let you do what you want.
  291. We're on Oracle 9i and there is no way on this Earth we are moving off of Oracle. 95% of the apps are writting in PL/SQL. So if Oracle contract comes to us and it says Larry Ellison gets hookers and blow. By god, we're getting him hookers and blow for the man.

    Anyone ever use database views to help merge the object and relational models? Maybe make a view of a complex relationship and then use an O-R mapper to map the view facade to the object model?

    I checked out Hibernate. It was cool. Really similar to Castor I thought.

    <Q>
    Avoid stored procs at all costs. They will compound your problem. They are database specific and become more of a maintenance issue than SQL in 'objects' or common code.

    If you want to see the problem first hand check out the http://sourceforge.net/projects/compiere and look at the forums.



    Also, for another mapping tool checkout Hybernate http://java.foundries.sourceforge.net/search.pl?section=&query=hybernate . It might be more flexible and let you do what you want.
    </Q?
  292. <Q> We're on Oracle 9i and there is no way on this Earth we are moving off of Oracle. 95% of the apps are writting in PL/SQL. So if Oracle contract comes to us and it says Larry Ellison gets hookers and blow. By god, we're getting him hookers and blow for the man. </Q>

    Guess you might as well continue down that path. I still think it will make the apps less maintainable. Maybe with the right tool to maintain the SPs it won't be so bad.

    But it does prove my point. Larry has you in a bad way. Just like MS has those writing software with MS tools. One reason I jump on my Soap Box when new apps are being developed. It is too late for yours. :(
  293. This stuff is getting too hard. I think I might get into an easier business. Moores law has done nothing at all to increase the speed of computers. My current computer it just about as fast as the 4.77Mhz PC-XT I had in the 80s it just does a whole lot more and the displays are prettier to look at. CPU power has doubled every 18 months? Software complexity has marched in lockstep. You literally have to know 15 seperate technologies just to get something done. I feel for anyone just coming into this field without the benifit of watching the evolution. Java, JSP, HTML, SQL, PL/SQL, a little networking, an app server, Unix, windows, Javascript, JDBC, ANT. You have to know a little about each of those concepts to get an application together these days.


    You're right about us being tied to Oracle. It's really hard to make your app so flexable as to be able to change databases. It's really not all that bad. Oracle is a good database it runs on robust hardware and I don't have to write the check to keep the licence up to date.

  294. Anthony,

    I used the "too hard" phrase above also. I think it would be more accurate to say "too much". If you take each skill on it's own, no big deal. When it takes 30+ skills, 7 or 8 roles, and "a village (can't believe I just said that)" to pull it off... it's "too much". :)

    Don was dead on with the PB analogy. There were not roles to learn, you just trained yourself on PB. It's not J2EE's fault that n-tier development IS much more complicated than client server, but "This much more complicated?" ... call me a doubter. For J2EE to become mainstream the "average" developer community has to have a path to ramp up. If I'm learning J2EE from home, how exactly do you tackle that to prepare for employment. My take has been to spend most of the effort on the server side, but then you walk into a client site without the full suite of J2EE skills. I want to have a handle on ALL of it.

    Let me use myself as an example of "real world" issues learning J2EE. Around a year ago, I decided I needed to install an application server at home to prepare for the J2EE learning curve. I wanted to start with WebLogic or WebSphere because they seemed to clearly have the market share. Both only provided a 1 or 2 month trial. Like that will be long enough. Here I'm interested in tooling up on their products which will add to the labor market that can support their products, and they require me to uninstall and reinstall every month or so. (Now IBM gives you six months). How much imagination does it require to provide a "developer only" copy... jeeze. Anyway, 1 or 2 months evals didn't suite me, so I looked elsewhere. I heard about Orion and installed it on both my linux server and my Windows client. Looked like a pretty good server, but guess what... the documentation wasn't worth a damn. Hey, I have MVC, Struts, JSP, Taglibs, Ant, JUnit, EJB, JDO (although I didn't know that then), oh yeah .. Java, yada yada in my future, and learning an undocumented application server seemed like a bad plan. Then I found JRun... cool... documented ... developer copy ... forum support. It also seemed like an easier learning curve, but then they really didn't have much market share. Also, you started hearing quite a bit of feedback that JRun 3.1 was really not ready for prime time (production). I hope Macromedia's new JRun 4.0 IS ready for primetime. I looked a bit at JBoss, but I'm not sold on the "open source" application server concept. I'm ok with open source MVC, and logging, and script based building tools, but I want an application server vendor to be on the hook with me at the client site. I reserve the right to change my mind on that in the future. :)

    So there is a real world example of total BS that I shouldn't have to struggle with just because I want to learn J2EE. Sure, maybe I made some dumb uninformed decisions, but then, I bet I'm not the only one. I think it's OK that I support J2EE at the same time I say, "hey industry.... quit blowing it by making things so damn complex or YOU WILL lose out to that vendor lockin guy".

    JMO

    J2EEorBust

    Mike

    Mike
  295. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Things are always easier when you don't have to take the big picture in the equation. For example, your PowerBuilder analogy is accurate because PowerBuilder made our lives easier by automatically joing the front end and back end within the same editor and life was a breeze. Same with Delphi.
    To call yourself a Java Developer is to place a mighty burdern on your shoulders. When others point out how heavy it is, just smile and say that "while my feets may be hurtin', my spirits are high".

    Basil.
  296. <Q>You know all of these O-R mapping layers, Castor, EJB CMP, Toplink all work great with simple toy data models. I understand EJBs inside and out and I find it overly difficult to work between software objects and the underlieing data model. I will give you an example; I have to do a three table join plus two where conditions to fill a listbox on a webapp. The first answer is always, "well your database is poorly designed." That may be, but it's outside of my control. Welcome to the real world. The fact is when you're working with existing large corporate databases you have to do all kinds of ugly things to get data into and out of them and none of those hacks really works well with elegant O-R mappers. Aside from straight up JDBC EJB BMP is about the only thing that works. EJB BMP is just an RMI wrapper in JDBC anyway.</Q>

    Then do it that way. It wont be any better with ADO.Net

    Putting a nice, new, pretty ribbon on a pile of garbage will only make the ribbon look like garbage.

    Anyway, I am doing joins like that in an OR tool and it works fine.

    OR tools work fine in more than toy models.
  297. More fuel for the flames...

    I had a couple more random comparison points to offer based on a project I'm working on now. As I said earlier, I have worked with both .NET and J2EE. I'm currently working for a client on a project that will eventually be doing a Windows Forms app (.NET). In the meantime, I'm building a Java-based knowledge base to deploy to their website, which is linux/tomcat. Interesting enough already but that's not my point.

    In my work on their knowledge base, I've done a lot of investigation into ORM (Object Relational Management systems, like TopLink, CocoBase, Castor, etc.) systems to help ease the deployment and improve performance. Last I checked, there were something like 8 or 9 out there, about half of which were commercial implementations, the other half open-source. All have merits of one sort or another. What is interesting to me is that I have a choice. Would I have the same choice on the .NET platform? My history with COM products proves otherwise. There may eventually be half of that number of such systems, but I guarantee that most of them will be commercial implementations and thus more expensive than I am willing to pay for to support such a small project. I seriously doubt that there would be nearly as many open-source implementations, or that they would be as robust as those now available for Java. That's simply not the way Microsoft products have been historically supported. On the other hand, I would venture to guess that the commercial implementations would be somewhat cheaper than the equivalent Java systems, like TopLink and Cocobase.

    This reminds me of another difference, when dealing with web programming. A close look at ASP.NET reveals a lot of similarities to JSP. Where JSP says "tags", ASP.NET says "controls". They work about the same, they look about the same. The ASP.NET framework also provides a structured way of programming web pages and hooking them into the code behind, in some ways an MVC pattern. JSP doesn't provide this out of the box BUT there are quite a few frameworks out there that will give you MVC web programming with a well-defined structure (Struts, Turbine, etc.). Again, some are open source, some are commercial. But this strikes me as an area in which you won't see much more effort by anyone else to come up with another framework. Maybe it's because ASP.NET is so thoroughly designed. Most likely it's because any effort to come up with a competing .NET framework will never have the tool support of ASP.NET. WHile the Java web MVC frameworks don't have the tool support either (although Dreamweaver MX is working out REALLY nice with struts these days), at least there's a choice. That choice can become very important, depending on whether or not you need to do funky things with load balancing or other performance issues, or if you have a certain development process in your shop that you'd like to support.

    Again, just some more random thoughts for the debate.
  298. Do you have any experience with OR mapping tools. I'm looking into them now and am pretty dissapointed. None of them seem to deal with the complexities of a large real world corporate database.

    I'd love to hear from anyone that has tried to glue a set of J2EE web apps on front of an large poorly designed corporate database.

    spam at irondonut dot com

    Thanks.
  299. <>I'd love to hear from anyone that has tried to glue a set of J2EE web apps on front of an large poorly designed corporate database. <>

    No wonder you are disatisfied. That is not the fault of the OR tools. Trying to write and OO application, no matter what the tool, for that type of database won't be any better.
  300. Yeah no shit. Wasn't it great in the .com days when you could just make up a database from scratch to fit your needs?

    Now I have to munge software on top of a giant database that's evolved over the last 12 years and designed for PL/SQL apps.

    Course actually getting paid and leaving at or around 5pm isn't bad either.

    B2B = Back To Banking

    Tradeoffs...



    > No wonder you are disatisfied. That is not the fault of
    > the OR tools. Trying to write and OO application, no
    > matter what the tool, for that type of database won't be
    > any better.
  301. Overall, it's a pretty week article. I would agree that EJBs are unnecessarily complicated. But then again, they are only used in 20% of the J2EE applications out there, and probably only really needed in about 5% of the applications out there. So one or two optional features are too complicated. Don't use them. The main complicated thing about enterprise Java is that there are so many choices. By switching to .Net, you are just limiting your choices. You could do something similar in Java.

    We generally don't use EJBs them, except occassionally a session bean. Unfortunately vendors are promoting them as the golden hammer of J2EE. Even all the J2EE training is centered around EJBs. So either the big sin in J2EE is not fixing an unnecessarily complicated design or the insane amount of attention they receive. But just as EJBs are not the golden hammer, neither is SOAP/XML. Which is one of the problems with .Net.

    One thing you need to keep clear is just because you see problems with J2EE, doesn't mean Java isn't still the best solution for enterprise applications. But unlike MS, decide on the Java/J2EE platform doesn't yet limit you to a specific solution.

    try comparing a specific Java solution to .Net instead of the J2EE spec and in general the specifics of .Net.

    Compare Oracle's BC4J to .Net.

    read this

    http://www.oracle.com/forums/message.jsp?id=1060955&gid=315684

    you can skip to the good ones in the middle -
    one from Steve Muench and the one above it.

    after that it digresses.
  302. As Warren Buffet likes to say, "You can't trust the barber to tell you if you need a haircut."

    Vendors WILL NEVER TELL YOU THE TRUTH. If they did that they would be out of business.

    Vendor Speak:

    "10,000 hits a day? Buy WebLogic 7.0 and 200 hours of consulting services to make this think totally EJB blah blah blah 2.0 blah J2EE SOAP object blah compliant and backend it with Oracle 9i." We recommend running this on Sun or HP hardware."

    The Truth:

    "10,000 hits a day? How about Apache and Tomcat to run the JSPs and servlets and back end it with MySQL. Run the database and the web stuff on seperate Intel based Linux boxes."


    You can't really trust anything these guys say. Particularlly now that a lot of them are on the ropes.



    <Q>
    We generally don't use EJBs them, except occassionally a session bean. Unfortunately vendors are promoting them as the golden hammer of J2EE. Even all the J2EE training is centered around EJBs. So either the big sin in J2EE is not fixing an unnecessarily complicated design or the insane amount of attention they receive. But just as EJBs are not the golden hammer, neither is SOAP/XML. Which is one of the problems with .Net.
    </Q>
  303. Anthony,

    The Truth:

    "10,000 hits a day? How about Apache and Tomcat to run the JSPs and servlets and back end it with MySQL. Run the database and the web stuff on seperate Intel based Linux boxes."

    What you mean when you say 10000 hits a day? Is it 10000 opened sessions, or 10000 requests? I have an aplication in my job(Call Center frontend relationship management - crm), which takes about 10000 hits (requests) an hour...
    It's using Apache and Jboss, with Oracle db...
  304. I just saw you're reference to SOAP/XML. In my opinion SOAP is the biggest bunch of BS I've ever run into. Come on it's RPC it's nothing new. Oh wait! It is new! It's human readable RPC. Which means it's actually slower than the old versions of binary RPC and remoting.

    We had some pinhead talking about using SOAP to replace clustered MQ Series queues for stock trades and other really high importance transaction data. Can you even imagine? That would be like structural engineer planning a highway overpass made out of cheese rather than concrete.

    Thats the thing about technology. You can say anything and it's hard for people to call you on your bullshit. It's SOAP! it's all new! It doesn't follow the "rules."

    If it smells like shit...


    <Q>
    We generally don't use EJBs them, except occassionally a session bean. Unfortunately vendors are promoting them as the golden hammer of J2EE. Even all the J2EE training is centered around EJBs. So either the big sin in J2EE is not fixing an unnecessarily complicated design or the insane amount of attention they receive. But just as EJBs are not the golden hammer, neither is SOAP/XML. Which is one of the problems with .Net.
    </Q>


  305. While I wouldnt advocate replacing a transactional MQ-based system with SOAP, I think its a little short-sighted to see SOAP as complete BS.

    Its been over-hyped as hell - but its still useful.

    You are right its nothing new - except that its somewhat simpler than some traditional RPC mechnisms (apart from RMI). The best description of the benefit of SOAP is "that nothing is intentionally hidden".

    Compare SOAP and CORBA for a C++ client, and SOAP is quite a bit simpler. (The OBV CORBA stuff is a bit smelly - the fact that you have to register OBV factories by hand is very error prone. I dont know if any ORB vendor tools generate that stuff for you...)

    -Nick
  306. I believe the questions below are on topic since this thread was partially based on the "complexity" of J2EE.

    Disclaimer: I have been hard at studying J2EE and supporting technologies for around a year. I have read several books including two EJB books and Floyd's "Design Patterns" book. I worked thru several EJB labs, including working thru deployment issues on WebSphere 4. I've looked at alot of code, but have not cut any on my own (I think the fact that there is enough to study in the J2EE world to fill up a year without cutting much code backs up the "complexity" charge. We aren't in client server or Powerbuilder or "Kansas" anymore. :) I was about to dig deeper into CMP 2.0 but was persuaded by Floyd's argument that JDO makes more sense so I will probably be off to study Castor. Anyway, let me ask questions\make observations below that some of you in the trenches can give me some feedback on.

    1) I see constant references to the fact that the O/R mapping in J2EE land is very complex, particularly with CMP 1.1. Why does it turn out to be so complex (again, I haven't cut the code so I'm just asking for why it turns out to be so complex). It would seem in the worse case, one would "roll their own" and populate objects with JDBC. Why does that turn into the nightmare that is proclaimed. In the old procedural code days, didn't we have to code at this detail (granted, data was pulled to rowsets and not objects, but ??). I spent alot of time with PB, and the datawindow saved us from writing alot of sql by hand, but there were times where you just had write your own data retrieval. Again, to rowsets, but still hand coded. Also, haven't many of you had to get down and dirty with stored procedures. I know I have. So what am I missing. Why is roll your own O/R mapping such a big deal. Seems like you could abstract some of the basic stuff you do over and over like connections and pooling and whatever.... What am I missing ... why is it such an issue?

    2) Observation: J2EE is such a broad and complex topic that it's almost a full time job to keep up... and that's without even cutting code. OK, I just admitted I have spent a year studying J2EE without cutting much code. I know that's opposite to how many learn... they start coding first, and then lookup what they need (that has never been by method to the madness) I did sling a bunch of little java programs to pass the Sun Java Programming certification test, but I'm talking J2EE\EJB. I always intended (and still do) to stop reading so many books and web articles and go write an application... front to backend to nail down the learning curve, but I never run out of topics that seem important (e.g. application server selection, IDE, MVC, Struts, JSP, Taglibs, EJB, JDO (maybe something like Castor), Ant, Junit, Xdoclet, Log4j, Clustering, Design patterns, yada yada yada). So again, my observation... what a frickin nightmare for someone ramping up. I happen to be one of those sick suckers that think J2EE is worth doing because it is complex, but if the industry makes it to difficult, the average IT shop will not pull this stuff off, and then we all lose, IMO. IMHO, I'm way above average with many years experience, and this shit is pretty hard. I guess you could divide it up, and maybe just shoot for "server side" J2EE, or UI and MVC, or maybe be a O/R layer expert. ??

    So to restate this observation: The points about you not having to use "all of J2EE" on every project is valid, but I also think it is valid to question if the "average" IT shop can J2EE successfully. I think the answer is "yes", but like I said, we are way beyond client server and Powerbuilder.

    3) Let me make a challenge on what part of the J2EE learning curve is the biggest, IMO. I don't think it's the specs (JSP, EJB, CMP, ...), and I don't think it's the O/R mapping issues. Given enough time, you can turn the complexity of the J2EE environment into workable standards for your project. I think the biggest issue is the CONSTANT learning curve ... difference between IDE's, application servers, deployment, proprietary clustering, yada yada yada. I don't intend to .NET, but part of me see's ONE IDE to learn, and once becoming .NET ready, ALWAYS being ready for the next gig. If I'm a WebSphere geru, but the next gig is JBoss or WebLogic, I will still have a significant learning curve to migrate. I don't know about the rest of you, but after a while spending the weekend with frickin computer books gets a little old. I love the challenge like I said, and that's what makes it worthwhile, but there is a finite limit of what's worth putting up with. Maybe Jonathan's article should have been titled "I don't know if J2EE or .NET is better, but I do know that both SUCK in there current forms, and are blantantly unfair and unworthy of the developer community". :)

    Rant over. I really love this site. If the industry is going to push developer's this hard, they should at least buy us beer. :)

    J2EEorBust

    Mike

     

     
  307. Opinion: Java to J2EE to Oblivion?[ Go to top ]


    Mike Jones wrote:

    "I think the fact that there is enough to study in the J2EE world to fill up a year without cutting much code backs up the "complexity" charge. We aren't in client server or Powerbuilder or "Kansas" anymore. :)"

    Absolutely true! Some of the work that BEA is doing will tend to take some of the complexity out of deployment descriptors, and obviously onbe ought to be able to generate CMP bean DD's off of an E/R or UML diagram - which would take a good deal of complexity out of things.

    EJB's raise expectations I think, with all the talk about 'coding business logic'. I think the 7 roles that the earlier EJB books tried to solve that by putting the deployment and assembly on the shoulders of specialized pro's who know the app server well whilst allowing the coders to code.

    The problem with that approach is that everyone trying to learn this is basically out there alone and have to learn at least 4 or 5 of the roles to be able to get it working at all! And that is for a single App Server product. Extend that into multiple App Servers and you add at least another role per app server. Powerbuilder and the like were built to support you in what you already did. At most you would have to learn a single role, perhaps two.

    EJB itself requires knowledge of coding against multiple API's, setting up generic and vendor-specific deployment descriptors, installation and administration of an App server. Add Rmi and/or JMS for input, and (most often) you'll need to know JSP and Servlets (plus attendant administration tasks). And that is just to get a single test app running! After that it snowballs, particularly with Web Services coming on strong.

    Mike again: "IMHO, I'm way above average with many years experience, and this shit is pretty hard."

    You aren't joking. It's been a humbling experience for me also. Especially since my employer can't seem to find a use for it yet. Pie in the sky.

    Mike: "I think the biggest issue is the CONSTANT learning curve ... difference between IDE's, application servers, deployment, proprietary clustering, yada yada yada"

    And this is the real reason this thread went thermonuclear, I think. There are people who have sweat blood and spent much money learning EJB and want to believe there will be a payoff. Then Jon Gibbons (who knows a thing or two) comes along and tells us to throw all that away because .NET is going to be the future. Someone is going to throw a digital lynching party....

    I believe that ultimately J2EE will win in the larger enterprise-level deployments and .NET will take ground in simpler jobs where scalability and performance is less important. Going either way is a reasonable career choice. But .NET guys may have to do less homework.....

  308. People get a grip.

    .Net is dead on arrival.

    J2EE got there first, solves the problem better and cheaper.

    The postings here i support of .net is just Micro$oft trying to inject fear and uncertainty to try to revive their initiative.

    If I was an IT manager, I would not risk my career or my company on an risky proprietary new technology like .net when J2EE is already established, is more open, runs on just about any machine, and is stable and will exist on to infinity.

  309. Peter English wrote:

    ".Net is dead on arrival.

    J2EE got there first, solves the problem better and cheaper."

    Sorry, it isn't that simple. The first question is 'which problem?'.

    For that hypothetical IT manager, I suspect the very first question will be 'What skills and legacy apps do I already have on board?'. Perhaps the second might be 'What am I (the manager) most comfortable with?'.

    .NET is incremental, not revolutionary, and VB, VC++, and ASP programmers will be much more comfortable working with the .NET versions of their tools than moving to Java. So they won't move. C# seems to be M$ big initiative to bring over Java programmers, and it is not working very well as yet (low demand for it on Monster.com).

    For M$ shops .NET solves the problem easier and more cheaply. For Java shops, J2EE is the way to go. Pretty much status quo for the time being.....

  310. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Don,

    I just put on the "manager's hat" for a moment, and asked myself what I would allow my shop to be willing to support as far as skills. I have always been one of those that said "only one language if possible", and if you have to have C around, ok, we will pay for one C guy. :) But my god, think what a manager signs up for with the full suite of J2EE skills. It just occured to me that when I nail down all of these skills and get my first contract, I will be there for the life of the software. I would think supporting a legacy J2EE application these days with any kind of turnover would be a beast. Of course, these days, those with jobs aren't leaving in mass. :)

    Mike
  311. Opinion: Java to J2EE to Oblivion?[ Go to top ]



    Mike Jones (good chap) wrote:

    "But my god, think what a manager signs up for with the full suite of J2EE skills. It just occured to me that when I nail down all of these skills and get my first contract, I will be there for the life of the software."

    I'm not sure. If you read some of what Tracy Milburn writes about his shop, it appears that they deploy a lot of roughly similar BMP Entity beans on Weblogic 5.X or 6.X. Once you have one of these systems working it might not be that difficult to create, deploy, and support many other similar systems.

    "I would think supporting a legacy J2EE application these days with any kind of turnover would be a beast. Of course, these days, those with jobs aren't leaving in mass. :)"

    No more than supporting any kind of enterprise software is a beast, and probably a good deal less difficult than in the C++/Unix days if only because EJB/J2EE skills are more standardized than C++ enterprise-level skills were.

    Moreover, refactoring older EJB-based systems to use better practice ought to be much easier than rewriting C++ code. About the most radical thing you would want to do at the interface level would be to add a local interface to an Entity bean and/or interpose some kind of facade between the entity bean and the client.

    The most traumatic thing with EJB seems to be changing containers. Even that should not be too bad once you have deployed to the new container once.

    Our problems with EJB derive from two causes I think.

    Firstly we're 'first onto the beach' with the technology (or at least relatively early adopters). Both the market and the specifications are still mutating fast, and the tools are not keeping up as fast. We're the ones who have to make the first system work with inadequate knowledge, and it's. The ones who follow will be able to read our source code, deployment descriptors, and Ant build.xml files and will be able to learn much more quickly because they won't have to go through all the mistakes.

    Secondly, many of us are would-be Ed Romans or Floyd Marinescues (knowledgeable architects). To achieve this goal we have to know a helluva lot about the entire J2EE platform, and lose the advantages of 'divide and conquer'. Factor in the rotten job market and we start to believe we need to know EVERYTHING!

    We hear too much about how difficult J2EE/EJB is. My question is COMPARED to WHAT? Having worked on last-generation C++ 'enterprise' systems I can say that EJB is easy by comparison. Pie-simple.

    EJB is also very easy compared to the early days of Java Enterprise development, which was an absolute horrorshow of non-scaling server systems. EJB is not simple compared to Servlets or JSP I will admit. Adding Web Services to the broth doesn't improve things.
  312. Let's put to rest the argument that EJB is difficult.

    If you do not understand how to use EJB, get the following free downloadable book:

    http://www.theserverside.com/books/masteringEJB/

    It provides a clear explanation and gives examples of how to do EJB.

    The book is also available in print and I reccommend getting that too so you can read it without needing a computer. Once you see the quality of the book in PDF edition, you will definetly want to invest in the print copy.
  313. And furthermore, after reading that book, if you show me somebody who complains about EJB complexity I'll show you somebody who has very low applied-knowledge skills. ie. learning the syntax and structure of Java is the easy part, the hard part is understanding what your business needs are, and I'm willing to bet a lot of money that the people who complain about complexity have very little experience outside of making cute little tic-tac-toe games on an applet.
  314. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Basil and Peter,

    As Richie said on Happy Days .... "I only had tiny little glasses of beer ... 100 of them .... or something like that :)".

    I agree ... EJB is not to difficult. As I stated above, my real beef is "too much" not "too difficult". It's not EJB... it EJB + MVC + JSP + Servlets + Taglibs + Struts + PM + JDO + HTML + XML + XSLT + SAX + DOM + Javascript + OS's + Application Server's + Ant + JUnit + XDoclet + IDE's + CVS + UML + Rational + Jakarta + Keeping up with the TSS :) + Java + J2EE API's + dbms + security + web services + messaging products + design patterns (or whatever new buzzword you want to invent) + SOAP + web server configuration + application server configuration + load balancing + clustering + stress testing + production system monitoring and maintenance + software updgrades and migration + bugs in those little application server black boxes + yada yada yada.

    AND ... most of the skills above is a moving target. New releases, new versions of the specs, your favorite IDE or application server goes under or is no longer supported. Other professions (Lawyers, doctors, CPA's) are expected to have continuing education, but they don't have to practically start over every 4 or 5 years. :)

    I'm one of those guys who have been around a long time, and I need something new to come along and keep my interest. I'm having a blast learning all of this. But based on the list above (and all the stuff I couldn't think of) anyone with a brain should at least ask if the unspoken contract between the vendors and the developer community isn't a little whacked at this point. Hell, I've seen many client sites screw up Powerbuilder\Oracle. Those folks are going to have a field day with this stuff. The industry can't succeed if only the elite developer's among us can pull this off. Every skill you use in development is a skill a company has to commit to, to support the application (ok, maybe a few exceptions, but most of them). If I'm a manager, I don't want single points of failure. That means I'm hoping for at least two of my team members to be responsible for each skill (maybe mentor \ protege) to provide some sort of backup. That's either alot of folks, or a few folks that know a hell of alot. :) Obviously shops ARE succeeding in pulling this off, but I still think it's valid to question the current state of J2EE. For example, during my 6 or 7 years with Powerbuilder, I don't remember one person saying "wow, this is way to complicated". Obviously not an apples to apples comparison, but software is software.

    OK... rant over. I don't really have time for these little chats because I've only nailed down 20 of the 40 skills above. :)

    Mike



  315. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    One more observation.

    All successful developers\programmers pick up skills in their own way. I'm one of those guys who like to read the documentation cover to cover before I code. Yeah, maybe sad, but it has worked for me pretty well in my career. I get the big picture of "what is available" up front, and then can come back to the details if I ever need the feature or functionality. This has worked in the past with skills like Powerbuilder, because there was a finite amount to learn. This is no longer the case with J2EE. There is an infinite amount YOU COULD LEARN. You always only use a small percentage of any language or utility or technology to develop applications. So it would seem, with J2EE, I no longer have the luxury to read everything first. I need the ability to zero in on what I HAVE TO KNOW. That's why practical books like Floyd's Design Patterns is so important with J2EE. I have to cut to the chase. I don't have the luxury of sticking to my old techniques.

    Mike

  316. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mike Jones writes:

    "It's not EJB... it EJB + MVC + JSP + Servlets + Taglibs + Struts + PM + JDO + HTML + XML + XSLT + SAX + DOM + Javascript + OS's + Application Server's + Ant + JUnit + XDoclet + IDE's + CVS + UML + Rational + Jakarta + Keeping up with the TSS :) + Java + J2EE API's + dbms + security + web services + messaging products + design patterns (or whatever new buzzword you want to invent) + SOAP + web server configuration + application server configuration + load balancing + clustering + stress testing + production system monitoring and maintenance + software updgrades and migration + bugs in those little application server black boxes + yada yada yada"

    Yes this is the problem. I believe this will tend to filter out as time goes by. When I worked on C++ enterprise apps all of these skills (or their close equivalents) were problems. And there were teams of 20 or 30 people working between 1 and 3 years to deal with the issues, each to their own specialty.

    Today we have J2EE, which can be described as 'Enterprise Apps out of a box'. It's not really that but makes it a helluva lot easier to handle many of the problems of enterprise apps.

    But there is a kicker. It looks so easy that we are trying to substitute 3 people working 3 months for 20 working 3 years. And it is not working - yet. It is possible for people like yourself, Basil, Jon, Peter, and perhaps myself to learn enough to do large complex enterprise systems in a small fraction of the time and cost that they used to take.

    Talented, experienced developers will eventually catch up with enough of it to make it a go, especially factoring the efforts of equipment vendors to make their products easier to use.

    Mike writes:

    "The industry can't succeed if only the elite developer's among us can pull this off."

    But it won't be that way. Divide and conquer. We will have front-end specialists using JSP, ASP, Swing, Servlets, and VB to implement clients and UI's. There will be specialists writing EJB's on the other end. There will be admins to sort out what the DD's have to look like for the environment and to optimize performance. And there will be experts who do architecture and connect it all together.
  317. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Don,

    "But it won't be that way. Divide and conquer. We will have front-end specialists using JSP, ASP, Swing, Servlets, and VB to implement clients and UI's. There will be specialists writing EJB's on the other end. There will be admins to sort out what the DD's have to look like for the environment and to optimize performance. And there will be experts who do architecture and connect it all together."

    I agree about the divide and conquer. What I don't agree is the industry is doing a very good job at helping teach this to potential client sites and recruiters. I'm not even sure if we are doing it that well amongst ourselves as J2EE "wanna bees" show up. I want one of those J2EE architect jobs, so I'm trying to learn it all. A dedicated year later, and I'm hit with the potential that this is unrealistic, particularly if you also want a life. How many adds (well not many in this economy) where you see them asking for 3 or 4 years in J2EE. What does that mean? What application server... and what version. Were you a MVC guru, or where you a business logic EJB slinger. If you were a business logic slinger, did you also work on the persistence layer. If so, CMP or BMP or Castor or Cocobase? If I'm a Cocobase stud, am I qualified to come in an Toplink for you. Is it ok to use your EJB guy to gather requirements and UML? If you had two years with Visual Age and WebSphere 3.5, are you ready for WSAD and WebSphere 4? If not, can anyone be ready, because you always have a new release (kind of hard to find 4 years experience in WSAD and WebSphere 4.0). Of course starting completely over with the tools like WSAD\Eclispe is a moving target. I'm on the technical side of the fence and have a hard time giving honest answers to these type of questions. The clients are really at our mercy more than ever. I want to build them some quality software. I dont' want to leave them with a maintenance nightmare. I think the best thing I could do today for a client is to reduce the industry J2EE offerings down to as simple a scheme (KISS) as humanly possible. Even then, they better commit someone full time to keeping up with the moving J2EE target. If you didn't keep up with Powerbuilder, and you got a couple of versions behind, not that big of deal. If you put your head in the sand for a couple of years with J2EE, you may be toast. Bottom line, whatever you bite off to put into production has to be supported. It's been quite a while since my statistic class, but I remember something about the number of permutations. J2EE projects represent alot of permutations. :)

    I don't really agree with the "foot stomping" comment. I'm constantly amazed by how much I can learn from a discussion that started from a comment or article I completely disagreed with. I happen to believe .NET is not going to takeover mid to small sized global applications because .NET is going to be very complex also. Someone can list .NET required skills like I just did with J2EE, and I'm willing to bet it will be just as long, with many items duplicated. I think a more relevent thread would have been "Are the distributed software vendors failing to provide the developer community with workable solutions".

    For example, IBM and BEA have been charging $20,000+ per cpu for an application server, and yet the industry has turned to open source for products like Ant and JUnit. Am I the only one that would expect those types of features to be included with $20,000+ per cpu? I know everyone is sick of my Powerbuilder analogy, but one more. When a shop decided to develop in PB, they didn't have to go run around to pick from a list of IDE's or look for utilities that should have been included with the product in the first place. No scavenger hunt required (I'm not knocking Jakarta and open source. It's amazing what folks that pool together are able to produce). In some ways, you are denying it if you don't think a one vendor solution like .NET will have advantages in this area. That said, many of us will be willing to incur quite a bit of pain to not be locked into Microsoft. Renting your software... what's up with that?

    Mike



  318. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Well said, both of you... as for the article, Don, I have to respectfully disagree with you ( that is the only thing I don't agree with out of all you said... the article is garbage ). But let's not bicker over that, some like tea some like coffee.
    I would just like to point out that the *pace* at which Java technologies are growing and the *weight* of their growth is not IMHO as great as it was in the late 90s, and that we should keep this fact in perspective. Remember when JSP came out, or when servlets hit the scene? Remember when XML first went mainstream and most people had no idea about DOM/SAX and so forth? Nobody seemed to complain about the learning curve then. This phenomena can be explained by looking at the environment at the time:

      1) Everybody who could spell "Java" could get a job in it.
      2) The jobs paid more money than we had ever seen before...
      3) Java solutions were a panacea for all evils involving development, SUN was a relatively new player on the scene and everybody likes the underdog. No longer, now that SUN has grown so much in popularity and importance, the pendulum has swung the other way, crashed through the glass of tolerance, and caused more than its fair share of casualities among world opinion.

       Today it seems like many ( not *all* people, just many... ) want to slow down and go into cruise control, as if the technologies available today were sufficient. They are not, and with the explosion in B2B and internal integration projects that will arise because of Web Services, we will soon find that we have a long way to go. Yes, EJB app servers are a commodity now, but let's not be too eager to jump off the J2EE boat.
       PS: Don, how could you possibly like that article? It gave no rationale for its statements, it was just fluff. The links that others have provided for further research were 10 times more valuable than anything in the article. NO offense to Jonathon, I'm sure he's a fine developer in his own right and has nothing to prove, but I'm not sure that he understands the needs of the community reading a piece like that.

    Basil.
  319. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Basil,

    "PS: Don, how could you possibly like that article? It gave no rationale for its statements, it was just fluff. The links that others have provided for further research were 10 times more valuable than anything in the article. NO offense to Jonathon, I'm sure he's a fine developer in his own right and has nothing to prove, but I'm not sure that he understands the needs of the community reading a piece like that."

    Hey, Basil. I'm not Don, but let me respond to how I viewed the article. To me the article was an opinion piece predicting how the market would split between .NET and J2EE on mid to small scale global development projects. He did back up his opinions with reasons (i.e. Windows OSs will be good enough, Linux not coming on as strong as anticipated, J2EE overly complex) whether we agreed with them or not. He seemed to be looking for feedback including those that disagreed. Maybe he was just playing the devil's advocate role to stir up a debate (I have done that before). I guess all opinions and predictions about the future could be called "fluff", but it made for an interesting thread. :) Besides, all of us in the "skills race" are constantly trying to predict the future so we can be marketable.

    Anyway, enjoyed your comments and the others on the thread. A person could do alot worse than hanging around TSS for relevent J2EE info. :)

    Mike

  320. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Yes, I see your point.

    Basil
  321. Basil McRae wrote:

    "I would just like to point out that the *pace* at which Java technologies are growing and the *weight* of their growth is not IMHO as great as it was in the late 90s, and that we should keep this fact in perspective."

    The wave front is widening though, as Mike pointed out. However I think you hit the nail right on the head with your observation that the Java job market has turned rather mean over the past 18 months or so.

    In 1999 you could get a good job with what you already knew and learn at your own pace by working the new technologies into whatever you were doing at the time. Today many of us feel as though we have to be perfect and know everything to get any job at all! J2EE is a drug on the mart in my firm, and they have me out doing Unix scripting work to earn my crust. Honest work is never to be sneered at, but scripting is no longer where I'm at.

    Another reason we have to know *everything* is that we're frequently on our own. With J2EE projects going to bind us together, we have to do it *all* ourselves. Which means knowing it all.

    Basil:

    ".

       Today it seems like many ( not *all* people, just many... ) want to slow down and go into cruise control"

    It's psychological, not technical. Many of us went straight from 2 years of 89 hour weeks straight to the unemployment lines, or so it seems. I've busted my butt for 30 months learning J2EE and J2SE only to find there is inadequate demand for those skills. Others have experienced the same thing.

    My mind tells me that the J2EE skills will be pure gold in a year or two, but my gut wonders whether I have made a huge and expensive blunder?

    Basil asked:

    " PS: Don, how could you possibly like that article? It gave no rationale for its statements, it was just fluff."

    Not quite all fluff. MS.NET will continue to occupy a good-size chunk of the market. It has advantages for early entrants (it's easier to get into). I didn't 'like' the article. I called it 'thoughtful' buit what I actually meant was it was thought-provoking.

    I tend to treate serious dissent in a forum like this with respect. We are all subject to me-tooism, so it takes a bit of courage to post something like this. Particularly for someone like Jon who has been part of the J2EE community. And Jon has one good point in that all this diversity in the general J2EE space makes it difficult to develop a good integrated skill base which doesn't erode too quickly.

    Most dissent on theserverside.com comes in one of two forms, either mindless taunting by juveniles 'MS.NET rules and J2EE isd dead!' or marketing pieces written by people from Redmond. This was neither and deserves some respect for that!

    I believe Jon's paper is dead wrong. Let me go on record with that. Burt he could be correct on some things, and J2EE usability is the issue on which he is most correct.
  322. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Don,

    "The most expensive fashions in business have been A) Managerial incompetence (particularly in handling staff)"

    How true. I'm inclined to blame that dilema on the way corporate america defines the IT roles rather than those managers (although we have all met some that should not be defended :). Software development (business apps) has always been more about experience and not IQ, IMO. Company after company seems to fill IT manager roles with folks that would not qualify as a senior developer (at least the ones I tend to end up at). This forces these individuals to rely on technical advice from the senior developers or consultants on the project. This communication challenge on projects has always existed, but throw in J2EE and you have some very long debates\explanations on your hands. :)

    I hope you have not wasted your 30 months of J2EE training, because as you know, I'm making the same bet.

    "I tend to treate serious dissent in a forum like this with respect. We are all subject to me-tooism, so it takes a bit of courage to post something like this. Particularly for someone like Jon who has been part of the J2EE community. And Jon has one good point in that all this diversity in the general J2EE space makes it difficult to develop a good integrated skill base which doesn't erode too quickly.

    Most dissent on theserverside.com comes in one of two forms, either mindless taunting by juveniles 'MS.NET rules and J2EE isd dead!' or marketing pieces written by people from Redmond. This was neither and deserves some respect for that!"

    Well said. I agree.

    I think the following is true (from Jonathon's article)

    1) Windows OS's are\will be "good enough servers" for mid size apps. I guess we could be more specific about defining "mid size", but I believe his basic premise
    2) I do believe the .NET learning curve, with one IDE, and one application server (do you call it application server in .NOT) will be a significantly easier than what the J2EE developer faces. That doesn't mean .NET will be easy, just easier. Including the constant hit a J2EE developer will incur if he moves from one application server to another (e.g. WebLogic to WebSphere). Java may be write once, run anywhere, but J2EE applications servers are "learn my proprietary rules, and learn them again for the next one". I think this one issue is a HUGE negative for the developer. If I have a J2EE career ahead of me, I will be more than happy if I don't bounce from one application server to the next. :)

    Someday I would be interested on your take and opinions about how you would attack the persistence layer on a J2EE project, if you were in charge. :)

    Mike



  323. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mike Jones writes:

    "1) Windows OS's are\will be "good enough servers" for mid size apps. I guess we could be more specific about defining "mid size", but I believe his basic premise"

    What is 'good enough'? The feedback thus far is that Win XP is somewhat more stable than Win 2000 Pro, but can *still* be flaky as hell. Win Xp remains more difficult to administer remotely than any Unix box is.

    Philip Greenspun (one of the early WWW pioneers) wrote a wonderful book titled 'Phil and Alex' Guide to Web Publishing' in 1999. Alex (a big white husky) presumably lent moral support ant the occasional 'woof'. The book is dated now but still an ideosyncratic guide to the industry.

    In the section about operating systems Phil notes that Unix is a week of hell to get running but goes forever once you have it going. He shows a screen shot from a wheezy old HPUX box which was 'running 54 days, 10 hours, 21 minut5es, and 15 seconds'. Unix can be administered remotely through telnet sessions. He personally favored HPUX over Linux because they had the best worldwide support organization and he could get help 24 X 7 X 365. You have to know what you're about to use Linux.

    I submit that until Win NT or it's derivatives can stay up for 2 months at a time reliably that it may not be 'good enough' to host mid-size apps.
  324. Hi Mike

    'I submit that until Win NT or it's derivatives can stay up for 2 months at a time reliably that it may not be 'good enough' to host mid-size apps.'

    This is crucial.

    I have win 2000 (not server) running with Oracle, MySQL, JBoss, and bespoke scheduling, ftp, email etc code.

    This box has run for 4 or 5 months at a time (before power cuts take it down). It is stable as hell - and I run office and all sorts of dev tools on it as well (dreamweaver, excel, word, IDea, Jcloak..). I have multi processes running... basically all the stuff that should kill the box off if it was rubbish.

    It isn't. Note that this is out of the box - without some internal IT dept working it over and turning it into a fetid pile of... you get the drift.

    I admit the load is very low - web site has maybe 3 or 4 concurrent users max, so I have never stressed the i/o on this box. And I have throttled it just in case via a fire wall.

    This is countered by microsoft who apparently still recomend a 90 day reboot. So I'm left with no idea why my system is actually working, when ms says I should reboot it.

    Anyone got experience of runing exchange servers? How often are they rebooted - thats a nice benchmark because of the massive load.

    Jonathan
  325. Jonathan Gibbons wrote:

    (About his Win NT 2000 box)
    "This box has run for 4 or 5 months at a time (before power cuts take it down). It is stable as hell "

    Glad to hear you have had a good experience. Against this is our accumulated experience of Microsoft products generally. I have a home computer running Windows 98 (2nd release) which hangs perhaps 10-15 times in a typical week and also does a CTD (Crash to desktop) while I am websurfing a couple times a day.

    I was happy enough with my Windows 95 box a few years ago, but at work I've had repeated "pull out your hair by the roots" experiences with MS Word. Once I had to save a document to ASCII text and re-format a 150 page document because Word went ape every time I tried to paste in text.

    Running Win NT 4.0 on a laptop 3 years ago I had to travel back to the office several times (100+ miles by trains) to get the operating system re-installed because software installations would not uninstall correctly.

    Not reassuring. So whenever I hear Microsoft tell me that Win XP 'is the future' I need a few pints before I can stop laughing.

    Linux/Apache/App Servers actually work reliably. Win NT-based machines sometimes and sometimes projectile hurl repeatedly. Microsoft doesn't support it reliably. Why do people bet their businesses on products which don't work reliably and aren't well supported? Because they market well?
  326. Exchange Servers[ Go to top ]

    "Anyone got experience of runing exchange servers? How often are they rebooted - thats a nice benchmark because of the massive load. "

    I am a user on an Exchange system. It seems as if it is brought down twice a month on weekends for an hour or two. Periodically (once a month or so) it seems to crash for 2-3 hours. Last time was a doozy, it went down over the weekend and they couldn't get it to boot up and stay up for 4-5 days. YMMV

  327. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mike Jones writes:

    "For example, IBM and BEA have been charging $20,000+ per cpu for an application server, and yet the industry has turned to open source for products like Ant and JUnit. Am I the only one that would expect those types of features to be included with $20,000+ per cpu? "

    Not necessarily. I come out of the Unix world where more of less open tools (make, vi, emacs) are commonly used.

    Powerbuilder sounds like it was a completely integrated product including build and perhaps testing. That can be nice but it can also be limiting. I tend to prefer seperate (and open-source) tools for build and testing. Using these will allow me to write Ant files which kick off unit tests of my entire app at a time, and if that succeeds kick off system and integration testing. Have a look at the 'eXtreme Programnming Explained' book for an idea of what my favored testing procedure looks like. I've been doing stuff like that wherever I have enough influence to get it adopted for at least 10 years. It is very powerful.
  328. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Don,

    "Have a look at the 'eXtreme Programnming Explained' book for an idea of what my favored testing procedure looks like."

    I meant to reply to this. I haven't looked at the book, but have looked briefly at the website.

    Opinion:

    1) writing tests first - great idea, although not that revolutionary. I've always sat down after coding stored procedures and created a test plan. I now think doing that before (and during) the coding is even better. I'm also on board with developing tests that remain a permanent part of the use case deliverable, that must be updated along the way. Seems like JUnit is a common tool for that, but I haven't had a chance to dig into it (one of many). I know ahead of time, regardless of testing technique or tool, the biggest challenge will be dbms data population and initialization for the tests.

    2) coding in pairs - Will NEVER happen in any project I ever run. You just divided your resources in half, as far as I'm concerned. I would address mentoring requirements through other techniques like published project standards and appropriate walk throughs. Walk throughs to enforce/teach standards and techniques are good... walk throughs for individual "preferences" (i.e. anything that wasn't important enough to be included in your standards" is not productive. And a really big pet peeve of mind... walk throughs that happen after testing were someone claims "it should have been coded this way". That should have already been caught. By the time you get to testing, you should have already been through your "checks and balances" types of standards review and mentoring. Of course, you may have needs to bounce ideas against each other when considering refactoring and issues that do come up when testing.

    The one thing that is somewhat similar to pair programming that I have seen work for a group of developers that are all ramping up on skills at the same time is what I call the "developer pit" or "lab". Basically, several developers all seated together in an open environment without walls (maybe a huge cubicle). I worked in that environment, and as one developer gained knowlege beneficial to the project it was easy to share the info with others in the "pit". I would hope to add one thing to that equation we did not have on that project ... a quiet office or cube a developer could go to for that "heads down heavy code cranking" which was difficult in the "pit". :)

    All, IMHO, of course. :)

    I hope we are not violating the spirit of TSS when we go a little off-topic in these threads. If these types of discussions have another home on the TSS, or if we should go off-line to email, I'm more than willing. I hardly ever feel there can be too much debate, but that's just me. I'm sure opinions may vary.

    Mike
  329. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mike Jones:

    "1) writing tests first - great idea, although not that revolutionary."

    This was what I was referring to. Writing a test program first requires you to think about what the interface looks like early on, which is desireable. It also enables you to
    run tests from the very beginning of development, which means you have working software beginning to end. It also enables you to refactor with impunity, which is really why the xP people do it.

    "2) coding in pairs - Will NEVER happen in any project I ever run. You just divided your resources in half, as far as I'm concerned."

    I'm not so sure about this one. To be honest I do my best coding in the late afternoon and evenings. Pair programming in the morning might help me get my batteries juiced earlier and make me more productive. A lot of errors get introduced during solo programming, and I find that having other eyes looking at the code leads me to see things I otherwise do not. 'Why did I do that?'

    As for code reviews and structured walkthrough, well how often do you really see them happen? We're more good intent than good practice in this industry!

    How about some of both?

  330. Peter English writes:

    "Let's put to rest the argument that EJB is difficult."

    EJB is not that difficult. CMP 2.0 entity beans can be difficult, and doing Entity beans of either type right can be quite difficult. But that is a design issue.

    Getting an EJB deployed and running on a specific App Server product can be difficult. Properly using load balancing and clustering can be difficult. Porting an EJB app from one App Server product to another can be quite nastily difficult.

    Most of the difficulties I am pointing out are not directly related to EJB, but rather to deficiencies in documentation of the products themselves, particularly the proprietary features of the products and their proprietary deployment descriptors.

    When these things are properly and accurately documented (as in the downloadable worksheet for Weblogic 6.1 for Monson-Haefel's "Enterprise Java Beans 3rd Ed"), all becomes very simple.

    When they are not (as in the Girdley book about BEA Weblogic 6.0) it is living hell to sort this out!
  331. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    .NET is incremental, not revolutionary,


    It is revolutionary for VBers and ASPers. Just not for us Javaers, at least those of us paying attention. It is incremental at best for us. They (VBers and ASPers) will only be comfortable with the syntax (somewhat) and the fact it came from MS. Yes, there are a few exceptions to the rule.

    I have experience with VB/ASP, MS.Net and Java so I'm not just blowing smoke.


    >For M$ shops .NET solves the problem easier and more >cheaply.

    Not any more or less than it currently is. :)

    >Pretty much status quo for the time being.....

    Seems to be.
  332. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    I wrote: .NET is incremental, not revolutionary,

    Mark replied:

    "It is revolutionary for VBers and ASPers. Just not for us Javaers, at least those of us paying attention. It is incremental at best for us. They (VBers and ASPers) will only be comfortable with the syntax (somewhat) and the fact it came from MS. Yes, there are a few exceptions to the rule."

    Mark, could you explain what is revolutionary about .NET from the POV of VB'ers and ASPers (flame not intended). I don't really know what .NET brings to the party. I have reskilled at least 3 times during a 20 year career, so learning something new doesn't strike me as revolutionary any more.

    ASP and JSP struck me as being pretty revolutionary and neither is that old. Perhaps 3-4 years old? So why cannot ASPer's readily pick up a new paradigm like they did the first one?

    Me again: For M$ shops .NET solves the problem easier and more >cheaply.

    Mark: "Not any more or less than it currently is. :)"

    What I meant by the first statement is that learning VB.NET/ASP.NET/ADO.NET has to be easier and faster than completely retooling the staff over to J2EE/J2SE. I'm not contending that .NET solves everything that J2EE does, but that it solves more than ASP3 and VB6 did and is (relatively) incremental to those technologies.
  333. Evidencce that .Net is dead on arrival!!!

    FROM: OMB advocates J2EE, .Net for e-gov

    In the study, they gave J2EE the highest overall technology ranking, saying it scored 22 out of 24 points on a scale for meeting federal government program architecture requirements. Microsoft .NET scored a 17 out of 24.

    "J2EE is an established, mature technology and by far the more open of the two (J2EE and .NET)," said Debra Stouffer, who served as a federal enterprise architecture program manager for OMB, in a recent interview with Government Computer News. "The fact that it is multi-platform is key."

    See the following link for full article:

    http://www.gcn.com/21_9/top-stories/18493-1.html

    Also see the accompanying discussion thread at The Server Side:

    http://www.theserverside.com/home/thread.jsp?thread_id=14281
  334. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Hey Don,

    "But .NET guys may have to do less homework....."

    Good one. Less homework = more golf. :)

    I think .NET IS "Vendor lock in", and I for one am willing to jump thru alot of J2EE hoops to avoid it. Maybe J2EE has it's own form of lock in.... "way to much blood and sweat invested in search of the holy grail to give up Lock in". :)

    Thanks for the feedback. I'm still looking for someone to give me the short version on why roll your own JDBC O/R mapping turns into such a beast. The closest thing I ever used to an O/R mapping tool was a Powerbuilder datawindow. :)

    Mike
  335. <q>
    The closest thing I ever used to an O/R mapping tool was a Powerbuilder datawindow. :)
    </q>
    Hmm...
    What about Sybase EAS (Jaguar). You can use PB datawindow on server or maybe java datawindow - runs on any AppServer.
  336. Mike,

    A good OR-Mapping product can dramatically improve programmer productivity by making the code simpler and yet more efficient. Please check out JDX OR-Mapping product white paper that discusses the complexities and issues in using direct JDBC/SQL to achieve persistence of business objects.

    http://www.softwaretree.com/products/jdx/whitepaper/JDX-WhitePaper.htm


    Damodar Periwal
    Software Tree
    Simplify Data Integration
  337. Damador,

    Thanks for the link. That is a pretty good list to consider on the topic of RYO JDBC O/R mapping. An obvious issue that causes complication is the nesting of objects with OO. In practice, I would not mix java and sql. I would be in the camp that stored procedures for data retrieval and updates are ok (but no business logic in stored procedures). Most applications will NEVER change databases. It would seem that you would be able to setup pretty much a one-to-one between a dbms table and stored procedures parameter driven to pull data as required. You would also end up with seperate update stored procedures. Maintenance should track use case's and I'm not sure having to touch a few extra objects (stored procedures) is such a big deal. For example, let's say to modify a particular use case functionality, what's the big deal if I have to touch one, or 5 objects as long as it's well documented and trivial. Now, not having to touch any code when you add a column to a table would be excellent, but if your adding a column, aren't you probably needing to change code for some reason (otherwise, why did you add the column). I reserve the right to change my mind as I get into it deeper.

    Again, thanks for the input.

    Mike
  338. Opinion: Java to J2EE to Oblivion?[ Go to top ]

     ...Have a break ... have a KITCAT and read the most recent
    thread.
    thank u
  339. Mike,

    Since there are no standards for stored procedure language, such a solution may not be portable across different databases.

    Regarding adding a column to a table, typically there would be a business reason to do so - you would perhaps add an attribute to the corresponding class and write business logic to take advantage of that extra attribute. However, with an OR-Mapping technology like JDX, adding an extra attribute does not require any changes to the persistence logic code because all the appropriate SQL statements are automatically and dynamically generated at runtime.

    -- Damodar

    Software Tree, Inc.
    Simplify Data Integration
  340. Damodor,

    "Since there are no standards for stored procedure language, such a solution may not be portable across different databases."

    Yes, I understand the implications. Definite factors in selecting an O/R solution would be whether your application needed to be portable across dbms's, project budget, and also the size of your application. My development experience has tended to be with clients that don't intend to change databases, ever. In those cases, I wouldn't automatically throw out stored procedures as an acceptable RYO technique for O/R mapping. I'm just now digging into the issue, so maybe I would change my mind when I got into it a little further. Particularly for legacy dbms, stored procedures would seem to offer an acceptable technique for O/R mapping. Scott Ambler's O/R white paper seems to support that premise (for legacy apps, but not for development from scratch). http://www.ambysoft.com/mappingObjects.pdf

    Stored procedures are compiled and efficient, and if you limit them to data retrieval and updates (i.e. no business logic), they should be pretty small blocks of code. Porting to another dbms by rewriting stored procedures would be doable if you had to, but yes, not having to touch the O/R layer would be optimal. I notice Oracle now allows stored procedures to be written in Java. Does anyone know what other dbms vendors now support that, are is planned for the near future.

    As I stated in a post above, I think a developer has to take the broad J2EE world, and attempt to trim it down into as simple as possible standards are frameworks for project development (KISS). I happen to know and am comfortable with stored procedures. An O/R tool is another layer, potentially a "black box" depending on the vendor, that I have to have faith in. I've already accepted that RYO application server code is a bad concept. I'm more than convinced I need to depend on the vendor for the application servers. Maybe I will come to the same conclusion with O/R mapping. We will see.

    Again, thanks for the input.

    Mike


  341. Mike,

    Good points. BTW, JDX also allows invoking stored procedures in an object-oriented fashion. For example, stored procedure results may be converted into business object instances by JDX.

    An evaluation version of JDX can be downloaded from http://www.softwaretree.com

    -- Damodar

    Software Tree, Inc.
    Simplify Data Integration
  342. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Mike Jones asks:

    >I notice Oracle now allows stored procedures to be written
    >in Java. Does anyone know what other dbms vendors now
    >support that, are is planned for the near future.

    Sybase has had Java for stored procedures, functions, triggers, and columns in the database for a couple years. I have used it in Adaptive Server Anywhere.

    There is still O/R translation effort happening, but it is possible to have stored procedure code in Java that can later be moved to a middle tier.

    j f
  343. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    j,

    If most of the dbms's supported java as a stored procedure language, it would put a dent in the dbms portability argument against using them. Even if you can't use a common base language (java) for the PM layer stored procedures, having to rewrite them for another dbms seems like it would be more than doable (again, no business logic in them). JMO. I am really wrestling with the J2EE PM layer. I believe JDO makes alot more sense than CMP. Floyd's point about not needing the "heavy weight" nature of CMP EJB due to the fact most are already fronting them with Session EJB makes total sense. So starting from "CMP is out", I'm left with considering current JDO tools (Castor maybe if robust enough), or some RYO technique. If RYO, I definitely don't want to mix java and jdbc. Small stored procedures (even if many of them) which provide for the PM layer seems acceptable. I'm aware that many preach to avoid stored procedures. Scott Ambler goes as far as to refer to them as nothing more than a hack unless dealing with legacy dbms. He also proposes to avoid joins due to their inefficency. I don't buy that. You can't get more efficient than a compiled stored procedure, and relational dbms's are made to facilitate joins. Why fight the tape? If I'm building a prototype for a client, I may attack this in iterations. It would make for a good comparison to build the PM layer with stored procedures, and then follow up with a tool (JDX, Castor, ...) and make a judgement call. If a third party PM tool provides enough gain and productivity to overcome "yet another layer of black box trust", then fine, use it. I've been on one n-tier project so far (COM+, not J2EE) and we were using Transact SQL stored procedures for the PM layer. You end up having to make some project standards early on. For example, in a typical business system you end up with retrieval requirements from a table where you also require "lookup type" columns (names, descriptions, ...). What if you also need data from the same table sometimes where you don't need the "lookup" columns. Do you just write one stored procedure that always returns the "lookup" columns which WOULD serve both needs. Probably not, because in distributed systems you need to minimize the network traffic where you can. So you could have two seperate stored procedures for each need. You could also cache all of the "lookup type tables" and resolve them after the initial data retrieval. I suspect that would normally be the most common technique. This would leave you with just base table column retrieval (including joins) via stored procedures which seems very efficient to me (in and out, avoiding dbms bottleneck). I like the idea that the developer, or maybe the dba now has an opportunity to tune or tweak the sql vs "black boxing" it. Sure, system modifications will now probably require me to touch a couple of layers of code, but if it's well documented and standardized, so what? Anyway, just thinking out loud. Still in search of J2EE KISS. :)

    Oops... maybe really off-topic now. I've turned ".NET will dominate" into, "what PM technique". :)

    Mike
  344. Guys.

    This is *another report* on NET/J2EE published recently

    http://www.sdtimes.com/news/057/story7.htm

  345. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    The following quote was taken from the link

    http://www.sdtimes.com/news/057/story7.htm

    <quote>
    The bottom line: Despite the best efforts of Microsoft and Sun, the platform battles remain deadlocked, with both .NET and Java expected to perform strongly over the next year.
    </quote>

  346. One factor that will make the .Net adoption much slower is the overall economical situation around the world. People are less tempted to just try things out and throw budgets for unproven technologies or even re-do stuff that they have already invested in. This means the pure MS shops will actually have to spend to upgrade their skills, but the Java shops can go on and build on what they already have. VB.Net is not VB and the migration is not smooth as people would expect.

    A lot of the quick technology adoption of the late '90s was also fueled by the availability of funding and technical "exuberance". This has now slowed down, every decision to support or implement a product/technology has to have a clear economical sense. This gives a very powerful influence to the open-source community that keeps on the good spirit and necessary exuberance which is not to be found in the big companies anymore.

    Just an opinion.
  347. I've enjoyed reading the ongoing debate regarding this issue.

    My only point is the lack of credibility in the so-called 'paper'. I respect the author's opinion, but it's not a serious document. It lacks in direction and scope (is it about Net/J2EE/others, OS, hardware, etc?), it name-drops technologies for the sake of credibility or empathy, the personal opinions subtract from the objectivity required, the arguments do not conclusively support the premise, and the spelling mistakes indicates a laziness of effort. Such writing should be labelled as what it is, an opinion (or somebody's thoughts), and not pretend to be otherwise as a PDF paper with pretty layout.

  348. Hi Ben,

    I regret the spelling. I did not do the last check after the last set of rewrites. And rather than publish a fixed one and be accused of changing the message due to popular pressure I left as is.

    I have read more balanced papers from lots of people and they are all basically saying 'do nothing, wait and see'. Which comes accross as balanced, but does not reflect my feelings on what is going to happen. Most papers are not aimed at developer architects who have to actually be able to code as well as draw the pictures. Most are aimed as decision makers who simply sack the deskilled and rehire the new skilled - especially with so many techies 'between jobs'.

    So, the lack of 'but this, but that' was deliberate. And after reading the massive number of comments I still recon the main message is totally true (i.e. train). The debate of tech A v's tech B is way too large for a 4 page paper. There are 400 page books for each aspect of java and .Net, so no-one is going to do a useful comparison in 4 pages. What they can do is state a position, with a little background and hope to get some decent ideas going, especially in a forum such as this.

    For instance, I had no idea that Forester was touting fat (fit) clients. Or that so many people would agree with that position.

    Jonathan
  349. I understand that condensing such a complex subject into a brief synopsis is difficult, but I have to admit that I had some major problems with some of the content.

    - Java is simple.
    Only if you write simple code. Look at the concurrency issues, double-check locking and the ongoing JSR 133 work to realise how complex some areas of it can be.

    - J2EE is not.
    I think you are mis-stating your case. You wish to say that EJBs are not - with which most people would agree. To tar all of the technologies represented by J2EE with the same brush is very unfair. The other elements of J2EE are pretty straightforward (or as straightforward as the underlying technologies will allow).

    Fundamentally distributed scalable server-side solutions are complex. To state that they should be simple is a nice wish, but is somewhat orthogonal to reality.

    - Front ends will be written in C#
    Very much doubt it. There are hoards of VisualBasic(.net) programmers to throw at front-ends. Had you said (Windows) front-ends will be delivered in CLR, I might have agreed.

    - Fat clients will return.
    The fat client/thin client pre-eminence is cyclic. Given that thin clients have been strongly in the ascendent recently, some correction is inevitable, but I don't see it as a long term trend.

    The thickness of the client is always going to a trade-off between -
    - Portability, ease of upgrade deployment and ease of system maintenance for thin clients.
    - Responsiveness and functionality favouring the thick clients.

    - Success of Unix/Linux will affect J2EE.
    Not to a large degree. The biggest selling point of J2EE is not its platform portability (although that helps it integrate with a company's existing infrastructure). The big selling point is the ability to free yourself from vendor lock-in, whether that be app-server vendor, messaging vendor, etc. This is very powerful because it puts the company management/purchasing in a strong position when negotiating with vendors.


    The context of the article is made most plain in the statement that after 20 years of slating MS technologies, it was a shock to the author that they had a credible offering.

    To those of us who have come to Java from a Windows background, this is not a surprise. The Windows NT 3.5 of 7 years ago was probably the most stable OS that they've yet produced, etc, etc. We know that MS products work (when used with other MS products!), the issue I for one have with buying into their products is partly business, partly philosophical, and centres around freedom of choice:

    - Our own freedom of choice:
    MS products are only ever really guaranteed to work with other MS products. Thus by choosing an MS product for one part of your system, you are effectively denying yourself choice on the supplier on another part of you system. You will be sucked into vendor lock-in.

    - Other people's freedom of choice
    MS's aggressive business methods mean that any money given to them will be used directly to eliminate/absorb the competition. This reduces consumer choice. Thus by buying MS products you are indirectly denying choice to other people.


    .NET will always be around, I just hope that it's not the only choice.

    /david
  350. Beavis & Butthead respond[ Go to top ]

    I went to the experts to get their take on this whole J2EE vs dot-Net debate. Here is the highlight of the interview:

    Beavis - "hehehe dot-Net rules!!!!"

    Butthead - "shutup Beavis...huh huh huh Java is cool"

    So that about sums it up, Java is cool.

    :-)
  351. Jonathon,

    I will let other's decide if you supported your opinions or not, but I just wanted to make the observation that this thread definitely brought to the surface the effort and sacrifice so many have made learning J2EE (including yourself). I think building successful, maintainable software has always been a challenge. Add to that a choice between J2EE and .NET, and I find myself asking, "aren't the vendor's asking for to much from the developers". Maybe we are just in a transition period, and the required skillsets for n-tier development can be condensed in the near future.

    I did want to ask you a question. Why do you think "async" needs have not come up more in your projects. I was on many Powerbuilder client server projects where something always came up that would have been perfect for "asnync" requests. Stuff like really long running reports, or maybe "batch" type requests. This usually led to some "home grown" approach where you would insert a row in table from the PB UI, which would then get picked up by some server side process. It looks like JMS would serve such a purpose in a much more straight forward fashion. ??

    Mike
  352. One other comment:

    All of us technical types should really try and not flame each other. We should save all of that energy for our "stupid" management. :)))))

    Cheers,

    Mike

  353. Well said! I think I was writing to my project manager (the one who writes questionable documents which we're meant to use to write bug-free systems) when I critisized Jonathon's article. I'm all for this interesting debate, and perhaps if the paper was perfect we'd have nothing interesting to add.
  354. I have a question about C#... anyone????

    Since everyone is so down Java's use of accessors/mutators, and C# lets you access variables property style, does that mean you can synchronize variables?

    In java you can't, so to enforce read concurrency, you would create an accessor method and synchronize it. If no method then I assume MS has provided some way to obtain a monitor on a variable.

    Am I missing something here?

    -Newt
  355. No, You have to use lock method to make sure sync.
  356. Now that is interesting about the synchronization.
    I find that sort of defeats the purpose of usinge variables as properties instead of through accessors and mutators.

    If I use the property way, and something changes requiring synchronize (or something else not accessible), I have to not just change the method, but I have to add a method, and change anywhere where the variable is called.

    So I would probably end up using getters/setters _anyway_ just to ensure common use, changeability/extensibility.

    Does this make sense?
  357. <Quote>
    Since everyone is so down Java's use of accessors/mutators, and C# lets you access variables property style, does that mean you can synchronize variables?
    </Quote>

    I'm reading Inside C# and this snipplet is from their "Thoughtful Innovation" bullet:

    <Quote>
    ...if the framework supports properties and the language doesn't, incrementing a property is awkward (for example, o.SetValue(o.GetValue() + 1)). If the language also supports properties the operation is simple (o.Value++).
    </Quote>

    Maybe they should have looked at Meyer's Uniform Access Principle before totting this around.

    As far as monitoring variables I do not know, but it's the same in java. You may use accessors and mutators but if the access modifer on the member allows direct access then your in the same boat.

    This is pure rhetoric, I'm just bored.
  358. When Microsoft share their source with me and stop their anti-open source campaign, I'll think of sharing my time and money with their solutions.
  359. This article is simply a case of immature foot stamping "if I can't know it all, I don't want to be part of it", has theserverside really dropped to this level of garbage?
  360. I don't think it is "immature footstamping". It was quite a thoughtful piece. Dead wrong of course, but thoughtful.

    And Jon does have a point. .NET is apparently easier to get going than current APp Server products, a competitive adavantage which BEA is addressing with Weblogic 7.0.

  361. Comes to my mind a piece from my old professor:

    When a psychologist explains something for the class and the students responds, "we don't understand anything", the psychologist feels proud.

    When a philosopher explains something for the class and the students responds, "we don't understand anything", the philosopher feels ashamed.

    For some reason the Java evangelist feels so proud when people don't understand their J2EE/EJB mishmash. Is it possible they all are former psychologists?

    50+ application servers, 20+ different frameworks on top of that = 1000 different approaches..

    Regards
    Rolf Tollerud
  362. Rolf Tollerud writes:

    "For some reason the Java evangelist feels so proud when people don't understand their J2EE/EJB mishmash. Is it possible they all are former psychologists?"

    This isn't at all true. Enterprise-level software is relatively complex, always has been, probably always will. Relative to many other types of software, that is. As with many other types of software there is a tendency for the scale of the projects we undertake to grow as the capacity of our tools increase as well.

    There are a lot of talented developers who don't have much problem with the percieved complexity.

    J2EE is actually a simplification of about an order of magnitude over the previous generation method of doing such things.

    One can get a minimal server-side EJB system up and working with fairly minimal effort if you possess decent documentation about your specific App Server.

    The problems tend to come when scaling up. How do you benchmark the results, how to test, and how to do optimization to get the best results?

    Server-side is not as easy and simple as painting a UI in Visual Studio or JBuilder I will readily admit, but then few programming tasks are as apparently easy as UI programming. I find PL-SQL code (for the Oracle DB) more difficult than the typical EJB.

    If you look at the code which an IDE generates, it is not easy to understand without knowing the API's it is using. IDE-generated GUIs tend to be hundreds of lines long, though of repetitive structure. The reason IDE's work is that these are among the easiest kinds of programs to write, as they require almost no code design. Bad programming but who cares as long as nobody ever has to go in to directly hack the code?

    1000 different approaches? Perhaps so but it doesn't matter. The same EJB will run on all App servers unchanged, though the App server will have to be configured to recognize the EJB. There are at most 10 App Servers offering EJB's, and to my reckoning 5-6 important App Servers. Weblogic, Websphere, JBoss. Perhaps IPlanet, HPAS, Oracle, JRun, and Borland are pretenders.

    Apart from configuration the complexity comes from how you put the EJB's together, which interfaces they use, and sizing thread pools, instance pools, and using shared connections. Do this part right and you will have an enterprise app which humms. Do it wrong and it will still work but much more slowly.

  363. "Apart from configuration the complexity comes from how you put the EJB's together, which interfaces they use, and sizing thread pools, instance pools, and using shared connections. Do this part right and you will have an enterprise app which humms. Do it wrong and it will still work but much more slowly."

    Well you may be right that some projects needs all that but I am quite convinced that JPetStore (independent implementation of Petshop based completely on open source freeware), with code base about 25% of the original EJB Petshop, will manage quite well at 2000-3000 users.

    The problem is that of all the projects where you bring in the heavy EJB artillery it is blatant overkill in 19 of 20 cases. EJB have become the most expensive fashion in business. I have seen money been destroyed before but nowhere like this. Where is KISS? What is it in J2EE/EJB who seems so attractive to impractical theoreticians?

    Regards
    Rolf Tollerud

  364. Rolf Tollerud writes:

    "The problem is that of all the projects where you bring in the heavy EJB artillery it is blatant overkill in 19 of 20 cases. "

    Sometimes yes. How many database projects are done with Oracle when MySQL would have been perfectly adequate? Plenty, I assure you! That is one facet of a very old problem.

    The most expensive software problem is underspecification, not overspecification. Overspecification leads to a working system which is more powerful and expensive than needed to solve the immediate problem. An upside is that such a system can be expanded and upgraded with relative ease.

    Underspecify and watch a 'solution' thrown away or never deployed because it cannot perform.

    "EJB have become the most expensive fashion in business."

    ROTFL! Nowhere near 'the most expensive fashion'. The most expensive fashions in business have been A) Managerial incompetence (particularly in handling staff) and B) Fascination with expensive CASE tools.

    "I have seen money been destroyed before but nowhere like this. Where is KISS?"

    How long have you been around? The bigest, hairiest EJB project around must have cost all of maybe $10 million bucks. In 1997 my employer at the time (Bell Atlantic) stopped three major projects for a total cost of a cool 500 million!

    1What is it in J2EE/EJB who seems so attractive to impractical theoreticians?!

    I haven't met an 'impractical theoretician' yet in the J2EE space. Neither Mike Jones, Basil McRae, or myself are impractical theoreticians. I have helped deliver many working systems in my career as has Mike. We're moving into J2EE because it is a better, faster, and cheaper way of doing what we do already.

    Do you work in Redmond, Washington perchance?

  365. Hi Don,

    "The most expensive fashions in business have been A) Managerial incompetence (particularly in handling staff) and B) Fascination with expensive CASE tools."


    Well, I can agree with you there!

    I am not employed by Microsoft but I admit that I am working with MS tools. But I have two years working with Java (ATG Dyamo, Tomcat/Velocity, not EJB) before going back to MS.NET What I missed most was the debugger..

    Anyhow as long as the two camps only keep bashing each other we are getting nowhere but we do have a common interest, a common cross platform language that is accepted more or less by the whole software industry..

    Java was going to be that language, but the Sun lawsuit stopped that. You have to admit that MS could not accept a programming platform that was totally defined by Sun? After all Sun was and still is MS worst enemy (long before Java) and never did loose any chance to bash MS.


    Java is not going to be that language now MS will never accept it. How much chance do you think is it for Java to succeed (as a common cross platform language that is accepted more or less by the whole software industry) with MS dead set against it?


    So we are left with two possibilities, either C#/.NET or some combination/amalganion of the two platforms. I don't think C# is going win either so some compromise has to be made, both camps have to admit the weaknesses of their own sides. The Java community have to admit that EJBs with entity beans and container-managed persistence was not a good idea and should never been in the standard in the first place.

    That is nothing to be ashamed of, mistakes are done (by humans and especially by committees) and there is probably something similar wrong with .NET. Mistakes exist to be corrected. But as long as the community blindly defends everything down to the last comma based on religiously feelings we are not getting anywhere and progress can not be made.

    Regards
    Rolf Tollerud
  366. Rolf Tollerud wrote:

    "Anyhow as long as the two camps only keep bashing each other we are getting nowhere but we do have a common interest, a common cross platform language that is accepted more or less by the whole software industry..

    Java was going to be that language, but the Sun lawsuit stopped that. You have to admit that MS could not accept a programming platform that was totally defined by Sun? After all Sun was and still is MS worst enemy (long before Java) and never did loose any chance to bash MS."

    Actually the Java vision was FAR more complete than a mere 'common cross-platform language accepted by the entire software industry'. We already had that with C++ which was the most common language on Unix platforms and was also used for most serious Microsoft development. The problem with C++ was that the Unix and Microsoft C++ communitied used almost completely incompatible APIs, which meant that programs were not cross-compatible accross platforms.

    The Java vision is not only a cross-platform language but a completely cross-compatible operating environment. Write once, run anywhere. All you have to do to run Java programs on a platform is to obtain a JVM for that platform.

    Microsoft tried to adopt Java as 'J++', just another language in the Microsoft stable of languages. Visual J++ was going to operate similarly to Visual C++, using the same Microsoft-specific stable of API's, and Microsoft would then claim to 'support Java' when it broke one of the most important ideas behind Java. M$ J++ programs would not run anywhere but Windows.

    I don't claim to know whether Sun should have filed suit against Microsoft over that issue, but Sun did and does own a copyright on Java, and Microsoft was taking the parts of Java they found convenient and discarding the rest.

    Rolf:

    "How much chance do you think is it for Java to succeed (as a common cross platform language that is accepted more or less by the whole software industry) with MS dead set against it?!"

    Technically Java DOES succeed as 'a common cross-platform language'. The only one to date.

    On a business level I don't expect the 'whole software industry' to adopt a single standard because Microsoft insists on a large degree of control over anything it works with. Look at the history of CORBA and COM if you doubt that. OMG wasn't even a Microsoft rival, just a standards body. Even so Microsoft could not agree on CORBA as a standard.

    BTW, I am not 'bashing' Microsoft .NET as a product. It is something which I intend to learn at some point. The problem is that I don't have it at work, the Visual Studio product costs a mint, and most books use Visual Studio. Microsoft ought to make it cheaper to acquire and learn if they wish people like me to adopt .NET.


  367. Don Stadler wrote:

    "Microsoft insists on a large degree of control over anything it works with. Look at the history of CORBA and COM if you doubt that. OMG wasn't even a Microsoft rival, just a standards body. Even so Microsoft could not agree on CORBA as a standard."

    OMG and Corba. Has there ever existed a more elephantiasis committee product by impractical theoreticians, are you serious in blaming MS for not accepting that?

    The main thing we don't agree upon is that MS is "evil". MS did not want a large degree of control over the Java standard, but only wanted "some" influence.
    Should MS throw away all COM/ActiveX work with thousands of third party products?
    Was it not necessary to have an efficient way to communicate to legacy API?
    Is not the IBM Eclipse project nothing other then a duplication of MS Java AFC?

    To me it seemed that Sun deliberately wanted Java to perform badly on Windows.

    I would prefer that Java was free and open sourced, but if that is not possible I am convinced that if MS really had a "large degree of control of Java" the situation would be infinitely better for everybody. And I am sure they would not have come up with EJBs with entity beans and container-managed persistence..

    Can you honestly and seriously deny that there are not at least a little grain of truth in what I am saying?


    Regards
    Rolf Tollerud
  368. Rolf Writes:

    "OMG and Corba. Has there ever existed a more elephantiasis committee product by impractical theoreticians, are you serious in blaming MS for not accepting that?"

    Yes. Do you remember MS Bob? And the bloody paperclip....
    Brain dead.

    Talking about impractical, shall we discuss the subject of MS Word, feature bloat, and flaky, unsupported applications? What about enormous gaping security holes in a macro language used across an entire integrated office suite? Practical?

    Actually CORBA works and it would work better if companies like Microsoft weren't seeking to protect their own turf.
  369. Rolf: "OMG and Corba. Has there ever existed a more elephantiasis committee product by impractical theoreticians, are you serious in blaming MS for not accepting that?"

    What an unsubstantiated crock of shite.

    CORBA may not be "beautiful", but it holds together most of the pre-J2EE enterprise systems that are in existence.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  370. Think the man works for Bill, Cameron?
  371. CORBA[ Go to top ]

    Yes, but didn't CORBA only work well in the 2.0 specification?

    Perhaps Microsoft ought not to point the finger here, given their well-known penchant for only getting it right in version 3.1 themselves......
  372. Hi Jonathan,

    I agree with every point bar one:- Page 3, under the heading 'Unix' - "If you have maybe two thousand users, then a Microsoft server will be fine. In fact any old PC
    running NT, 2000 or XP will probably be fine." You must have taken leave of your senses - whilst the first sentence is more than correct, "any old PC" will most certainly not do for "maybe two thousand users", unless you are talking one. The moment I saw this in print I was reminded that you are a developer and director of your own consultancy - understate the platform requirements so that the software and project costs becomes affordable, which, to turn a respectable profit, you would have to do - if coding in J2EE.

  373. When it comes to uptimes for Windows 2000/XP server the TSS members would not have very much to learn from Baron von Münchausen.

    Regards
    Rolf Tollerud
  374. Rolf writes:

    "
    When it comes to uptimes for Windows 2000/XP server the TSS members would not have very much to learn from Baron von Münchausen
    "

    Well... In my shop, I have an exchange machine running Win NT. It has a great traffic. 1000 users. Usually, it crashs every 2 weeks. At its side, I have a Linux machine, running a web server with apache + tomcat. The last time I rebooted it? January, 2002 (when I installed it).

    To be fair, I have another NT Server, this time running Oracle. It has not been rebooted since february, and it's very stable. Of course, it's a very controlled environment. I installed NT Server, nothing else, than Oracle. And now, the dba only administers oracle, remotely. No one touchs the machine directly.

    Now, where is the problem? In the exchange server, or in the operational system?

    My point is: Microsoft knows how to do SOMEthing. The problem, actually, is that they want to do EVERYthing.

    Standards. What a beatiful word.
  375. It sounds like the exchange server is the problem in this case.

    Microsoft has to realize that their brand name has come to stand for flaky software and voodoo support service. Coming from a Unix background I simply could not BELIEVE my EARS when I was first told by a NT SA that he was going to have to reload the operating system in order to fix an apparently trivial problem.

    I spent an hour on a MS help line seeking help with a huge Word problem only to be told (in essence) that they didn't know and could not find out why Word was massively reformatting pages of test when I pasted text from one Word
    document into another (same version) Word document. I've heard tales of the same kind of clueless 'support' on all versions of the NT operating system.

    Does Mr. Gates really believe that slick marketing will compell people to believe him and not the evidence of their own eyes?

    It may be that XP is (finally) stable. But a MS Server installation is based on several packages. Is it reasonable to believe that every MS package used will be stable? Would you bet your business on it?
  376. Dennis, it depends on whether one defines it as 2000 total users or 2000 concurrent users. I believe 2000-5000 total users were the meaning in this case.
  377. .Net is sold like a product (even thought MS claims it to be a technologie) and will follow the same product life cycle as any other MS "technologie" product. And you will be tied to that.
    Debating over UI aspects is irelevant and narrow minded. UI is the top of the iceberg. It's your job as a consultant to make your client understand there's more to an enterprise's information system than user interfaces. But my guess is you only dealt with small front-end apps so far.
  378. Jonathan, I suppose http://www.tallsoftware.com is your professional website. You say your a senior consultant, so your website tells us what you do. Then why is it that your website's pages have frames in them since you're such a Web/Java/HTML-and-stuff Guru? After all, you allow yourself to give us "advice" about what we should do or shouldn't do, right?
    Tell me, what's the story with that anti-american joke on your home page? Links to RPG games?? As a matter of fact, how old are you?
  379. Implementing J2EE for small and medium projects is (very) easy and (very) cheap. Implementing J2EE for large and very large projects is (very) difficult, but it's much easier than if you didn't have the J2EE framework to take advantage of.
    In the end, J2EE is not that difficult in itself, it's what you do and how you do it that makes things difficult, and it would be just as difficult with any other technologie.

    Are you afraid of acronyms? Go to Microft's website and be scared to death.

    Since you like games so much, I'm sure you'll appreciate this one. It's called Twenty Question:

    - If you go .Net will you be given choice and freedom or will you be a servant with a wallet?

    - What's the difference between "making things simpler" and "making things easier"? (Do you really think there's no diference?)

    - What's the rest of the sentense "Why bother...":
    a) "... thinking since MS does it so well for you?"
    b) "... changing my good ol'habits?"
    c) "... risking my life on ship to see if the world's round?"
    d) "... bothering?"

    - Can you only be productive with a MS helping hand? (Can't you be on your own? Why not?)

    - Why do you think life support and surgery systems don't run MS technologie/products? (You probably never worked for clients in the medical sector.)

    - Why do you think people like Boeing, Airbus, Lockheed Martin and Nasa are investing in Java instead of .Net? Do you think it's just because they like complexity instead of simplicity or do you think they're plain stupid? Do you think they're not concerned about productivity?

    - What do you think kids are learning in university today? C# or Java? Windows or Unix? The answer is Unix and Java. They use Linux to work and Windows to play (but that you already know). Today's students are tomorow's developers, architects and managers.

    - You think J2EE is creating problems. To J2EE you oppose .Net. Does that mean you think .Net is not creating problems at all. Or do you think it will also create problems but MS will in time solve them for you. How many service packs do you expect for .Net?

    - You don't like having problems with J2EE and therefor prefer .Net. Does that mean you prefer to have vendor related problems than technical problems? Or do you think vendor related problems are easier to solve than technical probems?

    - You doubt that you'll need JMS in any futur project of yours. Is that because you'll defenitely be using .Net or because you don't know what Javamail is?

    - You wrote "Three years ago I would have written the same system using servlets, html templates, jdbc and some stored procedures - and this would work just as well as the J2EE based, app server hosted modern Java equivalent."
    Why is it you don't know the fundamental diferences between a J2EE architecture and Model 1 since you claim to be a J2EE architect? As a matter of fact, how will your Model 1 based online banking system scale to a secure clusterd environment when your client's business will expand? I think you'll be out of business before your client is.

    - I can't believe there's a "Web page design" (~guide) section on your site. Have you actually read it? I don't think so.

    - Don't you think an "advice" like "Listen to me, you should really start learning this or that, especially .Net" is misplaced? Don't you think we are mostly adults who are able to make descisions for ourselves?

    - What did you expect when posting a message that says ".Net's so great" on a java/J2EE thread? Did you really think we would all say Bravo and applaus?

    Of course, I don't really expect any sensible answers from you...
    Your "paper" is a pure subjective point of view. It reflects your very own and limited experience with the market. Don't you worry about all those acronyms you're having a hard time to learn, others are succeeding where you seem to fail. They'll make and take the kind of market you don't want.
    Don't tell me what I should do and I won't tell you what you should do.
  380. Just had to essay some answers to the following questions from Mr. Kosravi.

    <Irony>

    Stephen Kosravi asks:
    "- Why do you think life support and surgery systems don't run MS technologie/products? (You probably never worked for clients in the medical sector.)"

    and

    "- Why do you think people like Boeing, Airbus, Lockheed Martin and Nasa are investing in Java instead of .Net? Do you think it's just because they like complexity instead of simplicity or do you think they're plain stupid? Do you think they're not concerned about productivity?"

    Two quick answers. One might be that every single person working with Web-based apps in both the surgical and aircraft sectors is brain-dead. Another possibility is that it's a real lead-plated SOB when an app crashes in the middle of a surgical procedure (and even worse if an app crashes in the middle of a flight). They don't understand that MS.NET and Win XP don't crash anymore being now perfect.

    "- What do you think kids are learning in university today? C# or Java? Windows or Unix? The answer is Unix and Java. They use Linux to work and Windows to play (but that you already know). Today's students are tomorow's developers, architects and managers."

    You know college kids. They must *all* be on drugs! Except the few who made the *obvious* choice that is. Kids have no judgement......

    "- You doubt that you'll need JMS in any futur project of yours. Is that because you'll defenitely be using .Net or because you don't know what Javamail is?"

    I don't *need* JMS because MSMQ *rules* the universe! Being ignorant I'm not certain what the direct connection between JMS and Javamail is (apart from sharing the first initial and both being Java API's.

    </Irony>


  381. Don,

    The brain dead comment is almost ridiculous. I've worked with defense related industry for the last year, and the simple fact is that these people are not brain-dead, they're paranoid. The defense organization I worked with won't even allow Microsoft servers in the data center. Would you feel secure/robust/happy handling classified information on Windows? I don't, and won't. These people don't just do this to be picky, they do this to ensure maximum safety tp prevent information loss through crashes or hacking.

    I'm sure the big aircraft manufacturers are really brain dead, but at least their information is robust and secure. Would you like to fly on an airplane whose avionics were run by windows? Do you really trust windows that much? How about the security of the JSF? Would you trust the designs to be stored on a windows server?

    I don't think so.

    Now XP may have eliminated these problems, but I'm seeing too many patches to believe it. MS loves to have their customers do their testing. Win2k went into sales with something like 26,000 known bugs. If I did that, my clients would go nuts.

    Even if XP was most secure and robust today, it would be some time before anyone believed it and adopted it.

    I've been bitten too many times trying to run production systems on Windows. Reboots once a week, crashes, security flaws.

    Even if .NET's functionality smoked Java's I still wouldn't be convinced. Maybe after XP and .NET been out there for a while, and I've seen some really good implementations.

    -Newt
  382. Jason McKerr wrote:

    "The brain dead comment is almost ridiculous."

    Bingo. Got it first time (well, almost).

    "I'm sure the big aircraft manufacturers are really brain dead, but at least their information is robust and secure."

    You might want to swot up on the meaning of the <Irony> tag,
    guy. There were enough clues in my post, including the reference to apps crashing in the middle of surgical procedures and the note that an app crashing in the middle of a flight was potentially more serious than that. Crash an app, crash a airpl...?

    .NET: a natural for air traffic control, don'tcha think?
  383. Don,

    it's not kind, you naughty man.

    Jonathan
  384. Sorry Don,

    Didn't read your post that carefully. I will do better next time. I beg forgiveness. I actually noticed the irony tag right after I posted....


    I guess using .NET in aircraft might give the BSOD new meaning.

    -Newt
  385. Apology accepted, Newt. No problem at all.
  386. Opinion: Java to J2EE to Oblivion?[ Go to top ]

    Don, Anyone, ??

    An OT question, since so many experts are here. Don had mentioned connection pooling above handled by the application server based on proprietary settings. Like I said, I haven't cut much code yet.. stuck in theory land.

    Question: If I avoid entity EJB's and used a tool like Castor, or roll my own (RYO) persistence layer with JDBC and/or stored procedure calls from simple java objects instead of entity beans, would I still be under the control of the application server connection pooling (simple java classes being called from Session EJB facades), or does RYO imply you also have to RYO connection pooling? Probably a very rookie question.

    Mike
  387. You can use a javax.sql.DataSource from anywhere in your J2EE app; you only need JNDI to look it up.
    Any database access, container managed or not, goes through a java.sql.Connection, which can be obtained only from a java.sql.Driver or a javax.sql.Datasource.
  388. reserved,

    Thanks for the repsonse, but let me clarify my question. I understand JNDI lookup and java.sql.Connection. What I'm asking about is connection pooling. If I use entity beans (CMP or BMP), database connections are managed (pooled) by the J2EE application server per proprietary setttings of that server, right? So my question is, if invoke (via Session EJB facades) plain old java objects (RYO persistence layer) which use java.sql.Connection, would those connections also be managed and pooled by the application server? I think the answer is yes, but am not positive.

    Mike
  389. Mike,

    why not use one of the open source ones - that way you can examine exactly how it works and fiddle with it depending on your own requirements. No need to use the app server at all.

    As for the exact question. Hmmm. If you use the configured data source located via JNDI then you get their pooled connections - ie its their code you are running which adheres to the spec. If you simply use the oracle driver you get the oracle connection - ie its the oracle implementation of the connection class, vanilla. Is that what you mean? If you use your own then you have to do your own transaction stuff, and watch out for class loading issues with singletons within the app server (ie the connection pool of your own would be a singleton). I'd have to dig up the issues there as it's some time since I did that.

    Jonathan
    ps I'd use the app server and jndi to the data source myself.
  390. Jon,

    Hey, you provide thought provoking white papers and help out. Excellent. :)

    "why not use one of the open source ones - that way you can examine exactly how it works and fiddle with it depending on your own requirements. No need to use the app server at all."

    That's exactly what I intend to do next... that and look for work. :) Can you recommend one to start with. I am leaning towards Castor, but I have seen a couple of comments on this website that lead me to believe it is not robust enough.

    "If you use the configured data source located via JNDI then you get their pooled connections - ie its their code you are running which adheres to the spec. If you simply use the oracle driver you get the oracle connection - ie its the oracle implementation of the connection class, vanilla. Is that what you mean?"

    Yep, that's exactly what I was asking. That's what I thought, and I apprecite the confirmation.

    By the way, in reference to your conversation with Don about C# vs VB.NET skills. I think you are both right (how diplomatic). I think current VB\COM+ programmers and client sites will stick with and promote VB, and Microsoft will actually claim they hacked\rewrote VB and actually turned it into an OO language. I think C# will take of IF your prediction about .NET winning a large market share, which will bring over the java guys. I think most Java developers would desire to migrate to C#, and not VB.NET. Granted, the client site will dictate which skills that are used, but if you have a large influx of java programmers to .NOT (Sorry, typo), you have to figure the voices from the developer community would win over a large number of project startups. JMO and frickin guess ABOUT THE FUTURE.

    Thanks for the help,

    Mike

  391. You ALWAYS use a java.sql.Connection, which can be pooled or not.
    Entity beans don't necessarily use connection pools, and it is not at all automatic: either you tell them to use some DataSource you have defined or you use a Driver (and possibly homemade connection pools, like you suggest for your session beans).
    Connection pooling depends from where you get connections from: a DataSource is supposed to use a pool, a Driver (usually accessed via the DriverManager) is supposed to actually create them.
    Therefore connection from a DataSource, when closed, go back to the pool while connections from a Driver are really closed and lost.
    Typically connection pools are implemented with a class that implements java.sql.Connection and delegates all JDBC calls to a "real" Connection which is left open and managed by the DataSource implementation.

  392. Reserved,

    Thanks. Good explanation.


  393. Why do I keep posting to a forum that is basically a java/J2EE thread?

    Because it is fun of course. It is always fun to be the "niño" as in The Emperor's New Suit by Hans Christian Andersen. And in my experience the person who is very angry and raise his voice are very seldom right.


    Cite of the day for free (Yahoo Finance):
    "Wooing programmers and their employers in Bangalore, India's southern software centre, involves blending serious mental challenges with fun. Microsoft and Sun line up day-long seminars and months-long competitions, laced with entertainment.

    In the past few weeks, Microsoft, Sun and chipmaker Intel (NasdaqNM:INTC - News) have all held seminars for Indian developers. Sun's "Tech Days" saw 1,000 paid attendees, the Intel Developers Forum 700 and Microsoft's VisualStudio tool show drew 7,500."

    Regards
    Rolf Tollerud
  394. Hi Stephen,

    Bit more awake now, and rereading your post I think you are serious as opposed to simply flaming. So to answer your points.

    I took up java when it first started. For about the first 4 years no one would use it in aircraft or military projects because it was percieved as crap. ie garbage collection could pause your aircraft and make it fall from the sky. Eventually it reached critical mass, then dotcom started up and everyone had cash for large app servers and so they spent it all. I was well positioned, which a great skill set to milk this market.

    .Net is relatively new, (but I realise now that loads of folks are already ramped up...I'm a late entrant). In two years it will have proved itself in the early adopter mid size projects. At this point (ie 2 years) I want to be in a position to 'get that job'. I think the first para of my paper mentions being employed as a major motivator.

    Some of your other points:
    model 1 doesn't scale? Rubbish. If you use Oracle then anything you do will scale. Been there, done that. You can write it in whatever you like and let Oracle take the load. I am starting to hear better things of sqlserver since they got in an external db expert... wait and see on that one. Obviously you can use oracle badly. For instance you can distance yourself from its power and use a lowest common donominator technology. Your choice.

    You say I prefer .Net. Please read it again. What I say is I must learn it, and that I'd recommend learning it to everyone. I never say I prefer it.

    You ridicule the web site. Honestly I don't care. That part of your post is entire flame.

    One thing to think upon. What is one of the most crucial business system, enterprise wide at the moment. Email. What is the worst implementation, which crashes in the server, installs viruses at the client and generally annoys the hell out of me. Now why is that almost everyone uses it? It's got nothing to do with technology, it's to do with business and marketing and a 'good enough' perception.

    Now think again about the next two years and where the market will be. Not now, but in two years. When you have aged a little, and there are younger and cheaper techies on the market. Now what skill set do you want?

    Java will still be big, much as C++ is. I have friends who have 14 years C++ under their belt and will probably do another 14 years because of the systems they work on. You can stay with Java, there will still be lots of java projects. There will also be loads which require java and .Net or just .Net. Do you honestly recon I am wrong in this? If so you can disagree with the paper, because that is all it says. Everything else is in your imagination.

    Jonathan
  395. Jon Gibbons writes:

    "Now think again about the next two years and where the market will be. Not now, but in two years. When you have aged a little, and there are younger and cheaper techies on the market. Now what skill set do you want?"

    This is a good point, Jon, but are you sure that MS.NET is the place where you are going to want to be? The best current info on .NET skills demand is that there is very little current demand for C# and quite a lot for VB.NET, ASP.NET and VC++.NET. That seems quite significant to me.

    I would not care to try to compete with 'younger, cheaper techies' in either VB or ASP which are reputed to be easy to learn. That leaves one with VC++, which is a firmly established market niche with thousands of established practicioners, or C#. Hmmmmm.

    MS.NET has two advantages in this respect. 1) it costs money to get an MS environment, 2) students are reputed to favor Java and Linux over VB and Windows. OTOH it's not expensive to buy a copy of VB or C# Standard.

    Java has plenty of market niches in which the value of experience can make itself felt. For starters try JCA, JMS, JMX, Jini, Jiro, and all the other J's around. remember that the larger and richer a skill set gets the harder it is to master it. Java has grown enormously in complexity and size since the early days, giving a natural advantage to the experienced person.

    Actually this is a point against Java in your reckoning, because you believe that Java's complexity and size will cause many organizations to dump Java and go with .NET.

    This seems to be a contradiction in your argument which you may wish to address, BTW. Java is too complex, therefore too many youg programmers are crowding in? Hmmmm.

    This hasn't been happening at my firm. I know of perhaps one truly young Java guy. All the other Java people are in their 30's and 40's.

    In your view MS XP has become stable enough to run many applications on. Perhaps so, but it will have to overcome the brand name for poor quality which MS operating systems have earned. Also the reputation for difficult systems administration. This will be difficult to do.

    "You can stay with Java, there will still be lots of java projects. There will also be loads which require java and .Net or just .Net. Do you honestly recon I am wrong in this? If so you can disagree with the paper, because that is all it says. Everything else is in your imagination."

    Agreed. I have written that one can make a career in Java or .NET or both many times, as have others. But what you claimed went quite a bit further than what you assert in this paragraph. You wrote that the market was going toward .NET and it was learn .NET or die (pretty much).

    And that is why you get flamed, Jon.

  396. Don,

    Nice sumary. I still recon I am right as well. That will be the way the market goes for the mid size enterprise systems I work on. I like making guesses like this. Historically I guessed well with OO, C++, Java, XML. I guessed badly on Linux (I learnt lots of it - no one with money wants it as a skill), and some others. When I say guessed, I mean put effort in and trained up in. We shall see.

    Jonathan
  397. Jon,

    You probably are right - for you. As I recall you intend to learn the C# language with .NET, probably with a bit of ASP and ADO (at a minimum) thrown in. This should fit in well with your J2EE background and set you up to be a nice Web Services all-arounder. Even though there don't seem to be long queues forming for C# programmers at the moment, you can make money in a niche as long as too many people don't crowd in.......

    What if everyone on TSS (or even a sizeable minority) thought as you do? You would have competition in what might remain a small niche. OTOH, you might believe C# will go nowhere if more people don't get into it (if there is no reliable supply of programmers, nobody will use it). Hmmm.

    I've been looking at developing .NET as a side skill, but my take differs from yours in that I would plunge straight into VB.NET and not bother with C#. I think that the bulk of the .NET adopters will be from the existing Microsoft community, and those will be VB and ASP programmers for the most part. VB.NET will be the Java counterpart for MS.NET, not VC# or VC++. Web Services look set to be the interface between our world and the .NET world, so learn that first.

    YMMV
  398. <JG>
    Solaris, HP-UX, AIX and so on will remain. But
    they are no longer required for mid size projects.
    If you have maybe two thousand users, then a
    Microsoft server will be fine. In fact any old PC
    running NT, 2000 or XP will probably be fine.
    So I believe many mid-level projects will slip
    away from Unix guru&#8217;s and fall neatly into the
    hands of Microsoft developers.

    ...

    The Unix vendors must come up with products
    that work on Microsoft, or come up with a very
    good argument for rolling out Unix based
    systems which are not simply based on
    performance, robustness and clustering.
    </JG>

    I find some confusion about hardware and software here, equating today's big servers with Unix and future powerful PCs with Windows.
    It might be half true that a common PC can be adequate (reliability is limited, and it is an hardware, not operating system, issue) but PC performance improvement doesn't imply that Windows becomes better than proven Unix-like operating systems, or should be chosen because it is traditional.

    What is a Unix product that works on Microsoft? A POSIX operating system for cheap x86 computers (at least three major ones are already available)? A .NET porting of existing middleware?

    Also, I really like performance, robustness and clustering; what else do you expect from server hardware, operating systems and middleware?

  399. Some more issues:


    Remote Management

    I have typically installed into production environment I have never seen.


    Up Time

    Requiring a reboot after installing new software etc.
    Low uptime is typically regarded poorly in production environments.


    Stability

    A platform which has had a limited set of both code and feature changes is highly regarded.


  400. What is really clear from this 65 Page!! thread,
    is that this issue really gets people talking.

    Why?

    Well clearly its important if a technology you have invested in declines (or does not accelearate as you anticipate).

    Issues raised are J2EE complexity and UI's.

    Can a J2RSE (Java 2, Right Sized Edition) be defined
    which is simpler but still
    addresses the most common issues?

    Can UI issues be addressed?


    These are not my favourite issues, which are:
     * A framework for syntax evolution (JSP, SQLJ, AspectJ, the new BEA tags, jContract, Scenario Beans, Templates etc)
     * A process architecture

    Can the Java community address the critical issues?

    If the Java community can respond, then GUI's, and development ease, web services and any other
    technical issue will be solved.

    If the Java community can not respond
    to issues they are dead.

    I think there are too many people
    who are too invested
    in the many vendor Java solution to
    allow one vendor to win everything.

    There are issues (there always will be),
    the Java community needs to address them.

    Brendan
  401. Here are some comments from the other side of EJB, 4 papers:
    www.ntnse.com/bad.jsp

    Also.... maybe you just try J2EE minus EJB?

    I do great with MVC + JSTL + DAO,
    see samples at www.baseBeans.com/downloads.jsp.

    Vic
  402. Hi Jonathan,

    You mentioned some "in-memory distributed database" in your paper. Where did you get that from? It could be crucial for my application.

    Ben
  403. Cheer up...[ Go to top ]

    You present some good issues: suitability of J2EE as a platform, long-term viability of Java, and ability for Microsoft to capture the hearts of the server communities, but it lacks persuasion.

    Suitability of J2EE as a platform
    My opinion on this sides with you. While there are several desirable features of J2EE, EJB is no longer one of them. At the time EJB first hit the market there were not many solutions. Big companies were clamoring for any solution they did not have to invent themselves.

    These days middleware layers are gaining traction: Hibernate, JDOGenie, Cayenne, etc. Most of these are fairly easy to use, perform well, and are getting better all the time. Also the utility libraries are more powerful than ever(xml/xslt, caching & concurrency, transaction, etc) and many with source to boot.

    Long-term viability of Java
    This is difficult to determine. It's hard to see what five years in the future will bring. I would agree there are many technologies that go into developing a successful product. This is particularly challenging for newcomers to the Java language. While the Java language can be mastered in relatively short order; mastering all the utilities and popular open source offerings could take a couple of years. But there is a lot of talent in the Java community.

    Ability of Microsoft to capture the hearts of the server communities
    I am a commercial software developer with 15 years of experience. I develop in both Java and VC++. I like Java particularly since the community is very open. Microsoft does not have a good reputation in this respect. There are two hearts to capture in the server communities: those of the developers and those of the IT staff. I think Microsoft has made some improvements in manageability over the years that will keep IT folks happy. For developers, I still joke that the 10% Microsoft falls short is where I spend 90% of my time <grin>. I don't foresee a mass exodus to .NET.
  404. Cheer up...[ Go to top ]

    Also there is a related thread for eBay's conversion from .NET to J2EE. Not that one success story means .NET is out but it's interesting.

    eBay thread
    http://www.theserverside.com/news/thread.tss?thread_id=20155