Discussions

News: Meta Group: J2EE Complexity Holding Back Platform Adoption

  1. The Meta Group on Wednesday released a research report saying that the relative complexity of doing server-side development using J2EE is hurting adoption of the platform. Among other predictions are the continuing dominance of BEA and IBM, more consolidation, and increasing vendor competition in tools and frameworks.

    Unfortunately, the report is not freely availble.

    Key Findings:

     -Success in the J2EE application server market is dependent on the vendor's combination of performance and presence. Moving forward, dependency between these two areas will increase, particularly as the number of vendors with significant presence decreases.
     -Although support for enhanced development productivity and application frameworks/patterns will remain core differentiators for the next two to three years, the broader technical capabilities among platforms are moving toward relative parity.
     -Companies selecting platforms should weigh market presence and vendor viability more heavily than technical capability -- to reflect the relative importance enterprise customers place on presence when selecting a strategic supplier.
     -As vendors continue to leapfrog one another in technological prowess, users are more concerned with providers' long-term commitment to the market and their ability to adequately service and support products on a global scale.
     -Although many corporations have selected Java as a strategic platform for enterprise development, adoption has been hampered by J2EE's complexity -- the principal competition to J2EE servers will remain the Microsoft .Net platform for the next 18 months.

    Read Java Adoption Hampered by J2EE Complexity, According to New METAspectrum Market Evaluation.
    Read Meta Group: J2EE Complexity Holding Back Platform Adoption.

    Threaded Messages (64)

  2. My suggestion is that tss shouldn't reference any of these hokey reports when they're not freely available.
  3. Thanks for your input Der Rockstar. I was wondering about that when posting it.

    I chose to post it because some of the key findings are useful to know, even if you can't get the report itself. Thoughts?
  4. Ah, no worries Floyd. You are the man.

    Without the report, it's tough to trust the conclusions -- even if it's from a (relatively) reputable firm. We must remember that these analysts make their money by selling opinions and consulting, which is hopefully based on data. Without seeing the data from their study, it's not worth trusting IMHO. In any case, the conclusions are nice, but we shouldn't waste our time without seeing the data.
  5. The only realy viable alternative is .NET. And while it has some neat conventions, it really isn't that simple either.
    You still have to be a pretty good developer.

    We're developing complex software top model complex problems. If people want to do it the simple way, use Cold Fusion. But you lose a ton of scalability, extensibility, other stuff (all the good buzzwords). Sure it's complex, but until we can model complex functionality with simple solutions it's the best we got.

    Some of the things .NET supposedly simplified didn't really simplify them. So often when you go for simple, you sacrifice elsewhere. For example, in .NET you can access variables property style, without getter/setter type functionality. But what if you want to synchronize access to the variable. Oops, you need to write a getter/setter.
    So through simplifying that access, there's reduced functionality.

    Of course this isn't always the case, and everyone's always trying to build the better mousetrap, but until then...

    I know plenty of developers and companies doing just fine with J2EE, and they are _not_ full time technology companies. I suspect many of us know these companies.

    -Newt
  6. Floyd,

    Keep the information coming, even if it all of it is not free. I would rather have the high level information and then know where to go buy it rather than not have the information at all.


  7. Although I m a total java geek, to some extent I agree with the fact that J2EE is complex to deploy. We have to accept the fact that sometimes coding takes less time in java and config-deployment takes more time.
      I m sure u guys would argue that its simple, people just have to understand it, etc etc. But on an average, deployment is difficult, specially when it comes to EJB, Transactions, etc. And howm much ever we all know this thing well, an average user/ average level companies may not have courage to go for something they are nt sure of. They generally go in for a simpler MSFT solution.
       Anyway, lets hope JAVA takes over soon.
       
  8. 100 % true...
    Please look into the JBoss CMP documentation..
    <quote>
    The declaration of relationships in the ejb-jar.xml file is complicated and error prone. The XML
    used to declared relationships is as inconsistent as Visual Basic syntax. The best way to configure
    a relationship is to use a tool, such as XDoclet, or cut and paste a working relationship.

    </quote>
    Now this is the state of J2EE. Things are not easy.. Agreed that it is get easier day by day but still a long way to go.

    One of my colleague is an ASP programmer . What he knows/cares is only Visual Inter Dev . Thats it. He writes HTML,VBScript,ASP,Java Script ... name anything... he writes in that.. I can't believe that..
    The coolest is that he could even introspect the "Javascript" methods !!!

    On the other side I do the following
    a) Modelling - Together Control Center
    b) Java Code - Eclipse ( I am a VAJ guy)
    c) XML - XML Spy / Textpad
    d) JSP - Net Beans
    e) SQL - Textpad
    f) FTP - Command line / WSFTP
    g) HTML

    In addition to this i use Struts Console etc
    Add to this all the effort involved in configuring & setting up all these things..
    Don't we feel all this are real pain !!!
    IMHO J2EE is still not Programmer friendly

    ~ murali
  9. <Q>
    The coolest is that he could even introspect the "Javascript" methods !!!
    </Q>

    Check out WSAD.



    As for HTML,VBScript,ASP,Java Script, etc - Great he can do all that. And most times the end up with an maintainable, single use system. Pretty much all I see in this stuff.

    See, you are using free stuff. Don't compare what you got for free to what your buddy has to pay (and pay, and pay, ...) for. Want to compare? Check out WSAD. I'm doing everything in the same tool. It is real cool.

    Again J2EE != EJB.
  10. Check out WSAD


    Let me check that out !!!

    Regarding free stuff.. I really cannot ask my boss to buy "n" number of tools to do "n" number of jobs..
    Ok let me try out WSAD get back ..

    anway thanks for the info..
    ~murali
  11. <q>
    Regarding free stuff.. I really cannot ask my boss to buy "n" number of tools to do "n" number of jobs..
    </q>

    I understand that. Then don't be upset if your buddy buys a tool that is 'better' than all your free stuff. And don't by 'n' tools. Buy one - WSAD.
  12. <q>I understand that. Then don't be upset if your buddy buys a tool that is 'better' than all your free stuff. And don't
    by 'n' tools. Buy one - WSAD.
    <q>

    We used WSAD and went back to using 'n' tools. Now we can to our jobs again.
  13. We used WSAD and went back to using 'n' tools. Now we can to our jobs again


    That is perfectly fine. WSAD is a whole lot like VS.Net. That basically is my point. If you don't like IDEs then don't be wow'd by what others are using. Use what works for you. For me, WSAD is great and is as good if not better than VS.Net and when 5.0 shows up next month ... .
  14. <Q>
    Although I m a total java geek, to some extent I agree with the fact that J2EE is complex to deploy.
    </Q>

    Hmm. EJBs are part of J2EE. One can do J2EE with out EJBs. EJBs are not always complex. Other tools (MS's) don't have anything like EJBs.

    So if people want, they CAN do a simpler J2EE solution. But the FUD and sales people say you gotta be doing EJBs if you are doing Java. Nonsense. I do Java because I can do it if and when I need to. Check out Scott Stanchfields article at www.javadude.com.
  15. Hmm. EJBs are part of J2EE. One can do J2EE with out EJBs. EJBs are not always complex. Other tools (MS's)don't have anything like EJBs.


    Think about what you just said. Your position that you can do J2EE without EJBs-- that ludicrous. In one sentence you've successfully erased session beans, entity beans, message driven beans, and...well, you're left with Servlets. (For those of you who are running low on caffeine this evening, JSPs compile into servlets (-; ).

    Do you honestly intend to take the position in this thread that you can write ENTERPRISE scale applications across hetereogeneous datasources with just.....servlets?

    The bottom line, J2EE is too complex and Meta hit the nail on the head. I've stated in other threads the same thing I'm stating here-- the only way to "master" J2EE (and I use the term lightly since all of the specs total 1000s of pages of text) is to spend your nights and weekends locked in a room away from the family and your friday night date reading the latest EJB spec.
  16. <Q>
    the only way to "master" J2EE (and I use the term lightly since all of the specs total 1000s of pages of text) is to spend your nights and weekends locked in a room away from the family and your friday night date reading the latest EJB spec.
    </Q>

    i believe more in implementing rather than "reading" spec and as a developer in j2ee what i have exp is that im coding all thing from jsp to ejb, i would like to see an IDE that can help a guy like me (i used WSAD and i like it)

    J2EE is complex cause is still new and it want to be everything.
  17. Here's my 2 cents:

    Yes, J2EE is complex.

    But part of that complexity is only "imaginary".

    Developers flock to J2EE because it promises to take care of lots of "boring" and "complex" stuff, such as security, transactions, persistence, scalability, etc., via the J2EE containers.

    Sadly, that is NOT the case. You, as the developer, still need to know about all the relevant issues, e.g. A.C.I.D. properties, locking issues, security levels, etc. You (usually) don't have to write code to get the functionallity, instead, you specify what functionallity you want via the deployement descriptor. But YOU are still responsible for knowing what all the "boring" and "complex" stuff does.

    It is getting to know these issues that is complex (trust me, it is!), but this has little to do with J2EE!

    ANY development project that has to do with transactions, concurrency, databases, scalability, security, etc. is complex, weither written in J2EE, .NET, or any other tool.

    Many developers, when first faced with a project of a magnitude that indicate J2EE (or .Net, ...) is the tool of choice, are bound to say J2EE is complex, but this complexity stems from the complexity of the project, NOT the tools!
  18. PPl,

    I would be considered as a "Junior" Java developer since I have a little over a year's experience of J2EE. Most of the applications developed at the organisation I work for use only servlets and *sometimes* EJBs.

    I did NOT have to read the WHOLE EJB spec to write a "Hello World" J2EE application with EJBs as was suggested by 1 of the other posts in another thread!!!???!!! This was fairly trivial and took only an afternoon (NOT a week!!!???!!!).

    I completely agree with Koen Rousseau when he said -

    <quote>
    You, as the developer, still need to know about all the relevant issues, e.g. A.C.I.D. properties, locking issues, security levels, etc. .... But YOU are still responsible for knowing what all the "boring" and "complex" stuff does.

    It is getting to know these issues that is complex (trust me, it is!), but this has little to do with J2EE!

    </quote>

    He hit it on the head IMHO and those are the real issues...

    The only problem I have with J2EE development is the development tools. I use JBuilder5 (but LOVE JDeveloper! Abit of a dirty love affair really :-]) but IMHO we still dont have a FULLY integrated IDE (i.e HTML/JSP editor - with introspection for both, taglib support ,Java, Javascript, and EJB generator - wizards, deployment descriptor generator, that deploys directly to the appserver, etc) that competes with the .NET IDE (which our company is currently evaluating).

    I know that there are many tools out there (hey some of the really great ones are free e.g. Eclipse! but they are not INTEGRATED. I could be wrong ... suggestions welcome. So I can have a look at them - bandwidth is cheap!) Until this happens I believe that "experts" like Meta group, Gartner etc will always write reports like this.

    From what Ive read in the news etc. J2EE and .NET solve the same problems but us in the J2EE world need better INTEGRATED, (and fast!) development tools not many great seperate ones to compete more effectively with .NET. (oh ... we also need JavaServer Faces now! ;-] but thats another story)

    Just my 2 pence...

    Comments welcome...

    Smythe
  19. Cheers Koen Rousseau!

    And there are other posters here who concur. The gist is this: that distributed enterprise software development entails addressing security, distributed transaction management, scaleability, all while using good OO design techniques. Period.

    Now, you can go build your own framework. I did. It took a lot of effort to get a basic server framework with built-in thread-management, a "data service", a "notification service", and a "business process service". We did it relatively quickly (~6 journeyman-months)...faster than ramping-up on J2EE (having a solid understanding of RMI, JMS, JDBC, JNDI).

    Ironically, we saw that our own framework addressed the same issues that J2EE does (just on a much smaller scope). Instead of a "data service" there's the J2EE EJB Container and our business objects are Entity Beans. Instead of a "notification service", it's a JMS Destination. Our "business process service" maps well to Session and Message beans.

    In short, J2EE presents one possible implementation for a distributed enterprise application framework. .NET presents another possible implementation. When you look at the two frameworks side-by-side, you see they are VERY similar.

    I get the feeling we're looking for a "solution" that allows us to eliminate skilled software designers in favor of application assemblers. But the industrial revolution in software has not hit yet, folks. And I wonder whether that's even possible. It is when we can say, "you can have that screen any color you want...so long as it's black."

    Until then, for anything larger than a single-machine application, you need software artisans.

    How about a new title for Meta Group... "Distributed Applications Complexity Holding Back J2EE and .NET Adoption."
  20. The J2EE platform is 100% targeted to server-side developments; so the complexity is inherent to this environment.
    In this way, I believe that the enterprise development must be addessed in another way than just "code". I think that the reading of the specs is very important to understand the importance of J2EE arena.
    The .NET architecture is still a long distance from J2EE since the fact that is based on client-side infrastructure.
    The client-side infrastructure has evolved and is evolving based on the "user experience" instead of "robutness".
    The "J2EE complexity" is right when compared with .NET in terms of pure development/administration. But remeber that the objectives and results of that developments are totally different.
  21. Angel -
     I absolutely agree with you - J2EE is targeted at the server, .NET (in my opinion) is targeted at the network Edge,i.e. web services et al.

    And, hmm, complexity - it sounds to me like replacing your flagship development environment (VB), ripping most of it's core internals out, and replacing it with the .NET framework and CLR, downgrading ActiveX - is stioll going to be complex for developers to get used to. C# - new language - new languages have steep learning curves at the beginning

    .NET and Winforms are faster (not necessarily better) than Swing, but it is still end-user client based

    And lets not also forget that Meta Group say that J2EE adoption will be 40% and .NET 30% by 2004, even though MS still has VS.NET Yukon (I believe this will be version 3) isn't yet pencilled in.
    http://www.theserverside.com/home/thread.jsp?thread_id=13176

    Just a couple of thoughts

    Calum
  22. <Q>And lets not also forget that Meta Group say that J2EE adoption will be 40% and .NET 30% by 2004, even though MS still has VS.NET Yukon (I believe this will be version 3) isn't yet pencilled in.
    </Q>

    I'm forgetting everything they've said.
  23. <Q>
    J2EE is complex cause is still new and it want to be everything.
    </Q>
    J2EE 'is complex' because most think they have to do EJBs and don't use good tools.
  24. Think about what you just said. Your position that you can do J2EE without EJBs-- that ludicrous.


    Is it? Why? We are doing it. Do you use JMS? Servlets/JSPs? If not, then under your definition, you are not doing J2EE.

    >. In one sentence you've successfully erased session beans, ...

    No I didn't. You use EJBs without servlets?

    <Q>
    Do you honestly intend to take the position in this thread that you can write ENTERPRISE scale applications across hetereogeneous datasources with just.....servlets?
    </Q>

    No. But without EJBs - Yes. EJBs are tool that must be used wisely within a J2EE application. Servlets are just another J2EE technology.


    Again J2EE != EJBs. Quit being fooled by marketing hype. I wish Meta and everyone else would be too.

  25. Hmm. EJBs are part of J2EE. One can do J2EE with out EJBs. EJBs are not always complex. Other tools (MS's)don't have anything like EJBs.


    >Think about what you just said. Your position that you can >do J2EE without EJBs-- that ludicrous.

    Many organizations have done J2EE without EJBs.

    >In one sentence you've successfully erased session beans, >entity beans, message driven beans, and...well, you're >left with Servlets. (For those of you who are running low >on caffeine this evening, JSPs compile into servlets (-; ).

    What about JMS, JDBC, JMX, JTA, JAS, Connectors, etc?

    >Do you honestly intend to take the position in this thread >that you can write ENTERPRISE scale applications across >hetereogeneous datasources with just.....servlets?

    Why not?

    What do EJBs provide that you can't get without them?

  26. Hi,

    I'm the manager of the development unit of one of the largest saving banks in Germany.

    I love J2EE especially cause it's an alternative to the Microsoft dominance but I must admit the biggest problem with J2EE is it's complexity.

    I have Cobol-developers and VB-deveopers, Delphi-developers and Java-developers - most of them have difficulties in understanding the big picture of J2EE...only those who're studying all the stuff in their free time seem to adopt the technology...

    But I won't give up

    Oliver.Lauer@sk-koeln.de
  27. "I have Cobol-developers and VB-deveopers, Delphi-developers and Java-developers - most of them have difficulties in understanding the big picture of J2EE"


    Well, you can tell the cobol developers (I'm assuming they're os/390-based) that the ejb developer/deployer split is basically the application/system programmer split that they know and love. It's just has some XML and OO squiqqles thrown on top!
  28. <quote>
    Think about what you just said. Your position that you can do J2EE without EJBs-- that ludicrous. In one sentence you've successfully erased session beans, entity beans, message driven beans, and... well, you're left with Servlets.
    </quote>

    An appserver provides resource pooling (eg database connection pooling and JMS session pooling) and distributed transaction management across a clustered of servers. Everything else is window-dressing.

    That's why I think you're just dead wrong to say that "J2EE without EJBs is just servlets". JTS, JTA, JMS, etc, still exist if you don't use EJBs.

    Sean
  29. <quote>
    That's why I think you're just dead wrong to say that "J2EE without EJBs is just servlets".
    </quote>

    Sean, I wholeheartedly agree. J2EE is Servlets, JSP, JDBC, JavaMail, JDNI Resources, JTA Transactions, JMS - and EJB. A lot of technologies you can choose from, under one umbrella called J2EE.

    You can develop complex web applications, even spanning more than one database and including rich clients, with Servlets, JSPs, JDBC DataSources as JNDI Resources, and programmatic transaction demarcation via JTA UserTransactions. You will probably add some nice and simple open source toolkits for logging, O/R mapping, HTTP-based RPC, etc - choose whatever you like.

    IMHO, the main benefits of using EJB would be distribution at the component level and declarative transactions. If you don't need either of those, you're fine without EJB.

    For apps without EJB but with JNDI Resources and JTA, you just need a J2EE web container like Resin 2.1, or Tomcat 4.1 (+ Tyrex for JTA). Even if you happen to use a J2EE container with EJB support like JRun 4 or JBoss 3.0, you don't have to deal with EJB deployment if you don't need to.

    Let's not forget development and IDEs: Developing J2EE applications without EJBs is simply less hassle, especially concerning debugging. And a Java/JSP IDE like IntelliJ IDEA 2.6 or NetBeans 3.4 is sufficient, with a developer-friendly web container like Resin or Tomcat that accesses the same project directories. No need for expensive so-called "Enterprise" IDEs with tightly integrated deployment support for certain app servers. Every change in the project directory is automatically reflected, and you can debug your app in the container via JPDA.

    Juergen
  30. I perfectly agree with Weiss's commments and I recognized myself thorugh this statement :
    '-- the only way to "master" J2EE (and I use the term lightly since all of the specs total 1000s of pages of text) is to spend your nights and weekends locked in a room away from the family and your friday night date reading the latest EJB spec'

    To make matters worse, web services stuff is moving in as
    a future 'must' to the skill set necessary. I believe thoough, that as EJB is fundamentally about distributed object computing, it is inherently 'non-simple' (to avoid saying complex) especially compared to its simpler brother
    2-tier client-server. The pain in deployment is a reflection of the multitude of sub-components involved in even the most minimal of a distributed system (transactions, security, ER relationships, etc.).

    I hope somebody sould illuminate in a few words on how to do the strict equivalent on .Net but remarkably simpler. I still do not know the direct equivament (inside .Net) of EJB containers or at least application servers.

    On the positive side, if we developers tame this complexity (after all of the sacrifices Weiss mentioned) and EJB imposes itself, we would probably sell better than the folks of 'simple' computing!
  31. i also think J2EE is too complex, and sometimes it is unnecessary. I love Java, but i really hate EJB.

    1 It is kind of black box. I have to go thr'u weblogic source code to get the idea how locking, concurent working etc... and it may not be same as websphere... I hate any one subclasses my class without my permission!!! In this case, i fully agree with cocabase when they fight with JDO spec.

    2. Java gives me the power to reflect, to fully OO, to multithread etc, but EJB/J2EE forces me not doing this not doing that.

    3. EJB spec seems funny in that making the ejb find and create methods not static!!! while they funtion exactly as static method. How come the EJB/J2ee designer didnt think of this at all? you basically got two different instances between find/create and business method! where is the Java spirite here in EJB?

    4. TX should be the responsibility of developers, not delpoyers. so why cannot we put this into the coding but deploymeny xml? funny! that is y M$.net does the other way.

    4. CMP looks always funny to me! XML is idiot yet i have to follow. And sun invented a new query lanuage for this! they think SQL is not enough for us! now they again want to invent one more OO query languge in JDO! comparing to this, i prefer BMP, which i can do whatever i want, and no need to learn the new ql.

    5.i believe a good BMP can be faster than CMP, or CMP 2.0. we not only have fine grain BMP, we can also have coarse grain BMP. The N+1 fetch can be easily get over by using a instance flag in ejbLoad, while in find doing nothing more than simply return a pk. It all depends on the nature of business.

    These are just a few thoughts....
  32. I agree with the point that if people do something in a simple way, we could lose some good things that the complex way would have.
    But I don't agree very much with your example with .NET's property. I believe you can still use lock statement to synchronize the access to variables in property's access blocks.
    I do have another proof in .NET for your point, that is box/unbox. Always if you use value types (especially the primitive type) with Collection framework without object wrapper, you could get performance penalty.

    --Gansha
  33. Synchronized properties in C#[ Go to top ]

    "in .NET you can access variables property style, without getter/setter type functionality. But what if you want to synchronize access to the variable. Oops, you need to write a getter/setter. "

    Is that so? How about this then:

    public class Employee
    {
      // other fields
      decimal salary;

      public decimal Salary
      {
        set
        {
          lock (this) { this.salary = value; }
        }
      }

      // the rest of the class
    }

    Salary is synchronized all right. By the way, in this case it is also a write-only property. Check your facts.
  34. Synchronized properties in C#[ Go to top ]

    isn't that just a getter/setter with different syntax?
  35. Synchronized properties in C#[ Go to top ]

    Mike Conway asked,
    "Isn't that just a getter/setter with a different syntax?"

    Yes. On the component side, there is syntactic sugar in C# to aid in writing getter/setter methods. see
    Sanchez. But the consumer of the component can still access it as a property. Eg, Employee.Salary= 72000;

    So...the original statement by Jason McKerr,

    "through simplifying that access, there's reduced functionality."


     isn't accurate. There is no conflict between simplified access and full functionality. You can have your cake and eat it, too!

  36. Whether or not the conclusions we see here are solidly backed up by whatever data may be in the report, it's probably the hype that's more important: if CIO's see a headline like this, they may think twice about adopting J2EE. (Of course, they'll never read the article.) In this way these predictions can sometimes be self-fulfilling.

    So it's good that this was posted. As developers we need to be aware of market - and marketing - forces. And all too often the hyped up headline turns out to be more influential than the research behind it.
  37. It is funny that this piece of news happened to be
    on the same page as the ObjectJuice comment.
    We started developing OJ for this reason exactly -
    because EJB development and deployment are so hellishly dificult.
    ObjectJuice will let broader number of Java developers develop enterprise applications with J2EE.
  38. <q>
    ObjectJuice will let broader number of Java developers develop enterprise applications with J2EE.
    </Q>

    That and all the other tools like it out there.

    J2EE doesn't have to be complicated.

    BTW, this was 'News' and not News.
  39. ObjectJuice is hardly just another tool.
    Name one tool that can deliver J2EE web application where data reside in legacy flat files, users are authenticated against corporate LDAP server and access control lists are stored in the database all at the same time.
    That is kind of things we build with OJ.
  40. ObjectJuice is hardly just another tool.


    Didn't say that. It probably has some cool additional features. The point was that this and other tools can be used to do what needs to be done under J2EE without EJBs.
  41. WebLogic 7.0 Platform
    Using Workshop, Portal, or Integration as necessary.
    Matt
  42. It is complex. But know what, so is making distributed applications regardless of the tools or technology.

    Tools & techonology can sure make it easier, and I agree that J2EE has long way to go making it easier. I bet .NET has done good work, but I also suspect that altough it's made to look easy, but in real life... there are the same problems anyway.

    I've done most of my work with open source software. Configuring and setting up the enviroment is time costing, hard work. Especially when you want to integrate all good stuff into it all the time.. ;). Anyway. I guess my point it that even though it's hard work, J2EE gives you freedom to do so. And when time goes, your stack comes constantly better. The development can happen in huge steps since all of the components of your stack evolve.

    You don't have to wait IBM, BEA or what ever to release new major version. Just round-up newest releases of you stack.

    /kte

  43. Another reason you don't have to wait for IBM or BEA is that Oracle has had a great J2EE framework in production for over 2 years now. :-)

    We have about 800 developers inside Oracle building J2EE web applications as part of our Oracle Applications suite. They don't have time to be low-level J2EE API experts, time to hand-code J2EE design pattern implementation code, or time to cobble-up low-value value-object classes just to put data on a JSP page, etc. They are all using Oracle's J2EE Framework, BC4J, that's part of our JDeveloper9i IDE (and has no framework runtime charges).

    Business Components for Java, simplifies a lot of the things that J2EE application developers are confronted with when building end-to-end solutions. This whitepaper tries to illustrate as many proof points of this claim as possible.

    http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html

    Our new release (Version 9.0.3, Developer's Preview) being posted within a few days on the Oracle Technet website, features new Struts integration at both the IDE and J2EE Framework levels so you can easily use the BC4J Framework as the Model of your MVC app, with Struts+JSP as the View/Controller layers.
  44. IBM has good tools too (WSAD).

    If you want free then you probably have to piece it together. With, lets say, Eclipse you can add in plugins (download/buy/build) and have an integrated IDE. That is what WSAD is.

    IBM and Oracle and (...) are committed to creating good Java tools and are providing them.

    The only thing left is getting developers to build good systems. That is not always easy and is not limited to Java. I would say that more try to do it in Java than in MS technologies and thus make it seem like Java is complex.
  45. Absolutely - distributed apps _are_ complex. J2EE maybe has a long way to go, but it already makes things much easier. Some people have the impression that the EJB spec changes every day - it doesn't. Another poster made the (correct) point that you do have to understand ACID/Security/etc which are part of distributed applications.

    I think the Meta report also reflects the current state of the job market - there are a tremendous number of junior application developers out there being hired at incredibly cheap rates (I saw an ad for a J2EE developer for $25/hr in San Diego I think it was) - and when you first start working with J2EE it can absolutely seem quite complex. So the companies that are getting drunk on junior labor have the perception that J2EE is too complex to use.

    But if you work with it enough (no - it doesn't require you to lock yourself away from your family to learn it) it starts to click in a reasonable time frame (a few months, not a few years). Especially if you start out working with an App Server like Orion or JBoss where the whole build/deploy process isn't hidden behind any slick wizard. Once you've got that, moving between app servers isn't that difficult - you are learning _how_ they do something rather than _what_ they are doing. And there's a big difference there!

    I also think that the report is a reflection on how companies use tools - EJBs aren't for everything. J2EE is a toolset. If you are building secure, transactional, distributed apps - EJBs are a good thing to use. If not, there are a wide variety of ways with J2ee to build other types of applications and not use EJBs. Companies need to be educated in the tools they are being sold.

    Anyway - enough of my rant for now.

    Ray

  46. Regardless of what tools you use, complexity will always exist - in fact I think that it will be relatively always the same.
    In the old days of machine code, to write something that would sort input and calculate a sum was complex.
    In C and UNIX world it was made easy by tools and libraries - and the complexity moved to things like multithreading and networking.
    Java (for example) made networking and multithreading easy, so our complexity moved to transactionality, security etc..
    J2EE is making that easier, and the complexity moves yet again.
    Hiding extra complexity and solving current problems only means that we take on things we wouldn't dare to do before.
    Better tools/processes/whatever can solve problems short-term, but saying"that's easy" will just get you more complex problems on your plate :).
    Regards,
    Vlad
  47. Attention: if your a microsoft executive, please dont read this message, :)

    Gize, the complexity issue is very significant when it comes to comparing Java IDEs and Microsoft traditional IDEs.
    Microsoft still offers better development tools.

    Ive been programming in java since 98 and i must admit, evry IDE platform ive been using (VisualAge, Oracle JDeveloper, Visual Cafe, emacs :) was far from being perfect, hmm, let me phrase that aging - far from being good.
    Serverside programming isnt always simple, you do work in several tiers, and it should all work and play together (web, ejb, mom, db), if your IDE doesnt help you , it usually gets in your way.

    The plot gets thicker when the Java IDEs are written in java. The UI is simply slow. Try remote-debugging using a sluggush java UI IDE.

    Im a devoted Java coder, i love the langugae, the spirit which the community shares, i love the new features, new possibilities in building faster and faster server applications.
    But, i feel that, while the complexity of development grows (new toys, frameworks, new tiers) the ease of development is still far from offering what Microsoft offer to its developers.

    Recently, two wonderfull developers joined my team. Theyve done serious traditional Microsoft coding (com, dcom, atl, stl) up to now. My team codes J2EE.
     While they value they possibilites of the J2EE plattform in terms of writing less code and focusing on the logic instead of housekeeping they keep complaining about the development enviroment.

    And they are right.

    Yuval.

    BTW: If your wondering, i currently using Oracle Jdev, 9ias, its slow, but it usualy does what you ask.
  48. <Q>
    Recently, two wonderfull developers joined my team. Theyve done serious traditional Microsoft coding (com, dcom, atl, stl) up to now. My team codes J2EE.
     While they value they possibilites of the J2EE plattform in terms of writing less code and focusing on the logic instead of housekeeping they keep complaining about the development enviroment.
    </Q>

    I've used MS IDEs for years and have done distributed systems with them. But when I moved to Java (and my favorite Java IDE) , I don't want to go back. (I am still doing MS stuff) WSAD is an excellent IDE, for those who like IDEs.
  49. Mark Nuttall sure seems to like WSAD.

    In case anyone's wondering about Mark Nuttall's objectivity...

    Mark Nuttall writes WSAD articles for IBM.

    http://www.ibm.com/Search?v=11&lang=en&cc=us&q=%22Mark+Nuttall%22&Search.x=11&Search.y=20

    Gordon
  50. Gize, the complexity issue is very significant when it comes to comparing Java IDEs and Microsoft traditional IDEs.

    Microsoft still offers better development tools. <
    Two years ago I would've agreed with you, but I believe IntelliJ has turned the tables. The Rename refactor alone makes it far more useful to me than VC#.net, as does the Ctrl-N class finding... and that's just the tip of the iceberg. IntelliJ is what made Java programming truly pleasurable for me. Eclipse has done a pretty good job of taking some of its best features but still needs some usability work IMO.

    I don't doubt, though, that Microsoft is hard at work on putting refactoring in VC#, along with all the other features available in today's Java IDE's. I won't be at all surprised if VS.net far surpasses IntelliJ/Eclipse/et al with the next release.
  51. As developer, but an outsider to J2EE, I'd like to toss in my nickel's worth. I am a C++ programmer from waaay back. In recent history, Unix and then Windows for the last four years. Yes, I am a dinosaur, but a paid dinosaur, unlike many of my J2EE friends. I have learned to leave with M$ in more or less the same manner that the little girl in The Exorcist did with her demon. (I have no new functionality, though, like spinning my head around, M$ never truly comes through on its promises ;-)

    J2EE presents a formidable learning curve. I like learning, so that doesn't bother me, but my boss doesn't like paying me to learn. INMHO that is a key reason slowing J2EE adoption.

    We will finally be writing a distributed version of pieces of our app in the upcoming year or so. We have two choices, .NET or J2EE. We will almost definitely adopt .NET. Why? There are two reasons. One, is that the distributed functionality must work with legacy COM C++ and VB. .NET promises that this will be relatively painless, whereas we have no idea how to do that in Java, and only three of us know any Java. I know, M$ always promises things will be painless, and they aren't, but still we know it is possible to do what we need. Second, the guy making the decision is a VB guy.

    M$ has given VB droids two choices: learn .NET or J2EE. Which are they going to pick? The M$ IDEs do tend to be superior, although JBuilder 6 seems to be comparable for single machine apps in its single language. From where I sit, .NET and J2EE look very, very similar in claimed functionality. I think M$ looked at J2EE, realized it had to changed, and "borrowed" as many concepts as they wanted. I prefer J2EE because it is here and now, .NET is merely more M$ promises, but VB programmers are very unlikely to chuck what they know, however little, for a technology they don't understand at all. I suspect that is why C++ guys seem to migrate to J2EE and VB to .NET.

    Will J2EE continue to dominate .NET? In my opinion, most VB programmers can't code worth a damn, and will struggle merely with OO concepts, but there are a lot of them and some are smart. M$ is betting that there are enough smart ones to win. I think the J2EE world must now take a robust platform/technology and make it enticing to the smart contigents of the M$ hordes.
  52. It's the tools stupid...[ Go to top ]

    Yes, J2EE is a very complex spec that simplifies an even more complex problem-space.

    The real problem with J2EE complexity is the vendors. IBM's approach is to hide complexity. They are the only vendor that manages to provide an end-to-end solution for J2EE that actually creates a working system implementing most of the spec. Appearently Oracle is getting into the game too, and BEA is partnering and aquiring towards this goal as well.

    But we still have the problem of stupid tools hiding complexity instead of simplifying it's management. The Open Source Java community on the other hand really understands this. Struts simplifies managing the complexity of maintaining state using a stateless protocol (HTTP). XDoclet simplifies complexity by managing the XML files in the source code that requires it. Ant manages complexity by allowing users to have properties and substitutions.

    Of course since the proprietary Java vendors have been drunk off the high margins of selling plumbing (basic infrastructure) they have really neglected this market. How is it that NetBeans is a POS compared to IntelliJ for server-side J2EE development? What, I have to pay ~$2K for Forte Enterprise to manage the complexity Sun created in the J2EE spec? Way to garuantee adoption Sun! IBM manages to make sure you'll never move off of WebSphere + Studio since your code now depends on it so much. IBM still reaps the benefits of the Open Source projects though... Ever notice log4j and ant jars sitting aroung your deployment server?

    This is the same bunch of yahoo's that handed UNIX server market share hand over fist, on a silver platter to M$ during the last decade, cause they couldn't see that the infrastructure always becomes commoditized. McNealy doesn't know who his friends are. It's the Linux community, the Open Source Java community, the JBoss Group.

    Why can't I install RedHat and have my Java development environment already there, like the Perl, PHP, Python, TCL, C, C++ environments that ship by default? Cause Sun wants big $$$ to allow RedHat to do it. The JVM, J2EE and class libraries are commodities. To beat back .NET we need more J2EE developers in the market, more mindshare. Why do the big boys make it tougher than it has to be for new developers to join the ranks? And yes it is tougher than it has to be if I have to go download 50+MB of stuff and figure out how to make it work on my OS of choice. RedHat does provide integrated solutions out of the box for other languages, and they would do the same for Java/J2EE.

    JBoss is holding back the tide of .NET, not the Mono or DotGNU projects and certainly not the $50K per cpu vendors. Sun needs to realize that we are here to win this battle. We are tired of bad software and monopolists.

    M$ is using their time-tested strategy to push .NET, make the developer tools great, skimp on the server-side for a couple of revisions. By the time you find out your .NET enterprise app doesn't scale or do everything you thought it would, your so invested in the technology that you'll wait for M$ to fix it and grind your teeth. The J2EE vendors need to wake up and dump resources into the Open Source projects like ArgoUML, XDoclet, Macker, Struts, Middlegen, Ant, Maven and JBoss. At least make it easy to integrate these projects into their products. Provide practical examples of how to use these tools and maintain portability for J2EE apps.

    The McNealy mantra of Open Standards, compete on implementation fails when the standard describes a commodity technology. As the report states, technical functionality is reaching parity. J2EE app servers are a commodity, time to move on in the market and compete elsewhere, vertical apps, tools, integration with legacy systems, services.

    The Open Source community knows this, but the J2EE vendors have there heads halfway where the Sun don't shine.

    I've been doing Java since 96 and J2EE for ~3 yrs, I've been a UNIX geek for longer. I love this tech, and I have a lot of respect for Sun and IBM, but the second their goals don't align with mine, I'll find something else. Keep my peers and I happy guys, it's the only way you'll win against M$.
  53. I guess I would shoot back with
    "Lack of skills and methodology holding back adoption of best new technologies" ...

    I would argue that the complexity is proportional the number of features and those who do not need all of the features should concentrate on defining accurate technical requirements and specifications so that they can more clearly "see" their return on investment.

    This "headline" is not news and has been the case for over three years now, but the total package of J2EE is getting much better, especially as an end-end environment.

    Prior to J2EE I was working with CORBA which offers much more in terms of flexibility of distributed components but offers nothing in terms of infrastructure and "server" environments. Our admins "non-developers" would spend as much as 3 months just getting the deployment environments together, developers wouldn't even consider the deployment environment as a whole since it typically involved a network of machines. Now the developer can complete an application and deploy it in a single "ear, war, jar" file as a complete package. This is a vast improvement over the pre J2EE world, and also over J2EE '1.0' with bare beans, files and limited clustering capability.

    Anyway, all of the issues aside, I wouldn't trade working in J2EE for any other technology.
  54. An interesting report (I've seen a copy) - oddly enough the summary in terms of "leaders" and "challengers" corresponds almost exactly to the current market share of each of the vendors (as reported by companies such as Giga). When you realise that they aren't actually talking about real measured product performance (as we know it - response time and scalability for example) - just "features found in the documentation" - and they have weighted presence to performance by 65:35, this is not at all suprising.

    Regards,

    Paul Brebner
    CSIRO

    PS I'd recommend our current J2EE AppServer comparison report for actual measured performance of course!
    www.cmis.csiro.au/adsat/
  55. Hard things are hard!
  56. There is a lot of truth in J2EE complexity when we start talking about anything more than Session Beans.

    Data Access is easily done using JDBC. There are several Data Access Layer Generators available. The complexity of BMP and CMP and their implementation by various Vendors either forces you to be WebLogic person or WebSphere person or Orion person or JBoss person. But this defeats basic J2EE idea to be platform nutral.

    ->Another major problem is mixture of Deployment and Development perspectives.

    ->You have to code stuff in XML. With every XML DTD there is a new language created. How does one learn all of these?

    ->Deployment Descriptors (a pain)

    ->Servlets and JSPs are pretty limited. One ends up reinventing UI framework.

    ->Web Services are totally not integrated. Why should one not be able to take an EJB and say that the call to it should be a web service call?

    -> tag libraries are a pain

    The list goes on...

    These guys at sun have become too confident of themselves. Maybe this is the reason that their stock is trading at $2.90

    Must say Java is a clean language though.

    If all of you out there are going through similar frustrations, that SUN is causing too much frustration in total to be any kind of market leader.






  57. Building enterprise apps is difficult. Sun should be commended for trying to do what they have so far with the spec. If you think J2EE is complex, you should have tried building enterprise-class systems with C/C++, Corba, Tuxedo, proprietary middleware, home-grown protocols, native database access, etc. At the risk of sounding old (is 38 old?) a lot of you guys sound like whiners. If your experience is with M$-based (VB, Access, etc.), lightweight apps, why would you suddenly jump into J2EE? Of course it's complex. There's a lot of things to make J2EE easier to use, but an IDE isn't going to solve your problems. Ever.

    The really scary part of the Meta Group (and Gartner, Giga, etc.) is that these reports often show what's important to upper management: "Companies selecting platforms should weigh market presence and vendor viability more heavily than technical capability". Once again, business people are making technical decisions and forcing tools on the developers. They say it's for strategic purposes, but at what cost? I've seen business deals you wouldn't believe. Fedex's CIO left to become the president of Netscape. Suddenly fedex's webservers are running iPlanet (whether it works or not) and Sun starts shipping with fedex instead of UPS (whether it costs more or not). These guys really think that there are no differences between products and they "leapfrog" each other: "As vendors continue to leapfrog one another in technological prowess...". This provides rationalization to 'partner' with vendors with no consideration to the negative impact it will have on their business.

    One more thing (sorry to go off) - if you don't use EJBs, and only use servlets, how do you support non-web-based clients?

    -Scott
  58. Scott -
    Well said! As an almost equally old (?) (37) person, I also come from a background writing enterprise systems with C++/Corba and the lot. As such, I really like J2EE and, as part of all of that, I (dare I say it?) like EJBs.

    Good to hear comments like yours.

    Cheers
    Ray
  59. <quote>
    if you don't use EJBs, and only use servlets, how do you support non-web-based clients?
    </quote>

    By writing business logic services in stateless, reusable plain Java classes implementing an interface, possibly accessing JNDI resources, JTA transactions, or some O/R toolkit. Exporting such classes is easy and non-intrusive concerning the services: via RMI, SOAP, or other HTTP-based RPC protocols like Caucho's Hessian or Burlap. Accessing them in client implementations is very easy, too.

    Have a look at the examples at:
    - Hessian (http://www.caucho.com/hessian/)
    - Burlap (http://www.caucho.com/burlap/)
    - GLUE (http://www.themindelectric.com/glue/)

    BTW, if you don't need RPC, you could simply write your own service servlet that your rich clients access via HTTP connections and a self-defined application-specific protocol.

    IMHO EJB Stateless Session Beans make sense if you need declarative transactions and/or declarative security at the method level. For everything else, plain Java services and JNDI resources are enough, plus a simple RPC toolkit if you need remote access.

    Stateful Session Beans are a different issue, as you get additional container benefits like session failover. I consider them a valid choice for accessing stateful services remotely. Note that you could use GLUE for that too, as it supports HTTP sessions, or RMI, via exporting an RMI service instance for every client.

    Juergen
  60. I knew somebody would respond......

    I think the thing that's bugging me is that before J2EE, there were front-end and back-end developers. The front-end web dev guys were interested in GUIs, dev tools, etc. while the back-end guys cared about transactions, scalability, performance, middleware, etc. The web dev guys went about doing servlets and the back-end guys jumped on the EJB wagon. Now there seems to be a lot of talk about just doing everything from servlets. (I know you're not recommending this, Juergen.) Architecturally, it doesn't make sense to me. Using standalone java "helper" classes is not a problem for me either, but you get so much more flexibility from an EJB server. I'm not even going to talk about how much of a difference caching makes, especially with EntityBeans. I guess I don't see a reason to write and maintain a lot of middleware (interfaces, "glue" code) myself these days, and I certainly don't want to increase the number of tools, libraries and software packages I need in production to get everything to work.

    -Scott
  61. <quote>
    Using standalone java "helper" classes is not a problem for me either, but you get so much more flexibility from an EJB server. I'm not even going to talk about how much of a difference caching makes, especially with EntityBeans.
    </quote>

    In my previous post, I have only been talking about Session Beans vs. plain Java classes, both provided with JNDI resources and JTA.

    Now, Entity Beans: I'm not even going to talk about the necessity for remote accessability of entities ;-) OK, so there are local interfaces now, but there's still the overhead of method interception on entity calls. I don't consider Entity Beans the perfect solution for modelling fine-grained entities, even with EJB 2.0.

    If you want to use a full-featured O/R framework with fine-grained caching, there are very nice ones around: Jakarta OJB, Hibernate, Castor JDO, all of them open source. Furthermore, there are commercial products compliant to Sun's JDO spec, and the "classics", TopLink and CocoBase. Lots of choices, but this is preferable to no choice at all.

    All things considered: IMHO you can build large and complex business logic with JNDI resources, JTA, a decent O/R toolkit, and plain Java service classes. When choosing good toolkits, there's hardly any "glue" code involved. And such a solution does not lack reusability: You can access such business logic from local UI tier serlets and JSPs, or export some of it via one or more RPC protocols of your choice.

    So, toolkit-wise, the options read:
    - J2EE Web container (JSP, Servlets, JNDI, JTA) including EJB container (Session Beans, Entity Beans) and maybe a Web Services solution
    - J2EE Web container (JSP, Servlets, JNDI, JTA) + O/R toolkit + RPC toolkit (SOAP or other protocol)

    In the former case, you have to deal with what your EJB container provides, in the latter case with the O/R and RPC toolkits of your choice. I don't see a significant difference in terms of library increase here.

    Let's not forget the container requirements and choices: With EJB, the minimum would be e.g. JBoss 3.0, Resin EE 2.1, or JRun 4. Without EJB, you can also use Tomcat 4.1 or Resin 2.1, for example - more choices, less license costs. And more portability: Web container compatibility is very good these days, and your toolkits will work in any container, even with the same config files (O/R mappings!).

    Juergen
  62. I've got a lot of experience with O/R tools. I started using them with C++. I think they're great, whether they're part of the container or not.

    These decisions always come down to tradeoffs. In general, if you get a full-featured J2EE server that has "everything" then you don't have to worry as much about getting different products to work together. On the other hand, you don't get the flexibility to pick and choose the individual products you want for each layer. I think the open source options available now change the equation - they're great and well worth the effort. (I love JBoss.)

    In my opinion, if you've got a container, why not use it? It's there to provide services for you. Whether your "container" is one product or several doesn't matter.

    Thanks for the discussion. Looks like there are several ways to have enterprise services (without putting all the logic into servlets).

    -Scott
  63. There's a lot of good stuff in this thread, so I'm only going to take up a couple of issues.

    - Yes, J2EE is complex. But a lot of the complexity does come from the underlying problems. Transaction management and distributed architecture, for example, are hard problems. I think the tools could be better, but a big problem is that people implement unnecessarily complex solutions. For example, how many web applications use EJBs with remote interfaces for no good reason? Unless there's value in a distributed architecture, it just adds complexity.
    - EJB != J2EE. EJB is great for some things. However, it does add complexity unless it's really required. The "all enterprise applications must use EJB" school of thought has probably cost the industry hundreds of millions if not billions of dollars in lost productivity and overspending on app servers. I see one of my first duties as a consultant as to advise clients as to whether or not they need EJB on a case-by-case basis. There is way more than servlets left, as several posters have pointed out. And the emergence of web services means that RMI/IIOP is no longer the only choice for supporting distributed clients.
    - Entity beans. I think they're of limited value. They're a pretty poor O/R mapping solution. I think JDO is much more likely to emerge as a viable O/R mapping solution.

    I discuss these issues in my new book Expert One-On-One J2EE Design and Development (Wrox). In particular, I talk about when to use a distributed architecture, and the pros and cons of EJB.
  64. Thoughts (and Cynicisms) regarding the report(inline).....
    <report>
    -Although support for enhanced development productivity and application frameworks/patterns will remain core differentiators for the next two to three years, the broader technical capabilities among platforms are moving toward relative parity.
    </report>
    How can they say there is Parity!?!? IBM is now almost 2 years behind BEA (again!!) in delivering EJB 2.0 and J2EE 1.3 (much further if you consider the products and frameworks already on top of WebLogic 7.0.1. )

    <report>
     -Companies selecting platforms should weigh market presence and vendor viability more heavily than technical capability -- to reflect the relative importance enterprise customers place on presence when selecting a strategic supplier.
    </report>
    No analyst ever got fired for stating the obvious! -adds credibility. ;-)

    <report>
     -As vendors continue to leapfrog one another in technological prowess, users are more concerned with providers' long-term commitment to the market and their ability to adequately service and support products on a global scale.
    </report>
    This isn't even happening. (part of the parity myth -debunked above.)

    <report>
     -Although many corporations have selected Java as a strategic platform for enterprise development, adoption has been hampered by J2EE's complexity -- the principal competition to J2EE servers will remain the Microsoft .Net platform for the next 18 months.
    </report>
    Complexity *always* hampers the adoption of technology.
    (Even riding bikes, much less unicycles)

    IMHO, it's the economy that is mainly responsible for slowing down adoption.


    Matt




    Matt
  65. Yes, Vendors are in the business to make money. However,
    I think they are pushing their proprietary solutions
    on many naive, or confused developers. Let's face it,
    with J2EE it can take a while to get a grip on what is standard and what is proprietary. Most IT shops are
    introduced to J2EE with some vendor's App server and IDE.
    Both are loaded with proprietary solutions. The vendor
    will mention the specs for a gratuitous CYA, then go on
    to bombard you with all their proprietary gimmicks.
                   

    I sincerely believe that the vendors are pushing themselves
    out of business with this tactic. I think that if the
    vendors were pushing J2EE development, and not proprietary
    quick results, lock-in solutions, we wouldn't be having this
    discussion. The amount of work required to port? to another
    J2EE certified App server can quickly make the move an
    unacceptable one, when there shouldn't be any port work
    involved other than using a different deployment tool.
    The perception to this tactic, is that J2EE is too complex
    to be implemented as portable, when it is all the vendor
    lock-in extensions that are confounding and confusing a
    much simpler architecture.

    I am referring to a vertical slice of the J2EE architecture,
    not a servlet mod 1 architecture.

    It seems many are confused that the J2EE strategy is that
    the vendors will provide value added (lock-in)extensions, when, in fact, the strategy is for vendors to compete
    by their implementation of the Standard J2EE APIs,
    in areas of performance and reliability.

    Now if I put on my vendor hat, their response would be;
    J2EE can't go out of business, we have too many customers
    locked in. Maybe, for old business, but kiss your new
    business goodbye. If people are being "led" into a
    proprietary architecture by J2EE vendors, they will soon
    realize that .net, at least doesn't lie about being
    proprietary.

    I would hate to see the immediate future go that way. Any
    future for that matter. A word to the wise to all the
    vendors;

    "stop speaking with forked tongue". Kick off new
    business with offers to help do standard, portable J2EE,
    and explain it at the same time.