Discussions

News: Whatever happened to building portable J2EE applications?

Bookmark and Share Get thread feed

  1. Whatever happened to building portable J2EE applications? (121 messages)

    A new article on SDTimes takes an extreme interpretation of new proprietary offerings from BEA, Oracle and IBM, claiming that these non-standard frameworks/extensions are proof that the promise of J2EE portability is false and that "No one has ever really believed in the "write once, run anywhere" credo.

    read more: http://www.sdtimes.com/news/045/story1.htm.
    Reply to this

    Threaded Messages (121)

  2. Whatever happened to building portable J2EE applications?[ Go to top ]

    I thought that 'cooperate on standards, compete on implementation' was always one of the points of J2EE. Vendors have always been providing value ads on top of the standards, and so what if BEA is creating a simpler tool for server side development. That doesn't mean that the Java promise is dead.

    The year 2001 saw dozens of frameworks and products emerge that can run on any J2EE compliant application server, a notable one being from Silverstream, which supports other application servers as well as its own.

    The promise of J2EE portability became realized in 2001 and will become even more obvious in 2002. Products like Cajun from BEA won't retract from this promise. As I understand it, Cajun is a product for people who like to use Visual Basic style development environments, who wouldn't program J2EE anyway.

    Floyd
    Reply to this Reply to original

  3. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Recent decisions by major J2EE app server vendors to extend J2EE in proprietary directions has made official what has been known for a long time—the promise of Java is now dead."

    HA! Dream on. What a dumb article. With every standard, you always have companies "extending" it but no one with a brain uses it unless they absolutely have to. Everything I do is 100% portable.

    How ignorant.
    Reply to this Reply to original

  4. Whatever happened to building portable J2EE applications?[ Go to top ]

    It's interesting to see that this "Zachmann" guy shows how completely ignorant he is of the whole Java world, and the way things work here. His astonishment of how something can be standard yet have competitive companies delivering products around it is amazing. I wonder if he has ever driven a car and thought about how nice it is that he doesn't have to wonder where to find the steering wheel. Open standardized API's, but proprietary engines. Seems kinds natural, doesn't it?

    Also, the comment "Java has to start delivering on the promises if it wants to succeed" makes me wonder if this is really -97 and I'm in a time warp kind of thing. Or is he?

    /Rickard

    Reply to this Reply to original

  5. Whatever happened to building portable J2EE applications?[ Go to top ]

    Lol, exactly. That was my point that he must be living in about 1997 when it truly wasn't portable. He's probably some pro-M$ bigot.
    Reply to this Reply to original

  6. Whatever happened to building portable J2EE applications?[ Go to top ]

    As opposed to an anti-M$ bigot?

    He could just be a knucklehead.

    What's the big deal anyway? If the spect says do A, B, and C and you'll get D and the vendor software does indeed get you C from A, and B good enough, right?

    If some vendor says you can also do AA, BB and get C but AA and BB are faster better whatever I say more power to them.
    Reply to this Reply to original

  7. Whatever happened to building portable J2EE applications?[ Go to top ]

    "What's the big deal anyway? If the spect says do A, B, and C and you'll get D and the vendor software does indeed get you C from A, and B good enough, right? "

    No, that's not right. You wind up with 100 different technologies and everything that goes with support that. No, one vision, one technology: Java.

    "If some vendor says you can also do AA, BB and get C but AA and BB are faster better whatever I say more power to them. "

    Think about it a bit more, spend a few more years in it then come back and join the thread.

    Reply to this Reply to original

  8. Whatever happened to building portable J2EE applications?[ Go to top ]

    "No, that's not right. You wind up with 100 different technologies and everything that goes with support that. No, one vision, one technology: Java. "

    You have 1 technology(spec) with maybe 100 special extras. If all you care about is one vision one technology then you will get the LCD. All businesses that I have developed for care more about a solution that works well and that is not costly. They couldn't care less about one vision, one technology.

    I've been doing this long enough to know(13 years) that in a few years J2EE will be vastly different than it is today if it's around at all.

    Remember CORBA - it's based on a spec. How many people care today?

    Poke your head out of the ivory tower occasionally and see what the real world is up to.
    Reply to this Reply to original

  9. Whatever happened to building portable J2EE applications?[ Go to top ]

    ". All businesses that I have developed for care more about a solution that works well and that is not costly"

    Right, and that is Java technology at this time in our industry.

    "Poke your head out of the ivory tower occasionally and see what the real world is up to. "

    I won't give you the reply I "really" want to give you to that statement.

    Reply to this Reply to original

  10. Whatever happened to building portable J2EE applications?[ Go to top ]

    "The actual ability to take a complex application from one J2EE application server vendor’s product to another is just not happening.” - Will Zachmann

    The guy just doesnt know what hes talking about. its absolutely laughable. just pass it off guys.

    We are developing a "complex" bank application. already put tons of code. and still not very sure on the application server we are gonna use. do u need any more proof, that the guy is talking crap. we r still evaluating various application servers and while evaluating we deploy or code without a change.

    i agree that app server vendor are bringing in their specific frameworks/infrastructure, but as someone rightly mentioned above whos gonna use that.

    it can be passed on as one of those M$ campaign at WORA (write once....)

    i m hearing it for the n'th time. getting so monotonous. need something new M$.....
    Reply to this Reply to original

  11. What are you advocating[ Go to top ]

    Sartoris:

    I'm sorry, I would just like to clarify what you just said:

    <Sartoris>
    All businesses that I have developed for care more about a solution that works well and that is not costly. They couldn't care less about one vision, one technology.
    </Satoris>

    <Me>
      Maybe I'm wrong, but are you saying that out of all the companies you worked for in the last 13 years as an IT professional, not a single one cared about adhering to some kind of standard??? Please give me the names of the companies -- they will be needing help the next time they want to upgrade or change their architecture to respond to their successful business models( because they ARE successful, right? ), and I get a finder's fee for referring big-time clients to this company I know of. Also, when you say "..works well..", aren't you really saying "works well at the moment" as opposed to "is a robust, scalable, and flexible system that also works well"? Methinks that you need to revisit the progress that this industry has made in the last 10 years with regards to having the wisdom to understand the crucial importance of standards.
    </Me>

    <Sartoris>
    I've been doing this long enough to know(13 years) that in a few years J2EE will be vastly different than it is today if it's around at all.
    </Sartoris>

    <Me>
      I certainly respect your experience Sartoris, but many of the lessons you learned in the past do not apply to today's business environment. In order to be able to properly predict your vision of the destruction of J2EE, you will need to have worked in companies which have dealt with this technology since the beginning and have followed the standard for better or for worse. Not to be antagonizing, but do you think that maybe your first statement is telling us that you do not have a lot of experience in following the J2EE standard? Or if you do, do you really understand why you are doing this( ie. put the technical reasons aside -- do you appreciate the importance of the J2EE standard from a non-technical point of view ).
    </Me>

    Thanx,


    Reply to this Reply to original

  12. What are you advocating[ Go to top ]

    <You>
    Maybe I'm wrong, but are you saying that out of all the companies you worked for in the last 13 years as an IT professional, not a single one cared about adhering to some kind of standard???
    </You>

    Did I write that? I was referring to the mythical One Vision, One Technology nonsense uttered above.

    <You>
    Please give me the names of the companies -- they will be needing help the next time they want to upgrade or change their architecture to respond to their successful business models( because they ARE successful, right? ), and I get a finder's fee for referring big-time clients to this company I know of.
    </You>

    <Me>
    So you write business applications that are tightly bound to an architecture? And when that architecture becomes obsolete, as it surely will, the applications need to be totally rewritten? Not a smart move.

    I'll give you a couple of clients names - Citigroup, PGA Tour - knock yourself out!
    </Me>

    </You>
    Also, when you say "..works well..", aren't you really saying "works well at the moment" as opposed to "is a robust, scalable, and flexible system that also works well"?
    </You>

    </Me>
    robust, scalable, and flexible system is part of the definition of "works well".
    </Me>

    <You>
      I certainly respect your experience Sartoris, but many of the lessons you learned in the past do not apply to today's business environment.
    </You>

    <Me>
    On the contrary. Today's business environment is like yeterday's where ROI is king. If adhering to some standard costs a lot more a client may choose to ignore the standard.
    </Me>

    <You>
    In order to be able to properly predict your vision of the destruction of J2EE, you will need to have worked in companies which have dealt with this technology since the beginning and have followed the standard for better or for worse.
    </You>

    <Me>
    You can't ignore history. J2EE is good. Today. If in 2 years J2EE is much like it is today then it will be not so good. EJB in 2 years will look nothing like it does today.
    </Me>

    <You>
    Not to be antagonizing, but do you think that maybe your first statement is telling us that you do not have a lot of experience in following the J2EE standard? Or if you do, do you really understand why you are doing this( ie. put the technical reasons aside -- do you appreciate the importance of the J2EE standard from a non-technical point of view ).
    <You>

    <Me>
    The J2EE standard is a moving target. J2EE is not that old. How much experience does anyone have? NewsFlash: J2EE is a marketing tag. Period. How much experience do you have with Message Driven Beans? Not much. MDBs are part of J2EE now. So we are all disqualified from disussing it(J2EE) because of lack of experience.

    I do appreciate what J2EE is about and for the most part it is a worthy goal to stick to it. But, it is unrealistic to say everything not J2EE is bad. I also realize that the real intent is to make money for Sun. That's not a bad thing either but that's the truth.
    </Me>
    Reply to this Reply to original

  13. What are you advocating[ Go to top ]

    <you>
      Did I write that? I was referring to the mythical One Vision, One Technology nonsense uttered above.
    </you>

    <me>

    All businesses that I have developed for care more about a solution that works well and that is not costly. They couldn't care less about one vision, one technology.


    Reply to this Reply to original

  14. What are you advocating[ Go to top ]

    <you>
      Did I write that? I was referring to the mythical One Vision, One Technology nonsense uttered above.
    </you>

    <me>
      Yes, you did. You say that you have been working as a developer for 13 years, and then you say that ".. All businesses that I have developed for care more about a solution that works well and that is not costly. They couldn't care less about one vision, one technology...". Did you really mean that some of your employers cared about standards and that some didn't?
    </me>

    <you>
    On the contrary. Today's business environment is like yeterday's where ROI is king. If adhering to some standard costs a lot more a client may choose to ignore the standard.
    </you>
     
    <Me>
      This comment is now inviting an endless subjective argument, because you used the words 'may choose' this time. Originally, I took your statement to mean that ALL clients should ignore the standard because you claimed that none of your past employers cared about this, you trashed CORBA, predicted the demise of J2EE, and created a picture of a J2EE idealist as being in a perfect world. Thank you for the clarification.
    </Me>

    <You>
    So you write business applications that are tightly bound to an architecture? And when that architecture becomes obsolete, as it surely will, the applications need to be totally rewritten? Not a smart move.
    </You>

    <Me>
      This is actually a very intelligent point that I think makes for good conversation. If J2EE becomes obselete as you seem to think it will, then writing J2EE apps based on J2EE architecture will indeed seem foolish. However, the only alternative is to believe that no standard WILL EVER last forever and therefore everything should be proprietary. My money's on J2EE not because it is perfect, but because ( and this is something you may not agree with ) the alternative is much worse. The more we support J2EE, the better chance we have of not making it obsolete. You yourself mention how it is a very recent revelation -- why not give it more of a chance instead of giving up on it so soon? If you have a problem with some of SUN's objectives, there are many community processes you can join to have your voice be heard.
    </Me>

    PS: Thank you for the names I asked for.. touche! :-)

    Reply to this Reply to original

  15. What are you advocating[ Go to top ]

    My original statement Copy-Pasted from above:

    "All businesses that I have developed for care more about a solution that works well and that is not costly. They couldn't care less about one vision, one technology."

    It's the "one vision, one technology" thing I was speaking to.

    I did not make the statement about standards.

    There are many standards(and "defacto standards) and specs that have been a great boon to software development: XML, SQL, ODBC, IIOP, TCP, IP, Berkley Sockets, COM, etc.
    Maybe I'm old, cynical, bitter, naive, stupid but J2EE seems to reach too broadly and too high. Parts of the standard must evolve in a short timespan to be useful in just a couple of years.

    I love(d) CORBA. I wish it had more success. But it is an example of a technology that is a standard that has not lasted long (barring a reemergence). Maybe it's aim was too high, too. Or maybe I'm doing a little apple-and-orange comparision.

    As to tight binding to an architecture; I have this argument with fellow developers all the time. It is my belief that business workflow and business objects should be usable regardless of the middleware. If I put my business logic in a Session Bean, e.g., I just coupled myself with what really amounts to a product. Even if that product is based on some standard. I assume, because of history, that the product will soon become obsolete but my business objects and workflow will stay the same for a long time.

    I do predict the demise of J2EE as it is today. There may exist a J2EE 5 years from now but it will be vastly different than it is today.

    Today's J2EE provides a fantastic platform. By all means use it. I do with no regrets. But I don't write code that tightly couples myself with J2EEs idioms. For example, I feel safe in tying code tighlty to SQL in many areas but not to EJBs.

    I really think that we are better served by having a J2EE and a .NET. The competition will make them both better.
    Reply to this Reply to original

  16. What are you advocating[ Go to top ]

    If you believe that J2EE will be the "one true solution" that will dominate big-company server-side IT then you are advocating that in business terms "Java is the next Cobol".

    Personally, if this were to become true, I think it would be no bad thing. But understand that nature embraces change, human nature being no exception. One day, perhaps in 10 years time people will come to abhore Java much as they do Cobol today. Let's just hope we're not in love with .NET :-)

    john
    Reply to this Reply to original

  17. What are you advocating[ Go to top ]

    "Let's just hope we're not in love with .NET :-) "

    Lol, exactly.

    As I said on another thread, alot of the hype about .net was web services, and everyone is going to Java for web services according to a poll I saw. cya
    Reply to this Reply to original

  18. Whatever happened to building portable J2EE applications?[ Go to top ]

    Sartoris- "Remember CORBA - it's based on a spec. How many people care today?"

    Smells like Microsoft...but you get extra points for the Faulkner pun.
    Reply to this Reply to original

  19. Whatever happened to building portable J2EE applications?[ Go to top ]

    Here's one story on how my project (for one of the major credit card companies) capitalized on the J2EE standard:

    Project was a small online enrollment application for member banks to gain access to our secured extranet. Once the requirements were completed, there were many discussions regarding the platform on which to run the application. Debate was around Win2K vs. Solaris. Manager asked me my opinion, and I comfortably said - "From a development standpoint, it's not that important to me." That statement threw him back and I had to pick up his jaw.

    To make a long story short, it took about 6 weeks for them to decide the OS. Gladly, we finished up coding in about the same time. And oddly enough, we then picked the application server to run it under.

    I could safely defer this decision since we closely adhered to the JSP, Servlet, and JDBC spec. We knew exactly where the boundaries were and decided to avoid them. We successfully finished up the development with a week of integration esting on the chosen app server and deployed to Production.






    Reply to this Reply to original

  20. Whatever happened to building portable J2EE applications?[ Go to top ]

    What a great example of J2EE standardization.
    Reply to this Reply to original

  21. Whatever happened to building portable J2EE applications?[ Go to top ]

    Faulkner is great!

    WRT M$. There is a large and ever growing market for small to medium sized apps. You can't tell me it's not cheaper to build the same deliverables using M$. Even "old" pre .NET tools. Do you think that Joe's Auto Salvage cares abot some standard?

    The anti M$ world cracks me up.

    Reply to this Reply to original

  22. Whatever happened to building portable J2EE applications?[ Go to top ]

    <quote>
    WRT M$. There is a large and ever growing market for small to medium sized apps. You can't tell me it's not cheaper to build the same deliverables using M$. Even "old" pre .NET tools. Do you think that Joe's Auto Salvage cares abot some standard?

    The anti M$ world cracks me up.
    <quote>

    Sartoris, can we have hard $ numbers to back up your claim that an M$ stack would be cheaper to implement? Care to calculate the cost of your bare bones Windows 2000 system with 500 concurrent Internet users? Not XP of course because XP has more holes than swiss cheese. We have to wait 10 years for that to stabalize first. Ok, we're developers, we're patient, we'll wait :-). How about some hard numbers showing IIS and .NET performs better than Resin/Orion/JBoss on comparable hardware? I didn't think so. We're still waitng...
    Reply to this Reply to original

  23. Whatever happened to building portable J2EE applications?[ Go to top ]

    At the risk of repeating the threads elsewhere on this site |-O ... take a look at:

    http://www.tpc.org

    This has lots of real data to back up the claims made by Sartoris. Perhaps an open-source group should submit some entries to prove the the transaction per $ quality - not to mention _any_ J2EE entries to back up the grandiose claims.
    Reply to this Reply to original

  24. Whatever happened to building portable J2EE applications?[ Go to top ]

    Went to TPC website.

    In regards to:

    This has lots of real data to back up the claims made by Sartoris. Perhaps an open-source group should submit some entries to prove the the transaction per $ quality - not to mention _any_ J2EE entries to back up the grandiose claims

    I looked at transaction results based on clustered vs. non-clustered servers. When viewing all results Microsoft seems to work better that Sun environment. However I do believe that is misleading because when looking at this it is a clustered solution. When checking the results for non-clustered MS was found to be lacking. 498K transactions for Sun at non-clustered and 750k for MS clustered. MS in a non-clustered environment did not seem to perform well. If we do a hardware to hardware test in a clustered environment then we could extrapolate that the Sun environment running Java and a MS environment have significant performance ratings with Sun and Java coming out on top. I have done this type of analysis in the past and have seen 7,000 MS environments handling 1/4 the web traffic of the same solution with 400% improvement using 70 Unix boxes.

    Do the math for yourself and draw your own conclusions.
    Reply to this Reply to original

  25. Whatever happened to building portable J2EE applications?[ Go to top ]

    500 concurrent users? I clearly stated small to medium sized apps. Be real dude. Today's app servers are not well suited for that load either. We are talking big money for that type of system.

    Who said anything about XP? I have built and delivered systems using J2EE and M$ technology. Small, medium applications are cheaper to build on M$ because:

    - IIS is free, MTS is free, ASP developers are cheap, VB developers are cheap, (C++ developers are not cheap), the tools are very good. A monkey can administer IIS and MTS (even if an occasional reboot is needed ;-))

    - Tomcat/Apache/JBoss are all very good but are harder (read takes a more expensive person) to setup and administer, JSP and Java programmers are more expensive than ASP, VB programmers. The development tools are not nearly as good.

    "How about some hard numbers showing IIS and .NET performs better than Resin/Orion/JBoss on comparable hardware? I didn't think so. We're still waitng... "

    I searched my post for an argument about superior M$ performance and found nothing. So keep waiting.

    But since you brought it up I have no doubt that an MTS container with C++ components will outperform an EJB container by a wiiiiiiiiiiiiiiiiiiiide margin. If you are looking for pure performance than Java is the wrong way to go.
    Reply to this Reply to original

  26. Whatever happened to building portable J2EE applications?[ Go to top ]

    <QUOTE>
    500 concurrent users? I clearly stated small to medium sized apps. Be real dude. Today's app servers are not well suited for that load either. We are talking big money for that type of system.

    Who said anything about XP? I have built and delivered systems using J2EE and M$ technology. Small, medium applications are cheaper to build on M$ because:
    </QUOTE>

    This has been my experience as well. It is a shame that we cannot just pick the right tool for the job at hand and stop being so religious about technology.
    Reply to this Reply to original

  27. Whatever happened to building portable J2EE applications?[ Go to top ]

    "500 concurrent users? I clearly stated small to medium sized apps. Be real dude. Today's app servers are not well suited for that load either. We are talking big money for that type of system."

    See the JBoss thread. A free, Open Source J2EE web server easily handles north of 500 concurrent users.

    "Small, medium applications are cheaper to build on M$ because: IIS is free, MTS is free, ASP developers are cheap, VB developers are cheap, (C++ developers are not cheap), the tools are very good."

    You make two claims here. One, the development is cheaper; two, the setup and administration is cheaper. VB was great for client/server in the mid-90s, however it still has to even show that it is a viable solution on the web serverside. Give me one major site developed in pure VB. Also, your point on cheap developers reeks of a condescending marketing standpoint. When it comes to development, good developers get paid, VB or java. Period. As for tools, I personally have never found a java project I worked on where IDE choice was a major issue or brought that much to the job.
     
    "A monkey can administer IIS and MTS (even if an occasional reboot is needed ;-))
    - Tomcat/Apache/JBoss are all very good but are harder (read takes a more expensive person) to setup and administer, JSP and Java programmers are more expensive than ASP, VB programmers. "

    When you talk about setup and administration, you're talking production. This sentence tells me two things. One, you've never worked in a Weblogic production environment. Two you've never even tried Tomcat/JBoss. With JBoss, all you have to do is extract a winzip. Weblogic has a proven track record in production and is far superior to IIS, MTS when it comes to configuration and setup. Frankly, while I'm ok to discuss .NET as regards the cost of development, I won't trust a Windows production environment (seeing as .NET runs only on Windows) until Microsoft itself migrates hotmail away from Unix/BSD to Windows.

    "But since you brought it up I have no doubt that an MTS container with C++ components will outperform an EJB container by a wiiiiiiiiiiiiiiiiiiiide margin. If you are looking for pure performance than Java is the wrong way to go."

    Get real. Java's performance on the serverside is a topic that even Slashdot abandoned two years ago. Sartoris, your choice of arguments makes it clear that you are neither a developer, nor a sys-admin. You might qualify in Microsoft marketing camp, but at least interview some real developers and sys-admins and obtain some real data points before you come back here to lecture us.
    Reply to this Reply to original

  28. Whatever happened to building portable J2EE applications?[ Go to top ]

    "See the JBoss thread. A free, Open Source J2EE web server easily handles north of 500 concurrent users"

    Would you say that a requirement for 500 concurrent users is a small or medium sized app?

    Please read more carefully what I'm writing.

    "VB was great for client/server in the mid-90s, however it still has to even show that it is a viable solution on the web serverside"

    Again, my claim was for small and medium sized apps. But I do know of non-trivial web applications that use VB as middle-tier components. Bank Of America uses one that I know of. This is the architecture: IIS -- MTS(VB COM components) -- Oracle. It is a viable solution.

    "Give me one major site developed in pure VB."
    Who said anything about site and who said anything about major? Read before you type.

    "When it comes to development, good developers get paid, VB or java. Period"
    Go to Dice.com and compare VB rates with Java rates.

    "I personally have never found a java project I worked on where IDE choice was a major issue or brought that much to the job. "
    Since it's true for you personally it must be true universally.

    "When you talk about setup and administration, you're talking production"
    You don't need to setup and administer during development? Please tell me how you do this. In fact, you could write a nice article on it and save a lot of people a lot of time and money.

    "One, you've never worked in a Weblogic production environment. Two you've never even tried Tomcat/JBoss"

    Wrong on both counts buckaroo.

    "With JBoss, all you have to do is extract a winzip. "
    No GUI = hard time for less experienced developers.

    "Weblogic has a proven track record in production and is far superior to IIS, MTS when it comes to configuration and setup"
    Right. Let some greenhorn go into WebLogic console and start monkeying around with the JNDI tree! No such capability with MTS. Compare building/deploying in MTS with building/deploying with WLS or JBoss. I, unlike you, have done so many times on real applications.

    "Sartoris, your choice of arguments makes it clear that you are neither a developer, nor a sys-admin"

    You're right about me not being a sys-admin but dead wrong on the other count. It is you, as I see it, who has never built anything using any of what MS offers. I have so I am credible in doing comparisons.

    "You might qualify in Microsoft marketing camp, but at least interview some real developers and sys-admins and obtain some real data points before you come back here to lecture us. "

    Who's lecturing whom? I simply made staments.

    I think you read way too much into what I wrote and contended.
    Reply to this Reply to original

  29. Whatever happened to building portable J2EE applications?[ Go to top ]

    "See the JBoss thread. A free, Open Source J2EE web server easily handles north of 500 concurrent users."

    We are trying to gauge the reliability and scalability of JBoss. I haven't uncovered a single big 24x7 e-commerce use of JBoss, and I've tracked the threads here and done searches on the net. That's probably not surprising since the enterprise-level features (clustering, failover,...) are due in JBoss 3.0.

    But I have uncovered two independent tests. The most pertinent to your comment is http://www.cmis.csiro.au/adsat/jboss.htm

    At least in this instance, JBoss does not easily handle north of 500 concurrent users. I'd also like to get some metrics on Orion and Iona, because those two seem like the two commercial vendors that have affordable price points.

    Regarding IDEs, I have used simple text editors, vi, emacs before, but nice IDEs like Visual Studio are a joy to develop with. When trying to port vendor-agnostic J2EE code, you'd also have to move the development team to the vendor's tool set and that's not insignificant.
    Reply to this Reply to original

  30. Whatever happened to building portable J2EE applications?[ Go to top ]

    "We are trying to gauge the reliability and scalability of JBoss. I haven't uncovered a single big 24x7 e-commerce use of JBoss, "

    Who the heck needs 24x7 with clustering? Probably 5% of the applications.

    "Regarding IDEs, I have used simple text editors, vi, emacs before, but nice IDEs like Visual Studio are "

    Gross! That's a m$ app. I used that years ago, until I found out it produced proprietary code and we had to keep re-compiling .java files on the sun box after transferring them, or else they wouldn't work. I then found JBuilder and haven't looked back. And it's free!
    Reply to this Reply to original

  31. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Who the heck needs 24x7 with clustering? Probably 5% of the applications."

    Ah yes. But unfortunately it's 100% of the application I need to develop.

    "Gross! That's a m$ app. I used that years ago, until I found out it produced proprietary code.."

    According to some reviewers, JBuilder outputs some nice vendor-specific code and a few crashes as well. I don't dismiss good tools like VS.NET because they are written by Microsoft. Give a good programmer a text editor, and he'll do a good job. Give a good programmer a great IDE, and he'll do a better job. I can't fault J2EE vendors like BEA for trying to match VS.NET.
    Reply to this Reply to original

  32. Whatever happened to building portable J2EE applications?[ Go to top ]

    "According to some reviewers, JBuilder outputs some nice vendor-specific code and a few crashes as well. "

    I've had 0 in the 4 years I've been using it. Admittedly, most of it has been server-side.
    Reply to this Reply to original

  33. Whatever happened to building portable J2EE applications?[ Go to top ]

    <quote>
    500 concurrent users? I clearly stated small to medium sized apps. Be real dude. Today's app servers are not well suited for that load either. We are talking big money for that type of system.
    </quote>

    I've seen a single ATG Dynamo instance do 500 concurrent sessions with sub 10 second response times on a Windows NT SP6 system against a SQL server 7 back end. So, it clearly can be done by some bright people. "Big money," I would say, is a relative comparison. But, it is true that quality usually costs a bit more.
     
    <quote>
    Who said anything about XP?
    </quote>

    .NET deployment implies Windows XP, does it not? The native component model of Windows 2000 is COM+. This is why I mentioned XP. I assumed this would be the deployment platform for .NET. I believe that M$ has even stated as much.
     
    <quote>
    - IIS is free, MTS is free, ASP developers are cheap, VB developers are cheap, (C++ developers are not cheap), the tools are very good. A monkey can administer IIS and MTS (even if an occasional reboot is needed ;-))
    </quote>

    This why Nimidia and Code Red viruses continue to propagate. Beacause monkeys are allowed to touch production systems instead of qualified personnel. I'm not trying to be insulting but I don't believe you can get around the need for good people with proprietary software, no matter how simple the GUI is to use and no matter how often you reboot. That's not to say every Windows Admin is a moron but I think the Unix environment guarantees a certain level of ability. This is just my opinion.

    <quote>
    - Tomcat/Apache/JBoss are all very good but are harder (read takes a more expensive person) to setup and administer, JSP and Java programmers are more expensive than ASP, VB programmers. The development tools are not nearly as good.
    </quote>

    I agree with the first part of your statement. I disagree with the second. The tools are better, in my opinion. They're uncluttered by GUI nonsense. Resin and a simple text editor is the most efficient development environment I've ever seen for small teams. The auto-compilation and dynamic class reloading is just one feature that I haven't seen in any other product. Think beyond hot deploy.
     
    <quote>
    I searched my post for an argument about superior M$ performance and found nothing. So keep waiting.
    But since you brought it up I have no doubt that an MTS container with C++ components will outperform an EJB container by a wiiiiiiiiiiiiiiiiiiiide margin. If you are looking for pure performance than Java is the wrong way to go.
    <quote>

    I threw that in there just for the heck of it :-). Published benchmarks are more of a marketing tool than anything else, so I'll trust my own and I'd advise you to do the same. As for the C++/MTS comparison, it's

    1) apples to oranges because we're comparing the JVM and Java class library performance to the .NET CLR and .NET libraries. C++ does not run inside of a virtual machine and
    2) other threads have beaten the C++/Java performance question to death. The bottom line is that Java seems to be 1.5 times slower than C++ but the OO nature of Java makes it worth it.

    I think that factors such as disk I/O and network latency are far more constraining than the pure processing speed of the JVM.



    Reply to this Reply to original

  34. Whatever happened to building portable J2EE applications?[ Go to top ]

    I don't understand why people keep bringing up Microsoft. They're totally irrelevant to this topic. Are we just looking for an excuse drag out that old war horse of spelling their name with a '$'? Does it make us feel like hipsters when we tautologically bash them until the criticisms have lost their meaning?
    Reply to this Reply to original

  35. Whatever happened to building portable J2EE applications?[ Go to top ]


    Are open source initiatives like JBoss not also a major incentive in the big players move towards custom extensions. If there is a free implementation of the full J2ee spec with competitive performance then surely the only way the main vendors are going to survive is to offer a suite of value added extensions that make the cost worth while.

    Reply to this Reply to original

  36. Whatever happened to building portable J2EE applications?[ Go to top ]

    <Ignatius Reilly>
    I don't understand why people keep bringing up Microsoft. They're totally irrelevant to this topic. Are we just looking for an excuse drag out that old war horse of spelling their name with a '$'? Does it make us feel like hipsters when we tautologically bash them until the criticisms have lost their meaning?
    </Ignatius Reilly>

    MS are not irrelevant to the portability issue -- with MS there is no portability and that needs pointing out. However I agree with you on the $ thing. I make it a principle never to use it and I believe all Java developers/proponents should do the same.

    It clearly shows you are biased, detracts from the points you are trying to make, and makes no more sense than saying $un -- they're both big companies who wish to maximise profits -- that's the world of big business my friend.
     
    Regards,

    Ben
    Reply to this Reply to original

  37. Whatever happened to building portable J2EE applications?[ Go to top ]

    "I don't understand why people keep bringing up Microsoft. They're totally irrelevant to this topic. Are we just looking for an excuse drag out that old war horse of spelling their name with a '$'? Does it make us feel like hipsters when we tautologically bash them until the criticisms have lost their meaning? " -Ignatius


    I would rather cross my legs and meditate for peace but being bombarded with all these disinformational marketing campaigns from writers who don't know what "hello world" is justifies it. Her "research" is based on Microsoft headlines, that's how they fit into this.

    P.S.

    The true hipster is Christina Purpi, the one who wrote the article. Do your 'due diligence' and find out.


    Reply to this Reply to original

  38. Whatever happened to building portable J2EE applications?[ Go to top ]

    "I've seen a single ATG Dynamo instance do 500 concurrent sessions with sub 10 second response times on a Windows NT SP6 system against a SQL server 7 back end. So, it clearly can be done by some bright people. "Big money," I would say, is a relative comparison. But, it is true that quality usually costs a bit more"

    I still would not classify that as a small to medium sized application.
    Quality does cost more. But in a system like that extra pain (money) must taken to assure data integrity, speed, etc. Speed, data integrity in small applications is much easier/cheaper to attain.

    "NET deployment implies Windows XP, does it not? The native component model of Windows 2000 is COM+. This is why I mentioned XP. I assumed this would be the deployment platform for .NET. I believe that M$ has even stated as much. "

    The last I heard, .NET could run on 2000. In fact, I was part of a team that built a storefront site using .NET beta last August. For the record I didn't like the platform at all.

    My original post mentioned pre-MS .NET platforms.

    "...but I don't believe you can get around the need for good people with proprietary software, no matter how simple the GUI is to use and no matter how often you reboot."

    You are assuming that the end users - clients have good people. In my experience (13+ years) this is a bad assumption. Small, medium sized organizations may have some good network people but not good "production support" people. Seeing a JNDI tree would scare the pants off of them.

    "That's not to say every Windows Admin is a moron but I think the Unix environment guarantees a certain level of ability. This is just my opinion."

    My opinion is the same. But, again, the client may not even have Unix boxes.

    "I agree with the first part of your statement. I disagree with the second. The tools are better, in my opinion. They're uncluttered by GUI nonsense"

    Again, you assume a certain level of expertise by the client.

    "I threw that in there just for the heck of it :-). Published benchmarks are more of a marketing tool than anything else, so I'll trust my own and I'd advise you to do the same. As for the C++/MTS comparison, it's

    1) apples to oranges because we're comparing the JVM and Java class library performance to the .NET CLR and .NET libraries. C++ does not run inside of a virtual machine and
    2) other threads have beaten the C++/Java performance question to death. The bottom line is that Java seems to be 1.5 times slower than C++ but the OO nature of Java makes it worth it. "

    I originally never brought up the performance issue. And, again, you assume things I never stated. I said "C++ running in MTS". This has nothing at all to do with .NET or CLR.
    In case you haven't noticed, C++ is a fully OO language.
    It support encapsulation, inheritance, and polymorphism.
    In fact, C++ has many, many more features than Java.

    "I think that factors such as disk I/O and network latency are far more constraining than the pure processing speed of the JVM."

    My experience (in the traditional db backend sense) is that the database is the bottleneck. And that is probably mostly a function of disk I/O and network latency.

    Reply to this Reply to original

  39. Whatever happened to building portable J2EE applications?[ Go to top ]

    Sartoris Rules!

    Sartoris is kicking your butts.

    LOL.
    Reply to this Reply to original

  40. Whatever happened to building portable J2EE applications?[ Go to top ]

    Amazing, Internet Explorer is now packaged with blind cheerleaders.


    Reply to this Reply to original

  41. Whatever happened to building portable J2EE applications?[ Go to top ]

    CORBA has been and continues to be tremendously successful and relevant. It has become the foundation of EJB through RMI/IIOP, which is now required by EJB 2.0.

    A true test of technology acceptance is the degree to which it becomes pervasive. The most successful technologies become part of the fabric of computing, where their utility and value is no longer questioned, and thus no longer debated.

    Do you think anybody really 'cares' about TCP/IP? No, its just part of the mix of technologies upon whichall Java developers rely. The same is true of CORBA/IIOP.

    Native CORBA development continues as well, especially in telecom, where people are still developing primarily in C++ and need a robust, reliable distributed computing framework.

    I think its you that need to wake up and recognize reality...
    Reply to this Reply to original

  42. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Native CORBA development continues as well, especially in telecom, where people are still developing primarily in C++ and need a robust, reliable distributed computing framework. "

    Lol, corba sucks. The main reason it was created was to be language-independent, but eventually Java will be the only language, so it won't matter. Corba is horrible.
    Reply to this Reply to original

  43. Whatever happened to building portable J2EE applications?[ Go to top ]

    GET LOST YOU MANIAC!
    Reply to this Reply to original

  44. Whatever happened to building portable J2EE applications?[ Go to top ]

    One additional argument for the business aspect of J2EE compatibility / portability is that you do have a choice of application servers, giving you room to negotiate the cost of your application server (assuming you go commercial).

    You can't tell me that account reps don't get scared when negotiating for prices if I say that my app runs without [major] changes on most application servers (BEA, Sun, JBoss, etc). I think someone talked about purchasing cars, exactly the same analogy here -- when buying a car, haven't you ever said "there's nothing in particular tying me to brand X when I could buy brand Y for less money"?

    Just an additional point.

    I agree that *if* you can identify app server-specific functionality you can usually avoid it, however, we found that it was often the case that application server vendors were providing this functionality to fill important holes in the J2EE spec. There are a lot of examples of this where there are ways around these holes, but using the "patches" that specific vendors provide result in much more elegant solutions. Generally you can figure a way around this by a refined build process as well.
    Reply to this Reply to original

  45. Whatever happened to building portable J2EE applications?[ Go to top ]

    Sartoris Snopes,

      Is that you Greg Leake ?






    * grin *

    Reply to this Reply to original

  46. Whatever happened to building portable J2EE applications?[ Go to top ]

    Hi,

    Sartoris, I have lost track of the fundamentals of your argument. Could you please explain( in short point format ) your clear positions on the issue of Portability practicality in the J2EE world and why? I would like to to reexamine your arguments in a manner that we can actually draw some conclusions upon ( ie. don't say "Java's bad, but everything out there is bad, so everyone's wrong but everyone's right" type of thing... ). It seems as if the Devil's Advocate role is just being played out for the heck of it.

    Reply to this Reply to original

  47. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Sartoris, I have lost track of the fundamentals of your argument"

    Me too.

    1) I see nothing wrong with a J2EE vendor adding extensions to their product as long as the product satisfies the spec.

    2) I see nothing wrong with .NET being not-J2EE. Competition at this level will benefit us all I think.
    There is a market that will be filled by .NET as there was a market filled by MS pre-.NET technology.

    3) I think J2EE reaches too wide and too high to make a standard. JDBC as a standard? I can see that. EJB? That's a liitle harder to see.

    4) It seems that standards(de facto standards) that exist today are languages and plumbing but not moustraps. I could be wrong. Are there any standard mousetraps - like middleware servers, web servers, TP monitors?

    I guess CORBA falls into the moustrap category. But it never really gained momentum, unfortunately.

    5) Perhaps J2EE being tied directly to Java (which is itself not a standardized language - a little ironic) is
    a problem, too. C++ EJBs? Why not?

    Many of the other points I was making were rebuttals to things I never argued.

    "I would like to to reexamine your arguments in a manner that we can actually draw some conclusions upon "

    It will be hard to conclude some things because some/most of it is subjective and based on my experiences. But I look forward to your comments.

    Reply to this Reply to original

  48. Whatever happened to building portable J2EE applications?[ Go to top ]

    Just to add to the flamewar :)
    Where M$ (and no, I'm not ashamed of the $ - and I consider $un the same :) ) has something that a lot of other companies forgot about (fortunately, some - IBM for example - are rediscovering it now). That is, that by definition most of the developers there are average (reason? the bell curve). Therefore, if you provide nice and easy environment for them, it will increase their productivity a lot.
    That's what M$ is all about, that first jump, initiall learning curve. If you give a new guy VS and emacs, guess what will he be more productive with in a short time? Remember VS4Java? What was the best IDE then?
    This is _not_ arguing that those tools are the best. In fact, in a lot of cases when you want to do something special, non-obivous and standard, it's hard to do. But they are pretty much the best for your day2day, bread&butter operations.
    In the other thread it was mentioned that a good snr. developer can be of the same productivity as 4-5 normal ones. Yes, I agree with that. But the current situation is that there's a lot of people who got attracted to IT only because of the salaries, not the intelectuall chalenge and most of them never will be more than average developers. And it was always hard - especially if you're a big company - to consistently attract good people only.
    That's for examle why Java gained on C++ so rapidly (not to talk about Smalltalk that's probably better than both of them ;)). Because despite all the nicer features in C++ (yes, you can add even garbage collection and make it even smarter than default Java is, not to mention things like STL) productivity gain in Java is just so much better than C++. So what you couldn't do with average people in C++ you can in Java (multithreading, memory management, networking etc.)
    Yes, there's a lot of security holes in M$ software. Do you really think that there's not that much security holes in your favourite flavour of UNIX? Then you need a wake up call. It's just that for every person that wants to hack a linux machine, there's a 100 that make it their personal crusade to hack M$ sites/find&exploit some other Outlook/IE hole. (and that's what I would take into consideration when doing a site with IIS etc.).
    Yes, the M$ software crashes and burns. Well, most software I dealt with I managed to crash, whether on UNIX, Win, Mac. Who was it that last mention how unstable some app server was on a unix machine? That does not absolve M$ from producing crap - it's just to point out that most of the commercial companies there produce software of similar quality (and have the same unhelpful people manning technical support, the same we're the best marketing lines etc. Anyway seen Larry talking recently?).
    Yes, people can talk about good things with open source, and there is no doubt a lot of great stuff out there. But to deal with it, you need generally smarter (which hopefully translates into more expensive) people, not monkeys. And then the question you ask yourself is "Do I really need it? What are my tradeoffs? Can I justify it?". A lot of CIO/CEOs these days asks these questions, and not that many techies are able to answer them. I'v lost count on how many projects I've seen to die unborn because of this. This is really unrelated to M$/$un/IBM/whatever but it seems to me that a lot of techies still don't understand that it's the business (ROI) that drives (or at least should) technology use, not the other way around. Strangely enough, most of them behave similary in their field :) (hands up who uses formal specification languages - hey, how many of you can write a couple of lines in Z or OCL and how many did really do it - ever?)
    And no, I don't work for M$, in fact I work for $un distributor (and so have some experience with $un as well). And I used to work for IBM.
    All the above opinions are my own and not of my emlpoyer.
    Reply to this Reply to original

  49. Whatever happened to building portable J2EE applications?[ Go to top ]

    Please, don't booze while typing.
    Reply to this Reply to original

  50. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Yes, there's a lot of security holes in M$ software. Do you really think that there's not that much security holes in your favourite flavour of UNIX? "

    Yes, I do think they're not there. When was the last time you heard someone hacking into a unix box?

    You're obviously very, very biased. That's fine, so am I. But the difference between you and me is, I don't let my bias blind me into believing anything Java reigns supreme.

    Face it, m$ technologies (an oxymoron) really, really... really suck. Big time. Get over it, and move on.
    Reply to this Reply to original

  51. Whatever happened to building portable J2EE applications?[ Go to top ]

    Dear Tracy,
    obviously you have no experience from security world. Last time I checked bugtraq (Tue), there was quite a few security problems with UNIXEs - from Solaris to various flavours of Linux. I cannot fault you for not reading security forums - only a few non-security people do, but then you do read the serverside, so have a look at http://www.theserverside.com/home/thread.jsp?thread_id=11293 will you?
    So to answer your question is "today". And pretty much about once a week before that - it's just not nearly as public as M$ attacks are.
    Vlad
    Reply to this Reply to original

  52. Whatever happened to building portable J2EE applications?[ Go to top ]

    Vlad, no offense, but what you just said is sort of a joke. I *do* read the security forums regularly, and no matter what you say there are not as many security holes in most unix flavors as there are in even the most secure windows flavor. I once suggested to the department of defense that they use Crystal for a reporting tool. I practically got laughed out of the room. DoD won't let ANY ms puters in there major data centers and research labs for one reason, SECURITY. And I assure you they read the security bulletins. As good as windows is on UI and functionality, and integration, its bad on security. I wouldn't recommend to most of my clients that they use windows for production system environments. Development is another matther. The only place where I've seen windows used securely is behind extremely draconian firewalls on intranets.

    In fact windows probably can be as secure as unix with the right people behind it. But the hard fact is that it's not *generally* as secure as unix. Until a fairly simple setup for win2k is as secure as a similar install for Solaris, I'll stick with solaris, and I think a lot of people in industry feel that way.

    By the way, that doesn't mean I don't expect Solaris to have wholes, as you posted that link. But it certainly seems more rare.

    -Newt
    Reply to this Reply to original

  53. Whatever happened to building portable J2EE applications?[ Go to top ]

    "-Newt "

    Is this really the girl from Aliens???
    Reply to this Reply to original

  54. Whatever happened to building portable J2EE applications?[ Go to top ]

    Hmm.. last time I checked a lot of Navy was using NT to run even missile control computer on their ships. That of course if more of a stability issue then security though.
    Anyway, to the security of MS applications. Yes, it's far from perfect - and I didn't dispute that. I still believe that there's about the same amount of holes in "out-of-box" unix as in Windows - that's why most of the people out there apply patches and/or change software (i.e. the infamous sendmail) immediately to something more secure.
    Then your UNIX machine _will_ be more secure. OTOH, you can apply security patches on Windows as well, now that people started to post the holes to force MS to patch them. Most of the exploits you will read of are using holes that are about two-three months old, with existing patches.
    There's though one huge disincentive to use MS products in any environment that requires security, and I mentioned it in my original message.
    People that hack UNIXEs do it either a job (legitimate - I have friends who make their living trying to break security systems) or an intelectual challenge (as it tends to be harder than reading a post on MS vulnerability and putting together a VB macro).
    Breaking into MS products is mostly "for fun" and most of them are teenagers "proving" themselves.
    For each of the security professionals who can break into almost anything out there there are 100s of hackers trying to wreak havoc on anything MS just for the kicks of it.
    That is precisely why I wouldn't use MS product even if they had the best security around, as the numbers are heavily stacked against them.
    Incidentally, you wouldn't believe how paranoid are some companies on their internet security while their internal security measures are a joke and getting into the building & even asking the helpdesk for a password change is not a problem. When someone defaces your site it's an embarassement, but if someone gets all your financial information + other business critical confidential stuff that's entirely different story.
    Reply to this Reply to original

  55. Whatever happened to building portable J2EE applications?[ Go to top ]

    hey, how many of you can write a couple of lines in Z or OCL and how many did really do it - ever?


    Actually this is "a bit" of topic.

    However, I like your challenge. I suggest that Rikard Öberg adds some poll features to this site so we can find out the answer to your question.

    For me to get started:
    I've written both Z and OCL specifications and it was not just a couple of lines ;) I'll send you my OCL specification of "The Meeting Scheduler" which I completed some weeks ago, just contact me at ocl at pietervangorp dot com.

    Also, I'm not some old expert/guru, I'm only 21 years old and I'm proud to say: "I love formal methods." Actually I think that working with formal methods isn't more difficult than deploying to different J2EE application servers.

    A poll would be more appropriate than mixing it in this thread, but you asked for it, so I gave my answer.

    Regards,
    Pieter.
    Reply to this Reply to original

  56. Whatever happened to building portable J2EE applications?[ Go to top ]

    I definitely agree with point 1. I think that, as long as the application servers support the spec, code that needs to be portable can be written. However, if what I'm writing doesn't need to be portable, the ability to take advantage of additional features the application server offers is a good thing. It just has to be done in an intelligent fashion, to ensure that platform dependencies are well known.

    Vendors are always going to want to add additional features. That's one major way to differentiate their products. When all the features become a commodity, suddenly the selling points have to either move to different offerings (support, professional services) or plumbing (performance numbers and such), and the prices usually get pushed lower. I'm actually not sure how Sun is going to handle this (and I mean this as an honest question, since I'm sure it's a difficult balance to get right) since they need to walk a fine line -- standardizing as much as possible, while allowing room for the vendors to innovate and differentiate their products.

    Mark
    Reply to this Reply to original

  57. Whatever happened to building portable J2EE applications?[ Go to top ]

    "However, if what I'm writing doesn't need to be portable, the ability to take advantage of additional features the application server offers is a good thing. It just has to be done in an intelligent fashion, to ensure that platform dependencies are well known. "

    ALL business application code should be portable.
    Reply to this Reply to original

  58. Whatever happened to building portable J2EE applications?[ Go to top ]

    "ALL business application code should be portable."

    I disagree. I think, again, this totally depends on the situation. If there are requirements which can't be met in a portable fashion, or if there are huge gains that could be achieved (in productivity, performance, whatever) by doing something non-portable, I think they should be allowed. "Allowed" is the key -- it should be possible to write portable applications as well, if that is a requirement. And obviously, if that is a requirement, any non-standard features should be avoided.

    I think that, if portability is forced, there are going to be situations where either Java cannot be used, or the price is driven way up for little or no gain (most companies, at least in my experience, don't regularly switch platforms). I guess I would rather have the option to use Java, even if the solution can't be portable.

    Mark
    Reply to this Reply to original

  59. Whatever happened to building portable J2EE applications?[ Go to top ]

    ""Allowed" is the key "

    That's why I said "should" as in, that's what we should "strive for."
    Reply to this Reply to original

  60. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Is that you Greg Leake ? "

    No. Is he related to Kelly Leake? The dude from The Bad News Bears?
    Reply to this Reply to original

  61. Sartoris does, in fact, rule.[ Go to top ]

    Good stuff Sartoris!
    Reply to this Reply to original

  62. Whatever happened to building portable J2EE applications?[ Go to top ]

    Well when all you write are "Hello World" applications of course their all portable. Everything is portable? Gimme a break...anything portable is not worth running in a true business.
    Reply to this Reply to original

  63. Wha-a-a-a-t?!?!?[ Go to top ]

    Anything portable is not worth running in a true business? Could you please explain your reasons for making this statement because I don't see your point.
    Reply to this Reply to original

  64. Wha-a-a-a-t?!?!?[ Go to top ]

    Any business application that doesn't take full advantage of whatever platform it runs on (which makes it non-portable) to provide scale, security, data access or whatever isn't worth writing for a business that needs volume processing or stability in a known environment.

    Everyone here pontificating about how great Java is from a portability standpoint is nothing more that hobbyist talk. True app developers, in any language, care about the business problem and will use any tools at their disposal, including the good features and APIs of the platform to make good software.
    Reply to this Reply to original

  65. Wha-a-a-a-t?!?!?[ Go to top ]

    It takes a narrow view to claim portability exists. Maybe some source code is portable, but with EJB's you also have deployment descriptors, which are just barely becoming standardized, not to mention the stub/proxy generation.

    Engineers don't just code; they also design. Maybe your app server optimizes out some RMI overhead, supplies a connection pool, supports clustered EJB's, generates unpredictable session ID's, supplies a database connection pool, and has a JDBC driver which implements 100% of the API's methods. Or maybe not. If your design takes all of these issues into consideration, then your code can be industrial-strength, but it won't be portable.

    This not to mention IT issues. I don't know about you, but I don't just write some code and send it down the pipe. I can just imagine telling the systems guys that we want to rip out all of our Websphere servers and put in WebLogic or JBoss. But don't worry, because all the code is J2EE-compliant and written people who have achieved the Java vision.
    Reply to this Reply to original

  66. deployment descriptors[ Go to top ]

    You can factor out many app server specific deployment settings in deployment descriptors of that app server. As a good example take a look at XDoclet's samples, a single set of EJBs are annotated by generic javadoc @ejb:bean/etc portable @tags and also by some @weblogic:blabla/@jboss:blabla @tags. The end result is that it deploys on both weblogic and jboss. The code is the same, but you just add some javadoc @tags in code and it deploys on your favorite app server with app server specific deployment tweaks easily handled by those @tags. XDoclet currently has app server specific @tags for weblogic/jboss/orion/websphere, so it's specially a very good tool for companies who have to support different app servers simultaniously.

    Ara.
    Reply to this Reply to original

  67. deployment descriptors[ Go to top ]

    <Ara Abrahamian>
     The code is the same, but you just add some javadoc @tags in code and it deploys on your favorite app server with app server specific deployment tweaks easily handled by those @tags.
    </Ara Abrahamian>

    Thank you very much for giving a technical solution to the problem. Up to now, I did not know of that option. Still I believe that adding the app server specific information can take a lot of effort! Can somebody tell me how the J2EE spec. handles the vendor specific info: is it fully optional or can a vendor require the addition of specific info?

    I respect all successful deployments that are mentioned in this thread. However, all failures by others cannot be overlooked. It's quite normal that J2EE experts deploy to multiple application servers without any problems. However, not everyone has that experience.

    My personal experience is that generating the deployment descriptors for an other application server can take a lot of time. _If_ you are working in a tool like Together, there's hardly a problem: you simply enter the target application server and the tool generates the default deployment descriptors. However, I recently had to deploy the ECperf benchmark on different application servers and in that case I did not have the luxury IDE features (or I should have refactored it all, an option that I am still considering...) If anybody knows an easy way to deploy such a raw application to different application servers, PLEASE let me know, I'd be very grateful. I mention this benchmark case, because it is a standard application, developed under the JCP. So it should be developed using only the standard J2EE spec features.

    Now that I've asked the experts to teach me the easiest way to deploy such a standard application to different application servers, I'd like to add that if there isn't an easy solution to this problem, there is something lacking to the J2EE spec IMHO.

    Once again, I respect all success stories here, but I should not neglect other project failures. Simply stating that the developers from those failed projects are stupid, is not what I should do...

    Best regards,
    Pieter.
    Reply to this Reply to original

  68. deployment descriptors[ Go to top ]

    <Pieter>
    My personal experience is that generating the deployment descriptors for an other application server can take a lot of time. _If_ you are working in a tool like Together, there's hardly a problem: you simply enter the target application server and the tool generates the default deployment descriptors. <snip/>
    </Pieter>

    http://sourceforge.net/projects/xdoclet

    :o)

    Ara.
    Reply to this Reply to original

  69. deployment descriptors[ Go to top ]

    http://sourceforge.net/projects/xdoclet

    >> :o)

    <cut source="http://xdoclet.sourceforge.net/">
      A checklist of things you will need to do to get XDoclet running is:
     <ul>
      <li>Modify (creating if required) your build.xml script (see ant for details).</li>
      <li>Add XDoclet tags to your source code. </li>
      <li>Stop worrying about all that boring code you use to have to write! XDoclet does it for you now.</li>
     </ul>
    </cut>

    So you suggest I go through all the files from the ECperf benchmark and add XDoclet tags?

    I do not know for sure, but I think that the vendor specific deployment descriptors are not fully optional by the J2EE spec. Can somebody explain me why? If they were fully optional, you could build a completely vendor neutral EAR file which could be deployed on any app server.

    I clearly must be missing the point somewhere...

    Regards,
    Pieter.
    Reply to this Reply to original

  70. deployment descriptors[ Go to top ]

    <cut source="http://xdoclet.sourceforge.net/">
      A checklist of things you will need to do to get XDoclet running is:
     <ul>
      <li>Modify (creating if required) your build.xml script (see ant for details).</li>
      <li>Add XDoclet tags to your source code. </li>
      <li>Stop worrying about all that boring code you use to have to write! XDoclet does it for you now.</li>
     </ul>
    </cut>

    I sense your fear about having to insert @tags in a big bunch of code. I know, it sucks, so we (XDoclet team) are working on a tool that will do that for you - provided you already have the deployment descriptors. Hopefully we can release something in a few months.

    Aslak.
    Reply to this Reply to original

  71. deployment descriptors[ Go to top ]

    <Aslak Hellesøy>
      I sense your fear about having to insert @tags in a big bunch of code. I know, it sucks, so we (XDoclet team) are working on a tool that will do that for you - provided you already have the deployment descriptors.
    </Aslak Hellesøy>

    Great! I'll keep an eye on that.

    To continue on the subject of deployment descriptors beying optional or not: I really cannot understand why the community doesn't bother more about it.

    Yes, tools like XDoclet would still be needed if you wanted to use specific servers settings (clustering info for example)
    But as Cedric Beust mentioned above, why does WebLogic (just as an example) mandates the inclusion of their specific deployment descriptor, just to override the JNDI name? I believe that for any parameter, reasonable defaults are possible.

    I believe this is a nice proposal for the next J2EE spec, unless somebody explains me why it isn't possible.

    Regards,
    Pieter.
    Reply to this Reply to original

  72. deployment descriptors[ Go to top ]

    <Quote>
    Thank you very much for giving a technical solution to the problem. Up to now, I did not know of that option. Still I believe that adding the app server specific information can take a lot of effort! Can somebody tell me how the J2EE spec. handles the vendor specific info: is it fully optional or can a vendor require the addition of specific info?
    </Quote>

    The optional descriptor settings are often required.
    For instance, in WLS you specify a bean's home JNDI
    name in the weblogic-ejb-jar.xml.

    I've always thought it would be a good thing IF containers operated sans vendor-descriptors. For
    example, WLS could bind the home to the full
    package name of home interface class.

    Re: the article, why bother...
    Reply to this Reply to original

  73. deployment descriptors (EJBGen)[ Go to top ]

    <quote>
    My personal experience is that generating the deployment descriptors for an other application server can take a lot of time.
    </quote>

    If you are deploying on Weblogic, check out http://beust.com/cedric/ejbgen

    As to the more general problem of deploying the same ear on several application servers, there are no easy ways, but it can basically be broken down in two phases:

    - Deployment descriptors. This is the easy part. Use tools that generate these descriptors for you for the various application servers and include them all in your ear file. The containers will pick the descriptors they recognize and ignore the errors. I believe a mix of EJBGen, XDoclet and IDE's will get you reasonably far.

    - Java code. This part can vary substantially from one appserver to another (InitialEntityContext, etc...). For this part, I think a mix of simple design patterns (factory, singleton, etc...) is probably the safest bet but I've never done this in practice

    Keep us posted!

    --
    Cedric
    Reply to this Reply to original

  74. deployment descriptors (EJBGen)[ Go to top ]

    If you are deploying on Weblogic, check out http://beust.com/cedric/ejbgen


    Hi Cedric,
    how does EJBGen compare to XDoclet?
    Reply to this Reply to original

  75. deployment descriptors (EJBGen)[ Go to top ]

    EJBGen is focused on Weblogic. It also has some additional features that would take too long to enumerate here. Please take a look at the documentation and the mailing-list:

    http://beust.com/cedric/ejbgen
    http://www.yahoogroups.com/groups/ejbgen

    Feel free to ask questions on the mailing-list.

    --
    Cedric
    Reply to this Reply to original

  76. deployment descriptors[ Go to top ]

    In order to benefit from the J2EE platform, it is recommended to stay with the J2EE APIs as much as possible. There may be exceptions, where functionality is needed that only a vendor-specific API will offer a solution, but this will be at the expense of portability and ease of maintenance.

    The first choice for transactions should be to use the EJB container, and only to use JTA in cases where the container cannot provide the needed functionality.
    The JAXP Java XML APIs, being a simple wrapper do not need evaluation.

     

    Reply to this Reply to original

  77. Wha-a-a-a-t?!?!?[ Go to top ]

    better said than what I wrote.
    Reply to this Reply to original

  78. Wha-a-a-a-t?!?!?[ Go to top ]

    Well I think the point is that Java gives us the portability. Don't forget what happens. The code is abstracted from the environment it runs on. Connect to a database, write to a file, use JINI, JMS, etc. regardless of the platform. The implementation details are contained in the JVM and runtime environments. Because of this the code is truly portable and scalable but the complexities of the environment are not worried about by the developer. It seems that we as developers get caught up in the implementation details and the true issue of portability is handled for us.
    Reply to this Reply to original

  79. Whatever happened to building portable J2EE applications?[ Go to top ]

    At the Northwest Alliance for Computational Science and Engineering(NACSE) we have a heterogenous computing lab that tests out our software on many different platforms. Various OS flavors, hardware (even SGI workstations and a Cray somewhere around here although I've never even seen it), and various application servers. We're finishing up an application that will handle 6000-7000 users that so far has been about 95%+ (probably more, but we haven't done that much testing yet) portable on 4 different app-servers. I am pretty sure it's not a "Hello World" application.

    So far the ONLY portability bug we've run into was when we had a private setter method in a tag library. Using tomcat as our servlet engine, this works fine. I believe the spec says there shouldn't be private tag setter methods(although I'd have to check) because the methods are supposed to be found through reflection. Other app-servers validated, and threw exceptions, when Tomcat didn't. So, the portability problem arose from our not following the spec. Some servers just do a better job validating these things.

    Contrary to what some people seem to think, a lot of companies and R&D organizations(NACSE included), feel very strongly that applications *should* be portable across 'puters, OS's, app-server's, etc. There are plenty of solutions that don't meet portability needs, and are fine. The right tool for the job and all that. But portability is certainly important to us and many of the companies, universities and government agencies that we work with.

    -Newt
    Reply to this Reply to original

  80. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Well when all you write are "Hello World" applications of course their all portable. Everything is portable? Gimme a break...anything portable is not worth running in a true business. "

    Pardon my rudeness...

    You IDIOT. You don't have a clue. You must be a disgruntled vb guy. Get lost.
    Reply to this Reply to original

  81. Whatever happened to building portable J2EE applications?[ Go to top ]

    Good answer!
    Reply to this Reply to original

  82. Whatever happened to building portable J2EE applications?[ Go to top ]

    Ya
    Reply to this Reply to original

  83. Whatever happened to building portable J2EE applications?[ Go to top ]

    Fortunately, I also see an overwhelming trend towards genericization of J2EE servers, such as recent JCPs from Sun for management and deployment API's. Of course another parallel route is the deprecation of J2EE servers all- together and movement towards componentized services, or 3rd Generation Servers:

    http://www.sys-con.com/java/article.cfm?id=1257

    BEA, IBM and Oracle can offer all the propertietary "starter-kits" they want, but they won't impede the application server evolution.

    Gene
    Reply to this Reply to original

  84. Whatever happened to building portable J2EE applications?[ Go to top ]

    If running a fast, scalable, application using these app servers was only possible using their extensions, then I would agree with the article.

    However, so far these extensions just seem to be convenience features, and can always be designed around. I see them like temptations to be avoided, unless the lifetime of the project is short, so that using something like Cajun (BEA's new framework) shortened the lead time so much that depending on Weblogic was deemed "OK".

    So far J2EE seems to cover the bases "well enough" that we can stick with that + our own designs (which are portable unless we strike a deal with the devil) to go forward.

    Lawrence

    Reply to this Reply to original

  85. Whatever happened to building portable J2EE applications?[ Go to top ]

    "However, so far these extensions just seem to be convenience features, and can always be designed around. I see them like temptations to be avoided, "

    Lawrence, that is completely correct imho. Nail on the head.
    Reply to this Reply to original

  86. Whatever happened to building portable J2EE applications?[ Go to top ]

    I think the test of the article author's premise comes down to two things.

    1) How easy is it to identify what is "proprietary"
    2) If you can identify "what" is proprietary and you do avoid it, is it reality or not that you can port it to other application servers with minimum trouble.

    and I will add a third item:

    3) Is it reasonable to believe you can / will avoid the proprietary extenstions. (i.e. have you ever used oracle and actually NOT used the proprietary DECODE statement).

    Even if the author of this article is all wet, with .NET now on the seen, this is (was) a good discussion. MSFT has 1 application server and 1 platform, and you can be sure they will provide excellent tools. I believe the J2EE developer pays the cost of additional education requirements than a .NET developer due to the variations. It's a good idea to always rethink "WHY" it's worth it.

    JMO.

    Mike
    Reply to this Reply to original

  87. The evolution of J2EE[ Go to top ]

    The author is arguing that proprietary extensions threaten the promise of standards based application portability---that Java's promise of "write once, run anywhere" is dead, and was never a reality anyway. This demonstrates to me a tremendous lack of vision.

    The J2EE platform is growing as a language. This means starting small and collecting the best contributions over time into a larger, more capable language. The language evolves with the community that uses it. A standards based approach to application development suggests that if you constrain yourself to using only the standard features and interfaces, then you should be portable to any implementation. Generally, that is true of J2EE; standards based portability is certainly more a reality with J2EE than on any other equivalent platform (e.g., Microsoft .NET).

    Proprietary extensions by application server vendors are expected. Applications written to the standard will still be portable, because they do not depend on proprietary extensions. In time, the scope of standards will expand, as technologies mature and become commonplace. The industry's best practices become encoded into standards, because the market demands it for portability (reducing costs). Innovation (proprietary extensions) will happen further out into the leading edge, where technologies are unproven. Vendors can differentiate their product based on quality of implemention and value added features. The latter requires extending beyond the standard features.

    The article paints a picture of a static standard, which is being eroded. In reality the J2EE standard is constantly evolving to expand its capabilities. Application server vendors are moving in lock step to embrace the newest standard; often, their products have already implemented the standard by the time it is officially published. In reality, J2EE application portability is continually improving rather than being threatened due to this natural evolution.
    Reply to this Reply to original

  88. The evolution of J2EE[ Go to top ]

    I agree... and offer my 2c worth:

    Any organisationwhich has spent reasonable sums of money on application server platforms, development tools and costly ;-) manpower are going to be keen on making sure that they get a good return on their investment. In other words: of course we´re going to build code which is portable/reusable. That´s why we´re using Java, and J2EE as the serverside standard of choice.

    The "write once, run anywhere" is attainable even though J2EE and other platforms continue to diverge. It just doesn't work at the code/Java level. It has been shown to work in production environments at MDA level (www.omg.org/mda). How this works was clearly explained in a recent book on convergent Architecture (www.ConvergentArchitecture.com) which has received top reviews. There are architectural platforms, so-called Architectural IDEs, executing "model once, deploy anywhere" in production today to leading J2EE application servers and soon to .NET. See for example www.ArcStyler.com.
    Reply to this Reply to original

  89. Whatever happened to building portable J2EE applications?[ Go to top ]

    It seems to me that the author is asking for way too much, namely that the mere use of Java make it *impossible* to write non-portable code. Java had one promise: to allow you to write components that can run on multiple architectures without recompilation, thus facilitating code re-use. That by itself is a huge achievement.

    JCP, however, is another matter. If the standards are too vague, then the cost of porting will go up. This is no surprise, since it already happened with SQL. The book "A Guide To The SQL Standard", by C.J.Date, explains how the SQL standard came out wrong because different wonders had existing implementations that were slightly different, and for this reason the definition of SQL came out vague.

    Guglielmo
    Reply to this Reply to original

  90. Whatever happened to building portable J2EE applications?[ Go to top ]

    This story doesn't 'get it'. The value is derrived from a standard said of interfaces, not implementations.

    For me, the goal isn't about taking your application and plop it on another vendor's server. The 'write once, run anywhere' is more about java code not J2EE Specification implementations and the apps that run on top of them. I can write a set of java classes and compile and run them on any machine with a compatible JVM. You are seeing this more and more in Swing based applications that act as administrative consoles/helper tools that can run on any machine.

     As a consulting organization, we can focus on training our staff on J2EE, the interfaces are the same for servlets, jsp, ejb etc whether we are consulting on an Oracle 9i project, a BEA project, EA Server Project, JRun, JBoss, or a Websphere project. So our approaches to core problems like state management, Session Management, Security, Messaging, Desing Pattern Implementations, Packaging, and Deployment are consistent because of the 'specification' that J2EE provides.

    We can also address our customers needs better because we can provide an Enterprise solution that fits their budget and business needs. We can go with an expensive J2EE app servers with more robust proprietary extensions to leverage legacy investments(Oracle and IBM) or a bare bones NET new development focused application server like Macromedia's JRun or open source like Tomcat and JBoss. Also, training costs can be minimized because their is so much published literature and training companies out there. Now we have cost options, based on our customer needs, and a set of skill sets that can be leveraged far better than propriety/application server specific skills before J2ee (Powerbuilder WebPB and PowerSite, ASP, ColdFusion, PL/SQL, Oracle Forms, Perl, CGI scripts etc....).
    Reply to this Reply to original

  91. Whatever happened to building portable J2EE applications?[ Go to top ]

    "This story doesn't 'get it'. The value is derrived from a standard said of interfaces, not implementations. For me, the goal isn't about taking your application and plop it on another vendor's server. The 'write once, run anywhere' is more about java code not J2EE Specification implementations and the apps that run on top of them. I can write a set of java classes and compile and run them on any machine with a compatible JVM. "

    Exactly, the guy that wrote that article acts like Java isn't portable but it most certainly is. Who cares what the app server vendor does as Twhat's one cool about oop and, specifically, interfaces: the implementation is separate from the interface.
    Reply to this Reply to original

  92. Whatever happened to building portable J2EE applications?[ Go to top ]

    "This story doesn't 'get it'. The value is derrived from a standard said of interfaces, not implementations. For me, the goal isn't about taking your application and plop it on another vendor's server. The 'write once, run anywhere' is more about java code not J2EE Specification implementations and the apps that run on top of them. I can write a set of java classes and compile and run them on any machine with a compatible JVM. "

    Exactly, the guy that wrote that article acts like Java isn't portable but it most certainly is. Who cares what the app server vendor does as they stick to the interface. That's one cool about oop and, specifically, interfaces: the implementation is separate from the interface.
    Reply to this Reply to original

  93. Whatever happened to building portable J2EE applications?[ Go to top ]

    That would be "write once, run anywhere IF YOU RECOMPILE". :)
    Reply to this Reply to original

  94. Whatever happened to building portable J2EE applications?[ Go to top ]

    Since fully portable enterprise scale applications may not
    yet be always possible.

    My personal vision has always been :
    Stick to the standards as much as possible. But, when valuable and reasonable, use the features provided by the products used for a specific project.

    That said, if I rely on some proprietary features, I make sure it is in some isolated part of the code (not all aver the place).

    The result is that we may have to rework some part of the application when porting it to different application servers but still the cost and time will be way way way less than having to rewrite the application completely.

    Is n't this the case with . NET ??

    Personnally, I see a huge value in the J2EE related standards.

    Cheers
    François

    Reply to this Reply to original

  95. Whatever happened to building portable J2EE applications?[ Go to top ]

    Here's my take on the J2EE portability issue:

    - If developing with EJB's, then no J2EE is not currently 100% portable, let's be honest here (deployment descriptors etc). You can make it relatively easy to port provided you stick to standards as much as possible (and where applicable) and try and encapsulate any proprietry parts of your application (if possible -- XDoclet, mentioned above, sounds like an interesting approach to this). IBM, BEA want to "add value" to their app servers via non-standard extensions (optimisations etc) to justify their price and I really can't see this changing in the near future.

    - However, if NOT developing with EJB's, J2EE IS nearly 100% portable. Moving applications to different servlet engines can be trivial (I've migrated a medium scale app from Tomcat 4 to Resin-2* with zero code rewrite). I believe that EJB's are really over-used/emphasised and aren't needed for anything but large scale apps (of course that is a seperate debate :)), so for your small-medium scale J2EE apps (not using EJB), true portability is a reality. This is *very important* - it gives real freedom of choice in purchasing decisions and maximising ROI.

    - As difficult as it might be to migrate a given J2EE app it pales in comparison to migrating a .NET app. The chances of a MS .NET application working under a Mono .NET implementation (Mono is currently to only real alternative), without huge rewrites to the code or ignoring significant .NET libraries would be nearly zero.

    Regards,

    Ben
    Reply to this Reply to original

  96. Whatever happened to building portable J2EE applications?[ Go to top ]

    Ah, it's good to start 2002 with the knowledge that the portability police are still out there...

    I really should make copies of some of the stuff being said here and re-visit it in the future.

    So "J2EE enables portability but does not enforce it"... would providers spend time adding extras just for a laugh or are they getting used? If they are getting used then portability is shot, fair enough, you decide... would however be interesting to see all the figures re J2EE takeup including a portability check!

    I would love to know what percentage of J2EE based applications are portable.

    Anyone care to start a thread re the evils of extensions to ANSII standard SQL?

    A new year but still the same sh*t...
    Reply to this Reply to original

  97. Whatever happened to building portable J2EE applications?[ Go to top ]

    Surely the facts are:
    1.Deployment descriptors are vendor specific.
    2.App servers have config tweaks for performance.

    So the net result is:
    a) All app servers ARE different
    b) To optimise performance you MUST put in app server specific deployment info (at the least).

    Which means writing cross server apps is a pain because of deployment issues, rather than core coding issues. I would always steer clear of coding in app server specific stuff.

    As for write once run anywhere, I just upgraded by CPU to AMD 1800 and Oracle don't work (because of java) and java fails randomly (because of hotspot). I wish I used a different language :(

    Jonathan
    Reply to this Reply to original

  98. Whatever happened to building portable J2EE applications?[ Go to top ]

    Why is it that every discussion on this site seems to end up in a 'Java is best, M$ sucks' flamefest.


    Surely as developers our responsibility is to pick the tools that best serve our purpose. Part of this involves the inevitable trade off between portability and the productivity gains that may come with a single vendor solution (whether that be .NET or BEAs cajun or whatever). I'm a huge java and j2ee fan but that doesn't blind me to the fact that unless criticism of java is taken seriously then one day a better language/ technology is going to be the the best solution and i for one will be using it.

    Surely the bigger question is what are these extensions offering that is not a core part of J2EE and to ensure that sun pushes fowards in standardising such extensions and making them a part of J2EE as soon as possible. When such functionality is brought into J2EE then surely vendors will be forced to refit old propriotry extensions to fit the standards or otherwise risk losing there J2EE compliancy.

    I think that there is no real concern of losing the portability of j2ee as long as vendors ensure that pure j2ee solutions can be created with there app server - it is then down to the developer to decide whether they want to use these extensions whilst sacrificing total portability. Surely this type of behaviour is unavoidable and indeed necessary in the competitive app server market. All vendors after all want some degree of lock in whether they be M$, IBM or BEA its there job to ensure that you use their product over their competitors.

    Stuart
    Reply to this Reply to original

  99. Whatever happened to building portable J2EE applications?[ Go to top ]

    The thing about Microsoft is that when they do something really really well, they still do it badly from a techies point of view.

    I prey .Net is good, but my guess is that the vendor tie in theme and msofts view of how the internet will be will end up choking it. At home I have dos, windows, nt 351, 4, 2000 pro, 95, 98, 98se, xp home, xp pro. The mean time between new releases is actually decreasing. And on every release I have to re-engineer parts of the infrastruture/code base to reflect some MS proggers new version of reality.

    Whereas, unix shell scripts I wrote 15 years ago still work (mostly). This is why msoft gets a bashing, as techies we get annoyed at the problems they create for us.

    And their techs will not ever work on unix/some other OS, yet sometimes they make out that they may consider it just to muddle the waters. i.e. their marketing creates as much FUD as possible. Also old code for MS OSx often fails on new MS OSx... etc etc

    So even though much msoft stuff is brilliant from a consumer view point, its very very bad from a techies view point, especially when taking a longer or larger view (ie enterprise projects with a product lifespan of longer than 6 months).

    And its nice to rant about something!

    Jonathan
    ps completly off thread.
    Reply to this Reply to original

  100. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Christina is starting her career as a journalist here at SD Times and handles day-to-day reporting while TRYING DESPERATELY TO UNDERSTAND the ins and outs of the computer software industry. she received her bachelor’s degree from Hofstra University in print journalism where she was the managing editor of their student-run newspaper, the chronicle. She is also an avid photographer and sports junkie." - bzteam/SDTIMES


    They changed her description since we last shead light on her background. Take a look at her NEW description.

    http://www.bzmedia.com/bzteam.htm
    Reply to this Reply to original

  101. Whatever happened to building portable J2EE applications?[ Go to top ]

    &#8220;Anyone that is doing enterprise Java development is learning that you don&#8217;t pick up an application from one application server and drop it on to another without any pain,&#8221; said Zachmann.

    Zachman seems to be viewing the enterprise landscape rather narrowly because he would otherwise know that there ARE indeed solutions for painlessly deploying J2EE applications across J2EE compliant application servers such as BEA WebLogic, IBM Websphere, and JBoss/TomCat.

    AltoWeb is one such solution - and is leading the pack as a J2EE Production Platform. It's easy to see that these guys had an advantage having the former CEO of WebLogic - Ali Kutay providing the vision for this J2EE production platform. Clearly from his experience at WebLogic, he could foresee the next big enterprise requirement would be to maintain J2EE interoperability through solutions that

    1. Would make it seamless to assemble J2EE applications without having to keep up with changing standards

    and

    2. To empower customers in deploying their solutions across any platform - operating system or application server.

    Is JCP moving a bit slow to resolve proposed "standards"? - perhaps, but that doesn't mean that customers are forced into vendor lock-in. Companies such as AltoWeb recognize that customers are wary of the risks involved with obtaining all of their enterprise solutions from a single vendor. So it acts as a neutral platform in which to assemble, deploy, and monitor your J2EE applications regardless of the app server or operating system.

    The SDForum article obviously has been written to create panic around the coming of Cajun, but we should simply recognize this for the hype that it is. Choice is good.
    Check one of them out: http://www.altoweb.com
    Reply to this Reply to original

  102. Whatever happened to building portable J2EE applications?[ Go to top ]

    AltoWeb may in fact be all you say but from what I recall, Mr. Kutay was there to sell WebLogic to the highest bidder.

    Reply to this Reply to original

  103. Whatever happened to building portable J2EE applications?[ Go to top ]

    On a side topic, what about different behaviour between app. servers for J2EE-compliant code? We just ran into an issue with WLS 6.1's handling of filter post-processing of responses. Basically, trying to buffer the response object (so that you can add headers after the response has been generated, for example) is broken. The same code runs correctly in Tomcat.
    Reply to this Reply to original

  104. Whatever happened to building portable J2EE applications?[ Go to top ]

    That sounds like a bug to me, not a portability issue. Hopefully, there are not too many of these when porting from one app server to another.

    Incidentally, I've found porting my Web Applications far easier than porting my EJBs. As noted before, app server specific deployment descriptors tend to be the biggest problems. I do most of my servlet/JSP development in Resin and deploy on Weblogic. Everything app server specific is stored as properties in the database and get loaded on class creation. In this way, my app is completely portable. It took a bit of work initially but now my apps, including config meta data, are completely data driven.

    Reply to this Reply to original

  105. Whatever happened to building portable J2EE applications?[ Go to top ]

    I have to agree with most of this article.
    Who wouldn't want to develop with tools that allow you to accomplish your work quickly and accurately. As a developer, I must also gather requirements, test, meet with users, sit through status meetings and still complete the work on time.
    I work with both VB and Java and find that the tools provided by Vstudio allow for RAD. To develop and deploy something quickly in Java/J2EE, I would much prefer to use an IDE that integrates completely with the App Server. As a developer I should not have to worry about deployment issues.
    Project managers want a system deployed on time and on budget. If that means that the development team needs a fully integrated solution from Oracle or BEA, then so be it. The idea of write once, run everywhere is a marketing gimic sold to upper level management who will buy onto anything if told that it will save them money.
    When it comes down to it, I need to work with tools that will allow me to develop something rapidly and perform well enough to satifsy the users. If you actually have months, years to work on something and never have to meet a deadline, then stick with your J2ee mantra and consider yourself a hobbiest. However most of us are required to produce something by the end of the day and which ever setup (ide and appserver) gets the job done, that's what we will do.
    Reply to this Reply to original

  106. Whatever happened to building portable J2EE applications?[ Go to top ]

    "I work with both VB and Java and find that the tools provided by Vstudio allow for RAD. To develop and deploy something quickly in Java/J2EE, I would much prefer to use an IDE that integrates completely with the App Server. As a developer I should not have to worry about deployment issues. "

    Wayne, you're completely wrong and very narrow-minded. If you don't want to be concerned with deployment issues, write a stink' batch file to deploy your apps and be done with it. What deployment issues are there in Java? Hardly any at all. I don't even think about deployment, I just click on a batch file. Try THAT with a m$ environment!
    Reply to this Reply to original

  107. Whatever happened to building portable J2EE applications?[ Go to top ]

    When I develop something, isn't it nice to just be able to "make" the DLL and then go and test the code in my asp page, without having to run some batch script? Where's the Rapid development in that approach?
    As a developer, I'm concerned with getting the job done and avoiding those obstacles that slow me down. Granted, I don't consider myself a Java expert, but I have worked enough with Websphere and Oracle App server to have formed some opinions about my likes and dislikes.

    And with regards to commenting on other people's replys, you might want to consider your writing style. If you want to be thought of as knowledgeable and helpful and express your ideas to the general public, you need to articulate yourself better so as to not come across as a biased and stubborn person. Your M$ comments only suggest that you are insecure about your place in IT, and maybe are concerned that being so narrowly focused on Sun Java technologies may limit your career potential. To succeed in the IT world, you should have a thorough enough understanding of all technologies in order to design and architect a business solution for your clients that is in their best interests, not yours.

    " Wayne, you're completely wrong and very narrow-minded. If you don't want to be concerned with deployment issues, write a stink' batch file to deploy your apps and be done with it. What deployment issues are there in Java? Hardly any at all. I don't even think about deployment, I just click on a batch file. Try THAT with a m$ environment! "
    Reply to this Reply to original

  108. Whatever happened to building portable J2EE applications?[ Go to top ]

    "When I develop something, isn't it nice to just be able to "make" the DLL and then go and test the code in my asp page, without having to run some batch script? Where's the Rapid development in that approach? "

    What? What's not "rapid" about clicking a file? I think you misunderstand me.
    Reply to this Reply to original

  109. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Your M$ comments only suggest that you are insecure about your place in IT, "

    Lol... that's all I have to say about that.

    "and maybe are concerned that being so narrowly focused on Sun Java technologies may limit your career potential."

    I graduated from m$ technologies long ago; if I had to go back into that, I would absolutely leave the IT field, believe me. I always wanted to be an attorney anyway.

    "To succeed in the IT world, you should have a thorough enough understanding of all technologies in order to design and architect a business solution for your clients that is in their best interests, not yours. "

    I disagree with that. I would asser that the IT field is too big and that people have to specialize in something they like. If there's an "expert" on both m$ and Java out there, they're very rare, as that would take quite a bit of time. And I have absolutely no interest whatsoever in keeping up with m$ technologies. If a company mandated that "technology" was used for a project, I would go on to the next company.
    Reply to this Reply to original

  110. Whatever happened to building portable J2EE applications?[ Go to top ]

    "When I develop something, isn't it nice to just be able to "make" the DLL and then go and test the code in my asp page, without having to run some batch script? Where's the Rapid development in that approach? "

    Wayne, I wanted to show you how you can be far more productive with Java.

    1) Download the latest version of Resin from www.caucho.com
    2) Create your tree structure on your hard drive that matches the servlet 2.2 spec.
    3) modify resin's resin.conf file to point at your working directory above
    4) Throw away your Dlls, asp, IDE, compiler and other fancy tools as all that is now automatically handled for you. What's more, your web application code is completely portable.
    Reply to this Reply to original

  111. Whatever happened to building portable J2EE applications?[ Go to top ]

    Sounds like wayne needs a little experience in programming-101.

    Also, wayne, try running your dll under unix. oh wait, unix doesn't matter.
    Reply to this Reply to original

  112. Whatever happened to building portable J2EE applications?[ Go to top ]

    I realise that this is a change of topic, but I must comment on the way many of the threads here mutate into J2EE/Java vs .NET/C#. I'm usually a bit of a lurker - read a bit here, read a bit there, digest some info over there. I lurk at a number of sites, including .NET sites, as I tend to be a bit promiscuous with tech :-). As a consequence, I'm very aware of the contrast in the debates. In particular, there is nobody at the other sites advocating J2EE over .NET.

    Out of interest, I did a quick google search across the serverside site with ".NET" and Microsoft as the keywords. Amazingly, I got 6 pages of hits.

    Now, do the same thing at gotdotnet with Java and J2EE as keywords - 1 page, and most are official releases from Microsoft. Do it again at www.asp.net - 1 single hit (not 1 page, only 1 hit).

    With statistics such as the above, you have to wonder - why? Why are Java sites magnets for .NET advocates, but not the other way around?

    I have a few theories myself ...
    Reply to this Reply to original

  113. Whatever happened to building portable J2EE applications?[ Go to top ]

    Gerhard, I can tell you why I post J2EE questions with .NET tie-ins over here and not on getdotnet.

    First, this web site allows me to extract more information on J2EE products. There is only one set of Microsoft products while there are over a dozen J2EE products. Needless to say, it takes a lot more research to do a fair evaluation on J2EE side because you have many more products.

    Second, this site has active J2EE vs .NET forums where we can see the J2EE point of view best championed. Also the site is more user-friendly in presenting debate forums.

    Third, there are a few cons of J2EE development that I'm trying to clear up (performance, complexity, IDE, Linux compatability, portability across vendors) but only one super-major con on the .NET side (vendor lock-in). [Security/Reliability are issues for all products]

    These are the reasons why I've been frequenting this website. I may wander over to gotdotnet and see if there are some good discussions over there. Regards.
    Reply to this Reply to original

  114. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Third, there are a few cons of J2EE development that I'm trying to clear up (performance, complexity, IDE, Linux compatability, portability across vendors) but only one super-major con on the .NET side (vendor lock-in). [Security/Reliability are issues for all products] "

    William,

    What is there a negative regarding Java ide's, or portability, Linux compatibility or performance??? I'm assuming you're new to the Java realm, so let me suggest these in answers to your question:

    Borland JBuilder - it's free, easy to use, and is simply awesome.

    Linux compatibility - Java is completely portable. You'll notice if you download an API from somewhere (e.g., the apache xerces XML parser library) you'll get "one" set of .jar files. That is because the .jar will run just fine on Linux as well as m$ or anything else.

    COmplexity - nothing worth having is easy. And I would submit that the m$ technologies (oxymoron) "seem" simple at first to lure in developers, but afte rthat, nothing seems to work. I had a vb "guru" once tell me that he had to periodically re-install his apps and format his drive because deploying vb and c++ programs destroyed his computer. And, believe me, this guy knew his stuff big-time. Also, Java is a fully object-oriented language with capabilities to do just about anything in the application development realm you could possibly imagine.

    performance - a properly-written Java program performs almost as good, sometimes better, than a C++ program with FAR, far fewer possibilities of bugs. Sun calls it a "safer" language, I call it a "kinder, gentler C++." And forget about vb. Java's multithreading is an amazing match for server-side development; unfortunately, it's been my experience than many, many developers don't even utilize multithreading and lead to many poorly-scaling and poorly-performing apps. But, make no mistake, Java is VERY well-performing platform. Just look at some of the sites out there done "right" in Java.

    Also, as you mentioned m$ technologies are vendor-lock-in. To me, that right there ends the discussion alone. No need to continue.

    </soapbox>
    Reply to this Reply to original

  115. Whatever happened to building portable J2EE applications?[ Go to top ]

    Thanks for your input Tracy. I'm new to Java realm and am going through as much material as possible. We plan on doing some hands-on testing while continuing to look at reviews. Although this is off-topic now, I should answer your points.

    "Borland JBuilder - it's free, easy to use, and is simply awesome"
    As far as I can tell, Borland JBuilder 6 Enterprise (what I'd need) is $3000 and the Advanced version is $1000. Which version is free? Seems like its pretty good from what I've read although it has few quirks. Have you personally used its UML modelling?

    "Linux compatibility - Java is completely portable."
    Well, actually I'm talking more about Linux support/optimizations. Most of the J2EE app server production deployments seem to run on proprietary versions of Unix (e.g. Solaris) or Windows. Iona E2A J2EE Tech Edition 5.0 (release notes Feb 2002), one app server we are considering, currently doesn't install to Linux although it handles a variety of other OSes. I would agree that this is probably a non-issue in the future, esp. with Sun just announcing a ramp-up on its Linux support.

    "COmplexity - nothing worth having is easy."
    I'd agree here. But your VB example is a deployment/reliability case example - not pertinent to .NET. As a professional C++ programmer having built mission-critical applications used in surgery/radiotherapy, I would dispute MS reliability and furthermore say many J2EE app servers are hardly bullet-proof either. (Lots of examples throughout ServerSide on this issue.) This is really a J2EE vs .NET framework issue and not Java vs C#.

    "performance - a properly-written Java program performs almost as good, sometimes better, than a C++ program"
    I'd dispute Java programs getting better performance than C++ programs, and it's not particularly relevant. Once again, this is more a frameworks issue (transaction monitors, DB, front-end, and how they work together). See the thread on Petstore if you want to debate this issue, but the lack of performance benchmarks on the J2EE (not Java) side is quite troubling.

    As mentioned above by others, vendor lock-in is bad but not a deal killer for me. Rather have future-proofing through J2EE but have to make sure I'm not giving away too much for it.
    Reply to this Reply to original

  116. Whatever happened to building portable J2EE applications?[ Go to top ]

    ""Borland JBuilder - it's free, easy to use, and is simply awesome"
    As far as I can tell, Borland JBuilder 6 Enterprise (what I'd need) is $3000 and the Advanced version is $1000. Which version is free? "

    The free version of jbuilder is freely downloadable from their site; that's all I've used with huge success for years.

    "the lack of performance benchmarks on the J2EE (not Java) side is quite troubling"

    I don't need them; I can tell from the apps I have dealt with and authored that properly-written multithreaded Java performs fantastically and can't be beaten.

    Good luck with your C#.
    Reply to this Reply to original

  117. Whatever happened to building portable J2EE applications?[ Go to top ]

    Tracy, are you using EJBs and if so, on what app server & for what kind of application? Thanks in advance.
    Reply to this Reply to original

  118. Whatever happened to building portable J2EE applications?[ Go to top ]

    "Tracy, are you using EJBs and if so, on what app server & for what kind of application? Thanks in advance. "

    Yes, we're using bmp's and stateless and statful sessions; we're using wls 5.1 STILl :( so cmp's are out. Also there are a number of applications. cya
    Reply to this Reply to original

  119. Whatever happened to building portable J2EE applications?[ Go to top ]

    Ladies and Laddies:
    Folks, now someone was wondering out loud if this is a debate of J2EE versus Microsoft, and I think that really is not the case. J2EE is nothing BUT a specification, and Sun Micro is not the owner of that spec. but just an author. J2EE manifestations are springing up with vendor embellished stuff-ola, as would be the case with any open source stuff-ola. So, while Microsoft's .NET IS a product suite, J2EE is not. That said, let me just say some things about the portability of J2EE.
    Has anyone tried to do the XML deployment descriptors some vendor products like Weblogic ? Or even Websphere? It is a bloody pain in the you know what. As I sit in my garage manufacturing some very COOL BEANS, i wonder if all this hype of J2EE does in fact give me yet another opportunity for my company of one to develop some cool Best Practices for J2EE? But the portability issues will remain until such time that the purveyors of J2EE based products do not get carried away with all the too consuming creative aspects and brand recognition aspects of their interpretation of J2EE.
    Reply to this Reply to original

  120. Whatever happened to building portable J2EE applications?[ Go to top ]

    And I always thought that Bean Managed Persistence is far from a desirable thing. Is it not Sun itself that says that as a possible knock against J2EE? So, what gives, eh you wild woman? (;-)
    Reply to this Reply to original

  121. Whatever happened to building portable J2EE applications?[ Go to top ]

    Tracy Milburn writes:

    "Borland JBuilder - it's free, easy to use, and is simply awesome."

    I got a bit PO'ed with Borland recently after I had popped for a 'student' version of JBuilder5 Enterprise for about £400, only to see it last about 3 months before Borland come out with JBuilder6. No easy upgrade of course. I've tended to stay with free stuff since then, as Borland seems to want me to be a cash cow for them.

    To be honest the most impressive package I've seen recently is the HP Bluestone App Server product, HP-AS 8.0, which they will ship to you free if you register. It includes an EJB 2.0 compliant app server, an IDE named Radpak, and a cd full of training 'trail maps'. The entire product worked very well and blew my socks off. Completely free, and can be embedded in shippable apps. The only catch is when you want to cluster and load balance. Another version is required for that, favorably priced with Weblogic.

    "Linux compatibility - Java is completely portable. You'll notice if you download an API from somewhere (e.g., the apache xerces XML parser library) you'll get "one" set of .jar files. That is because the .jar will run just fine on Linux as well as m$ or anything else. "

    Yup. This is why I switched from C++ to Java in the first place. Completely portable if you stay away from JNI.

    "COmplexity - nothing worth having is easy. I had a vb "guru" once tell me that he had to periodically re-install his apps and format his drive because deploying vb and c++ programs destroyed his computer"

    I believe this. I had a helluva bad experience installing Oracle 8i once. I think M$ apps (and Oracle) heavily rely on the M$ Registry, which apt to go badly wrong on you! The most you need do with any Java package I can think of is add something to your Path and Classpath.

    People get frustrated with Java sometimes because you need to get *exactly* the proper JVM with a downloaded package, and this can lead to a lot of cussing in early days before you get the hang of things. Basically you have to find and install the proper version of the Sun JDK just before installing the package. That's all.

    "Also, Java is a fully object-oriented language with capabilities to do just about anything in the application development realm you could possibly imagine."

    Agreed. Actually Java is more of a community, with initiatives going on all over the place! Very hard to keep up with it all. Off the top of my head there is JSP, Servlets, EJB, JMS, JCA, Jini, Jiro, Javaspaces, and a ton of industry-specific API's out there to be explored. It's the most exciting thing going in architecture I think. There is attendant complexity, sure. But you pay for the simplicity of .NET by becoming a Microserf....


    Reply to this Reply to original

  122. Whatever happened to building portable J2EE applications?[ Go to top ]

    For companies with mixed application server environemnts (over 40% of large enteprises by some estimates), building portable J2EE applications is a must. Additionally, many people want to start building their applications without having selected an application server (I have seen many people build on an open source app server and want to deploy on a Weblogic, etc.).

    To help you build truly portable J2EE applications, you should investigate using a framework or some other type of application server neutral architecture. Our company, Wakesoft, provides such a framework. Applications written with Wakesoft can be deployed on any J2EE compliant application server with a minimum of effort.

    We are finding that companies with mixed app server environments truly appreciate this type of low-friction portability.

    To learn more about Wakesoft and how Wakesoft can help you build portable J2EE apps, check out our weekly webinars or download our product for a free 30-day evaluation at http://www.wakesoft.com

    Sorry for the blatant product plug, but it seems quite relevant to the thread.

    Harley Sitner
    Wakesoft
    Reply to this Reply to original