Bloomberg Anywhere Remote Login Bloomberg Terminal Demo Request


Connecting decision makers to a dynamic network of information, people and ideas, Bloomberg quickly and accurately delivers business and financial information, news and insight around the world.


Financial Products

Enterprise Products


Customer Support

  • Americas

    +1 212 318 2000

  • Europe, Middle East, & Africa

    +44 20 7330 7500

  • Asia Pacific

    +65 6212 1000


Industry Products

Media Services

Follow Us

Bloomberg Customers

Businessweek Archives

And another thing..... about Java

? Haiku Contest: It's time for a vote |


| Bubbasoft? Puh-leeeze ?

January 06, 2006

And another thing..... about Java

Steve Hamm

Man, did I step in a sinkhole when I published a story about Java on the BW Online Tech Channel a few weeks back. A lot of commentators called me stupid, and worse, for saying that Java has lost momentum recently compared to Microsoft's .Net and some other programming tools and toolsets--including AJAX. I'm no programmer, and I chose to simplify some of my descriptions of technologies so I would not leave many readers behind. That seemed to outrage some people. I have been gratified since then to talk to CTO-types and be assured that I'm not an idiot, after all.

One point that several of my critics made was that I obviously didn't understand what I was talking about since I asserted that somebody might use AJAX as an alternative to Java. People also said AJAX isn't used in enterprise computing--just in the Web 2.0 Zone. Well, people do use AJAX as an alternative to Java, and they do use AJAX in enteprise applications. A case in point is GridApp Systems, a three-year-old New York software company that sells an application for managing large numbers of corporate databases.

GridApp, begun in 2002, built its application, Clarity, to run on an open-source stack of software including Linux, the Apache Web server, the Postgres database, and the PHP scripting language. No Java involved. "It's not really cross platform," explains Chief Scientist Matthew Zito. GridApp first used AJAX to perform some of the basic technology plumbing in its application, which runs on a server and is viewed via a browser.

Then it considered using the Java programming language to build a client piece of its application that would be downloaded from the Internet to a users' PC. The reason it considered this was that its application had some rough edges. Database administrators looked at static Web pages full of information about their databases, and, every 15 seconds or so, the pages would refresh--going blank for a second--and then re-appear with updated information. Not optimal. GridApp ultimately decided against writing a Java client and instead used AJAX to solve the problem. Using the AJAX toolkit, it modified its application so that data is updated real-time without having to refresh entire Web pages. The new version of Clarity is in beta-test mode now and is coming out in commercial release in February.

Says Zito: "Sure there will be applications that Java and J2EE makes sense for. But it's very complicated, there's a soup of different Java standards. I'd be hard pressed to think of a situation where I'd want to build an enterprise Web application with Java. It's like swatting a fly with a two-by-four. I want the technology stack that lets me build the highest quality code with the least amount of effort and the fewest people, and that's going to generate the highest customer satisfaction."

And this just in: I just found out that MySpace, the mega-kid-community Web site, with 47 million regular users, is switching tools. It has outgrown ColdFusion and is switching, not to Java/J2EE, but to .NET.

Enough said?

02:45 PM


TrackBack URL for this entry:

What's the point of comparing them? AJAX predominately addresses needs in the presentation space, while JAVA covers a much larger portion of the software space including the presentation space. That doesn't make JAVA better or worse; it makes it different. There will never be a silver bullet language to replace all past languages. They all have their trade-offs.

Posted by: Barry Baker at January 6, 2006 07:09 PM

What are you trying to prove here? Are you just out to bash Java/J2EE? Why? Do you understand what it is? Do you understand what AJAX is? Do you realize that many J2EE apps actually use AJAX on the presentation layer? Maybe you can learn a few things here:

Do you know what MVC is, and that "V" is just one part of MVC? Do you understand the concept of "degrading gracefully", and that because of this concept, you cannot make frontends as a whole actually rely on AJAX? This is a stupid rant, and it really seems that you do not understand the technologies you mention for one bit. Do you know what the exact motivations were to choose .NET over J2EE at MySpace? I'm suspecting you do not. Maybe run your articles by some actual software engineers the next time you publish something like this, because it makes you look like an idiot.

Posted by: Leendert Brouwer at January 7, 2006 07:12 AM

This isn't worth commenting on but for the fact there might be some "CTO-types" who are reading this and getting confused.

AJAX is HTML and Javascript getting data (usually in XML) from the server to change the view dynamically. It may be able to replace some Java client applications (but there aren't too many of those out there). It is not a replacement for server side Java (including J2EE).

Sever side technologies that you could compare include .NET, Ruby on Rails, LAMP, and of course Java to name a few. They each have their pros and cons and it is quite possible to mix them in an application stack. So without a particular application in mind, it is quite useless to say one is better than the other.

Posted by: Sean Timm at January 8, 2006 08:23 AM

Sean Timm..could you give table of overview(comparison/use/pros/cons/function) for "They each have their pros and cons and it is quite possible to mix them in an application stack. So without a particular application in mind, it is quite useless to say one is better than the other."

Posted by: Lana Karl at January 8, 2006 11:08 PM

Here is an excellent article on the future of Java:

I'll briefly address Lana's question. Not everyone will agree with my opinions, but here they are. .NET is a good match for a pure Microsoft shop. Others probably want to stay away to avoid vendor lock in. Ruby on Rails is great for smaller and simpler websites backed by a database. It is hailed for extremely rapid development. LAMP is good for the same space as Ruby on Rails--though Yahoo! certainly has applied it to complex websites. Java is good for complex high traffic websites (e.g., numerous banking sites, AOL Search, and EBay use Java to name a few). Personally I would stay away from EJB and stick with lightweight frameworks such as Spring and Hibernate.

Posted by: Sean Timm at January 10, 2006 10:53 PM

I think an important thing to emphasize here is that an application that uses AJAX on the front-end could still be using Java as its server-side component. The two are not mutually exclusive. So, when GridApp chose to use AJAX as an alternative to a Java rich-client app, they could have also chosen to use Java as the server-side app as well.

Further, I would be willing to bet the reason MySpace went from ColdFusion to .NET is b/c they had already invested in tons of Microsoft tools/OS/etc. ColdFusion, while available I believe in more than just the Windows platform, is still best run on Windows.

Posted by: Paul at January 11, 2006 10:12 AM

My experience with Coldfusion is a the ability to write applications that can run on a J2EE (MX7, BlueDragon) or .NET(BlueDragon only)application server . Coldfusion integrates with native Java or .NET code for high transaction items that are better suited for those languages. Just to add about MySpace, I was at a conference a couple of months back the founder of MySpace stated that they moved from aColdfusion Server to Bluedragon running on a .Net server with very minimal code rewrite. The same thing could have been true to move to MX7 or Bluedragon on a J2EE server.

Coldfusion has a long history with the FLIP methodology and the Fusebox framework (used by PHP, JSP, ASP developers alike). Using these tools to develop a Coldfusion application negates the arguments that since Coldfusion is such a rapid development tool that it has no structure and can not be easily maintained. There is not today or will there ever be a language that can keep a developer from created bad code.

Posted by: Dion at January 12, 2006 01:18 PM

'Vendor lock-in' is a red herring.

No sane organization is going to invest in a big enterprise application with Oracle tools, and then switch to IBM.

Once the infrastructure is up and running, you

are de facto 'locked in'.

Posted by: Ron at January 13, 2006 06:42 PM

Vendor lock-in as you describe it is a myth. Environments always change, and you need to port your applications to new platforms/app-servers. (In our organization we've done it twice and about to do it for the third time because some business people got a good offer on another app-server which would cut our costs "in the long run" .. pfft ;) )

Posted by: Soren at April 16, 2006 02:03 AM

Right, MySpace did make the move to .NET, notice the lack of reliability on many of MySpace's features? I just got paid to recode a large section of the MySpace site in Java 5 - Tomcat 6 - Wicket - Hibernate 3.2

MySpace is investing on prototyping alternative technologies OTHER than .NET because of a wide variety of problems (#1, reliability) with .NET on such a large scale.

Posted by: Jim at January 5, 2007 06:08 AM

blog comments powered by Disqus