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

Comments

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

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:You mean the buzz?

[Savage-Rabbit]

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. Being on the cutting edge is fun, and sometimes we forget that old, tried and proved techologies lasted so far for a reason.

<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:You mean the buzz?

[Anonymous Coward]

you forgot python and bash and added C++. -3 points. boo.

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.

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.

Re:You mean the buzz?

[DrXym]

And even AJAX has had it's day. Flex is the new buzzword. My management has caught the "thin is in" vibe which is fine if not for the fact that our existing product manages hundreds of billions of dollars and requires lots of complex database queries. Trying to replicate that in thin client would be great no doubt but it means producing literally hundreds of web service calls and convincing our clientèle that they don't really want to see all their records at once.

By the time we get around to producing a thin client, they'll suddenly decide they want to support Sparkle or something.

Re:You mean the buzz?

[Anonymous Coward]

Java on the client suffers from two major problems:
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.

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:You mean the buzz?

[furry_wookie]

+1 for Python, -1 for leaving off PERL

Re:You mean the buzz?

[gbjbaanb]

alomst, I think as soon as AJAX became 'cool', the geeks split into 2 camps: those that persuaded their bosses that they could work with this new, cutting edge, cv-enhancing technology, and those that couldn't.

I'll leave it as an exercise to the reader to determine which group thinks AJAX is the best thing, and which group in its jealousy thinks its rubbish :)

Re:You mean the buzz?

[Anonymous Coward]

That and the java people that don't write code need to go away. That's what this is about. THere are people who see themselves as architects, who get all these ideas about acceptable technologies in their heads and they are vocal. They are the same people that are always looking to the next thing to glom on to, always trying to be an expert without actually producing.

Many of them are running to Rails. Focus on results, not hype and talk.

Re:You mean the buzz?

[hotdiggitydawg]

Sarcasm tag? Sorry, XML was yesterday's buzzword...

Re:You mean the buzz?

[Anonymous Coward]

Ah, touché...

Re:You mean the buzz?

[alyou]

Perhaps something in the Java line that does something that solves 'some of' the same problems AJAX solves.... http://www.ektasis.com/ Check this out.

Re:You mean the buzz?

[OwnedByTwoCats]

AJAX is a better technology for creating interactive web sites than Java EE's servlet post/get and response model. It's not just marketing buzz, it's real.

I'm getting paid to develop a web site. In Java EE. We're using Ajax when it makes sense.

Which aspect of Ajax?

[TubeSteak]

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

Re:Which aspect of Ajax?

[TubeSteak]

And I found this part of TFA interesting:

"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

Re:Which aspect of Ajax?

[Anonymous Coward]

If you look at Java 6 beta, they're adding Web 2.0 stuff --- classes are indicated as web services using annotations, IIRC.

BTW, which god are we supposed to be thankful of?

Re:Which aspect of Ajax?

[Lehk228]

i think they meant suicidal

Re:Which aspect of Ajax?

[Billly Gates]

Java 6 looks very cool.

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 the server not to mention the gui's will look more native to the platform being used compared to previous versions of java. Java3d is fulling run on the GPU as well and is usable with java 6.

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.

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

[Iron Condor]

How about the Web 2.0 part

Web 2.0 is so last year. This year it's Web 2.0 two.

Re:Which aspect of Ajax?

[TubeSteak]

Did they really mean qualified to learn? Or did they mean qualified to apply properly?

Well, I don't really know anything about http://www.zimbra.com/ but a quick Google search tells me that they are entirely(?) OSS & AJAX

They also had a /. article about them a few days ago (they have a mail client to replace MS Exchange) http://developers.slashdot.org/article.pl?sid=05/0 9/27/2158240

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

[Anonymous Coward]

Web 2.0 two? Are you sure? I was sure it was Web 2.0 Core 2 duo.

Re:Which aspect of Ajax?

[fishbowl]

>> One out of 40 engineers is qualified.

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

It's a consequence that you face when you insist on hiring Computer Scientists to do the work of Programmers.
Some Programmers are Computer Scientists, and some Computer Scientists are Programmers. But in some fields,
the best programmers are those who understand the business domain for which they are developing. All the automata theory in the world won't prepare you for that. Likewise there are programmers out there who really are unaware of theory, and don't realize that a lack of a theoretical background is to their detriment.

In a way it's kind of sad to hire computer scientists who end up writing business software. The good ones know so much about the field, and have all kinds of research behind them, but they get jobs where very little of it is applied in any specific way.

You're free to disagree, of course. I myself might re-evaluate these ideas on a different day. (I consider myself to be both a Computer Scientist and a Programmer, but I regard these as separate, closely related disciplines.)

Re:Which aspect of Ajax?

[julesh]

There's somewhat more to writing a large-scale AJAX application than "understanding a javascript function call". You have to contend with multiple implementations that work different ways. You have to work around the fact that javascript has little or no support for techniques that are typically used in writing large applications. Modularising a javascript application is hell. The method of defining a class is bizarre. Inheritance is horrible, particularly if the class you're inheriting from is in a different file, because there are no guarantees about the order in which they will be loaded. Multiple inheritance...? The language can do it, sure, but it isn't trivial.

Re:Which aspect of Ajax?

[Anonymous Coward]

It's a consequence that you face when you insist on hiring Computer Scientists to do the work of Programmers. [...] In a way it's kind of sad to hire computer scientists who end up writing business software.

The job in question is not business software. It's developing an entire operating system - a resource-constrained soft realtime system with advanced networking, a custom filesystem, and fancy voice stuff.

Almost all the people I've interviewed have failed both my programming questions and my algorithmic questions. We need both, but if they had either, I'd consider them a significant step up. There are a lot of people out there who completely suck, and they make up the vast majority of respondents to any job listing. It seems that after you've hired all the good people you already know, you're kind of screwed.

Re:Which aspect of Ajax?

[Osty]

There's somewhat more to writing a large-scale AJAX application than "understanding a javascript function call". You have to contend with multiple implementations that work different ways. You have to work around the fact that javascript has little or no support for techniques that are typically used in writing large applications. Modularising a javascript application is hell. The method of defining a class is bizarre. Inheritance is horrible, particularly if the class you're inheriting from is in a different file, because there are no guarantees about the order in which they will be loaded. Multiple inheritance...? The language can do it, sure, but it isn't trivial.

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

Re:Which aspect of Ajax?

[Anonymous Coward]

All of that can be - and should be - handled by a framework. There are a couple of ready-made frameworks to choose from or you can roll your own. Either way you will code your application to one defined interface. The biggest problem of AJAX is the abysmal (read: nonexisting) multitasking support. There are threads, but they are cooperative, not preemptive, and the only way to give control to another thread is to end the current thread. How braindead is that?

Re:Which aspect of Ajax?

[jacksonj04]

Web 2.0 Platinum Extreme Edition (PEE) with Concurrent Request Application Processing Support (CRAPS)...

That's not too bad to say I just hammered in the words and realised the acronyms after previewing.

Re:Which aspect of Ajax?

[jrumney]

one out of 40 engineers interviewed would be qualified to learn Ajax.

The scary part is the other 39 are all working as consultants on J2EE and ASP.NET projects, and noone at management level questions their ability.

Re:Which aspect of Ajax?

[drgonzo59]

An application developer may be able to deliver 100% of wanted functionality, but in a way that a user finds aesthetically displeasing.

Digressing to another topic, that comment reminded me about the Gnome/MacOSX vs. KDE/Windows approach to user Desktops. According to the experts in HCI (Human Computer Interraction) field, Mac OS X is more "user friendly" than Windows. Apple has invested a lot more in usability research and it payed off, the interface is easier to learn, it is simpler and more intuitive. I think they managed to deliver 100% desired functionality in a way that users find very appealing. Microsoft on the other side, did a crappy job on the UI and they trained hordes of users around the world (most computer users) to accept it as a default standard.

Enter Linux, the two competing GUIs - Gnome and KDE have addopted different philosophies. Gnome wanted to follow HCI guidlines, their interface is simpler, and I think, more user friendly. I don't think they blindly copied Mac OS X, it is just that both Apple and Gnome creators looked at what a good GUI should be like accoring to previous research in HCI.

KDE on other hand, addopted Windows' kind of UI as their "ideal" model. In other words, anyone who used Windows should find KDE more appealing (I did too at first). But in reality the layout, the ammount of preferences, the number of options visible to the user can also be confusing when compared to Gnome's and Mac OS X's simplicity.

So what is the point of all this? It is that sometimes users don't know what they "need" or "want". Now, I know, that sounds silly to say, but I have become convinced of it over the years. Many users will say that they want such and such a feature but they don't really need it (i.e. they shouldn't have it). So this means that the boss may say he wants Ajax because Google has it, and the job of a smart developer is to explain what Ajax really is and that sometimes it would be a waste of time and resources to jump on the Ajax bandwaggon without getting himself fired. Same went for me and Gnome. I hated it, at first but over time I got frustrated with KDE's large ammount of options and preferences. I couldn't find a specific option I wanted when I had to, so I started to use Gnome more and more and eventually un-installed KDE completely because I was simply more productive with Gnome.

Re:Which aspect of Ajax?

[Anonymous Coward]

"one out of 40 engineers interviewed would be qualified to learn Ajax."

Um, forgive me, but learn JavaScript, learn Java, and basically you can program Ajax. This has to be the weirdest discussion EVER on Slashdot.

Re:Which aspect of Ajax?

[mpcooke3]

When do developers start to realize that users will not conform to what they should do, but what they want to do?

Unfortunately the underlying technology hasn't really kept up. What users appear to want in a lot of cases is application functionality deployed over the web. All we have as developers is the AJAX hacks on top of a language designed for sharing research papers and static page content.

Because some developers have started to make websites look more like desktop apps using a variety of ugly hacks, users expectations have changed and now we are all expected to use these hacks.

What being qualified to learn means in this context i'm not sure. Perhaps it means knowing exactly how far you push these horrid hacks without your servers falling over or some browser version crashing or having browser memory leaks or knowing when is best to break the standard browser functionality like forward, back, bookmark, etc,

Re:Which aspect of Ajax?

[Dacmot]

I'm pretty sure OO programming in Javascript can't be worse than Perl 5's. If thousands of CPAN developers can manage it, why can't people figure out AJAX?

Re:Which aspect of Ajax?

[fishbowl]

>The job in question is not business software. It's developing an entire operating system

In that case, you will be hiring people who studied Automata Theory and took the elective on Compiler design, I guess.

One way you get these people is to support them as interns, guiding them through their last year or so
of college, both by helping them pay for it and by giving them a job opportunity in a place where they already have some experience. That's one of the ways my company handles the problem.

Can you give me an example of your typical programming and algorithmic questions? I'd be truly interested in that.

Re:Which aspect of Ajax?

[fury88]

Amen, I say to you.

Re:Which aspect of Ajax?

[julesh]

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, and as such is designed around closures.

It's a pretty piss-poor attempt at a functional language. Sure, it has closures, which are useful at times. Hell, they're useful a lot of the time. And .apply() is beautiful. But a decent class abstraction would still save everyone a lot of hassle. The world has converged on OOP as the "best" way of writing large-scale applications. Now that may or may not be true, it's a religious war I don't want to get involved in; all I know is that if you're used to thinking in OOP terms, OOP is easier than a large functional program. And Javascript isn't very good for implementing OO designs.

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

Sorry, I've worked in the web design field for something like 10 years now. I was a late javascript adopter, not starting to use it until the Netscape 4/IE 3 era. But not until I started writing serious client-side apps (i.e. what people are now calling AJAX) did I even care about how javascript objects are created, how one would define new object types, and any of these other issues. Most web programming is simple event handling. AJAX programs typically manipulate complex data on the client side, which is where the complexities start coming in.

Of the things I listed, only one of them is a serious problem for traditional page-reload-request style web programming: lack of consistency. Such apps tend not to use enough javascript for the modularity to be a problem. They tend not to be written or designed in an OO style; certainly they don't use inheritance, let alone multiple inheritance. But those things are important in many circumstances, and this is what makes AJAX programming intimidating.

Re:Which aspect of Ajax?

[julesh]

At least in Perl, when you import multiple modules, you can guarantee that their code is initialised in a certain order. A Javascript program typically can't rely on this, so descendant classes must either be declared in the same module that their ancestor is in, or use some kind of event handling system to force their own initialisation to be after the ancestor classes.

Isn't Ajax Javascript?

[mark-t]

What does Javascript have to do with Java?

Re:Isn't Ajax Javascript?

[portmapper]

> What does Javascript have to do with Java?

They both contain the letters "Java" ;-)

Re:Isn't Ajax Javascript?

[CastrTroy]

Just ask my boss. He always refers to JavaScript as Java, and often talks like they are the same thing, although I'm pretty sure he's aware they aren't the same thing. 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. It's like comparing VBScript to VB.Net.

Re:Isn't Ajax Javascript?

[Xylene2301]

It's like comparing VBScript to VB.Net.

That's like comparing a fairly well-trained, slightly yappy, sheep-herding dog to a sociopathic rotweiler.
The sheep dog (vbscript) is useful in its environment. The rotweiler (vb.net) makes you feel invincible until it turns on you.

Re:Isn't Ajax Javascript?

[CastrTroy]

How exactly does a language turn on you? I don't get the analogy.

Re:Isn't Ajax Javascript?

[JacobO]

I hate it when people call JavaScript Java

I hate it too, but for the opposite reason. Besmirching my beloved JavaScript like that... it's just not right.

wow, what an excellent point!

[Anonymous Coward]

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.

Re:wow, what an excellent point!

[bcat24]

I know just how you feel! You wouldn't believe how much of my life I've wasting trying to optimize bubble sorts. Quick sort -- bah! Shell sort -- no way! One day I'll find it, the perfect bubble sort, and then we'll see true fear in the eyes of programmers everywhere. (Besides you and me, of course.)

Keep the bubble-sortin' faith, man.

Re:wow, what an excellent point!

[mark-t]

"Faster bubble sort"???

Are you serious?

The notion makes about as much sense as making a ton of nickels weigh more than a ton of pennies.

Re:wow, what an excellent point!

[truth_revealed]

I set up fasterbubblesorts.sourceforge.net so we can compare notes. I've been working on a promising branch of research the past few months - I think we could get some extra performance if we invert the "FOR I" and the "FOR J" loops.

Re:wow, what an excellent point!

[DSVaughan]

You kidding me? Bubble sorts are awesome and all, but the quick, shell, and comb sorts are so much cooler. Sure they require more code and a higher intelegence to use (why I copy and paste), but they are so much faster. For instance, it takes a reasonably fast computer more than a minute to sort a 10 million element array. the quick sort took .2 of a second. I use bubble sorts all the time because they are so easy, but other than that, I copy and pase myself to quickness.

Re:wow, what an excellent point!

[mark-t]

The only practical purpose that copying and pasting serves as a form of code reuse is potentially establishing job security because nobody else will be able to practically maintain your code.

Re:wow, what an excellent point!

[EugeneK]

WHOOOOOSHHHH

Re:wow, what an excellent point!

[newt0311]

WOOSH......................

That was the sound of the joke as it wooshed WWWWWAAAAAAAAAAAAAAAAYYYYYYYYYYYYYYYY over your head.

You are right in saying that bubble sort isn't that great. After all, who can beat Stupid sort (bogosort) (http://en.wikipedia.org/wiki/Bogosort)

Re:wow, what an excellent point!

[Anonymous Coward]

Are you serious?

No. Read it again.

AJAX between JS and Java servlets

[tepples]

What does Javascript have to do with Java?

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.

Re:AJAX between JS and Java servlets

[Anonymous Brave Guy]

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

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:AJAX between JS and Java servlets

[asylumx]

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

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

Re:Simple

[RuBLed]

...and here I though that Ajax is being used to make the coffee "foam"

Re:Simple

[Anonymous Coward]

Try looking up carriage returns...

Re:Simple

[Anonymous Coward]

No, not the Pacific Ocean - it is between the Java Sea and the Indian Ocean.

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:What does AJAX have to do with Java?

[Tablizer]

Java is whatever you want it to be.

OMG! I want it to be pretty pink ponies!

Re:What does AJAX have to do with Java?

[Charlie the Hammer]

There is a reason why Java has withstood the test of time (for 11 years anyways) That kind of thinking is why COBOL stuck around so long....(shudder).

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

Re:What does AJAX have to do with Java?

[saden1]

COBOL stuck around because people found it to be satisfactory. You don't throwaway software written in an old language because some fancy new language come out. Please don't confuse poorly written code with the language used to write it.

Re:What does AJAX have to do with Java?

[Charlie the Hammer]

You don't throwaway software written in an old language because some fancy new language come out. Actually, yes, you do. Unless you want to wind up with a repeat of the Y2K problem or (on a less grand scale) getting your lunch eaten by a company that uses a faster, more modern, and more productive language.

Re:What does AJAX have to do with Java?

[kin_korn_karn]

People didn't create software products in COBOL. It was strictly an MIS language, because the computers that it was used on were internal systems. That's why nobody ever felt the need to get rid of it - nobody ever wants to upgrade the backoffice.

Re:What does AJAX have to do with Java?

[newt0311]

I would also like function pointers and type inferencing along with dynamic classes with maybe little string execution thrown in for good measure but none of them are making it in anytime I suppose:((. God, python is really spoiling me.

Re:What does AJAX have to do with Java?

[saden1]

It just so happens that I'm in the camp against continuations. Looking at the negative aspects of it, I can't make the case for its inclusion into the Java spec. Continuations is simply a modern term for GOTOs and I can't understand why any sane person would want to go back to the nightmare that was GOTOs. As for first class functions, it's inclusion will make it easy to write non object oriented code. That isn't necessarily a bad thing but then again Java was born to be an OO language.

Re:What does AJAX have to do with Java?

[Anonymous Coward]

Goto has its place. You have been brainwashed into thinking goto is bad. But question WHY it is bad before spouting 'it just is'. I can use just about any language construct and abuse the hell out of it and make the nightmare that goto can be look like a walk in the park. I have learned from true masters how to make BAD code.

My favorite comment this week was some code that looked like this

try
{ INT *pXyz = INT [56]; }
catch (...)
{ // oh well...
}

nothing logged in the catch nothing done just a comment 'oh well'. I laughed for a few mins on that one.

I have seen people do some rather bad stuff with just about every construct of code. Goto is a minor infraction...

Re:What does AJAX have to do with Java?

[fishbowl]

GOTO has nothing on this:
http://en.wikipedia.org/wiki/Duff's_device

Re:What does AJAX have to do with Java?

[crucini]

Java doesn't have function pointers? How do you write code that maps strings to functions? For example, a config file parser that calls a handler for each keyword it encounters? This seems to me an invaluable idiom. For example, in Apache's http_core.c:

static const command_rec core_cmds[] = { ...
{ "NameVirtualHost", ap_set_name_virtual_host, NULL, RSRC_CONF, TAKE1,
    "A numeric IP address:port, or the name of a host" },

ap_set_name_virtual_host is a function.

Re:What does AJAX have to do with Java?

[chromatic]

Continuations is simply a modern term for GOTOs...

Maybe if you manage all of the memory management manually and implement your own frame storage and reclamation strategy.... (I like Sam Ruby's Continuations for Curmudgeons.)

Java was born to be an OO language.

Love those primitive types! (Smalltalk seemed to do okay without them.)

Re:What does AJAX have to do with Java?

[Dan Farina]

Reflection.

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.

Re:What does AJAX have to do with Java?

[cyber-vandal]

People did create software products in COBOL. I've worked with several of them.

Re:What does AJAX have to do with Java?

[owlstead]

Yes, and the fact that you had to explain that ap_set_name_virtual_host was a function says it all. Java is about readability and maintainability. This has the effect that you will have to write things out. This is not such a big problem if you remember that programming only takes about 20% in a product life-cycle, and that maintainance may even be a larger part of the pie.

Anyway, apart from refection (which I tend to avoid), you could do this simply using a large if-statement I suppose. You could also create a set of small command methods and put them into a hash tablen (using inner classes and an interface):

interface Command { callBack(params) };
HashTable ht = new Hashtable();
ht.add( "NameVirtualHost", new Command() { callBack(params) { setVirtualNameHost(params); } }); ...
ht.get(commandString).callBack(params);

That wasn't too hard now, was it?

Re:What does AJAX have to do with Java?

[owlstead]

No, this doesn't compile, you should use put, use more ';', use as generic type for the Hashtable etc. I'm not on my development machine and I hope that the general idea is made clear (remembering all the previous comments that I got for posting some example Java code).

Otherwise I have answer tomorrow, and the moron that says that it doesn't compile gets the modpoints, in a typical /. way of being a wise-guy.

Re:What does AJAX have to do with Java?

[newt0311]

what the heck was that third line of unintelligible crap??!?!?! readibility my ass.

Heres readibility: ht={'hello': meth_hello, 'z':blah} ht['hello'](args)

Re:What does AJAX have to do with Java?

[gutnor]

In this case, as in any OO language (including C++ ... which also has function pointer): you define an interface/class and use a reference instead of the function pointer.

In your case, problably the most common in java would be to define
interface command
{
              abstract string getname();
              abstract void handle(); ...
}

class NameVirtualHost implements command
{
      string getname(return "NameVirtualHost");
      void handle(/* do stuff */); ...
}

After you can implement a factory, or use an hashmap between the name of the command and a reference to the right command implementation.

For a more "function pointer"-ish code, you can use anonymous class

like

callmeback ( new Callback() { void handle() { a_function_in_this_class(); } } );

That should cove about 99% of the use of function pointer. As another author pointed out, there is still reflexion API to cover the last 1%.

Re:What does AJAX have to do with Java?

[espressojim]

How about this: implement an interface that all of your processes are going to implement.

Create a map of concrete classes to your names. As each name comes in, check the map, run the concrete class on the data. If the name doesn't exist, then throw an exception that the process hasn't been implemented yet.

You can 'inject' that map very easily, and you can configure it either using Spring Framework, or by setting it up in some properties file (or XML.)

I do this stuff all the time for scientific workflow pipelines.

Re:What does AJAX have to do with Java?

[Anonymous Coward]

The bulk of cobol runs on big iron machines in large data processing capacities. The reason it is still around and still doing its job is that the environment it runs in is perfect for the language and the language is perfect for the environment it runs in. Not certain which came first, but the two are very tightly linked.

I previously had responsibilities for all development architecture at a DOW 30 company. That included mainframe cobol architecture (yes there is architecture in cobol), Unix C & 4GL (Informix based), Java and .NET. We tried some of the various 'new' technologies on the mainframe, but nothing beat cobol for sheer data processing as it was intimately aware of it's platform and worked well with it.

Y2K had nothing to do with cobol the language, it was the applications that were written to save a couple of bytes by not saving century indicators. There was just as much code written in C that did the same thing.

What this all means is use the best tool for both the job and its environment. Many people forget to include the environment they are running in when they think about tools, but it needs to be part of the calculation. And don't just discount a technology because its older than you. If it works, it works. Afterall, how many of you still drive a vehicle powered by an internal combustion engine that was designed in the 1800's?

And before you say yes but the car engine has gone through major upgrades I'd like to point out that the current version of Z/OS cobol also has an OO flavor. That's right folks, you can write object oriented cobol (classes and the like) if you choose.

Ok, stop laughing now, I'm serious. No really I am. If you don't believe me look at this link.

Re:What does AJAX have to do with Java?

[maraist]

Reflection.
I dissagree with your response.. Reflection is a hack and should never be used directly.. You should always employ a framework which may or may need to resort to reflection (say to read Java5 annotations)..
The best way to dynamicly map strings is via Object Orientation.. Duh...
interface IFoo { ... }
Map m = new Map();
m.put("string1", new Foo1());
m.put("string2", new Foo2());
The way web services work is that there is an XML file which gives string names of classes and associates them with the string names.. (URLs for example).
So a base servlet, for example implements interface javax.servlet.Servlet which has the method
void get(HttpRequest request, HttpRespnse response)
You then write a lot of code that implements that interface, and you put into the J2EE web.xml file

Servlet1
com.company.project.ui.MyServlet

Servlet1 /myproj/edit/*

Behind the scenes the J2EE servlet engine is doing:
Map name2Servlet = new HashMap();
for config in configuration: name2Servlet.put(config.name, Class.forName(config.className).newInstance());
Map url2ServletName = new HashMap();
for config in configuration: url2ServletName.put(config.url, config.servletName);
The key is the semi-reflective Class.forName which retrieves a reflective Class object that can be used to inspect all the methods and fields and annotations for that piece of code. But calling:
Servlet myServlet = (Servlet)Class.forName(className).newInstance();
is identical in terms of performance to calling:
Servlet myServlet = new MyServlet();
They both compile down to similar base byte-code.
But you should almost never use the Class.forName(...) because you don't get compile-time safety.
The preferred method of dealing with dynamicly loaded code is to leverage a framework (such as the servlet engine).. Or to use an IOC (inversion of control) mechanism like picocontainer, hivemind, jBoss or spring.
In this IOC, you define interface fields and the IOC container mapps the names of the fields (often just string associations) to particular implementations.. So
class Foo:
IBar bar;
void run() { bar.doSomething(); }
interface IBar:
void doSomething();
class Bar1 implements IBar
void doSomething() { ... }
class Bar2 implements IBar
void doSomething() { ... }
So now the container has to recognize (somehow) that Foo.bar has to be set to either Bar1 or Bar2.. How this is done is up to the implementation details of the container.. BUT, the code doesn't give a crap.. It defines a contract saying I'm going to NullPointerException if the container doesn't properly configure me.. But the code doesn't have any reference to ANY container.. The knowledge of control in inverted.. Instead of code configuring itself, the container configures the runtime code.
These associations can be in an XML file (most common), they can be defined by Java5 annotations.. e.g.
class Foo
@SpringDependency(beanName="bar")
IBar bar; ...
@SpringBean(name = "bar")
class Bar1 implements IBar { .. }
@SpringBean(name = "bar")
class Bar2 implements IBar { ... }
Then configuration becomes a matter of WHICH classes get deployed to the server.
Alternatively, and most commonly is an XML file which maps classes to bean names, and dependencies to bean-names

So in this configuration we have 6 symbolic names: bar1,bar2,real-bar,test-bar,foo1,foo2
And the final mappings are
bar1
bar2
foo1 -> bar1
foo2 -> bar2
The key is that we have full object orientation and absolutely zero need for function pointers or otherwise symbolic loading of classes... The fact that somebody somewhere is calling Class.forName(..) (and also reflectively lookup up field naems) is 100% hidden from us.. Th

Re:What does AJAX have to do with Java?

[AnyoneEB]

Java 6 (in beta now) will add support for runtime access to javac. (ex. do("System.out.println(\"Hello World!\")"); would print "Hello World!" assuming you changed "do" to whatever the method's name is) I assume that is what you meant by "string execution".

Re:What does AJAX have to do with Java?

[newt0311]

good point. Yours is a much better way to write it in java. also note that this is good for a buisiness but sucks for the individual who have things other than gobs of code to worry about.

Re:What does AJAX have to do with Java?

[newt0311]

yes. that is also the reason I refuse to use C++. if I want something like that, Java is much better. otherwise, C is cleaner. and if I want fast and easy (read: also efficient) coding, I can use python and sacrifice runtime speed for developement speed.

Re:What does AJAX have to do with Java?

[kin_korn_karn]

I kind of shorthanded COBOL to mean "COBOL and the mainframe environment". The typical user of a COBOL system is a company doing internal data processing, financials, reporting, etc. The customers are internal, and they are happy when they are getting their services as cheaply as possible. It's a cost of doing business, an expense.

On the other hand you have software products - web-based applications and the like, whose customers want constant feature and content upgrades, and are willing to pay a reasonable fee for them.

Why upgrade your financial transaction processing system unless it's costing you more than it needs to? Are there more $$ at risk than the cost?

Re:What does AJAX have to do with Java?

[owlstead]

Ok, I admit that readability of anonymous inner classes requires you to understand anonymous inner classes. The thing is of course that parameters and stuff like that are checked and that type safety is maintained in Java. Just for your enjoyment I've added a worked out example which compiles/runs on any Java JDK of 1.5 and higher. As you can see, this is not as hard to do as some organization would like you to think. It's hardly worth creating special syntax for anyway.

Example follows:

package nl.owlstead.delegate;

import java.util.HashMap;
import java.util.Map;

interface Command {
        public String execute(String name);
}

public class User {
        private static String goodbye(String name) {
                return "Good bye " + name + ", thanks for visiting.";
        }

        private static String hello(String name) {
                return "Hello " + name + "!";
        }

        public static void main(String[] args) {
                Map greetings = new HashMap(); // uses anonymous inner class that implements the Command interface
                greetings.put("hello", new Command() {
                        public String execute(String name) {
                                return hello(name);
                        }
                });
                greetings.put("goodbye", new Command() {
                        public String execute(String name) {
                                return goodbye(name);
                        }
                });
                String name = "newt0311";
                System.out.println(greetings.get("hello").execute( name));
                System.out.println(greetings.get("goodbye").execut e(name));
        }
}

Example: IE6 https XmlHttpRequest 12030 bug

[Anonymous Coward]

On the topic of debugging strange AJAX bugs - is there a workaround for IE6 randomly reporting a 12030 status for XmlHttpRequests under https specifically? Mozilla and Firefox do not have this problem with XHR and https. Under IE6, an XHR request will fail with a 12030 error every few attempts - it will fail without any packet leaving the browser. It does not matter if the server serving the https is Apache, Tomcat, or other. If normal http is used, there is no problem on any browser.

Why a language thing?

[Tablizer]

I am hoping that Ajax becomes a set of GUI components and tools that are language-independent, at least from the server side (because one probably needs JavaScript to talk to client DOM). In that sense, the server-side language does not matter any more than Java conflicts with HTML in "old style" web apps. In Ajax, the server talks to the client via XML. If Java wants to make Java wrappers around this XML, that is fine. Other languages can do the same.

Or, is this a battle over JavaScript+DOM versus Java's various client-side GUI plugins? Because of Internet Explorer's lackluster support for client-side Java, I think JS+DOM is where it's at on the client side.

In short, the server-side language should not matter, and Java already lost the client-side GUI war.

Re:Why a language thing?

[Shados]

In a way this has already been done by a couple of toolkits out there, though none of them really picked up.

Honestly, as sad as it is, I find myself wishing something like Flash had picked up more than it did. Flash or another technology. Yeah 99% of Flash sites are annoying as hell, but thats the implementation. You can do annoying stuff with javascript and DHTML too :). If Flash (or something similar thats more open, some standard or another... vector graphics maybe, thats picking up a bit) had picked up, then we wouldn't have to worrie about browsers anymore.

As it is now, between issues with standard compliance, javascript being a mess, CSS being the most stupid implementation (even if the standard was being followed) of a good idea, EVER, making web APPLICATIONS is just a hell, probably the same kind of hell developers felt at the dawn of the GUI. Hopefully someday a good abstraction layer will come out and be widely accepted, then we'll be able to actualy solving business problems, instead of fighting with how to align pixels.

Re:Why a language thing?

[Tablizer]

As it is now, between issues with standard compliance, javascript being a mess, CSS being the most stupid implementation (even if the standard was being followed) of a good idea, EVER, making web APPLICATIONS is just a hell, probably the same kind of hell developers felt at the dawn of the GUI. Hopefully someday a good abstraction layer will come out and be widely accepted, then we'll be able to actualy solving business problems, instead of fighting with how to align pixels.

Perhaps starting over may be the way to go: a protocol *just* for biz GUI's. Perhaps that is faster than shoehorning different vendor's JS+DOM into a GUI standard. It should offer both coordinate-based positioning and "flow-based" positioning. Actually, it could offer just coordinate-based to keep the client simple, and let the server-side do the repositioning calculations. Shift as much of the work as possible to the server.

Re:Why a language thing?

[Shados]

That doesn't work, really. .NET is already pretty darn good at doing that, among other similar solutions, and its just not a good idea to move everything server side. Because then you have to make the data travel back and forth too, and thats way, way too much overhead... The client must do as much as it possibly can without compromising security, its the only way for the system to scale well.

But you're right, there needs to be a from scratch solution for this problem. Solutions already exist, but none are widely accepted enough, so I honestly don't know where the solution is at this point..

Honestly, the only thing that would work would be for CSS specifications to go forward faster and evolve in a more "business" oriented fashion instead of only caring about document layouts, and for companies like microsoft to push them faster. .

That, or the frameworks for Flash to start being more accepted...or something. To get any solution before I have to retire (and thats quite a few decades away), it has to be built on something that already exists, unfortunately.

Re:Why a language thing?

[scumbaguk]

Atlas?

AJAX from a UI design perspective

[isolationism]

Disclosure: I'm not very knowledgeable about Java or AJAX. I'm a UI architect, but I've been avoiding AJAX until the accessibility issues with synchronous content updates get sorted out. That being said, I'm more familiar with DHTML, which -- for the purposes of interface design -- is the part of AJAX relevant to my point.

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 doesn't help my desire to push for web standards when the CEO doesn't give a hoot about every browser out there except the 800lb. gorilla -- going as far as to specifically forbid using anything but in demos because, "That's what our clients use."

I guess it goes without saying that the "people in the community" referred to in the article are developers and not designers; if you think JavaScript support in the popular browser application is bad, try writing 25,000 lines of CSS for a web application designed to work on the "big 4" browser platforms (e.g. MSIE, Firefox, Opera & Safari).

Clearly, Mr. Wei has a point about at least one thing -- anyone who develops for Java should be grateful about the homogenous nature of the JVM. Sure, you may still need to require a specific VM version to run your program, but my experience is that it's not quite such a big deal to bundle a specific VM with a desktop application (and no problem at all to pick and choose what JVM to use on an application server like Tomcat). Why someone would abandon that in favour of the uncertainty (and constant flux) of a browser is beyond me.

Re:AJAX from a UI design perspective

[thrashaholic]

try writing 25,000 lines of CSS for a web application

Holy fuck batman that's insanity. Am I completely missing something about CSS, because I'd never imagine 25K lines of it would be needed to describe a layout.

Re:AJAX from a UI design perspective

[isolationism]

Sure, one layout. This is a product with n layouts, m skins, o colour schemes (each associated with a skin), ... etc.

Each component is also described using style sheets -- the code that renders several variants of a tree component, for example, could be a thousand lines of CSS.

It's also worth noting that when you're dealing with pretty big style sheets for an enterprise product, coding standards becomes a bit of a bigger deal than when writing a one-off web site. We, for example, use longhand for specifying everything then compress to shorthand as a last step using csstidy (I won't get into explaining why but there are a number of functional reasons for doing so.)

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?

Re:Not useful, not particularly entertaining...

[Anonymous Coward]

The whole discussion is a waste of time, and the article itself is lame.

You just described the entire JDJ magazine in a single sentence.

Re: Thank God Java EE Is Not Like Ajax

[salapaka]

The whole comparison of AJAX and Java EE is absurd. The 3.0 version of Java Enterprise Edition is going to be successful, better late than never. This what the community of enterprise Java developers, thank you Sun for making it happen!

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

[Anonymous Coward]

...the Web is not at /all/ a well-designed application platform in most respects. The only
good things about it are its ubiquity and (mostly) fundamental base of open standards.

Otherwise, it's just an awful application enviornment. I am always suprised that everyone
has been so duped for so long-- the phenomenal growth seems to be the answer.

Bleech. In the decades this has been advancing for commercial and application purposes,
we're now just barely reaching the equivilent of a 1990's desktop app, with arguably better
(though certainly more pervasive) network connectivity? Yuck, people! Let's get with it.

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

[ClosedSource]

I totally agree.

All web apps are kludges in one way or another simply because the web standards were never designed to support them. The mistake we made early on was not throwing the whole thing out and starting all over with a set of standards that were designed from the ground up for web apps. It's probably too late now.

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:...of course, the real problem is that...

[Anonymous Coward]

That's what some guys at Microsoft realized when they decided to make Avalon (WPF). Flex 2 is also a fix, but I think it still has too much disconnect between markup and code.

dom

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:Thank God

[Mr. Shiny And New]

Ajax is hard not because of the Javascript aspect, but because of the sheer number of differences between programming DHTML for IE and for Firefox (and Opera, and...). The problem is that each browser's implementation of the "standard" is different, sometimes wildly different, sometimes slightly different. And sometimes the difference is so subtle, yet so important, such as the order events are processed. The net result is that, for any Internet-facing app using Ajax, it's often very difficult to get all the details right. Whereas a similar application, written in the old-fashioned way, often won't have nearly as many cases to deal with. Things like the differences between how FF and IE alllow you to manipulate tables don't matter if the whole table is re-written on the server.

Also there are lots of limitations in Javascript that become more of a problem when you are putting more logic into the browser. Things like the timeout not firing all the time or other limitations due to the single-threaded nature of Javascript. You also run into more bugs when you use more language features and browser features.

Finally, many developers will find that writing AJAX also involves writing a non-AJAX fallback. Integrating this into your code without duplicating everything is tricky and tedious.

All of these problems "disappear" once you have a proper AJAX framework that you can control at a high-level: these become framework problems and the developers can concentrate on the apps. But there are hardly any good frameworks out there.

All of this added AJAX complexity, trouble, and work combine to make AJAX "hard" compared to regular web development. Add this to the normal workload and your web developers are going to be pushed harder than before. Some can handle it, some can't. Consider that the level of expertise required for a typical AJAX development position is now much higher than before: you need to be an expert in your server-side language (which you already were), HTML (you probably had some knowledge), DOM, Javascript (you knew some of the stuff but likely didn't do much DOM manipulation and probably only used JS mainly for form validation), and whatever other tools you are using. I'd say basically an AJAX developer needs to know 2-5 times the "browser" knowledge that a regular web dev needs; esp if the web dev used to have a graphics/html person who coded up html pages to use as templates. This web dev probably only needed enough HTML to know how to hook in forms and form validation scripts. Now he needs to know how to re-write parts of the dom, and he will soon become intimately familiar with all the bugs and limitations and browser differences therein.

mod parent up...

[Anonymous Coward]

...funniest thing I've read on Slashdot in some time. Thank you, sir.

The point being made is ...

[Elias Ross]

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.

Re:The point being made is ...

[owlstead]

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

Yes, indeed. That last sentence was important. I see a lot of new developments in Java, but most of the time the first implementations and API's are pretty lacklustre. What the JCP is really good at is to get the core ideas, take some time to think them over, and get the gist of them into the language. Sometimes the old implementation is adopted into the langauge in it's entirity (e.g. Apache XML), but behind a sane interface. The original Apache XML API is a horrible cludge with static calls etc., while the XML API of Java is a much cleaner API. The JPCSC API (a smartcard reader library) is too horrible to look at, but the javax.smartcardio.* API is - although yet pretty unusable - clearly made with Java calls in mind.

I think this way of adopting technologies is a very sane way of extending the Java runtime, instead of just ramming in any "rebel" technology at the time it is developed.

Continuations are being worked on....

[Anonymous Coward]

first class functions are a different matter.

-- ac at home.

Why can't JEE be more like AJAX? Simple...

[FerretFrottage]

you try running websphere in your browser :P Now from IBM for $250,000--The FireSphere Browser

From the article: "The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can't JEE be more AJAX like?"

I still see many of the best practices in AJAX being fleshed out in the year(s) to come. Hopefully things like Comet will become a reality in the near future and the many different toolkits/utilities (dojo, dwr, jmaki, et al) can continue to mature and make the development of AJAX apps faster, easier, and more reliable but the current amount of hacks required to get any decent app working in all the various browsers is just downright fustrating. J2EE has its own set of best practices which I dare say are much more tried and tested than most of those for AJAX. But in some cases best practices are easier to lay down for JEE as all things JEE must be "blessed" by the JCP/Sun so you have a "standard" target. This can be a good and bad thing and the article does touch on those points.

I think system engineers have become to realize that you don't need EJBs and all its baggage to solve every problem and that some problems can be solved by lighter weight solutions, but when you need atomic distributed transactions, fail over, horizontal and vertical scaling, and all that other enterprise jazz what are the current alternatives?

Like always (well mostly anyway), the good engineers/developers who are "free" to do their jobs will find the right mix of technologies from AJAX and JEE (or something else) to solve their given problem(s) despite what the industry tries to shove down their throats.

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:That's really kind of funny actually because...

[espressojim]

As an ex-EJB dev (oh, 1.0 was just the right time to adopt...ug!), I'm kinda hopefull about 3.0. It has adopted the spring framework aspects I like the most (injection-style programming), I can use hibernate for my ORM (which is stronger than just Java Persistance), and I get JMX/JNDI/JTA/etc services pretty easily.

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:That's really kind of funny actually because...

[Bill, Shooter of Bul]

So what are you now? what did you leave it for? anything intersting you'd care to share?

Remember caring is sharing

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

[_pruegel_]

I (not the gp author) left EJB because I could not stand the redundant XML configuration, -Home and -Remote classes and so on. EJB3 gets rid of those classes but a (for most users) completely redundant configuration stays as it is present with Hibernate and many other persistence frameworks. I never understood why everyone would want those since it all can be written in pure Java code.
But now there is cope 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:That's really kind of funny actually because...

[Assmasher]

The typical software architect. Tell what your needs are, platforms are, customers are, ancillary goals are, future needs may be, yadda^3.

I left it because the startup that had decided to employ it did a 'Titanic' ;). We didn't need to use it on the project, but it didn't really hurt us as the primary engineers (myself and a couple of other guys) were pretty decent developers who were excited about EJB, so we found a myriad of ways to get around the problems inherent in early *implementations* of EJB containers (not problems with EJB itself.) The problem was that EJB is a very solid, imho, interesting framework which unfortunately rarely (relatively) gets used in the proper context. We certainly didn't need to use EJB for our solution, it was like killing a mosquito with a shotgun. LOL.

I personally feel that EJB is most useful in a distributed enterprise development context. Not as in a company with 3 different development locations but as in several companies trying to band together to 'out service' another conglomerate of companies.

The only thing I think I'd suggest regarding EJB is this: If you have the caliber of developers who are really going to understand and properly implement an EJB based solution then chances are your developers could solve these framework problems without using EJB. Encrypted XML over TCP/IP for example, marshaling things themselves. Lifetime and memory management. These problems are simpler than they appear and any project which doesn't provide you with the bandwidth to accomplish these types of goals probably isn't giving you the bandwidth you need to use an EJB based solution either. (This is, of course, discounting projects wherein you're simply adding to an existing or integrating to an existing EJB infrastructure.)

People would be shocked at how much cool enterprise stuff you can do on your own in Java/C# (pick your poison.) I've spent quite a bit of time architecting an enterprise distributed system lately and found that most of our client systems (streaming video, geospatial display for example) integrate nicely into our middleware layer with Java as the implementation platform, and that the middleware layer works well in C# (some aspects in C++ since we're still looking at C# on *nix.)

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

[Anonymous Coward]

> I (not the gp author) left EJB because I could not stand the redundant XML configuration, -Home and -Remote classes and so on. EJB3 gets rid of those classes but a (for most users) completely redundant configuration stays as it is present with Hibernate and many other persistence frameworks.

What redundancy? Java Persistence API is 100% annotation-based. In fact, the main problem with JPA is that there's apparently no way to NOT use annotations. Hibernate has JPA-compatible annotations and lets you put all validators in annotations as well. Not one line of XML anywhere.

COPE looks wildly unexciting when compared to even the standard JTA annotations, since the whole point of those is to not have to sprinkle commits and rollbacks everywhere. Maybe COPE is smaller, that could be an advantage in some situations.

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

[Bill, Shooter of Bul]

I just asked because this whole notion of frameworks outside of java is somewht confusing. I'll need to resarch it myself. Also mystifying this concept of the "enterprise". I do mission critical software that handles high volume transactitions,but i've never found a need for anything else. I think it might just be because there isn't any legacy stuff to deal with, or complex interfaces between services. I'll investigate the whole issue again, but I have the feeling that I'd end up killing our elephant with a blowtorch (might work, but there'd be some screaming, a funky smell in the air, and a rotting carcass left in the sun for the other elephants to wistfuly pick up and rue the day EJB was created and secretly plot their revenge).

Whiskey Tango Foxtrot?

[rk]

FTA:

"I was always skeptical about AJAX. This technology can be useful for Google , Yahoo, or Amazon, and the like . Because regular businesses can not afford it. They can not hire a team of experts to find workaround for dozens of serious problems browsers/JavaScript introduce. Browsers/JavaScript is not an application development environment."

Oh, shit. I better tell my boss that all the AJAX-based apps I've written over the last six months need to be taken down. Apparently, we can't afford them!

My apps are certainly not nearly as complicated as the ones the big boys do, but they're still AJAX, carrying a dialog with the user interface through XMLHttpObject. I'm the only full-time developer at my company.

AJAX and Javascript are a mess, though.

Re:Whiskey Tango Foxtrot?

[julesh]

Having been working on a few AJAX applications myself lately, I can kind-of see his point. Writing a complex AJAX program is hard. You have to work around the limitations of javascript, and you have to work around the limitations of browser support. A typical day these days involves about an hour writing new code and about seven fixing obscure browser bugs that only turn up in one browser in some obscure circumstance.

Compared to writing more traditional desktop applications, I'd say AJAX takes at least twice as long to achieve similar results. It also needs a much more competent developer. For most businesses, whose development needs are for internal applications (i.e. intranet applications), you just can't justify it. You can develop the desktop application and roll it out to every desktop for significantly less money.

Re:Whiskey Tango Foxtrot?

[pimpimpim]

For intranet applications you could force everyone to use the same browser, as they will need to go there anyway. Whereas for internet applications, your costumers might have any browser, and will just go somewhere else if they are displeased with your service. Still, this will put your application at the same user-friendliness as any IE-only web-based system bought from microsoft, so you'll be pissing at least part of your employees off like hell, you might also not want that.

Re:Whiskey Tango Foxtrot?

[julesh]

For intranet applications you could force everyone to use the same browser, as they will need to go there anyway.

True. Then you only need to work around half as many browser bugs. You get to choose IE (more bizarre and insidious bugs that sometimes take days to figure out) or Gecko (more numerous bugs that are better documented and easier to work with).

Actually, if I had free choice, I'd probably pick Safari. I'm not a mac fanboy, in fact we're a PC-only shop, but we recently had to demo one of our apps to a client who uses macs, so I fired up a VNC link to a hired mac, expecting to have to spend a couple of days debugging to get the app to work, but it was flawless first time. I think this app had had something like 3 weeks of time spent on it, roughly evenly distributed between fixing IE bugs and fixing Gecko bugs, but Safari worked first time. So either it has no bugs, or it has bugs that are exact duplicates of IE/Gecko. ;)

Re:Whiskey Tango Foxtrot?

[easter1916]

I believe Safari uses the rendering code from Konqueror, so that might explain that, if Gecko does too. I gave up trying to keep track of the Irish nationalist paramilitary-like fragmentation of open sores projects long ago.

Coach Wei?

[BitwizeGHC]

I think I'm more interested in what Coach Z has to say:

"I use Ajarx to clean my terlet! It does a pretty good jaerb!"

god computers

[nihaopaul]

i'm sorry, but, god and nerd stuff doesn't go together, thats why we have redundancy, remember: god saves, but buddah runs a raid10 node apart of a intercontinental cluster with n+1 technology and a private directly linked fiber line +1

so the next time you put your trust in god to keep the matrix up, remember this.

Enterprise Class Jive

[Baldrson]

This guy, Coach Wei, whoever he is, compares a specific platform for Java with the general miasma of people who woke up a year or so ago and realized that Javascript was a programming language. Classic Jive: Pick a toss a red herring in the air, blow hard, set up a straw man hoping no one notices its a straw man, then knock it down.

Re:Enterprise Class Jive

[the grace of R'hllor]

I think you mean JIBE. Not jive. To quote Usenet, "Nothing of significance has 'jived' since Barbara Billingsworth on the movie Airplane."

Engineering vs. Hacking

[Anonymous Coward]

If like to engineer things in the true sense of the term, then you have to go for Flex/Java EE. If instead you like to hack things, then go with Ajax/Whatever. This is not to say that Ajax products do not work or do not kick ass from the user's point of view, though. Maybe this is all that matters in the end.

GWT

[HappyEngineer]

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.

Re:GWT

[njh]

So it gives you the run time performance and portability of Javascript with the concise and powerful language constructs of Java?

two words

[stoolpigeon]

microfocus cobol -- i was an admin for an app written in it. might be the only one in the world, but i doubt it.

There is no hope, but's be genetic

[Augusto]

Somehow you are totally missing any signs of the "sarcasm" gene, unfortunately for you, this is irreversible.

Re:There is no hope, but's be genetic

[mark-t]

No... I'm just incredulous that the author of the article somehow thought that the notion of "faster bubble sort" made any kind of sense. As soon as you make it faster (in the algorithmic sense, as bubble sort is a generic algorithm, not just a timed sequence of events), you don't have a bubble sort anymore... you have some other kind of sort. Several sorts are similar to bubble sort in concept and share its O(n^2) time, but derivatives of bubble sort, or almost any algorithm for that matter, that have better performance specs than the base algorithm they are derived from are usually given their own name to distinguish them.

but's be = must be

[Augusto]

Must be all the bubble sorting in my brain while typing ...

NewI\O

[cnystrom]

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

Re:NewI\O

[Anonymous Coward]

Nice pic, dude. You're hot.

http://www.newio.org/team.html

Re:NewI\O

[cnystrom]

Don't hate me because I am a sex symbol.

Good old technologies...

[Youx]

Agree. Fact is we'd have been better never moving from LISP.

Roads need to be more car like

[TopSpin]

AJAX and Java EE are orthogonal. Servlets and EJB serve AJAX clients just fine. Some large fraction of all AJAX clients use Java containers as successfully as any other back end.

If what is meant is Java EE needs some of the AJAX hype... well Java EE has the tools, libraries and maturity to continue thriving with or without AJAX.

I find this inevitable push to bury Hibernate and Spring as throwing a lot of very good tools down the drain in order to continue the Sun monarchy and JCP worship.

Monarchy, worship. Like Java EE doesn't have competitors. Go pop a zit Brandon.

Which aspect o they want?

[NamShubCMX]

How about the fact that it WORKS, despite all quirks, and that although Java Engineer TM Reg Inc. feels it sucks it still is what will power the internet tomorrow.

Re:Which aspect o they want?

[jandrese]

I think the Java guy is just jealous that Ajax pages don't freeze his browser up for 10 seconds while the JRE loads, well that and the fact that they integrate with the rest of the page instead of just taking over a part of it.

Re:Which aspect o they want?

[what about]

AJAX works only in well defined circumstances.

Countless website wants IE to work, or the latest Firefox, nothing else will work.

This is not user experience, this is user pain, and the saddest thing is that often javascript mess is used do do menu navigation (jumping to other webpages) things that can be done and have the same visual result as stndard HTML

The other sad thing is that Flash is reinventing Java (without the security model) and AJAX is reinventing Java (without the reliability). I don't know why, but it seems a worldwide sport to bash java and praise anything else that does just bits of what java does. I wonder why...

Re:Which aspect o they want?

[MightyYar]

The other sad thing is that Flash is reinventing Java (without the security model) and AJAX is reinventing Java (without the reliability).

From a user's perspective, Flash and AJAX are already superior to Java. Flash is better because it loads instantly and is very responsive, even on slow computers. AJAX is better because it involves the entire web page, and not just one little box somewhere.

From a more technical standpoint, I think that the design goals of Flash are completely different than Java. Flash is for multimedia only, with some very rudimentary applications supported through simple scripted responses to clicking. No one will ever write a bank transaction back-end with Flash. Flash, unlike Java, is not trying to be all things to all people. If Sun wanted Java to succeed as a plugin, all they had to do was strip it down to some very basic display code and call it WebJava. It would have looked a lot like Flash, but the "glue" would be Java-like. AJAX, on the other hand, was not really designed at all and isn't really comparable to Java. AJAX is just the tying together of a bunch of independent web technologies. No one language could replace AJAX, since it relies on a modern browser, JavaScript, and a server that knows how to speak the right language. Java is frequently used on the server, so one could argue that it already IS part of AJAX.

Java and HTML but not Ajax

[Anonymous Coward]

It would not be better to use the browser to show only HTML, extend HTML document oriented tags with application oriented tags, SVG and use a protocol designed for applications not one for download documents? A protocol like X11 but with HTML, DOM nodes and DOM modifications. A stateful protocol without cookies, binary, designed for minimizing the amount of data traffic needed between server and client. An asynchronous protocol with witch server can send HTML pages and DOM modifications to the client/browser at any moment and the cliente/browser shows the HTML, make the DOM modifications and sends function execution request to the server with user input. Just some ideas

Ajax serves one purpose: better user experience

[Anonymous Coward]

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 fluid user experience? The added flexibility on the client-side? The ability to make richer, more responsive applications?

Or do Java devs not think about "users" any more?

(Seriously, that's what Ajax is about, the USERS. Forget about the implementation for second. And yeah, Java and Ajax are pretty orthogonal so the whole article is (-1, Offtopic) but his criticism of Ajax needs to be addressed.)

Wrong article?

[SanityInAnarchy]

I fail to see what this has to do with Java or AJAX, and I don't have the mod points to mod you offtopic.

Are you a cut'n'paste troll, or are you simply in the wrong article? Or maybe you intended to reply to a specific comment?

Re:Wrong article?

[nihaopaul]

i'm sorry i forget that not everyone has a sense of humour or can read, did you miss the 'thank god' in the article header? so please stop trolling

You're an elitist "engineer".

[SanityInAnarchy]

You do use x86, right? Like most of the world?

x86 is an engineer's nightmare. It's horrible, it's ugly, it's loaded with legacy crap.

But the true engineer doesn't care, because he's likely working in a high-level language, like, say, Java.

Now, if you want to engineer a web app (and you're sure that's not an oxy-moron), you can do it in the low-level -- you can write the code manually, deal with browser issues, hack around. It'd be kind of like writing x86 assembly. Or you could do true engineering, just as easily. Hell, if you think Java==Engineering, you can do Ajax entirely in Java with the Google Web Toolkit -- it will take anything needed for the frontend and compile it to JavaScript.

But you're damn right it has to kick ass from the user's point of view. I could write a beautifully normalized, speed-optimized, complete, perfect relational database, but if the only frontend is a SQL commandline, I've failed as an engineer and a hacker.

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.

Re:Religion aside...

[owlstead]

Yeah, that's why every conference about Java EE (and most Java conferences mostly are all about Java EE unfortunately) always breaks into a complete cat-fight because of all the frameworks.

The Java community is pretty millitant against adding features, that's true. The reason behind that is that it quickly becomes very complicated to read and manage all those different concepts. If the Java community wasn't, with the popularity of the language, it would now be D+++.

Every time that some developer gets modded up for requesting things like continuations to Java, I wince. A concept like that goes against everything Java stands for, and then some. We think inside the "sandbox" because it's the one thing that makes Java great. Even though I sometimes wish we had feature X as well when doing the actual work.

Re:Religion aside...

[exa]

Looking at the posts about author's mention of bubblesort, it also seems that AJAX is very popular among lamers. You can't beat millions of lamers with wit, you need a nuke.

Re:Religion aside...

[pestilence669]

Bubble sort is super efficient on lists of less than three elements. 'Leetness isn't determined by the technology. Java has lamers too. Their called college freshman.

Bubble Memory optimizes Bubble Sorts

[SimHacker]

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

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!

Re:RTFA!!!

[the eric conspiracy]

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.

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.

Re:RTFA!!!

[SanityInAnarchy]

I don't know much about Java except that I hate the language, so you may be entirely right. I'm not agreeing or disagreeing with either viewpoint, I just want to bring us back on topic.

I like Perl a lot now, mostly because of CPAN. It's just awesome to sit there and think "I need to write a CSV file", and within minutes have Class::CSV installed on my system and be cranking out CSV files, with all oddities like quotation and punctuation handled.

Re:RTFA!!!

[the eric conspiracy]

I used to do a lot of Perl programming, but I eventually grew to hate the language because it is so hard to read and is missing so much in the way of object structures. Now if given a choice I use either Python or Ruby. Maintaining and modifying code in either of those languages seems much easier to me.

this really comes down to:

[namekuseijin]

java vs javascript

or in other words:

strongly-typed statically checked compiled language proponents vs weakly-typed dynamically checked interpreted language enthusiasts.

which is really as old a debate as C vs LISP...

yawn...

Re:this really comes down to:

[Dan Farina]

Lisp is dynamically and strongly typed and that C is statically and weakly typed.

By some definition...or at least the one I chose to believe. Static and dynamic are well defined, but strong and weak are anything but.

Re:this really comes down to:

[namekuseijin]

yes, yes... i was giving an example of a broader spectrum... ;)

Rapid UI Development

[Anonymous Coward]

I'm not sure why we always get so hung up on user interface development languages. Why do we keep adding VMs and abstraction layers when it still fails to solve the cross platform compatibility issues? I mean come on: ASCII, HTML, DHTML, javascript, AJAX (I think I left out at least 4 layers).

What is needed is a test driven robust standard that is not as open to varied interpretation. Build each requirement with a set of test cases that must be passed for an interpreter to be considered valid. Strive for as close to 100% logical coverage as you can get before you even implement a single interpreter. Then let us C++ nerds go and implement some virtual machines and client side libraries in our spare time ... it'll take maybe a weekend or two. No, never mind. What we really need is a layer that sits atop AJAX that interprets it into Java Swing classes. Yeah that'll do the trick.

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.

A lot of high scores on this post

[Anonymous Coward]

I'm quite curious about all of the posts rated as a 5 on this page. Could this be because of the interest the modders(web developers) have in this particular subject? Nah... I'm sure they're fair and balanced -- just like FOX News. Watch the score I get on this post.

God?

[lightspawn]

I knew about the Java Community Program, but I wasn't aware He was involved with it. No wonder it became so popular so quickly.

I wonder if He has contributed to any fully open source projects - the comments alone may be worth reading.

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:Javascript is ubiquitous, Java VM is non-portab

[GigsVT]

Why anonymous? What you say is absolutely correct and true, however unpopular it might be to say it.

I hear they are teaching Java more in schools now, a sad thing really that even acedemia bought into the hype and empty promises.

Not so sure... (was: Re:You mean the buzz?)

[beh]

Sure, there is a lot of buzz about Ajax - and right now, it does have its growing pains (fragmented browser support, more difficult to implement, ...).

But I wouldn't go as far and discount it as useless because of it, or just saying "Thank god, we're not like that". If you go down that route, you'll go down a route that ignores the market.

Let me move the original comment back a few decades and put in a slightly different context, and that will hopefully highlight what I mean:

'Which aspect of Graphical User Interfaces [do] we really want our Unix apps to have? The difficulty in developing Graphical User Interfaces [no UI builders] code? The difficulty in maintaining GUI code? The slowness of GUI code across the network? The resource-hungryness of GUIs?'

Surely, there was a time, when I thought real deep down X11 client programming was a pig - but if I had stayed with purely command line apps, I would have missed the market - or do you honestly believe you could find a mass market for a non-WYSIWIG command-line driven equivalent of Word or Excel?

If I compare, say, maps.google.com (AJAX) and streetmap.co.uk (non-AJAX); or gmail compared to some non-AJAX webmailers out there - google maps wins hands down in user friendlyness - and that's the bit that counts.

There will be sites/projects for which Ajax will not be the way to go (much like the way gcc doesn't have a built-in GUI), but for many functions with direct and interactive user-access - Ajax will be the way to go, until someone comes up with something even better.

Re:Not so sure... (was: Re:You mean the buzz?)

[bcat24]

I agree completely. The point I was trying to make is that technologies should be judged on their virtues, not pure newness. AJAX is very cool and very useful, but it's not a silver bullet. If AJAX is really best for a project, of course you should use it. If some other tool works better, use it, even if it's not quite as buzzword-compliant. Heck, even Perl has its uses. :)

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

[Anonymous Coward]

Why anonymous?

Because I no longer have the energy nor inclination to argue with the Java devout about their adored and worshipped system that can do no wrong and runs absolutely everywhere and makes the tea and takes the dog for a walk, and is the One True Language.

I sat for years on various Java technical forums, but that was during the early years when Java was in its infancy. Then things started getting ugly, when the language became a religion.

Every language has its fanboys, but there are usually good solid engineers around who will willingly discuss any shortcomings so that they can be improved. Not so with Java now. The Java community has taken the concept of "fanboy" to its extreme limit and totally removed the brains from anyone who might openly discuss engineering problems with its implementations. It is simply not allowed.

Well, I'm an engineer, and if discussing problems with a language is not allowed then I'm simply not interested in that language, because all non-trivial systems have problems. It's in the nature of complexity.

So, that's the reason for the AC post. Pretty sad, but that's life. Java for me is worthless. I wish it were otherwise.

s/Ajax/Java 1.5 + applets (or WebStart) ?

[drgonzo59]

Interesting that you mentioned that. The other day I was in a bookstore and was looking through the computer books section. There are a ton of Ajax books out there. It seems like out of nowhere we have all these Ajax experts writing books about Ajax. I picked up a couple of them and as I was reading I kept thinking that "I could do that with Java applets" or "Java + WebStart can do that".

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

Re:s/Ajax/Java 1.5 + applets (or WebStart) ?

[ultranova]

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.

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.

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.

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.

Re:s/Ajax/Java 1.5 + applets (or WebStart) ?

[Anonymous Coward]

"garbage collection lasts for minutes due to having to traverse nearly all of applications memory" !?

Sorry but that is a total troll. You obviously haven't run Java apps in a hell of a long time. With generational and incremental gc these kind of pauses don't happen any more.

Re:s/Ajax/Java 1.5 + applets (or WebStart) ?

[say]

I picked up a couple of them and as I was reading I kept thinking that "I could do that with Java applets" or "Java + WebStart can do that".

Funny, because when I read them I tend to think that I could do that with any language. It's not like Ajax technology is anything new ("ooh, the select lists are dynamically updated, just like Windows 1.0"). It's all about the method of delivery. Java applets require more stuff on your customer's side, and requires them to learn a different UI than the Web. Ajax utilises the poor environment of HTML to deliver content - meaning requirements and learning curve can be lower for quite a few applications.

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

You are strange, sir. First you advocate replacing thin solutions like Ajax with fat solutions like Java applets. Then you say "but many people need nothing", and go for the thinnest possible solution. Why is it suddenly a problem that Mr. Sixpack has a fatter solution than needed, when it's no problem that Ajax (thinner) gets replaced by applets (fatter) in all other situations? Web applications do demonstrably work with Ajax, you know, you don't need applets.

And why shouldn't Mr. Sixpack get easier navigation, sazzier transitions, pre-loading of slideshow images and so on for his fishing trip pictures? Whose "need" are you referring to when you say he doesn't need Ajax? Does Mr. Sixpack need to have his images online at all? Do most people need e-mail? Shouldn't they be happy with food?

Re:s/Ajax/Java 1.5 + applets (or WebStart) ?

[drgonzo59]

You are strange, sir.

Thank you, I've heard that before ;)

On a serious note sorry, didn't mean to mislead, what I meant to say is "the right tool for the right job".

Some sites (web applications) will benefit from Ajax, example: Google, Yahoo and other large portals are prime examples, but Ajax isn't the answer to everything like many of today's books and Ajax fanboys suggest. There is a place for rich clients -- with new Java native GUI l&f there is no need to have apps that look alien, they can look just like Windows or Gnome apps. I could see myself opening a custom Webstart Application to access my bank records or my email just as I can see doing it in a browser. Design and functionality -wise I think Java is a cleaner solution today (I know it wasn't the case a couple of years ago). Ajax has to jump through many hoops just to catch up with a basic UI capabilities that, like you said, have been there on the desktop since Windows 1.1.

As far as requirements go you say that Java applets require more stuff on your customer's side. But I say that all the customer needs is Java and a web-browser. Granted, JRE is not a small install, but in order to have Ajax, the developer has a hell of a time finding workarounds for various browsers that never quite seem to implement completely all the standards W3C standards.

And why shouldn't Mr. Sixpack get easier navigation, sazzier transitions, pre-loading of slideshow images and so on for his fishing trip pictures? -- Because Web and HTML was never intended to have sazzy transitions, flashing buttons and so on. Added flashiness != always equal better usability. For each site out there that has successfully used Ajax there is another site that made the user experience worse by slowing it down, or having it not work at all anymore on some browser just because they forgot to include an extra if(browser==Opera){...} among the code for many Ajax browser workarounds.

The right tool for the right job. Some sites will benefit from Ajax, some can just stay static, some will be better off as a Java Webstart application and many will just be somewhere in between.

Re:s/Ajax/Java 1.5 + applets (or WebStart) ?

[ultranova]

Sorry but that is a total troll. You obviously haven't run Java apps in a hell of a long time. With generational and incremental gc these kind of pauses don't happen any more.

I have, with both 1.5 and 1.6 beta. The problem, like I said, is that when full collection is needed, the program needs to traverse the object network, bringing memory pages in from swap in a random pattern. What's worse, if a single page contains many objects, it could be brought in, pushed out, accessed again, and so on.

It's a fundamental incompatibility between garbage collection and swap.

Re:s/Ajax/Java 1.5 + applets (or WebStart) ?

[ErroneousBee]

As a jEdit user, I can confirm that the presence of a java application on the desktop can stuff performance.

When jEdit is open on my PC, swapping windows can take seconds while the screen gets redrawn.

Knowing JS today != Knowing JS 5 years ago

[drgonzo59]

Note that "knowing JavaScript" 5 years ago meant "I know how to write an even handler for onmouseclick to make the text blink".

Today, with Ajax in mind, "knowing JavaScript" means "I know and understand async. I/O & DOM, I know about XMLHttpRequest and I could re-implement Google Maps for you if you ask me".

All of the sudden JavaScript went from being used as a toy scripting language to a full-blown develpment language. Not saying if it is a good thing or bad thing but you can thank Google for it...

So what are the AJAX-Patterns?

[iion_tichy]

The article mentions the extremely important best practices and patterns of AJAX. So what supposedly are they?

Python? Who said Python?

[drgonzo59]

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). Then Python could also be used on the server...

For interface, I'd like full SVG 2.0 supported in all the browsers and standardized (i.e. no need for Flash) and for a way for my imaginary browser-embedded Python to manipulate the SVG interface in an easy, clean and Pythonic way...

Ahh, it's nice to dream..

Re:Python? Who said Python?

[nuzak]

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

Re:Python? Who said Python?

[MP3Chuck]

One of the upcoming Firefox releases is supposed to support Python for XUL scripting (read: extensions). Obviously this doesn't give you document-embedded Python but it's theoretically only a few steps removed... it'll be interesting to see if they pursue that route.

It's about business

[iion_tichy]

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

That may be true, and isn't inherently a problem, or is it? However, somehow Java tends to be used in big companies and big projects, where it is really helpful to have those official standards. It helps to speed up the decision process on what technology to use for what purpose.

NO: Why can't JEE be more like AJAX? Simple...

[freedom_india]

J2EE/JEE can't be like AJAX for following reasons:
1. AJAX revolves around hitting the server hundreds of times and thus increasing the load on Server unnecessarily.
2. AJAX revolves around browser's support for XMLHTTP: Nothing else.
3. AJAX requires very fast user network connections, least redundant comnnections which may not be available at all times.
3. AJAX is basically JavaScript which CANNOT and will not replace enterprise computing until Rule Engines replace ALL programming.
4. Java is more robust, more feasible for virtualization, etc., which makes it attractive.
5. Not all enterprise applications require a browser: Most are Batch operations and as such require NO browser interfaces.

XML11 is better than GWT

[sproketboy]

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.

Re:XML11 is better than GWT

[Anonymous Coward]

GWT docs are pretty clear that 'GWT Java', the code the gets transformed into javascript, is a small subset of Java. See the emulation jre docs:

http://code.google.com/webtoolkit/documentation/jr e.html

If you are waiting for a GWT Java 5 version I would recommend rethinking how you use GWT. Keep the code that get transformed into js as simple as possible. Don't write whole apps in GWT. Write small components (forms, table views) as seperate GWT projects and pieced them together on the backend using the user's session.

You can use whatever you want on the server. Do the difficult work there.

Re:XML11 is better than GWT

[sproketboy]

Or just use XML11. ;)

Re:XML11 is better than GWT

[Anonymous Coward]

I walked into that one.

Re:XML11 is better than GWT

[HappyEngineer]

I'll take a look. I wasn't aware of any other implementation.

However, just to be clear, GWT is only limited to jdk 1.4 on the client side (the side that's compiled into javascript). The server side code can use jdk 1.5.

Good platform...

[DarthChris]

[Java] is good platform and a robust one at that.

I'm a bit late to this thread, but I'd like to say this anyway: surely a good platform is robust by nature? I would certainly expect it to be!

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

More about *Rich Internet Pioneer* Coach Wei

[brajesh]

http://www.coachwei.com/blog/_WebPages/AboutMe.htm l
Quote - "I live in Cambridge, MA. I work at Nexaweb Technologies (http://www.nexaweb.com), an Enterprise Web 2.0 software company. &...Many moons ago (1997 to 1999), I wrote an Ajax-based word processor, which is published and open source at http://www.ajaxword.com./ I also worked at EMC Corporation in the late 90s, doing work in the enterprise storage area. "

Oh & Btw - I'm Yuri Gagarin.
--
In Soviet Russia, the Rich Internet pioneers YOU. Obligatory.

Re:More about *Rich Internet Pioneer* Coach Wei

[easter1916]

You most certainly are not Yuri Gagarin. I've been pretending to be him since 1995. Go find your own famous dead person.

No connection.

[Futurepower(R)]

"What does Javascript have to do with Java?"

Nothing.

Re:No connection.

[AnyoneEB]

I'm very sorry, but Java 6 is adding built-in JavaScript support (ref). I think Sun thought the issue was not confusing enough.

Dijkstra was NOT a troll

[Kenneth Stephen]

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.

Re:Dijkstra was NOT a troll

[Raenex]

Amen. "troll" is so overused/abused it has become meaningless. Right up there with "lol" and "terrorist".

Re:Dijkstra was NOT a troll

[Anonymous Coward]

Thanks for the hot tip fag.

And see, I really -do- believe that. Does that mean I'm not a troll?

Re:Dijkstra was NOT a troll

[sammy baby]

If we can't call polemicsists trolls, then the terrorists have already won.

Or something.

Re:Dijkstra was NOT a troll

[o2sd]

LOL !!

J2EE & AJAX handle complexity differently

[HighOrbit]

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?

Re:god computers

[thenerdgod]

You're wrong, and that's about all I have to say about that.

Re:Java EE is *different* from AJAX, and vice-vers

[lateefj]

My beef is with this concept right here:

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.

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.

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

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

[mark-t]

...Because I no longer have the energy nor inclination to argue...

Oh, but you do... or else you would not have bothered to post at all. I expect the real reason you post anonymous is that you _want_ to argue but don't want to assume any responsibility for it.

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

[Anonymous Coward]

Oh, but you do... or else you would not have bothered to post at all. I expect the real reason you post anonymous is that you _want_ to argue but don't want to assume any responsibility for it.

That's a wonderful example of the standard form of response nowadays on any Java forum: don't address the message, just attack the messenger (for which you need an ID).

Thank you for providing so very rapidly an example of correct Java community behaviour in response to a possible question mark about VM portability.

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

[Anonymous Coward]

The problem is simply that Java devs have focussed on bytecode portability throughout the years and totally forgotten about JVM portability. As a result, it's nigh-on impossible to port the JVM, and even once ported laboriously by an outfit like IBM or Blackdown, installation into environments that depart from the tested cases seems to be totally undefined and speculative.

In principle, the JVM could have been written in pure ANSI C with zero system dependencies that cannot be handled by autoconfiguration, and thus would have run truly everywhere. But sadly, that became impossible as soon as the designers decided to throw everything and the kitchen sink in there. We're shackled with the consequences of that now, and it can't change.

Wanted: Web-Based Visual Basic 6.0 IDE

[Tablizer]

What would really take off is a web-based version of VB 6.0 or Delphi. I don't mean the language, but the IDE. People want to drag and drop widgets onto the screen and then set attributes and fill in events by right-clicking and editing Property grids.

People are used to the VB way and generally liked it. Regardless of your impression of it, it is what the market wants. (Remember, VB targeted custom apps, not mass-produced boxed apps.)

And one would be able to add plugins as needed. In the web case, it would download them from the supplier. That way we could get edit grids and tree browsers etc. without waiting for each vendor to incorporate them into their web browser.

One complaint about the VB approach is that it did not allow window resizing for bigger monitors. However, for most screens this was not a problem. Custom apps usually don't have as many options as commercial apps. Further, it is possible to make "stretch zones" whereby coordinate gaps can open up so that designated widgets could fill the area. One does not have to completely abandon coordinate-based IDE's to get scaling.

Re:Wanted: Web-Based Visual Basic 6.0 IDE

[jma05]

> What would really take off is a web-based version of VB 6.0 or Delphi. I don't mean the language, but the IDE. People want to drag and drop widgets onto the screen and then set attributes and fill in events by right-clicking and editing Property grids.

Isn't that what .NET Web Forms / JSF is about?

Re:Java EE is *different* from AJAX, and vice-vers

[bwy]

Thanks man. I was beginning to wonder if anybody posting comments had ever even used both technologies. It is kind of like comparing a mixer to an oven or some such nonsense.

Just look at JSF, where some components use AJAX. JSF is certainly the web framework used in many J2EE applications.

Slashdot channels TheServerSide now

[nuzak]

Seriously, what a crappy platform-fanboy article. And JEE is hardly one to talk about interoperability: can you mix ADF, Tomahawk, Icefaces, and Ajax4JSF components? I could probably mix dojo and prototype faster than that -- at least they won't give me a several-hundred line NullPointerException traceback because the FwibbleManagerFactory requires initialization of the BoffwizComponentFactoryManagerFactoryConfiguration FactoryManager before the FrobnitViewInitializerFactoryManagerFactoryCompone ntManager but that only happens when "dontbreak=false" is set in Undocumented.xml (because when using those components, false is true).

I actually use JEE, and while it's great for stuff like declarative transaction demarcation (meanwhile roles are ok, but an awful primitive kludge), when you start mixing things, it's a bigger nightmare than any AJAX code. At least you can watch the HTTP traffic with Ajax.

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

[mark-t]

Actually, I simply pointed out that your response strongely seems to indicate that you _do_ want to argue, in spite of what you claimed, because if you didn't, you wouldn't keep posting to respond, as AC or otherwise. Your continued responses only seems to further demonstrate the point that I was addressing.

And just so you know, my objection isn't so much that you want to argue... I like to argue too. My objection is to your claim that you _don't_ want to argue when all evidence exists to the contrary.

And also note that this has nothing to do with Java, yet you somehow seem to want to connect what I said to it. So who's the one who's obsessed with the programming language, exactly?

(mod -1 troll)

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

[Raenex]

Normally I don't respond to Anonymous Cowards, because I don't like talking to shadows. It's also highly likely that one is wasting their time, since ACs can't get email about responses. If you want to be taken seriously, then post with an ID.

As to your argument, I haven't run into the extreme portability problems you have. Java mostly works ok on the platforms I use (Linux and Windows). Lord knows I've had just as much trouble with non-portable Perl code on Windows as I've had with Java across platforms. I'll take coding in Java over C any day.

Still missing the point...

[pathos]

People are still missing the point the article was trying to make (or haven't even read / understood it).

The situation is this:

* On one hand JEE describes a set of patterns and best practices Java web applications should be architected with

* Additionally, JEE also prescribes the implementation of these patterns JEE developers should use (Session Beans, Entity Beans, etc.)

The fact is that when developing JEE applications, on a technical level developers can choose to completely ignore some of these JCP technologies and implement the JEE patterns using perfectly fine, capable and even superior alternatives, such as Hibernate and Spring.

So the point the article's author was trying to make was that just as AJAX describes a set of patterns for developing web applications, while the developer chooses the implementation he prefers (JSON, DWR, frameworks such as Dojo, YUI, whatever...), JEE could benefit from "officially" allowing developers to freely choose whatever implementation of those patterns they saw fit (such as using Spring and Hibernate instead of the JCP-sanctioned Session Beans and Entity Beans respectively), instead of trying to force them to use the standard ones.

That's how he was comparing JEE and AJAX and how he was hoping things could be similar - nothing to do with comparing "apples and oranges".

Personally, I've been using Spring and Hibernate in my JEE projects instead of the official implementations for some time now, and seeing the advantages and innovations these have put on the table, I have agree with his point.

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

[Anonymous Coward]

Don't bother. He expends a lot of bits on hot-button words like "lies" and "worthless" but provides absolutely no specific examples. He's not even a very good troll, having overplayed the style with very little subtlety.

Real Java trolls exploit divisions by pointing out areas where the language actually sucks (of which there are many), not on vague but fiery polemics.

Re:UI Architect?

[MightyYar]

What's wrong with a UI architect? How else do you keep all of the coders disciplined? At my company, all changes to the UI have to be reviewed by the UI architect. I'd hate to see the result of an application written by many programmers if there is no one in charge of enforcing UI uniformity.

AJAX does NOT mean fragile code!

[Mock]

If this guy had even bothered to look online at what AJAX is today, he'd realize that there are frameworks such as Echo2 http://www.nextapp.com/platform/echo2/echo/ that make writing AJAX applications no more complicated than writing Swing apps.

AJAX is happening because there's nobody willing to take the lead in Web 2.0.

Once again why AJAX didn't need a name

[drew]

AJAX is not a techology, or even a group of technologies- The only thing all AJAX 'implementations' have in common is JavaScript, and that has been around forever. AJAX is at best a loosely defined conceptual approach to building a web site. At least the guy writing this article gets that. The guy he is responding to has a bit of a clue (although not too much, or he might have realized how absurd the statement that "Java needs to be more like AJAX" sounds), but this line almost made me laugh out loud: "The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients." But too often it seems that people try to refer to AJAX as though it is a specific technology. Even these two, who generally get the point, seem to present their statements in that light at times. I think that the poster above summed it up well when he said "Comparing Java and AJAX is like comparing apples and blue." The more I see people talk about it, the more it confirms my long held belief that the AJAX name was both invented and promoted by consultants who needed a new buzzword to make selling websites "cool" again.

And while this guy seems to generally know what he's talking about, I have to take exception to several items in his list of AJAX shortcomings.

- AJAX is hard.
Yes and no. Any new technology is hard when you are coming from a different background. How long does it take people to become proficient in working with a relational database (obviously a long time, as Java developers seem to have been working for years to try and sweep that particular detail further and further under the rug) How long does it take a client-server C++ developer to be good at even fairly basic web development tasks. If you have been working with AJAX for long enough that you have the right mindset, it's not that much harder than any other kind of software development. If you take a roomful of experienced web developers and expect them to be good at AJAX overnight, you're going to be about as disappointed as you would be if you took a room full of experienced VB developers and expect them to learn J2EE overnight.

- fragmented browser support
Again, yes and no. While the situation was really bad several years ago, when IE 6 was new, Mozilla was floundering, and JavaScript/DOM support in Opera was still in it's infancy, these days it is not so much of a problem any more. While there are a few differences in the event models between browsers, those are rather trivially surmounted (if you are willing to pretend that there is no such thing as event capturing, which depresses me slightly). For the last 2 years, almost every one of my browser specific issues has been CSS related, and while that is definitely a big problem, it is certainly not limited to AJAX.

- The difficulty of finding and hiring Ajax developers
He cites two different engineers as saying that about one in 40 engineers is qualified to learn AJAX. That in itself is not so much of a surprise to me as the expectation that it would be substantially higher. What percentage of engineers would be qualified to learn VHDL synthesis? Multithreaded client-server application design? Database administration? I suppose that if you are in the habit of hiring OOP programmer monkeys to fill in the blanks in your UML diagrams that number might seem absurdly low to you (I don't know if that's what the majority of Java programming jobs are, but that's certainly the impression that I've gotten from some of the places I've interviewed at) but I'd say that to find any 'engineer' in the computer field that's qualified to do any more than basic monkey work you're already looking at about one in ten. It's only going to get lower from there when you start adding specific skill sets.

- businesses can not afford it. They can not hire a team of experts to find workaround for dozens of serious problems browsers/JavaScript introduce
My business can. We have about 35 web

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

[LizardKing]

You have to remember that the only other language he's programmed in is Visual Basic.

This should be fixed in the clients.

[Ayanami Rei]

JavaScript _should_ be multithreaded in the browser.
The interpreter core appears to allow for threadsafe contexts (last time I checked out Spidermonkey) but what hasn't happened is someone creating a wrapper/hook around pthreads (or whatever) to allow for spawning new contexts and syncronization between threads.

I really think this needs to happen very soon. It's already a pain working around the blocking nature of event handling in the current implementations of JS.

Re:This should be fixed in the clients.

[PastaLover]

What someone should really do is make the renderer run in its own thread instead of letting it lock up the entire browser UI, including all tabs, options and buttons, for several seconds. (e.g. Firefox)

That's funny.

[Ayanami Rei]

I never knew there was a requirement for Ajax to interface with J2EE on the server!

And here I am using Perl and Ruby like an idiot.

Re:UI Architect?

[isolationism]

Why would anything be wrong with a UI architect? It's the position I more-or-less created for myself where I work and I do more or less what you describe (and a number of other jobs, besides). I just don't have a lot of experience with AJAX and nearly none with Java.

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

[GigsVT]

Just a few minutes ago, Firefox crashed on my Linux box. I had noticed something was slowing things down. Anyway I run top, and what do I see... java_vm 99.9% CPU, with a few CPU hours tacked on it.

I wish I could say that was an isolated incident, but it isn't. It happens all the time.

Marker

[jasenj1]

Really just a comment to mark the article so I can find it later.

But while I'm at it, in case anyone ever bothers to read this...

I agree with those that say the question/argument is complete nonsense. Ajax is a display layer technology. J2EE is a giant stack of server side stuff and some display layer stuff. To use MVC: Ajax is all V, J2EE is MVC. Now, would it be spiffy to have some "standard" Ajax framework to interact with J2EE apps? Sure.

- Jasen.

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

[durdur]

> the designers decided to throw everything and the kitchen sink in there
You mean, like a JIT compiler? The one thing that makes Java perform acceptably well, and is necessarily system dependent? Or maybe the Java libraries, without which the language is useless, and which also necessarily have system dependent parts..

The JVM is not just an application - it is a mediator between the OS and the virtualized API Java apps see, so the bottom layers have to be ported and cannot be generic.