Forgot your password?
typodupeerror

Thank God Java EE Is Not Like Ajax 236

Posted by kdawson
from the you-want-bugs-with-that? dept.
Slightlyright writes, "Java Developer's Journal reports that some people in the community are wishing that "Java EE would be more Ajax-like because 'EJB 3.0 can not save Java EE.' This has caused strong reactions from bloggers such as Rich Internet Application pioneer Coach Wei, who wrote: 'Which aspect of Ajax [do] we really want Java EE to be like? The difficulty in developing Ajax code? The difficulty in maintaining Ajax code? The extreme fragile nature of Ajax code? The extremely fragmented nature of Ajax support from different browsers?'"
This discussion has been archived. No new comments can be posted.

Thank God Java EE Is Not Like Ajax

Comments Filter:
  • You mean the buzz? (Score:5, Insightful)

    by quick2think (833211) on Saturday September 30, 2006 @10:12PM (#16262573)
    I Think Java developers are more in need of the buzz java once had. A CEO looks at AJAX as better, because of it's recent exposure, and buzz word power. Java was no different in it's infancy, with it's broad promises. Java justy wants to be cool agaim ...
    • by bcat24 (914105) on Saturday September 30, 2006 @10:20PM (#16262613) Homepage Journal
      I think you just hit the nail right on the head. CEOs and marketing types want the latest, "greatest", buzzword-compliant software. Old standbys are no longer will probably work just as well, maybe better, but they aren't cool. Actually, geeks aren't immune to this problem either. Being on the cutting edge is fun, and sometimes we forget that old, tried and proved techologies lasted so far for a reason.
      • by Savage-Rabbit (308260) on Saturday September 30, 2006 @11:18PM (#16262903)
        I think you just hit the nail right on the head. CEOs and marketing types want the latest, "greatest", buzzword-compliant software. Old standbys are no longer will probably work just as well, maybe better, but they aren't cool. Actually, geeks aren't immune to this problem either. Being on the cutting edge is fun, and sometimes we forget that old, tried and proved techologies lasted so far for a reason. Being on the cutting edge is fun, and sometimes we forget that old, tried and proved techologies lasted so far for a reason.

        <sarcasm>
        So what you are saying is that after C, C++ and a number of other golden-oldie technologies have gone through the process, Java has now also become mature enough to be declared to be 'dying' by the buzzword junkies?
        </sarcasm>

        But on a more serious note this dude coachwei has a point, best practices is a concept that is pretty much non existent in a lot of places and that is not just true of AJAX. There are times I wish that more Java webapp developers knew why it is important to write thread safe code and what polymorphism and inheritance are useful for.
        • Re: (Score:3, Insightful)

          by quick2think (833211)
          It has been a long time since "Go To Statement Considered Harmful" by Edsger W. Dijkstra was released, marking the begining of the end for procedural based spaghetti code(or at least the acceptance of the inevitability of it's existence). Programs got too large and complex, and a new paradigm was needed. Now, with the web, computer solutions are no longer a single entity, and can span across systems and even languages.I think there needs to be a similiar paper to stress standards and best practices, and to
          • by joto (134244) on Sunday October 01, 2006 @03:24AM (#16263849)

            It has been a long time since "Go To Statement Considered Harmful" by Edsger W. Dijkstra was released, marking the begining of the end for procedural based spaghetti code(or at least the acceptance of the inevitability of it's existence). Programs got too large and complex, and a new paradigm was needed.

            Edsger Dijkstra was a troll. His "goto" paper is one of the most obvious examples of this. Now, just because you are a troll, doesn't mean you aren't right at times. Dijkstra was right almost all of the time. He rightly criticized a lot of "best practices" of his day. And coming from academia, he had the advantage of not having to offer anything better. Which he, by the way, didn't. Dijkstra preferred to write provably correct code in non-existing languages. Which is fine in academia...

            Now, with the web, computer solutions are no longer a single entity, and can span across systems and even languages.I think there needs to be a similiar paper to stress standards and best practices, and to caution the use of bleeding edge technologies.

            There are plenty. A quick web-search will likely reveal that there are more of them than you can expect to read in a full year. Programming is no longer such a niche area that a single professor can write a troll that will be quoted by almost everyone 30 years later.

            But if Dijkstra lived today, he wouldn't even touch web-programming with a ten-foot pole. He would have been more likely to start by proving some formal properties of a new system designed for the same purpose as web-programming, but never implemented it himself. He would then write papers advocating people start using this system instead of the web. And he would be right, his system would be better... if it only ever got made!

            It's not that people don't know web-programming as it exists today is too difficult. It's just that we fail to have better alternatives.

            Perhaps something with a title like "Why you should learn less and do more". Although many people complain about Java's complexity(The architecture, not the language), it is a very good model of standards. It is this model of standards, not the language itself, that make it so revolutionary in this era of web computing. It is a sad day when marketing wins, again.

            If you had read Dijkstras paper instead of just quoting the title, you would see that this is not in his spirit at all. See also my above comments.

      • Sure, there is a lot of buzz about Ajax - and right now, it does have its growing pains (fragmented browser support, more difficult to implement, ...).

        But I wouldn't go as far and discount it as useless because of it, or just saying "Thank god, we're not like that". If you go down that route, you'll go down a route that ignores the market.

        Let me move the original comment back a few decades and put in a slightly different context, and that will hopefully highlight what I mean:

        'Which aspect of Graphical User

      • Interesting that you mentioned that. The other day I was in a bookstore and was looking through the computer books section. There are a ton of Ajax books out there. It seems like out of nowhere we have all these Ajax experts writing books about Ajax. I picked up a couple of them and as I was reading I kept thinking that "I could do that with Java applets" or "Java + WebStart can do that".

        Yes, I know Java is not cool anymore because Google uses Ajax, and I acknowledge that when Java was being hyped as the "t

        • by ultranova (717540) on Sunday October 01, 2006 @07:50AM (#16264657)

          But a lot of those things have been polished in the recent Java 1.5 and will get even better in Java 1.6. UI got speedier, many bugs have been fixed, gc has been improved and most of all the performance in general is faster.

          As long as you don't hit swap. Once you do, garbage collection lasts for minutes due to having to traverse nearly all of applications memory. I don't think that problem can be solved in an userspace app.

          1) More consistency: a lot of Ajax code right of the bat deals just with different browser version and JavaScript versions, that's too many "if"s and "else"s to make it fun. With Java the developer has a clean slate work with, less workarounds means cleaner, more maintainable code.

          Except that the API documentation lies. Graphics2D methods that are specified as never blocking block. Methods that are supposed to return on true on success always return false, despite being succesfull. And methods throw random, undocumented exceptions. Then there's this weird bug where image scaling takes 10 times as much time if the source image is not in sRGB color space. All this in Sun's own Java implementation. I hate to think what bugs will surface if the program is ran in other implementations.

          So no, you don't get rid of workarounds in Java, at least in the GUI.

      • Re: (Score:3, Insightful)

        by Instine (963303)
        You're all missing one perspective, with is the geeks peverse atraction to the perverse. As soon as AJAX became a "buzz-word" there were geeks lining up to slate it, and claim that they had always thought Python to be the real solution. Until python become cool in the board rooms, at which point .... and so on.

        We could all do with being a little less reactionary IMO.
        • I love Python, I wish JavaScript would be Python (i.e. a browser would come with an embedded Python interpreter and a library to communicate with the server). Then Python could also be used on the server...

          For interface, I'd like full SVG 2.0 supported in all the browsers and standardized (i.e. no need for Flash) and for a way for my imaginary browser-embedded Python to manipulate the SVG interface in an easy, clean and Pythonic way...

          Ahh, it's nice to dream..

          • Re: (Score:3, Informative)

            by nuzak (959558)
            > I love Python, I wish JavaScript would be Python (i.e. a browser would come with an embedded Python interpreter and a library to communicate with the server).

            Check out Mochikit. It's very close to what you're looking for, and being "pythonish" is its main goal. I find it a nice happy medium between Prototype (a thin hacky wrapper around raw ajax) and Dojo (makes you drink the koolaid with its use of custom tags).

            Actually I really like Ajax4JSF, but that's a very different beast.
        • by gbjbaanb (229885)
          alomst, I think as soon as AJAX became 'cool', the geeks split into 2 camps: those that persuaded their bosses that they could work with this new, cutting edge, cv-enhancing technology, and those that couldn't.

          I'll leave it as an exercise to the reader to determine which group thinks AJAX is the best thing, and which group in its jealousy thinks its rubbish :)
    • by DrXym (126579)
      And even AJAX has had it's day. Flex is the new buzzword. My management has caught the "thin is in" vibe which is fine if not for the fact that our existing product manages hundreds of billions of dollars and requires lots of complex database queries. Trying to replicate that in thin client would be great no doubt but it means producing literally hundreds of web service calls and convincing our clientèle that they don't really want to see all their records at once.

      By the time we get around to produci

  • by TubeSteak (669689) on Saturday September 30, 2006 @10:12PM (#16262579) Journal
    "Which aspect of Ajax [do] we really want Java EE to be like?"

    How about the Web 2.0 part

    (It's a joke. Laugh)
    (Well, sortof a joke)
    • by TubeSteak (669689) on Saturday September 30, 2006 @10:15PM (#16262595) Journal
      And I found this part of TFA interesting:

      "What else? The difficulty of finding and hiring Ajax developers? According to Rod Smith (IBM) and Scott Dietzen (Zimbra), both independently mentioned that one out of 40 engineers interviewed would be qualified to learn Ajax."

      Not qualified to code,
      qualified to learn
      • by Lehk228 (705449) on Saturday September 30, 2006 @10:20PM (#16262619) Journal
        i think they meant suicidal
        • by Plutonite (999141) on Saturday September 30, 2006 @10:45PM (#16262751)
          I hope you're right.

          Because if 1 out of 40 S/W Eng. are capable of understanding a javascript function call, then by God I deserve more money.
          • by julesh (229690) on Sunday October 01, 2006 @02:59AM (#16263747)
            There's somewhat more to writing a large-scale AJAX application than "understanding a javascript function call". You have to contend with multiple implementations that work different ways. You have to work around the fact that javascript has little or no support for techniques that are typically used in writing large applications. Modularising a javascript application is hell. The method of defining a class is bizarre. Inheritance is horrible, particularly if the class you're inheriting from is in a different file, because there are no guarantees about the order in which they will be loaded. Multiple inheritance...? The language can do it, sure, but it isn't trivial.
            • by Osty (16825) on Sunday October 01, 2006 @04:12AM (#16264053)

              There's somewhat more to writing a large-scale AJAX application than "understanding a javascript function call". You have to contend with multiple implementations that work different ways. You have to work around the fact that javascript has little or no support for techniques that are typically used in writing large applications. Modularising a javascript application is hell. The method of defining a class is bizarre. Inheritance is horrible, particularly if the class you're inheriting from is in a different file, because there are no guarantees about the order in which they will be loaded. Multiple inheritance...? The language can do it, sure, but it isn't trivial.

              And you've just proven that you don't understand JavaScript. JavaScript != Java (or C++, or C#). It's not designed around functions and classes. Javascript is a functional language [msdn.com], and as such is designed around closures. Closures allow you to define classes and functions, but they also allow you to do quite a bit more (and also let you shoot yourself in the foot if you like).

              You're correct in saying that there's more to writing a large-scale AJAX application than just understanding a JavaScript function, but most of the things you mention are irrelevant (well, they're important to understanding JavaScript, but that's a core competency for any type of web design, not just AJAX). Using AJAX is easy, especially with all of the frameworks available that abstract browser compatibility issues for you. Using AJAX well is difficult (dealing with accessibility, server load, concurrency, etc).

          • Note that "knowing JavaScript" 5 years ago meant "I know how to write an even handler for onmouseclick to make the text blink".

            Today, with Ajax in mind, "knowing JavaScript" means "I know and understand async. I/O & DOM, I know about XMLHttpRequest and I could re-implement Google Maps for you if you ask me".

            All of the sudden JavaScript went from being used as a toy scripting language to a full-blown develpment language. Not saying if it is a good thing or bad thing but you can thank Google for it...

      • by Irish_Samurai (224931) on Saturday September 30, 2006 @11:11PM (#16262877)
        Did they really mean qualified to learn? Or did they mean qualified to apply properly?

        AJAX, and multiple other web technologies, suffer from being judged with criteria determined by the critic. In tech this translates into multile disciplines. UI guys love AJAX if used properly - the same build could be looked at from an app programmer's perspective as junk.

        AJAX seems to address the cultural side of things. People love flashy things, especially if they can deliver 80% -90% of the functionality they want. An application developer may be able to deliver 100% of wanted functionality, but in a way that a user finds aesthetically displeasing.

        I think this brings up an interesting point. When do developers start to realize that users will not conform to what they should do, but what they want to do? Learning the aspects of a development technology inside and out will not give a developer this edge. Paying attention to social aspects will.

        I think that's what these guys meant when they said qualified to learn.

        • by TubeSteak (669689) on Sunday October 01, 2006 @01:05AM (#16263391) Journal
          Did they really mean qualified to learn? Or did they mean qualified to apply properly?
          Well, I don't really know anything about http://www.zimbra.com/ [zimbra.com] but a quick Google search tells me that they are entirely(?) OSS & AJAX

          They also had a /. article about them a few days ago (they have a mail client to replace MS Exchange) http://developers.slashdot.org/article.pl?sid=05/0 9/27/2158240 [slashdot.org]

          I also Googled Scott Dietzen (Zimbra)
          "Scott Dietzen is widely credited with helping put together the J2EE standard, launching the web application server category, and launching the Java Community Process"
          "Scott Dietzen is the former CTO of the eCommerce Server Division of BEA Systems. Dietzen came to BEA via the acquisition of WebLogic"
          "President and Chief Technology Officer of Zimbra"

          And in the other corner, we have IBM. Nobody ever lost their job recommending IBM. Rod Smith (IBM VP of Emerging Internet Technologies) isn't small potatoes either.

          So, while I don't disagree with the meat of your post, it seems to me that when those guys say "qualified to learn Ajax" that is what they mean.

          I imagine that they interview lots of engineers. I hope that 1 in 40 isn't for engineers trying to get into a job involving AJAX, because that would be a dismal number. It'd make more sense if they were talking about 1 in 40 of all engineers interviewed for various positions... but that's just a wild ass guess with no factual support.
        • by drgonzo59 (747139)
          An application developer may be able to deliver 100% of wanted functionality, but in a way that a user finds aesthetically displeasing.

          Digressing to another topic, that comment reminded me about the Gnome/MacOSX vs. KDE/Windows approach to user Desktops. According to the experts in HCI (Human Computer Interraction) field, Mac OS X is more "user friendly" than Windows. Apple has invested a lot more in usability research and it payed off, the interface is easier to learn, it is simpler and more intuitive. I

        • by mpcooke3 (306161)
          When do developers start to realize that users will not conform to what they should do, but what they want to do?

          Unfortunately the underlying technology hasn't really kept up. What users appear to want in a lot of cases is application functionality deployed over the web. All we have as developers is the AJAX hacks on top of a language designed for sharing research papers and static page content.

          Because some developers have started to make websites look more like desktop apps using a variety of ugly hacks, u
      • by jrumney (197329)

        one out of 40 engineers interviewed would be qualified to learn Ajax.

        The scary part is the other 39 are all working as consultants on J2EE and ASP.NET projects, and noone at management level questions their ability.

  • by mark-t (151149) <[markt] [at] [lynx.bc.ca]> on Saturday September 30, 2006 @10:14PM (#16262591) Journal
    What does Javascript have to do with Java?
    • Re: (Score:3, Funny)

      by portmapper (991533)
      > What does Javascript have to do with Java?

      They both contain the letters "Java" ;-)
    • by tepples (727027) <tepples@g m a il.com> on Saturday September 30, 2006 @10:22PM (#16262621) Homepage Journal
      What does Javascript have to do with Java?

      ECMAScript code on the client manipulates the HTML DOM and requests data in XML or JSON format from a server through XMLHttpRequest. A servlet [wikipedia.org] produces such data.

    • by CastrTroy (595695)
      Just ask my boss. He always refers to JavaScript as Java, and often talks like they are the same thing, although I'm pretty sure he's aware they aren't the same thing. I hate it when people call JavaScript Java, because it gives people the wrong impression of what Java really is, and just how powerful It can bit. It's like comparing VBScript to VB.Net.
    • "What does Javascript have to do with Java?"

      Nothing.
  • by Anonymous Coward on Saturday September 30, 2006 @10:15PM (#16262593)
    When the guy in the first article said we must stop thinking about "faster bubble sorts"... well, that really hit home for me. Why, me and my buddies spend hours a day trying to improve bubble sorts. Sometimes I wake up in the middle of the night, thinking about bubble sorts. It's hard, man, once we came up with this recursive divide-and-conquer approach--looked not so slow, even quick, but then we realized it wasn't really a bubble sort so we couldn't use it in our programs. Back to the drawing board.

    Anyway, just wanted to say that I immediately realized that SOA guy was a real engineer--skilled, one of "us", not a marketroid at all--when I read that quote.
  • Simple (Score:2, Insightful)

    by dingDaShan (818817)
    Ajax: Legendary Greek Hero Java: Island in Pacific, also slang for Coffee The two obviously have nothing and common. Mod Story [-1] Offtopic
  • by saden1 (581102) on Saturday September 30, 2006 @10:28PM (#16262669)
    Java doesn't need saving and it isn't about EJB. Java is whatever you want it to be. Some folks have this notion that it should do and be what they want it to do/be which will hurt the platform in the long run because not everyone has the same need/requirements.

    p.s. There is a reason why Java has withstood the test of time (for 11 years anyways) and that's because it is good platform and a robust one at that.
  • Disclosure: I'm not very knowledgeable about Java or AJAX. I'm a UI architect, but I've been avoiding AJAX until the accessibility issues with synchronous content updates get sorted out. That being said, I'm more familiar with DHTML, which -- for the purposes of interface design -- is the part of AJAX relevant to my point.

    I especially know all about CSS and the nightmare of multiple browser support -- especially when CSS rendering support seems to be inversely proportional to a browser's popularity. It do

  • by meburke (736645) on Saturday September 30, 2006 @10:48PM (#16262769)
    The whole discussion is a waste of time, and the article itself is lame.

    First of all, there is no careful description of the problem. A problem is the difference between the way things are and the way you want them to be. This takes into account the way things are that already acceptable. AJAX has some deficiencies, and it has some attractions. My questions are: Is it worth the effort to correct those deficiencies in AJAX? Is it worth the effort to include the attrations in EJ?

    Secondly, there is no concensus on the appropriate domain for the different tools. Is EJ really a tool for doing the same things that AJAX does?
  • Thank God (Score:4, Insightful)

    by bahwi (43111) <incoming@josephg ... m minus math_god> on Saturday September 30, 2006 @11:03PM (#16262843) Homepage
    Javascript is not like Java.

    Ajax and Java are two completely different ideas/concepts. Second, if AJAX is hard and you do Java, you need to have your head examined. It's probably dyslexia, and you've been writing perl, not Java this whole time. Not to say if you know Java you know Ajax, completely untrue, but if you think it's hard that's a different story.
    • Ajax is hard not because of the Javascript aspect, but because of the sheer number of differences between programming DHTML for IE and for Firefox (and Opera, and...). The problem is that each browser's implementation of the "standard" is different, sometimes wildly different, sometimes slightly different. And sometimes the difference is so subtle, yet so important, such as the order events are processed. The net result is that, for any Internet-facing app using Ajax, it's often very difficult to get all
  • by Elias Ross (1260) on Saturday September 30, 2006 @11:10PM (#16262875) Homepage
    the JCP is too slow and crufty, comes up with homegrown technologies nobody wants to use, etc. and that tools such as Hibernate and Spring not borne from the community process are superior or, in the case of EJB 3.0, adopted.

    I guess I don't know why "Ajax" was brought up, I haven't used it and it's not something I'm familiar with. Maybe Ajax doesn't belong in the same class of technologies. Arguing about the specifics means missing the point, though.

    It often takes "rebel" technologies to move things forward. It also takes some experimentation to develop a technology; i.e. coming up with a rigorous, solid standard might prevent its spread. Sometimes sloppiness is good. RSS, HTML, etc. have done okay despite the sloppiness. Requiring every web page be HTML compliant would have stifled the web.

    Recently, I've started working on Weblogic. I used to develop with JBoss. In terms of service deployment, JBoss is superior to Weblogic. I guess with Weblogic, you're still stuck writing a lot of code to deploy JMX services. I noticed at my new company that programmers ended up launching network servers from a Servlet, which was not its intended use. The ease of deploying MBeans and dependency control with JBoss is superior. It can be done easily with a bit of XML, and no code is required. JBoss also handles ordered deployments better. With Weblogic, deployment ordering is done by assigning a deployment order number (1-4000 or something) to your deployment. It reminds me of writing programs with line numbers back in the good old days of BASIC.

    It's my guess that functionality from Spring will be eventually refined into a series of JCPs. Sometimes it's better that standards develop in this way.
    • by owlstead (636356)
      "It's my guess that functionality from Spring will be eventually refined into a series of JCPs. Sometimes it's better that standards develop in this way."

      Yes, indeed. That last sentence was important. I see a lot of new developments in Java, but most of the time the first implementations and API's are pretty lacklustre. What the JCP is really good at is to get the core ideas, take some time to think them over, and get the gist of them into the language. Sometimes the old implementation is adopted into the l
  • you try running websphere in your browser :P Now from IBM for $250,000--The FireSphere Browser

    From the article: "The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can't JEE be more AJAX like?"

    I still see many of the best practices in AJAX being fleshed out in the year(s) to come. Hopefully things like Comet [ajaxian.com] will become a reality in the near future and the many different toolkits/utilities (dojo, dwr, jmaki, et al) c

  • by Assmasher (456699) on Saturday September 30, 2006 @11:31PM (#16262957) Journal
    ...many ex-Java EJB devs think that all the current iterations of EJB are difficult to develop in (relatively), difficult to maintain, and fragile and difficult to support on multiple EJB servers... These are the main reason we're ex-Java EJB devs.
    • Re: (Score:3, Interesting)

      by espressojim (224775)
      As an ex-EJB dev (oh, 1.0 was just the right time to adopt...ug!), I'm kinda hopefull about 3.0. It has adopted the spring framework aspects I like the most (injection-style programming), I can use hibernate for my ORM (which is stronger than just Java Persistance), and I get JMX/JNDI/JTA/etc services pretty easily.

      As it stands, I've read the books, and the next project I start (in a few weeks) will be ejb3.0, just to give a quick back-to-front application a shot.

      I hear where you're comming from, though, a
    • So what are you now? what did you leave it for? anything intersting you'd care to share?

      Remember caring is sharing
      • Re: (Score:3, Interesting)

        by _pruegel_ (581143)
        I (not the gp author) left EJB because I could not stand the redundant XML configuration, -Home and -Remote classes and so on. EJB3 gets rid of those classes but a (for most users) completely redundant configuration stays as it is present with Hibernate and many other persistence frameworks. I never understood why everyone would want those since it all can be written in pure Java code.
        But now there is cope [sourceforge.net] which I try to use as much as a can (read: as much as clients permit me to) since it does everything
  • FTA:

    "I was always skeptical about AJAX. This technology can be useful for Google , Yahoo, or Amazon, and the like . Because regular businesses can not afford it. They can not hire a team of experts to find workaround for dozens of serious problems browsers/JavaScript introduce. Browsers/JavaScript is not an application development environment."

    Oh, shit. I better tell my boss that all the AJAX-based apps I've written over the last six months need to be taken down. Apparently, we can't afford them!

    • by julesh (229690)
      Having been working on a few AJAX applications myself lately, I can kind-of see his point. Writing a complex AJAX program is hard. You have to work around the limitations of javascript, and you have to work around the limitations of browser support. A typical day these days involves about an hour writing new code and about seven fixing obscure browser bugs that only turn up in one browser in some obscure circumstance.

      Compared to writing more traditional desktop applications, I'd say AJAX takes at least t
      • by pimpimpim (811140)
        For intranet applications you could force everyone to use the same browser, as they will need to go there anyway. Whereas for internet applications, your costumers might have any browser, and will just go somewhere else if they are displeased with your service. Still, this will put your application at the same user-friendliness as any IE-only web-based system bought from microsoft, so you'll be pissing at least part of your employees off like hell, you might also not want that.
  • This guy, Coach Wei, whoever he is, compares a specific platform for Java with the general miasma of people who woke up a year or so ago and realized that Javascript was a programming language. Classic Jive: Pick a toss a red herring in the air, blow hard, set up a straw man hoping no one notices its a straw man, then knock it down.
  • GWT (Score:5, Informative)

    by HappyEngineer (888000) on Saturday September 30, 2006 @11:52PM (#16263067) Homepage
    I just searched through these comments and didn't see any mention of GWT.

    GWT is wonderful. I've programmed ajax stuff (check out my chess and checkers games [tryit4fun.com]. It's definitely brittle if you actually have to write the javascript and parse the xml and convert the xml to java objects manually.

    But, using GWT has been a big eye opener for me. You write java code and it's compiled into javascript. It completely turns everything on its head. If you want to communicate some more information to the server from the client, all you need to do is add another method to the remote object (and its interfaces) and you suddenly have another statically type checked rpc call between client and server.

    I'll probably still do simple form apps in struts, but I don't intend to ever write another line of javascript that's of any significant complexity. It's no longer necessary. No longer do I need to figure out incompatibilities between browsers. GWT just figures it out.

    All these years people have been trying to make a good java webapp framework and GWT comes along and does things in a way that just turns everything on its head. Struts and Tapestry and JSF are all solving the wrong problems. They all try to make it easy to take html forms and retrieve and validate that information.

    GWT turns it around and just lets you communicate java objects. I used to be unhappy that I needed to settle for choosing which framework was the least bad. Now I just say to hell with the lot of them except in situations where javascript isn't allowed.
    • by njh (24312)
      So it gives you the run time performance and portability of Javascript with the concise and powerful language constructs of Java?
    • http://www.xml11.org/ [xml11.org]

      Although it doesn't get the hype that GWT does, XML11 is a much better implementation of the idea. It works with java byte code instead of source like GWT so it's more stable. GTW doesn't yet work with java 5 because of the new language syntax. XML11 works fine since the java byte code is the same between java 4 and java 5.

      Also, it's based on the AWT framework (same classes with different implementations) so developers already familiar with AWT can get productive faster - instead of h
  • NewI\O (Score:2, Interesting)

    by cnystrom (1007893)
    I believe both Java and AJAX are the wrong path to take. The web was designed for hypertext documents. It was not designed to run apps. Instead of kludging the web to run apps we need to create a new system that is designed to run Internet applications. I believe a simpler straightforward solution to this problem is the way to go. I have begun work on such a system which I call NewI\O (http://www.newio.org [newio.org]).
  • AJAX and Java EE are orthogonal. Servlets and EJB serve AJAX clients just fine. Some large fraction of all AJAX clients use Java containers as successfully as any other back end.

    If what is meant is Java EE needs some of the AJAX hype... well Java EE has the tools, libraries and maturity to continue thriving with or without AJAX.

    I find this inevitable push to bury Hibernate and Spring as throwing a lot of very good tools down the drain in order to continue the Sun monarchy and JCP worship.

    Monarchy, worship
  • How about the fact that it WORKS, despite all quirks, and that although Java Engineer TM Reg Inc. feels it sucks it still is what will power the internet tomorrow.
    • by jandrese (485)
      I think the Java guy is just jealous that Ajax pages don't freeze his browser up for 10 seconds while the JRE loads, well that and the fact that they integrate with the rest of the page instead of just taking over a part of it.
  • by mritunjai (518932) on Sunday October 01, 2006 @01:30AM (#16263465) Homepage
    I am disheartened by reading the comments... people, PLEASE for once in life go and read Java EE specs and see what it is intended to do.

    Java EE is a framework to write business applications, for any kind of business, from issue trackers to ERP, the "business" in it doesn't mean "$$$ business" literally.

    When writing business applications, it tries to enforce you to separate your concerns, especially, the presentation layer (Servlets & JSP), the business logic (EJB) and enterprize information systems (EIS) (JDBC, EJB container managed persistence etc). Its a complete stack for developing applications.

    AJAX deals with presentation layer, and more specifically, the interaction part of it. its a piece in the whole stack. The Java EE presentation layer does NOT depend on even having an HTML frontend even! (no sane framework does!).

    So now, if you have an HTML/XML browser frontend and a human user using it, you may use AJAX for enhanced user experiece. There is nothing in Java EE that says you cannot take your favorite AJAX toolkit and use that to build your frontend.

    So both technologies are not even competing on even a single issue. Both are complementary. You can use Java EE stack to develop your application, and when time comes to develop the frontend, you choose from plain old HTML, XHTML, XML, AJAX etc (or a combination thereof), to develop your application's "frontend".

    Please stop this ignorant war. To make another bad /. analogy, its like car lovers and music system fans fighting with each other that the other is not like their's!
    • My beef is with this concept right here:

      I am disheartened by reading the comments... people, PLEASE for once in life go and read Java EE specs and see what it is intended to do. Java EE is a framework to write business applications, for any kind of business, from issue trackers to ERP, the "business" in it doesn't mean "$$$ business" literally.

      Maybe I am in the minority but I have spent a lot of time reading the Java EE specs and trying to implement them. After implementing them for a couple of years

  • Religion aside... (Score:4, Insightful)

    by pestilence669 (823950) on Sunday October 01, 2006 @01:45AM (#16263513)
    I've written distributed applications using:
    - Java EE
    - CORBA using C, C++, Pascal, and Java
    - Microsoft DCOM
    - Various proprietary protocols

    AJAX isn't really a distributed software development technology... it's a sloppy mixture of features written by a varied group of contributors. What makes it interesting, is that no matter how implemented, the goal is the same. I think that's what the writer of this article was trying to articulate. With Java, there's only ONE way to do anything. Drink the punch, or don't use Java. If you dare suggest that any part of Java needs work, you get a room full of angry & militant Java advocates ready to stone you into submission. I'd like to say that I'm exaggerating, and I am, but only a little. I too wish that Java engineers could think outside of the "sandbox," instead of encouraging others to make due.
    • by owlstead (636356)
      Yeah, that's why every conference about Java EE (and most Java conferences mostly are all about Java EE unfortunately) always breaks into a complete cat-fight because of all the frameworks.

      The Java community is pretty millitant against adding features, that's true. The reason behind that is that it quickly becomes very complicated to read and manage all those different concepts. If the Java community wasn't, with the popularity of the language, it would now be D+++.

      Every time that some developer gets modded
  • RTFA!!! (Score:5, Insightful)

    by SanityInAnarchy (655584) <ninja@slaphack.com> on Sunday October 01, 2006 @02:18AM (#16263625) Journal
    For the love of all that is holy, RTFA! The claim was not that Java EE should use Ajax, or that Java developers should use Ajax at all. Google Web Toolkit is completely irrelevant!

    What was meant by this is that Ajax is a loose collection of cooperating technologies, without a standard, that develops very rapidly, and allows a lot of choices to the developer -- as opposed to Java EE as a rigid platform. Kind of like Linux vs BSD.

    Even TFA understood this in the response.

    The Slashdot response, so far, is roughly equivalent to if I said I wish Java had something like CPAN, and people jumped all over me with comments like "You want Java to use :: as the class separator? You want all variables to have dollar signs on them? You want no type checking, and all kinds of random C code?" Completely missing the point, of course. CPAN is a centralized collection of community modules, most of which play nice with each other, which make it possible to develop most Perl programs by splicing together 4-5 modules with <100 lines of glue code containing your actual program logic.

    It's like a Wikipedia of code -- NO! Not in that anyone can edit any module. It's like Wikipedia in that it's a central repository of the collective programming skill of mankind. It's sort of the library to end all libraries.

    Anyway. -1 Offtopic to the entire comment section this time. RTFA!
    • Re: (Score:3, Interesting)

      What was meant by this is that Ajax is a loose collection of cooperating technologies, without a standard, that develops very rapidly, and allows a lot of choices to the developer -- as opposed to Java EE as a rigid platform. Kind of like Linux vs BSD.

      J2EE is very well standardized, and goes through a very controlled process before it is extended. However that doesn't mean that Java in a larger sense can't take in external projects. Some of these like Struts, Spring, Hibernate, and so on fall into the loose
  • java vs javascript

    or in other words:

    strongly-typed statically checked compiled language proponents vs weakly-typed dynamically checked interpreted language enthusiasts.

    which is really as old a debate as C vs LISP...

    yawn...
    • Lisp is dynamically and strongly typed and that C is statically and weakly typed.

      By some definition...or at least the one I chose to believe. Static and dynamic are well defined, but strong and weak are anything but.
  • So basically (Score:3, Insightful)

    by julesh (229690) on Sunday October 01, 2006 @03:14AM (#16263799)
    So basically, this guy is pissed off that J2EE-focussed magazines won't buy his articles about technologies that aren't core J2EE technologies but which he thinks are cool anyway. And thinks an AJAX analogy will make his point, which is of course totally wrong.
  • I knew about the Java Community Program, but I wasn't aware He was involved with it. No wonder it became so popular so quickly.

    I wonder if He has contributed to any fully open source projects - the comments alone may be worth reading.
  • http://www.coachwei.com/blog/_WebPages/AboutMe.ht m l [coachwei.com]
    Quote - "I live in Cambridge, MA. I work at Nexaweb Technologies (http://www.nexaweb.com), an Enterprise Web 2.0 software company. &...Many moons ago (1997 to 1999), I wrote an Ajax-based word processor, which is published and open source at http://www.ajaxword.com./ [www.ajaxword.com] I also worked at EMC Corporation in the late 90s, doing work in the enterprise storage area. "

    Oh & Btw - I'm Yuri Gagarin.
    --
    In Soviet Russia, the Rich Internet pioneers YOU. Obligator
  • by HighOrbit (631451) * on Sunday October 01, 2006 @09:57AM (#16265141)
    AFAIK.. AJAX is still young enough not to have any sort of standard organized framework (although lots of frameworks exist, none are standard). AJAX is fairly straightforward and easy to grasp, but can quickly become a nightmare of spagetti once you get beyond the simplest application.

    J2EE and EJB on the otherhand are very standardized and highly organized, but complex by design and harder to initially grasp. Personnally, I'd rather try to detange AJAX than try to figure out what is going on with the dozen-odd layers of interfaces that EJBs seem to implement. I'd really wish EJB would get rid of all the complex interfaces and just allow direct acess to the object and its methods. It would much easier to grasp and work with. Why do I need muliple layers of interfaces when I just want to manipulate the object?
  • by bokmann (323771) on Sunday October 01, 2006 @10:21AM (#16265297) Homepage
    Comarting something like Jave EE to Ajax isn't even like comparing apples to oranges, it's like comparing apples to blue. They are totally, totally different things, and live at different conceptual points in the hierarchy.

    Of course, that is actually the point of the article... That Java EE shouldn't be a bunch of specs for implementation, that it should be a bunch of loosely coupled ideas that end up getting something done. I mean, AJAX originally stood for Asynchronous Javascript and XML, but today, you see things that don't use XML and aren't asynchronous using the buzzword. Ajax is 'just a bunch of ideas'.

    Of course, those ideas are based on Javascript, html, cascading stylesheets, the XMLHTTPRequest function in browsers, etc. If these things weren't all spec'd out, Ajax wouldn't have come into existence. The article makes it seem like the author is somewhat against specs, so I find this rather ironic.
  • by Aceticon (140883) on Sunday October 01, 2006 @10:27AM (#16265335)
    J2EE (Java 2 Enterprise Edition) is a mix of two very different frameworks:
    • EJBs (Enterprise Java Beans) and related technologies (such as JMS for asynchronous messaging) are backend technologies, aimed at things such as centralized business rules implementation, enterprise application integration, distributed functionality, multi-application interconnection, redundancy, integration with legacy servers and, more in general, big multiple-server/multiple-clients architectures. This stuff has nothing to do with AJAX and never will. It's used for reliable and flexible server-side provision of business functions (for example "Debit single account, credit multiple accounts") and is aimed at being easilly extended to provide extra business functions and cover extra resources (as in, more databases)
    • JSPs (Java Server Pages - basically web page templates, equivalent to PHP pages) and Servlets (basically the Java equivalent of CGI-scripts) are the web-based user interface support components of J2EE. This stuff is most often used in conjuntion with EJBs, for example, providing a user-interface for the user accessible business functions - this usually happens in an intranet


    JSPs and Servlets, with or without EJBs, can be (and are) used for web-based user interfaces on the Internet, although on their own they suffer scalability problems for concurrent access by many users and for speed of prototyping and developement of new features.

    They are, however, pretty orthogonal to AJAX since they are server-side technologies. Both an Javascript controlled asynchronous HTTP request comming from a browser and a user triggered browser HTTP request look exactly the same to both JSPs and Servlets - they're just another HTTP request (HTTP/1.1 GET /bla)

    Saying that J2EE should be more like AJAX is like saying that PHP should be more like AJAX or that CGI-scripts should be more like AJAX - complete nonsense!!!

    Having better architectural support in J2EE for AJAX (for example, for being able to access a server-side business function in Javascript from the browser just as easilly as you can do it from the JSP layer) would be a good thing. However the groundwork need to support this on the server (J2EE) side is already done (it's called Web Services), and thus the biggest part of the work still needed to seamless provide the Javascript/AJAX code running on the browser with access to such remotely hosted business functions is ..... on the browser - which means either some enormous complex Javascript libraries or standardized extensions to at least the two maintream browsers.

    Just as a reminder, AJAX is the kludge it is because there's so very little standardized functionality in the browser to allow dynamic, localized refreshing on a page of information which is externally hosted.

    To wrap things up: server-side support is there already in J2EE that provides, via HTTP, seamless access to business functions hosted in a J2EE server. Whether the requester is a piece of AJAXified-Javascript running on a browser or a batch C application makes no different. As usual, most of the necessary stuff missing, is missing from the browser.

    To the writter of the article: Server-side technologies are mature already, AJAX is far from it. Stop demanding that servers are adjusted to serve a single client implementation methodology. If you really want an architecturally sound solution, get up from your fat ass and start coding a Web Services client in Javascript.

For large values of one, one equals two, for small values of two.

Working...