Slashdot Log In
Thank God Java EE Is Not Like Ajax
Posted by
kdawson
on Sat Sep 30, 2006 09:06 PM
from the you-want-bugs-with-that? dept.
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?'"
Related Stories
[+]
Developers: What's Spreading "the AJAX Wildfire"? 192 comments
An anonymous reader writes "AJAXWorld Magazine is running an article entitled "What's So Special About AJAX?" in which the majority of the contributors agree among themselves that AJAX "heralds a new, global sense of what the web can be and what the web can do, in ways that are so different but so much better than what we have been used to." While many of those the magazine consulted adduced technical reasons for the spread what one of them, Rich Internet Application pioneer Coach Wei, calls "the AJAX wildfire," only two mention how human nature — including that of software developers — is, well, notoriously susceptible to the latest fad. Which side would you agree with?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
You mean the buzz? (Score:5, Insightful)
Re:You mean the buzz? (Score:5, Insightful)
Parent
Re:You mean the buzz? (Score:5, Interesting)
<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.
Parent
Re: (Score:3, Insightful)
Re:You mean the buzz? (Score:4, Insightful)
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...
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.
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.
Parent
Dijkstra was NOT a troll (Score:5, Informative)
Parent
s/Ajax/Java 1.5 + applets (or WebStart) ? (Score:3, Informative)
Yes, I know Java is not cool anymore because Google uses Ajax, and I acknowledge that when Java was being hyped as the "t
Re:s/Ajax/Java 1.5 + applets (or WebStart) ? (Score:4, Interesting)
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.
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.
Parent
Re: (Score:3, Insightful)
We could all do with being a little less reactionary IMO.
Re: (Score:3, Informative)
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.
Which aspect of Ajax? (Score:5, Funny)
How about the Web 2.0 part
(It's a joke. Laugh)
(Well, sortof a joke)
Re:Which aspect of Ajax? (Score:5, Informative)
"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
Parent
Re:Which aspect of Ajax? (Score:4, Insightful)
Parent
Re:Which aspect of Ajax? (Score:4, Insightful)
Because if 1 out of 40 S/W Eng. are capable of understanding a javascript function call, then by God I deserve more money.
Parent
Re:Which aspect of Ajax? (Score:5, Informative)
Parent
Re:Which aspect of Ajax? (Score:5, Informative)
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).
Parent
Re:Which aspect of Ajax? (Score:5, Insightful)
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.
Parent
Re:Which aspect of Ajax? (Score:4, Interesting)
They also had a
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.
Parent
Re: (Score:2, Offtopic)
I wish slashdot would cover more java oriented articles as its commonly used and not as lame as it once was.
Java 6 looks very cool from the desktop end with huge performance gains and the factory object model integrated with the threading with Swing makes gui apps more responsive and java programmers wont have to worry about using threading to make their programs look more responsive which is not as much as an issue with other languages.
The web 2.0 stuff is nice for webdevelopers for
Isn't Ajax Javascript? (Score:5, Insightful)
Re: (Score:3, Funny)
They both contain the letters "Java"
AJAX between JS and Java servlets (Score:5, Informative)
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.
Parent
Re:AJAX between JS and Java servlets (Score:5, Funny)
I'm not sure what's more terrifying, the number of buzzwords in the one-sentence parent post, or the fact that I understood them all.
:-p
Parent
Re: (Score:2)
Re:Javascript is ubiquitous, Java VM is non-portab (Score:4, Insightful)
Having read your other post, I almost dare not reply, but here goes...
What sort of app were you trying to get running? I've spent the best part of 6 years now writing web apps in Java, and have never had any problems getting them running on different systems. I develop under Windows, the apps are built on Windows, and are almost always deployed to Linux boxes, and we've not had any problems.
I can't vouch for applets (which I've never done, but they are historically a complete pain in the arse, although I believe that situation has improved) or client-side applications, but on the server, I'm not aware of there being any problems.
That's not to say that the language doesn't have issues (every language does, and Java is no exception), but I've never seen any relating to portability (again, not saying they don't happen, just relating my experience, for what little it's worth).
Parent
wow, what an excellent point! (Score:5, Funny)
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.
Re:wow, what an excellent point! (Score:4, Funny)
Keep the bubble-sortin' faith, man.
Parent
Bubble Memory optimizes Bubble Sorts (Score:3, Funny)
Don't you guys trying to optimize your software bubble sorts realize that these days, all the fast sorting action is happening in hardware accelerated Bubble Memory [wikipedia.org]?
Plus, Bubble Memory is much more secure and less obnoxious than Flash Memory (which everybody hates because it has major security holes and displays annoying advertisements). [wikipedia.org]
-Don
Simple (Score:2, Insightful)
What does AJAX have to do with Java? (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Re:What does AJAX have to do with Java? (Score:4, Informative)
The Java runtime can handle dynamic discovery and execution of procedures in any old Java class file, passing around Method objects and such. This falls short of first class functions and very short of closures, but that's how it's done.
Parent
AJAX from a UI design perspective (Score:2)
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
Not useful, not particularly entertaining... (Score:5, Insightful)
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)
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.
The point being made is ... (Score:5, Interesting)
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.
That's really kind of funny actually because... (Score:5, Insightful)
Re: (Score:3, Interesting)
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
Re: (Score:3, Interesting)
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
GWT (Score:5, Informative)
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.
XML11 is better than GWT (Score:3, Interesting)
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
Java EE is *different* from AJAX, and vice-versa (Score:5, Insightful)
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
Religion aside... (Score:4, Insightful)
- 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.
RTFA!!! (Score:5, Insightful)
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
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)
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
So basically (Score:3, Insightful)
J2EE & AJAX handle complexity differently (Score:3, Interesting)
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?
Wow. Talk about bad comparisons (Score:3, Insightful)
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.
A little clarification (Score:5, Insightful)
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
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
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.
Re: (Score:3, Insightful)
The web was built up on the need to make easily accessible complex documentation using a markup language and hypertext links at first.
Because the browser gave the impression the easy access to documents means the browser is a one-size fits all solution to every content, everywhere many peoples dedicated most of the last 10 years to fill holes to make it behave like the client-server applications already existing just before the web tsunami hit the IT world.
I'm not sure it is really les