Discussions

News: Analyst Report: J2EE In Jeopardy?

  1. Analyst Report: J2EE In Jeopardy? (59 messages)

    The Burton Group has done a study titled J2EE: A Standard in Jeopardy. Richard Monson-Haefel argues that "companies like JBoss, Apache Geronimo and Object Web's Jonas are commoditizing the standard and other projects like Spring, Hibernate and Apache Tomcat are providing a "simpler and good enough" model."

    While this may be true. Is that a bad thing for J2EE?

    Keith Donald, of The Spring Framework, thinks that J2EE is better off DUE to the open source advancements:
    I strongly believe J2EE is better than its ever been, because there are more choices now than ever. There are better ways of tapping into the J2EE stack than ever before! For over a year I've been leveraging The Spring Framework as the base architecture for my development projects. I can now treat J2EE infrastructure as a separate concern, one fully decoupled from the business logic ("core meat") of my application. Spring lets me choose which deployment environment is most appropriate for my application given the complexity of the domain problem at hand. That puts me in command: if all I need is a web container running Java Servlets to power a web application, Tomcat is best cost. For middle-ware intensive apps that require messanging, global transactions, and remoting, a higher-end EJB-capable application server is worth the investment.

    I'll say it again, J2EE is better than ever: for the consumer. I read success story after success story from real people working on projects with frameworks like Spring and Hibernate. And they're leveraging them in all kinds of environments and application servers--to support demands of all scales. This article, unfortunately, puts a bad spin on J2EE--it's a GREAT time to be developing enterprise applications in java. It's a great time to be a consumer.

    Read Report: J2EE in Jeopardy

    Read Keith Donald in J2EE in Jeopardy: a bad spin

    What do you think?

    Threaded Messages (59)

  2. Analyst Report: J2EE In Jeopardy?[ Go to top ]

    I don't think J2EE is in jeopardy at all, EJB, maybe, but not J2EE.

    I think the problem lies in the API, Sun specified an API for vendors, not for application developers. Developers don't want to have to worry about connection management, lifecycles, transactions, etc. The J2EE spec exposes those concerns to the developer.

    Tools like Spring, Hibernate, etc are developer oriented technologies (where J2EE is vendor oriented). Spring isn't a great framework. It's simply a collection of easy to use beans. Everyone and their cousin has written or used an IoC bean container and Spring is simply a collection of beans that make the developer's job easier.

    I believe the use of metadata in EJB3 and the work of BEA's Beehive project is a step in the right direction (I simply write beans and don't care how the container does its magic).

    Anyways, that's just my 2 cents--
  3. The J2EE spec exposes those concerns to the developer.Tools like Spring, Hibernate, etc are developer oriented technologies (where J2EE is vendor oriented). Spring isn't a great framework. It's simply a collection of easy to use beans. Everyone and their cousin has written or used an IoC bean container and Spring is simply a collection of beans that make the developer's job easier.

    I am somewhat confused as to what Jacob is trying to say here... I think he's saying Spring is good, but it's good not because it's a framework, but because it's just a bunch of JavaBeans you use. Well this is true and false of course. It's true that declaratively and programmaticly you use Spring mostly as JavaBeans, but the reality is that the code (of which there is a lot) in those JavaBeans, however you use it, is still a framework. I also don't see how the powerful IoC container and AOP implementation in Spring, which makes hooking up and using those JavaBeans much easier, also a part of the framework, and a key part thereof. W/respect to some things such as declarative transactions, capabilities like the AOP support are key to even implementing that functionality, JavaBeans usage-style or not.

    So I would say Spring is very much a framework, in every sense of the word... Just the usage patter is different from the traditional framework of a few years ago...

    Colin
  4. don't see how the powerful IoC container and AOP implementation in Spring, which makes hooking up and using those JavaBeans much easier, also a part of the framework, and a key part thereof.

    That should of course be:

    don't see how the powerful IoC container and AOP implementation in Spring, which makes hooking up and using those JavaBeans much easier, isn't also a part of the framework, and a key part thereof.
  5. Opensource virus[ Go to top ]

    Richard Monson-Haefel argues that "companies like JBoss, Apache Geronimo and Object Web's Jonas are commoditizing the standard...


    Nice one, so opensource will kill J2EE. I knew opensource is bad from the very start.
  6. Opensource virus[ Go to top ]

    The sooner someone puts it out of it's misery the better, have you ever actually had to use it ?

    Say hello to the 10 minute code umpteen classes, test, check console, wonder what's broken, impossible to debug cycle .....

    --b
  7. its a matter of where it _should_ be[ Go to top ]

    Java 2 Enterprise Edition. J2EE is a container based framework for enterprise applications. Unfortunately it has wedged its way into a market it shouldn't have - smaller much more simple applications.

    Where you have requirements for 2pc, high availability, back-end integration, and other such trickly items, J2EE is great.

    Where you _don't_ have these requirements, lightweight approaches are far more effective in almost every sense.

    I believe that the mindshare of the spring/hibernate/tomcat approach has reached the level where most people are aware of the option.

    So J2EE the standard isn't failing. It isn't in jeopardy. It is merely being trimmed back to its proper and targetted place - a framework for enterprise applications, as apposed to all applications.

    In my opinion this makes it more successful, not less.

    -Hugh
  8. This article makes no sense...[ Go to top ]

    It's hard to tell what the heck the author and the sources are trying to say.

    For example:"Should porting to native open source components rather than writing to Java specifications and a [Java Virtual Machine] approach be beneficial?"

    Are they talking about using PHP or Python instead of using Java?
  9. My view points[ Go to top ]

    I would like to make few points here. I am not clearly favoring any one side.

    1) AS long as you have "RIGHT" architecture, and you have used all the components at right place, most of the time, J2EE and .Net serves the same purpose.

    2) I like J2ee better as it's more cleaner and more OOP(and so less complicated).

    3) As long as these open source components are complimentary to J2ee and are really "OPEN", I don't think J2ee is in jeopardy.

    4) In our current project, we avoided using ENTITY EJBs and ever state less session bean due to lot of overheads. That makes me nervous about J2ee.


    Sorry if I said or raised any wrong point.

    MaxJava
  10. dotnet was first ?[ Go to top ]

    Did anybody notice this ?
    As a business tool, J2EE has achieved mass adoption because vendors like Sun, IBM, BEA and others are promoting it as a viable alternative to Microsoft's .NET framework.

    Huh, and you take this article seriously after such claims ?
  11. dotnet was first ?[ Go to top ]

    Did anybody notice this ?
    As a business tool, J2EE has achieved mass adoption because vendors like Sun, IBM, BEA and others are promoting it as a viable alternative to Microsoft's .NET framework.
    Huh, and you take this article seriously after such claims ?

    I certainly thought that this phrase was hinting about the mind set of the author...
  12. Development Effectiveness[ Go to top ]

    Well, J2EE is useful in providing some of the heavy-weight infrastructure for enterprise requirements.

    But a major advantage of newer approaches such as JDO and light-weight technologies, is in allowing business requirements to be expressed *directly* rather than having to go through all the indirection/ complexity required by J2EE.

    For developers working on business systems, you want to write code that directly expresses business requirements. Anything else is misuse of the language; if you're not focused on the actual task but on awkward intermediary gak and failed object semantics (eg non-portable references) your productivity is going to be vastly reduced.

    One problem was that the J2EE design attempted a 'magic bullet' solution, RMI, to the wrong problem. Applications require data storage, transactionality and management, with a little bit of distribution. J2EE instead focused on remoting and applied it to everything... which is why we have the ugliness, overhead, and polluted object semantics.

    These days application demands are better understood. We can more effectively implement applications by focusing on the application model and logic, serving these through a facade, and placing remoting only at selected boundaries where it is needed.

    As has been understood for 30 years, the network connection is placed between the user session and the database. Not between every object within a session.


    Cheers,
    Thomas Whitmore
    www.powermapjdo.com
  13. Development Effectiveness[ Go to top ]

    A major advantage of newer approaches such as JDO and light-weight technologies, is in allowing business requirements to be expressed *directly* rather than having to go through all the indirection/ complexity required by J2EE.

    Exactly. Capturing business contracts as plain old java interfaces independent of any infrastructure technology is critical to the development of focused, well-layered, adaptable, and easily testable applicationa. Combine that with a facility that selects, configures, and assembles fine-grained business object implementations (generally POJO based) into a working application FOR YOU, and the ad-hoc glue code you have to write is reduced to zero. Add on the capability to decorate those same business components with standard J2EE services (e.g. remoting, transactions, security facades) transparently and declaratively, and now you've got yourself an architecture that can scale up or down rapidly with little to no change required in application code.

    That's what Spring and approaches like it are all about. I believe this is the way of the future, and that's very good for J2EE. It's about providing a better way to tap into the power of the J2EE stack--and into the parts of it you need, when you need them.
  14. Development Effectiveness[ Go to top ]

    Well, J2EE is useful in providing some of the heavy-weight infrastructure for enterprise requirements.But a major advantage of newer approaches such as JDO and light-weight technologies, is in allowing business requirements to be expressed *directly* rather than having to go through all the indirection/ complexity required by J2EE.For developers working on business systems, you want to write code that directly expresses business requirements.

    I am wiping away the tears laughing. The effort and the turnaround time for even getting concise business requirements out of any medium sized real-world business is so long and cumbersome that the indirection and complexity of J2EE is a minor point anyway. The general idea of expressing business requirement in interfaces (and data objects) seems pretty nice, but in the real world it needs architectual consideration beyond interfaces and data objects.
  15. Development Effectiveness[ Go to top ]

    As has been understood for 30 years, the network connection is placed between the user session and the database. Not between every object within a session.

    This should have been obvious to people doing the EJB spec. Also they should have known that distributed systems can't be programmed in synchronously, because that's a waste of resources. From the time of Distributed LISP it has been known that the MDB model is the right way to go, but MDB is pale in comparison to Distributed LISP.
  16. "Perfect Hit"[ Go to top ]

    Thomas Risberg has some really insightful words on this subject:

    What do you mean by J2EE? It's interesting to see people's reaction to the "J2EE in Jeopardy" article. I would say that I agree with most that is said in that article even if some of the points seem to need some clarification. I don't necessarily agree with the title since I do agree with Keith here - J2EE is stronger today than it ever was.

    One issue I have is that we rarely qualify what we mean with J2EE in these discussions. Are we talking about the "Technology Platform" made up of all supported APIs or are we talking about the "Programming Model" as expressed in Sun's blueprints and in the Java Pet Store? Spring and other "lightweight" frameworks are challenging the "J2EE Programming Model" while embracing the "J2EE Technology Platform", which means that unless you qualify what you mean by J2EE, any statement about the relationship would be ambiguous. The only part of the "Technology Platform" that is being challenged is the EJB Entity Bean specification. And it seems that Sun does agree here. They are looking for a new persistence solution in EJB 3.0. Ironically, they already have the solution available in JDO as acknowledged by Sun's Mick Jordan. The following are two quotes from his report Comparative Study of Persistence Mechanisms for the Java Platform -

    "The EJB framework came out worst, requiring the largest number of changes to the source code and delivering the worst performance and scalability."

    "At the other extreme, acceptable EJB performance seems unattainable at present unless dramatic changes are made to the application object model to avoid fine-grain objects when mapped to EJB. While this approach is now reflected in standard design patterns for EJB, the extra effort that it implies is disturbing from the overall application design perspective. In contrast, JDO manages to achieve reasonable performance at much lower impact on application design, while remaining agnostic to the nature of the external data store. Therefore, at this time, JDO would seem to offer the best overall persistence mechanism for demanding, object-oriented, applications."
  17. "Perfect Hit"[ Go to top ]

    Thomas Risberg has some really insightful words on this subject:

    Exactly ! Those open source frameworks/containers don't compete with J2EE. They have some influence on J2EE standart (for example, EJB3 and Hibernate) which allows J2EE to evolve better.

    I have got impression, that this "J2EE in Jeopardy" article is written by some yet another clueless person.
  18. "Perfect Hit"[ Go to top ]

    I have seen some software developers that had been writing JSP pages for a long time. Once they heard that we will write some EJB's too, they started to scream in excitement "mate, we are going to use J2EE !" :-)
  19. Clueless?[ Go to top ]

    ...report author and Burton analyst Richard Monson-Haefel told internetnews.com...
    I wouldn't call Monson-Haefel 'clueless'.
  20. I dont care if J2EE is in Jeopardy or Not!

    In the Enterprise Scenario, currently these are 2 Major Solutions.

    1. MicroSoft Technology Solutions (.NET Based)
    2. Sun Technology Solutions (JAVA Based)

    Any alternate to J2EE would still have similar Enterprise concepts and its not a big deal to move on.

    On the other hand if you are saying .NET would replace J2EE then I would be a little concerned, Since now I have to learn MS Visual Studio.
  21. 2. Sun Technology Solutions (JAVA Based)
    No, not necessarily SUN. There are many J2EE "solutions" provided by other companies, including IBM, BEA, Oracle and Borland.
  22. J2EE is only the basement the stack[ Go to top ]

    Today J2EE app servers are only the basement of the whole family of integration, presentation and trasactions, ... There is more than J2EE and opensource systems (in my opinion) are not catching up.

    Things like BPEL (IBM and BEA), portals (again IBM, BEA and some plumtrees :-), integration with adapters (IBM, BEA + iWay and maybe Oracle) really matters to customers. If I want to make my homepage with jsps, ejbs and jms, I`ll definitely go to opensource JBoss (or Sun).
  23. If I want to make my homepage with jsps, ejbs and jms, I`ll definitely go to opensource JBoss (or Sun).

    I agree, and it's interesting that the servers you mentioned are two of only a handful of production ready implementations of the latest J2EE 1.4 standard. This standard has been out for quite a while but the big vendors are taking their time to implement it. They seem to be focusing more on this "J2EE super platform" that you and also Monson-Haefel mention.
  24. I agree iwth K. Donald[ Go to top ]

    I have to agree with Keith Donald. The J2EE Standard is in a much better position thanks to open source initiatives such as Struts and Hibernate... After working with both Struts and Hibernate, I can say that J2EE is still useful in many ways. I don't see how these "other projects" can put the standard in jeopardy, on the contrary it strenghtens it, in my humble opinion.
  25. to hear it?
    JBoss and Geronimo don't change the fact that EJB (yes v3 too) sucks.
    They all need to stop pushing it, or get sued when above mentioned happes.

    And lets not forget that Tomcat is J2EE too :-).
    You have a sweat spot with JSTL, Struts and iBatis, they use J2EE
    SoA is the way to go insted of EJB, like Hesian. (And SoA is J2EE)

    My concren like anothers above is that if O/S and non-O/S continue this path, which seems institusionlized, I have to learn Visual Studio.

    Hello "Expert Group", users here have a word?

    .V
  26. New Buzzword[ Go to top ]

    J2EE = MOP ( Marketing Oriented Programming )

    --b
  27. Analyst Report: J2EE In Jeopardy?[ Go to top ]

    We are moving a lot of projects from J2EE to .NET platform. Cheaper, easy to use, one vendor.
  28. Analyst Report: J2EE In Jeopardy?[ Go to top ]

    We are moving a lot of projects from J2EE to .NET platform. Cheaper, easy to use, one vendor.

    I guess it's only fair, since we're seeing tons of old COM/DCOM-style apps being moved over to Java.

    Anything to keep employment up ..

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  29. Analyst Report: J2EE In Jeopardy?[ Go to top ]

    Then use Java instead of J2EE.
  30. Analyst Report: J2EE In Jeopardy?[ Go to top ]

    We are moving a lot of projects from J2EE to .NET platform. Cheaper, easy to use, one vendor.

    Nice stuff... If YOU are doing it, it must be the industry trend... I'm definitely going to think twice the next time I start a new project, now that I know that you are moving "A LOT OF PROJECTS" to .NET... Thanks for the tip!
  31. the other way around[ Go to top ]

    Long ago somebody (Cameron) wrote that my talk about .NET and J2EE actually was advantageous to Java, "my opinions and talk lured more people to Java" ie the opposite of my intent.

    Alas, I think there are more probable that as more people hold on "institutionalized" EJB the more will choose .NET.

    Regards
    Rolf Tollerud
  32. the other way around[ Go to top ]

    Long ago somebody (Cameron) wrote that my talk about .NET and J2EE actually was advantageous to Java, "my opinions and talk lured more people to Java" ie the opposite of my intent.Alas, I think there are more probable that as more people hold on "institutionalized" EJB the more will choose .NET.RegardsRolf Tollerud

    Rolf:

    Switching to .NET isn't something a datacenter running *nix would consider. Since when did every complaint about Java result in a "Let's switch to .NET mentality".

    Perhaps you should stick to facts in future. That way you also won't make outrageous claims about the performance of C# vs Java like you did here and come off second best:
    http://www.javalobby.org/thread.jspa?forumID=61&threadID=15026&start=0&msRange=30
    It is rather amusing to watch the Javalobby coders leave Rolf in the benchmarking dust ;)
  33. Corrected link[ Go to top ]

    I posted the wrong link.
    Here is the correct URL:
    http://www.javalobby.org/threadMode2.jsp?forum=61&thread=14768&start=150&msRange=30
  34. the other way around[ Go to top ]

    Long ago somebody (Cameron) wrote that my talk about .NET and J2EE actually was advantageous to Java, "my opinions and talk lured more people to Java" ie the opposite of my intent.

    Alas, I think there are more probable that as more people hold on "institutionalized" EJB the more will choose .NET.

    Regards
    Rolf Tollerud
  35. they never let go..[ Go to top ]

    We are not getting anywhere, they won't listen. It is necessary to try another angle - like when raising small kids, you have to be pedagogic.

    We just have to find some other thing that the EJB people can be proud of! We can not take away all a persons self esteem without giving something in replace, can we?

    But what shall we give instead? It is a problem.

    Any suggestions?

    Regards
    Rolf Tollerud
  36. P.S.[ Go to top ]

    Grid computing?

    Remember it has to be:
    1) LARGE (Millions of rows of code..)
    2) EXPENSIVE
    3) "COMPUTER SCIENTIFIC"

    (Just trying to be helpful.. ;)
  37. Carifications[ Go to top ]

    Here is the main point, which may have been missed.

    1. The Threat of Commodization
    The open source project are commoditizing the J2EE platform. That's not a value judgment, it's a fact. The J2EE specification is expensive to maintain. Sun and other vendors have to develop the spec (employees time), implement a TCK (very expensive software to create) and an RI (also very expensive). If vendors can't make money on J2EE, than they will not want to invest in the continued development of the specification. This is one reason J2EE as a standard is in jeopardy.

    2. The Threat of Disruptive Technologies
    Alternative frameworks (including Servlet only model) service a neglected low-end market with simpler tools that are generally free. If you have studied Innovation Theory you would recognizes this as classic scenario for a disruptive technology. People are moving to Spring and Hibernate and other alternatives without J2EE - as long as J2EE remains complex and fat this migration will continue until more people are using the alternatives.

    3. The Threat of J2EE 5.0
    Simply put, it's a catch 22. If the JCP succeeds in making J2EE simpler it may eliminate most of the standard programming model - POJOs and ID are difficult to lay IP too. If they don't simplify J2EE, enter the disruptive technologies.

    There are a couple of other threats including Microsoft .NET and Model Driven Development, but those above are the primary areas of concern.

    This is not a value judgment about J2EE, it's simply an analysis of market pressures that threaten to mitigate the importance of J2EE in the market. The report, which will be published later this week, provides recommendations to vendors on how to preserve the J2EE standard and why they should. It also provides recommendations to end-users on how they should hedge their bets to mitigate problems if J2EE should go away.

    If you want to learn more about me, the author, you can visit my web site at http://www.monsoon-haefel.com. You'll find my bio and other stuff.
  38. missing the main point[ Go to top ]

    Here is the main point, which you missed:
    EJB technology is a total disaster for the Customers.

    "The J2EE specification is expensive to maintain."
    Don't make me laugh. It is the Goose with the golden eggs.

    Regards
    Rolf Tollerud
  39. missing the main point[ Go to top ]

    It is the Goose with the golden eggs.
    Exactly. And OSS Jack is stealing the eggs. What will the giant do?
  40. missing the main point[ Go to top ]

    Correction

    It was the Goose with the golden eggs. Imperfect.
    And Open source have no part of it, it is the customers that has discovered "The Emperor's New Clothes".
  41. missing the main point[ Go to top ]

    CorrectionIt was the Goose with the golden eggs. Imperfect. And Open source have no part of it, it is the customers that has discovered "The Emperor's New Clothes".

    Sure. Switch Fairy tales on me.

    You would think since the "clothes" are "see-through", the towns people would have seen right though it from the start. And that the clothes definitely don't make the Emperor look skinny (ewwww). Yet many towns people are still blind to the fact(s) as well are many of the emperor's court. Some are clued into the truth but are endowed to the emperor.
  42. Clarifications[ Go to top ]

    People are moving to Spring and Hibernate and other alternatives without J2EE

    But don't you mean "without EJB", and particularly without entity beans? Isn't EJB just one part of the larger J2EE platform? "Servlets only" is still J2EE. JDBC is still J2EE. JTA is still J2EE. JNDI is still J2EE. Branching out, JMS and JMX might be considered "J2EE". What am I missing?

    As Thomas described very eloquently, it's misleading to say the J2EE platform--in the whole sense of the word--is in jeopardy or is being challenged by disruptive technologies. This is simply not the case: the heavyweight EJB programming model and sub-par ORM specification is what has been challenged--and this is but one part of J2EE. Besides that, people are getting smarter about what parts of "J2EE" to use when, given their business requirements. People no longer view J2EE as this "monolithic all-in-one" behemoth; rather, it's viewed more as a set of standardized infrastructure services that can be leveraged independently or combined as needed.

    I think we're beginning to see acknowledgement of this view: for example, the new, united EJB/JDO persistence announcement. Won't it offer a specialized, standardized persistence service that can be used in a variety of environments? Won't vendors be able to develop their own implementations, each offering their own "value add", with pluggability? Isn't that a great thing for the consumer (more competition, more choices)? Isn't that a good thing for specialized vendors, who are experts in particular areas (for example, persistence/ORM)? What will your report say of this trend?

    I do hope your report clarifies what you mean by "J2EE" when you say "J2EE in Jeopardy"! I also hope your report acknowledges that many of these "disruptive technologies" build directly on parts of the J2EE platform--they embrace them.
  43. Clarifications[ Go to top ]

    People are moving to Spring and Hibernate and other alternatives without J2EE

    But don't you mean "without EJB", and particularly without entity beans? Isn't EJB just one part of the larger J2EE platform? "Servlets only" is still J2EE. JDBC is still J2EE. JTA is still J2EE. JNDI is still J2EE. Branching out, JMS and JMX might be considered "J2EE". What am I missing?

    As Thomas described very eloquently, it's misleading to say the J2EE platform--in the whole sense of the word--is in jeopardy or is being challenged by disruptive technologies. This is simply not the case: the heavyweight EJB programming model and sub-par ORM specification is what has been challenged--and this is but one part of J2EE. Besides that, people are getting smarter about what parts of "J2EE" to use when, given their business requirements. People no longer view J2EE as this "monolithic all-in-one" behemoth; rather, it's viewed more as a set of standardized infrastructure services that can be leveraged independently or combined as needed.

    I think we're beginning to see acknowledgement of this view: for example, the new, united EJB/JDO persistence announcement. Won't it offer a specialized, standardized persistence service that can be used in a variety of environments? Won't vendors be able to develop their own implementations, each offering their own "value add", with pluggability? Isn't that a great thing for the consumer (more competition, more choices)? Isn't that a good thing for specialized vendors, who are experts in particular areas (for example, persistence/ORM)? What will your report say of this trend?

    I do hope your report clarifies what you mean by "J2EE" when you say "J2EE in Jeopardy"! I also hope your report acknowledges that many of these "disruptive technologies" build directly on parts of the J2EE platform--they embrace them.
  44. Clarifications[ Go to top ]

    oops please disregard dupe post (I seem to have gotten a little click happy) ;-) Keith
  45. I see this as just another try of getting recognition by bashing J2EE or giving some "expert opinions" dressing up as a prophet.

    J2EE is a collection of techology solving many individual problems, it's value propersition is about cross platform portalbility and interoperbility. As long as companies keep using more than one vendor(Microsoft) techology, J2EE will survive, just like it's cousin Unix. J2EE is not in jeopardy, it's evolving. In this movement, I see open source is not disruptive, on the contrary, it helped delivered J2EE stardard implementations(Tomcat) and pioneered many concepts(lightweight containers and programming model) which in turn have been incorperated into J2EE as stardard(EJB3).

    As for vendor slowing down embracing J2EE 1.4, I think the companies have to follow their own pace of technology investment. While we are cooling off our passion on J2EE, it may be good that we take a step back and see how fast we should inovate and how JCP should work, as a whole JAVA COMMUNITY.

    just my 2 ¥
    (pardon my poor english)
  46. Portability Myth[ Go to top ]

    value propersition is about cross platform portalbility and interoperbility.

    I assume you never tried to deploy complex Swing apps for Cross plattform?
    It's not easy.
    Mono C# does just as well, and soon maybe better:
    http://www.oreillynet.com/pub/a/network/2004/10/18/mono.html

    And people have complained about taking EJB from one vednor to another or to another version of EJB.

    Unix has an edge but ... J2EE's edge is EJB? It's slow and becuase it's complex only simple apps can be written.


    See w/ iBatis DAO, I can do C# or Java. That's nice for me. And it's collection based so I can display and update a muti row grid easily. A list of rows!

    .V
  47. Portability Myth[ Go to top ]

    J2EE's edge is EJB? It's slow and becuase it's complex only simple apps can be written.

    On the contrary, simple apps don't require EJBs most of the time. And it's, at best, ridiculous to say that there aren't any projects where EJBs deal with complex businesses out there...
  48. Portability Myth[ Go to top ]

    Vic: "Mono C# does just as well, and soon maybe better"

    I second that, especially with Glade. Mono and Glade is a perfect pair, an instant hit with almost VB like productivity.

    http://www.lcdstudio.com/blog/index.php/archives/category/mono-for-the-vsnet-guy/

    For the first time it is now easy to build desktop applications on Linux and OSX that is fast and with snappy startup times. You can develop on Windows and deploy on both Linux/Unix and Windows. (They run on windows with a runtime gtk installation provided by Xmian.)

    Regards
    Rolf Tollerud
  49. Portability Myth[ Go to top ]

    Vic: "Mono C# does just as well, and soon maybe better"

    I second that, especially with Glade. Mono and Glade is a perfect pair, an instant hit with almost VB like productivity.

    http://www.lcdstudio.com/blog/index.php/archives/category/mono-for-the-vsnet-guy/

    For the first time it is now easy to build desktop applications on Linux and OSX that is fast and with snappy startup times. You can develop on Windows and deploy on both Linux/Unix and Windows. (They run on windows with a runtime gtk installation provided by Xmian.)

    Regards
    Rolf Tollerud
  50. P.S.[ Go to top ]

    This is the second time. Must be something wrong with my mouse.
  51. Portability Myth[ Go to top ]

    It seems that when referring to EJBs that all EJBs are entity beans. Do Session Beans perform so badly?
  52. Sessions Are OK for me.[ Go to top ]

    I never understood these things about "EJB's are too complex and bad".
    Noone force you to use it! I'm ok with SlSB using webstart and RMI/IIOP to connect it - so I have a rich client GUI working with Server. I even do not need to sign my jar coz it is downloaded from the same server (JBoss). I can send to my client a jnlp file by mail. Then one click over it and in a second can work with an application. The only thing he need is to have Java installed.
    I consider SlSB as a "magic" - I used to use CORBA back to 9x but it has no success because there were no standard for the container.

    Sincerely,
  53. Sessions Are OK for me.[ Go to top ]

    I think they're OK for most of the people, when needed. Most of our projects require remote business components, therefore we use SLSBs and we've had no problems with it.

    The incredible thing with the IT industry is that popular technologies are prone to move by waves. Good or bad opinion, there seems to be a bandwagon approach in everything. Something looks cool: Let's hail the champion! We discover the shortcoming by real life experiences: Let's beat it to death! Incredible!!!
  54. Wrong URL[ Go to top ]

    Richard, guess you've accidentally typed your website's URL wrongly. There's an extra 'O'. Must be the effect of overexposure to OO. :)
    If you want to learn more about me, the author, you can visit my web site at http://www.monsoon-haefel.com. You'll find my bio and other stuff.
  55. Uptake of J2EE 1.4 real jeopardy[ Go to top ]

    Where I see the J2EE in jeopardy the is lack of vendors embracing the newer versions of the standard, case in point J2EE 1.4. If we look back to J2EE 1.3 the vendors where racing to be amongst the first to be J2EE 1.3 compliant. However with J2EE 1.4 hardly and of the major vendors have taken it on, where is the BEA, Borland, Oracle, and Pramati implementations? I know some of these vendors are offering propriety versions of some of the ground covered by J2EE 1.4. This fragmentation is dangerous; lets hope the vendors return to compliance J2EE 5.0.
  56. Clarifications - Take 2[ Go to top ]

    1. What is J2EE?
    Ahh ... Sorry but Servlet engines (e.g. Tomcat, Jetty) are NOT J2EE. Guess what, JMS is not J2EE either, nor is JDBC, nor JNDI. J2EE is a specification that glues those pieces together into a cohesive platform. Come-on! This is basic stuff here guys.

    2. Maintaing J2EE Spec is expensive?
    Of course it is! Dah. If you say it is not, than you have absolutly no idea what your talking about. Have you ever seen what the cost outlays are for that or how much licensies actually pay? Please don't talk about things you know nothing about.

    3. He's just doing it for the recognition!
    I can assure you that is not the case. The people on this forum are not my customers. Sorry but that is the truth. I like developers. I've even been one for some time, but I don't need you to know who I am.
  57. Clarifications - Take 2[ Go to top ]

    1. What is J2EE?Ahh ... Sorry but Servlet engines (e.g. Tomcat, Jetty) are NOT J2EE. Guess what, JMS is not J2EE either, nor is JDBC, nor JNDI. J2EE is a specification that glues those pieces together into a cohesive platform. Come-on! This is basic stuff here guys.

    With all due respect, basic or not, a manager has this view: EJB=J2EE. And to see the same wrong assumption implied in your article surprised me too.

    As an example: According to my manager, using EJBs is a J2EE project however using Servlet/JSPs is a J2SE project. Do you see the difference in his mind? one is "Enterprise" stuff and the other one is the "Standard" stuff. We have to be careful not to encourage this misunderstanding because if "EJB=J2EE" then "failed EJB=failed J2EE" and we all know that this isn't true.
  58. Clarifications - Take 2[ Go to top ]

    1. What is J2EE? Ahh ... Sorry but Servlet engines (e.g. Tomcat, Jetty) are NOT J2EE. Guess what, JMS is not J2EE either, nor is JDBC, nor JNDI. J2EE is a specification that glues those pieces together into a cohesive platform.

    I really don't think we should just assume people share this view of what J2EE is. That certainly isn't clear. The J2EE acronym means different things to different people. I think this forum has shown that. Even JSR 151 mentions "The following JSRs enhance APIs that are in J2EE 1.3", with regard to the technology APIs I mentioned.

    I'm only yapping about this because I truly would hate to see misunderstanding spread: specifically, one that would assume enterprise java is resulting back to chaos because blanket "J2EE is in Jeopardy" due to proprietary technologies that are "complete replacements" for this "all-in-one" standard. This is not true and I feel this looks unfairly bad for Java.

    Perhaps I should rephrase: Servlets, JSP, JMS, JDBC, JNDI, JTA, JMX are all good technology standards to support enterprise development. J2EE (though I'd much prefer you say EJB) is one way of tapping into them, of glueing them together. That way -- as well as the need for a standardized programming model in the first place (thanks to the inherent simplicity of POJOs and emerging AOP techniques) -- is what is being challenged/questioned.
  59. Clarifications - Take 2[ Go to top ]

    1. What is J2EE?Ahh ... Sorry but Servlet engines (e.g. Tomcat, Jetty) are NOT J2EE. Guess what, JMS is not J2EE either, nor is JDBC, nor JNDI. J2EE is a specification that glues those pieces together into a cohesive platform. Come-on! This is basic stuff here guys.

    This is a somewhat limited view from a specification/server developer or analysts perspective. There are also J2EE Applications that are designed to run on the J2EE Platform.

    Let's say I develop a server application for the J2EE RI and I decide to use only the Servlet API and the JDBC API. I would still consider this application to be a J2EE application. I also beleive that it would pass the Java Application Verification Kit (AVK) for J2EE if I wrote it according to the specs. Now take the same app and deploy it on Tomcat - would it all of a sudden not qualify as a J2EE Application any more? I don't think so.
  60. Burton Teleconference today[ Go to top ]

    There is a teleconference on this topic with the same presentation today being hosted by the Burton Group.

    www.burtongroup.com

    I'm not sure if you can register for free for it or not. Is anyone going to be attending?