Discussions

General J2EE: How many of you actual require portability?

  1. How many of you actual require portability? (11 messages)

    You know, I get sick and tired when everyone talks about J2EE being so portable. Yes, if you more-or-less stick to one vendor that can support multiple platforms that you assume you might port to and that they don't go bankrupt (my advise: Choose your vendors wisely).

    Also, 94% of the computing industry worldwide, never had or never will port their software offerings. The costs are very high and vendor J2EE support slightly differs from one platform to another, from a performance to configuration standpoint.

    It’s good to know that if portability is required that J2EE has an upper hand vs .NET, at least thus far.

    So, my question to you is: How many have you ever ported a really large J2EE system (no Micky Mouse projects please)? And how many have you done it without any hitches? Be honest please, the whole world is listening.

    Long live J2EE (.NOT) ;D
  2. I think you are right that companies rarely needing (or wanting) to port applications from one environment to another, but there is a hidden benefit to standards-based, portable applications: backwards compatibility. If you are using a proprietary system (or a proprietary feature of a standards-based system), you are pretty much at the mercy of the vendor for whether or not that feature will be available in the future.

    I know of several organizations that are stuck using NT 4 because their software simply won't run on more modern versions of the Windows operating system. Microsoft simply changed the APIs from one version to the next, and some things don't work anymore. This means these companies are stuck with antiquated systems that they can't really do anything with.

    If, on the other hand, you go with a standards-based server environment (e.g. J2EE), it is much more likely that those features will still function when the next version of the server comes out. Therefore, migrations to new versions of the server from the same vendor go much more smoothly.

    This is the real benefit of portability, IMHO.
  3. Paul,

    I have to totally agree with your point. You're absolutely right. I believe this why MS is moving towards a VM type solution that has proven it self to be successful in an ever changing technological imperfect world. The DoD still uses Ada and favors J2EE for that very reason.

    Ross
  4. Actual Paul,

    I recall a time when porting from JAVA 1.0 to 1.3, there were a number of obsolete methods and there were other issues (I can't recall them). But for the most part, I still agree this model and your opinion.

    RP
  5. Never ported

    But I can develop (and I do) for variety of platforms: Resin, IBM WebSphere, Oracle9i, JBoss utilizing the same knowlege.
  6. Never ported


    I’m glad you’re honest :)

    >But I can develop (and I do) for variety of platforms: Resin, IBM WebSphere, Oracle9i, >JBoss utilize the same knowledge.

    Granted. However, In terms a performance and configuration standpoint, I recall our development team going through hell trying to get our system to insure that it worked for both WebSphere and WebLogic without lost of performance. We were budgeted $50,000 just for the development piece along. At the time we thought this was more than enough, considering that “Portability” shouldn’t have been an issue.

    So, to make a long story short, we at some point decided to hire a consulting company with a lot of experience. For the most part, I believe l0% or less was devoted to code rewrite to make WebLogic at least meet our performance numbers and the reset was configuration issues. Our final cost to get this all going and working was $100,000+.

    What I’m trying to say is that its not so clear cut as many people believe it to be.
  7. Portability isn't just about applications, it's about people. Using a standards based technology increases:
    - the likelihood that others will be *able* to maintain (or understand and replace) a system.
    - the likelihood that *enough* of such people can be found and employed.

    Skills portability, in other words.
  8. Ian,

    >Portability isn't just about applications, it's about people. Using a standards based >technology increases:
    >- the likelihood that others will be *able* to maintain (or understand and replace) a >system.
    >- the likelihood that *enough* of such people can be found and employed.

    I really don't buy that argument. Technology is not constant but forever quickly changing. Granted that JAVA will be around for a very long time but it will, one day be superceded as well as .NET with new and evolving technologies. This is what happened to COBOL in the mid 70’s and its slowing happening to C/C++. Legacy systems will still be around, however, support for such systems are slowly dwindling -- from a people to hard/software point of view.

    >Skills portability, in other words.

    What you’re saying is true for most technologies not just JAVA.

    RP
  9. Portability, J2EE[ Go to top ]

    In "J2EE Design and Development", Rod Johnson writes:

    {{

    There are several issues around the portability of J2EE applications:

    Portability of applications between application servers [...]

    Portability of applications between operating systems [...]

    The ability to change important resources that J2EE applications
    rely on [...]

    I feel that far to much emphasis is placed on database portability,
    in particular. [...]

    Portability between application servers, on the other hand,
    is more easily achievable and may deliver greater business value.

    [...]

    We must distinguish between implementation portability ("this
    code runs without change on any application server") and design
    portability ("this application will work correctly and efficiently
    on any application server, if a small number of clearly identified
    interfaces are re-implemented"). Total implementation portability
    can be achieved in J2EE, but may not be a realistic or even a worthwhile
    outcome. Design portability is achievable, and delivers most of the business
    value of portability. [...]


    }}
  10. Portability, J2EE[ Go to top ]

    If only we all lived a a perfect world.

    <quote>
    We must distinguish between implementation portability ("this
    code runs without change on any application server") and design
    portability ("this application will work correctly and efficiently
    on any application server, if a small number of clearly identified
    interfaces are re-implemented"). Total implementation portability
    can be achieved in J2EE, but may not be a realistic or even a worthwhile
    outcome. Design portability is achievable, and delivers most of the business
    value of portability. [...]
    </quote>

    I agree with Rod Johnson statement. However, read between the lines.

    >Total implementation portability *can* be achieved in J2EE, *but may not be a >realistic or even a worthwhile outcome*. Design portability is achievable, >and delivers most of the business value of portability.

    >if a small number of clearly identified interfaces are re-implemented then >portability can be achieved
    **** Like I said, choose your vendors wisely...

    The essence of my initial argument is that, realistically, portability in many respects, is far from being free and should be a design consideration from day one in any project that may require such capabilities. In other words, its not as easy as SUN or other J2EE avocates lead you to believe.

    So, have you ever ported and really large J2EE app?

    RP
  11. Porting[ Go to top ]


    > So, have you ever ported and really large J2EE app?
    >

    I ported applications from Websphere 3.5 to Websphere 4.0

    Does that count?

    The code did not require many changes at all. The JSP's had
    to be tweaked.
  12. Portability does matter - especially to those who develop products that can be used by different customers in-house. I do that and believe me, there is a need for us to deploy our application on different application servers. currently we have tested (or are in the process of) our application on WebLogic, Sun One, Web Spere and Pramati. My experience was sticking to standards helped us to it without any major pain.

    We used WebLogic as our development and first platform for the application and that caused us some of the headaches (listed below) and otherwise I am glad we used the J2EE platform (especially when most of the corporates are still using non-MS technologies/platforms for enterprise deployments)
    Problems caused because of WebLogic:
        1. Looks like when JSPs are compiled into Servlets, Weblogic adds java.util.* and java.io.* imports. Thus when we tested application on other app servers, JSP Compilation errors were thrown.

        2. Also WebLogic acts smart and uses a utility to print the values in generated Servlets. Thus in many cases, if the object was NULL, weblogic printed "". When ported to other application servers, null was printed. This was painful because we had to fix many JSPs. Thank you WEBLOGIC for being extra smart!

    Point being, Portability does matter (at least to few out there), at least till MS starts to dominate the enterprise server development and we don't have to worry about different Operating Systems or Application Servers.