Thank God Java EE Is Not Like Ajax 236
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?'"
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.
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.
Re:What does AJAX have to do with Java? (Score:2, Interesting)
NewI\O (Score:2, Interesting)
Re:That's really kind of funny actually because... (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, 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.)
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.
Re:That's really kind of funny actually because... (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 (schema, persistence mapping, searches and so on) in Java. Small, fast and very powerful.
Re:You mean the buzz? (Score:1, Interesting)
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.
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 having to learn yet another gui framework.
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.
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?
Re:Java EE is *different* from AJAX, and vice-vers (Score:2, Interesting)
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)
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.