Slashdot Mirror
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?'"
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 ...
"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)
[Fuck Beta]
o0t!
What does Javascript have to do with Java?
File under 'M' for 'Manic ranting'
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.
ECMAScript code on the client manipulates the HTML DOM and requests data in XML or JSON format from a server through XMLHttpRequest. A servlet produces such data.
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.
-----
One is born into aristocracy, but mediocrity can only be achieved through hard work.
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?
"The mind works quicker than you think!"
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.
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.
...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.
Loading...
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. 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.
Cow Cube
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.
/. analogy, its like car lovers and music system fans fighting with each other that the other is not like their's!
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
- mritunjai
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.
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!
:: 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.
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!
Don't thank God, thank a doctor!
http://www.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.
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.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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).
It's official. Most of you are morons.
I'm afraid you're using the wrong word. A troll is someone who doesnt even believe in the arguments that they are espousing. Their whole purpose is to dump fuel on smoldering embers. This is something that cannot be said of Dijkstra. A polemicist is a more accurate description of who Dijkstra was.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
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.