Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



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:
  • 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 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.
  • by newt0311 (973957) on Saturday September 30, 2006 @11:52PM (#16263069)
    I would also like function pointers and type inferencing along with dynamic classes with maybe little string execution thrown in for good measure but none of them are making it in anytime I suppose:((. God, python is really spoiling me.
  • NewI\O (Score:2, Interesting)

    by cnystrom (1007893) <.gro.oiwen. .ta. .mortsync.> on Sunday October 01, 2006 @12:07AM (#16263155) Homepage
    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]).
  • by espressojim (224775) <eris@NOsPam.tarogue.net> on Sunday October 01, 2006 @12:25AM (#16263239)
    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, as I've just also finished reading a lot of "Faster, Lighter Java" style books where all ejb services are replaced with lightweight componenets (like Spring.)
  • 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 _pruegel_ (581143) on Sunday October 01, 2006 @04:28AM (#16264093)
    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 (schema, persistence mapping, searches and so on) in Java. Small, fast and very powerful.
  • by Anonymous Coward on Sunday October 01, 2006 @04:56AM (#16264159)
    Java on the client suffers from two major problems:
    1) The runtime environment is huge and not instantly available on most browsers.
    2) Java applets have no access to the DOM.

    Java has a big advantage over Javascript:
    Multitasking. Java has real threads and the necessary syntax to write thread safe programs. There is no practical way to perform a time consuming task in Javascript: You either cause the browser to become unresponsive for the duration of the task or you chop the task into tiny subtasks, which isn't always possible, at least not in a way which doesn't cause massive performance penalties.
  • by sproketboy (608031) on Sunday October 01, 2006 @06:58AM (#16264503)
    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 having to learn yet another gui framework.

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

  • 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?
  • 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 I realized that Java EE is a solution looking for a problem. After writing applications for small web startup to a top financial institution, my reflection is that EE breaks KISS. The spec tries to be everything for everyone and thus is overly complex for most business applications and for all the benifits it is supposed to offer it creates as many problems.

    Example if you look at the Entity Bean OR mapper locking specs you will see that if you have any kind of load (Assuming one of the E stands for enterprise that is generally true) well you get locked up if more than one thread is trying to access that object at a time and your concurrency breaks down and if you are using a good provider it start spouting out Deadlock Exceptions. After I tweaked the provider to turn some of the "EE features" off, made a lot of work arounds and wrote a lot of scripts to generate all kinds of code I finally had something useful.

    BEGIN RANT
    Now I do not claim to be some super coder. My experience is that all the things EE spec was supposed to do it didn't. Unlike the servlet spec we still have vendor lock down, we have more code (XML, umpteen million interface files, lots of wrappers code that needs script generators or xdocletization) all so we can move data in and out of a database and on to a web page or GUI.
    END RANT

    Feels good to get that off my chest.
  • Re:RTFA!!! (Score:3, Interesting)

    by the eric conspiracy (20178) on Sunday October 01, 2006 @11:06AM (#16265605)
    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 collection of cooperating technologies model and are often used within the J2EE context to supplement or replace parts of J2EE's API.

    With Java you can eat a lot of cake and still have a lot more left.

Like punning, programming is a play on words.

Working...