Slashdot Mirror

← Back to Stories (view on slashdot.org)

Does J2EE Live Up To Its Promise?

Posted by Cliff on from the don't-believe-da-hype dept.

Rayooz asks: "With all the hype around the J2EE specification, I'm wondering if it truly lives up to its promise of "server independence" in the real world. Has anyone had experience developing/deploying a J2EE application on one application server and then moving it to another server without any modification?"

2 of 18 comments (clear)

  1. In some ways... by Orville · · Score: 3
    You need to be careful of how you address "hype" I suppose.

    When Sun released the J2EE along with all of the various specifications (i.e. the EJB spec), it was largely left up to the vendors as to *how* those specifications were met.

    Business code is largely portable across vendor products, as long as you follow the specifications yourself. That is, keep your naming standards consistent with Java RMI, etc. I have seen a lot of cases where a developer tried to be "clever" and screwed themselves in the end. Good design saves the day.

    Vendor-specific protocols are typically implemented during deployments, etc. For example, the Inprise Application Server has an Inprise-Specific XML descriptor file that specifies the JNDI names for object naming. Not a big deal, but a slight headache nonetheless.

    If you choose the same application server across different platforms (ex. IAS running on NT, Linux, and Solaris), you should have no problems with code portability whatsoever. (Again, as long as you avoid platform-specific bugaboos)

    In the end, here's the deal: Do not jump into writing server systems in Java if platform independence is your only goal. Use Java if you are willing to invest the time in designing and developing a clean, object-oriented middle tier that is understandable and flexible. If you can accomplish this, platform independence is a great secondary feature. Java also contains many features that are great for quickly developing complicated systems. (Java Network Programming *rocks*)

    If you just want to slap code together and gripe when it doesn't deploy on FooBar app server, just give up and start writing your whole transactional system in Python. Enjoy maintaining *that* system for a few years....

  2. Java Network Programming *almost* rocks... by jfrisby · · Score: 3

    (Java Network Programming *rocks*)

    Not quite. With things like CORBA and RMI, it's very good. But if you're talking sockets there are some serious problems.

    Fundamentally, Java I/O is very limited -- and intentionally so -- by the need for 2 threads to handle bi-directional communication. This is of course because of a lack of asynchronous I/O support. Add the lack of support for multiplexing I/O and you're basically screwed.

    Just *try* writing a server in Java that can handle 100,000 simultaneous connections. 200,000 threads is going to break pretty much any server. Yeah, you can resort to clustering and have your servers communicate but that adds a *lot* of complexity in some instances.

    A chat server with featues like rooms and private messages and all those goodies that can handle tens of thousands of simultaneous connections on a single machine would be relatively simple to write if one had multiplexing and asynchronous I/O. But without it you have to add your clustering system and implement things like message routing/forwarding and all other sorts of ickiness.

    But for simpler stuff, Java makes network programming VERY simple and straight-forward unlike other languages -- and that's a VERY good thing.

    -JF

    --
    MrJoy.com -- Because coding is FUN!