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.
Ajax: Legendary Greek Hero Java: Island in Pacific, also slang for Coffee The two obviously have nothing and common. Mod Story [-1] Offtopic
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 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).
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.
Achille Talon
Hop!
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.
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?
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).
-Don
Take a look and feel free: http://www.PieMenu.com
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!
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.
Yes, I know Java is not cool anymore because Google uses Ajax, and I acknowledge that when Java was being hyped as the "the new cool thing" 5-10 years ago, it was not up to par: limited and ugly graphics and UI, slow initialization, etc etc.
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. At the same time, computers were much slower back then. Now it would be safe to say that just the average raw machine performance has more than doubled, soon we will be seeing multple cores on home desktop machines. So could this be another chance for Java rich clients in form of applets or Java WebStart applications?
One of the biggest benefit of Java is that the developer can stay in the same environment, on the front end and the backend. No need to know JavaScript, HTML, DOM, XML, and whatever the backend uses. Just use one language. This, to me at least, leads to 3 other benefits:
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.
2) Can use any communication mechanism between client and server, no need to stick to XMLHttpRequest
3) Easier to find developers. On the job application just put down one requirement - "Java". Instead, Ajax means "JavaScript"+DOM+XML+backend language(SQL,C++,Java etc)....
Yes, yes, I know, I don't really see Google or Yahoo re-developing their portals as Java applets or even worse Java Web Start standalone applications. But how many large web portals are out there? On the other hand, I can see applets used more often in specialized sites, industry-specific sites.
And let's face it, most sites can just remain static. Mr. Sixpack doesn't need DOM, JavaScript and XMLHttpRequest to display his fishing trip pictures online...
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.
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.
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?
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.
Pedro For President!
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.
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.
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.
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
> 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.
Done with slashdot, done with nerds, getting a life.