Thank God Java EE Is Not Like Ajax

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?'"

You mean the buzz?

[quick2think]

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

Isn't Ajax Javascript?

[mark-t]

What does Javascript have to do with Java?

Re:You mean the buzz?

[bcat24]

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.

Re:Which aspect of Ajax?

[Lehk228]

i think they meant suicidal

Simple

[dingDaShan]

Ajax: Legendary Greek Hero Java: Island in Pacific, also slang for Coffee The two obviously have nothing and common. Mod Story [-1] Offtopic

What does AJAX have to do with Java?

[saden1]

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.

Re:Which aspect of Ajax?

[Plutonite]

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.

Not useful, not particularly entertaining...

[meburke]

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

[bahwi]

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.

Re:Which aspect of Ajax?

[Irish_Samurai]

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.

Re:What does AJAX have to do with Java?

[Charlie the Hammer]

I just want it to have continuations and first-class functions. One is about as likely as the other, I suppose. :-)

That's really kind of funny actually because...

[Assmasher]

...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:Which aspect of Ajax?

[Anonymous Coward]

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

That statement is too specific. This one's better:

One out of 40 engineers is qualified.

*sigh*. We're trying to hire people again...it's not going well...

Re:...of course, the real problem is that...

[AchilleTalon]

I agreed with that.

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 less trouble to program and interactive decent client-server application with the web interface then without it.

Re:You mean the buzz?

[quick2think]

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 caution the use of bleeding edge technologies. 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.

Java EE is *different* from AJAX, and vice-versa

[mritunjai]

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!

Religion aside...

[pestilence669]

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.

RTFA!!!

[SanityInAnarchy]

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!

So basically

[julesh]

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.

Re:You mean the buzz?

[joto]

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.

Javascript is ubiquitous, Java VM is non-portable

[Anonymous Coward]

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.

Maybe it's good advertising for Java though, because Javascript runs everywhere whereas it's extremely hard to get Java running, so that Java apps are "write once, run almost nowhere". (I'm serious.)

I have 15 machines here, spanning virtually every O/S and flavour. Over the years, I've managed to install one version of Java on only 2 of them, while all attempts with all the leading flavours of Java fail catastrophically on all the other machines. And as for applications, I've tried hundreds on the 2 machines where the install succeeded, and the only one that has ever worked for me is the Jext editor.

In my experience, Java is utterly non-portable, and the "write once, run anywhere" thing is one of the biggest deceits in computing, pure propaganda. Java is the most non-portable language system I've ever come across, and I run pretty much everything here.

C, C++, Objective-C, Perl, Python, Ruby, PHP, Lua, many flavours of LISP, Ocaml, Prolog, Pascal, Tcl, .... they all work here on every machine where I've bothered to install them, with zero hassles. Java? Forget it, with the rare exception.

I'd like to be more generous to Java because I love its syntax and semantics in the abstract, but a language that I can't use for applications because it just refuses to install or because it refuses to allow apps to run is useless to me.

So, dispensing with generosity, Java is utterly non-portable, and hence effectively is a useless pile of crap despite the collosal "run anywhere" lie. End of story.

Re:You mean the buzz?

[Instine]

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.

Re:AJAX between JS and Java servlets

[Anonymous Coward]

No, it's that you consider ECMAScript, HTML, DOM, XML, JavaScript objects and XMLHttpRequest buzzwords... when they are all basic standards.

I think the biggest buzzword has become... buzzword.

Re:Javascript is ubiquitous, Java VM is non-portab

[Tim C]

In my experience, Java is utterly non-portable, and the "write once, run anywhere" thing is one of the biggest deceits in computing, pure propaganda. Java is the most non-portable language system I've ever come across, and I run pretty much everything here.

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

Re:AJAX between JS and Java servlets

[asylumx]

So does a PHP script, yet I don't see any "AJAX vs PHP" articles.

Wow. Talk about bad comparisons

[bokmann]

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.

A little clarification

[Aceticon]

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.

Who really wants what?

[dwarfking]

Reading through the comments shows a number of competing needs. It got me to thinking about who exactly is asking for the various technologies. This is what I'm seeing.

1. In the beginning we had dumb terminals and centralized applications. The applications were stateful unless the terminal disconnected. Programmers liked this because there was platform to code to (whatever the application host was). Security and System admins liked it because all data was centeralized, everyone upgraded at the same time and security was also centralized. Users accepted it as it was the only way, but the text mode screens, timesharing issues and loss of work if the terminal dropped were annoying.
2. Then the GUI crowds hit and users were convinced they wanted more responsive and easier to use applications, so folks started using locally installed applications in a more detached mode. Programmers didn't mind this as it let the code for new platforms, but now they had to work with usability experts and deal with the problems the creep in when you don't know what someone has on their local machine that may cause incompatibilities with your application. System admins became PC Help Desk, going around cleaning up the mess caused by users doing their own installs, and security was based on locking the door where the PC was.
3. Then came the call for client server applications. Heavy responsive clients with stateful sessions talking to remote databases. The programmers world was still the same as in the standalone applications, only now they had to work with real DBAs to get database schemas created and they had to work more with security admins to connect the applications. System admins now had to support all those PCS and central servers and started having more problems due to resource issues as all these individuals were grabbing and holding resources on shared boxes. Security consisted of database logins, that most people were writing down on sticky notes connected to their monitors.
4. Then came HTTP and HTML. Static content was moved to stateless environments. Application programmers didn't really think about this environment except as a way to provide centeralized help pages. UI people thought they were actually programmers now. System admins were back to the centralized, lightweight server management, along with heavy client server admin and PC support tasks. Security folks were there to approve content.
5. Then came CGI in all its flavors (shell scripts, application servers, servlets, etc). Now we're back to programmers writing centeralized code that has to run on one platform, system admins still have stateless machines to manage, UI folks are now thought of as the application programmers since they provide the HTML interface that access the CGI code, and security folks now have a bigger headache making sure the CGI code is properly checked for security vulnerabilities.

Notice the users haven't been mentioned in the last couple of entries. Developers and system folks have been playing with technologies, but the users have just been taking it. Now users are flexing their muscles again and they want to go back to the days of responsive, more easy to use applications.

So what do we do? We take the technologies we have all become very familiar with and try to force it to meet these needs. Unfortunately the technology was never really intended for this usage.

All of this leads to my question, Who really wants what? Well, as I see it

• Users: Responsive, graphical, easy to use applications
• Programmers: Latest technologies, fewer target platforms, new programming models
• Usability Team: consistency in operation, common look and feels, responsive systems
• Security: centeralized security, reduced (if not eliminated) code vulnerabilities, centralized auditing and logging of usage
• System Admins: Centarlized code deployment, reduction in system resource usage