98% of Java developers just don't need it

Home

News: 98% of Java developers just don't need it

  1. 98% of Java developers just don't need it (287 messages)

    In "98% of Java developers just don't need it," Mike Cannon-Brookes says that a huge proportion of Java developers write applications that read/write a single database from a single application server, generally from the web, and don't use JMS. Transactions are about inserting into a single DB. JDBC does that. XA, two phase commit, and clustering are all foreign to them.
    After much to-ing and fro-ing, it was decided that yes - if you need 2 phase commit, XA across JDBC and external JMS, fast performance, session + server clustering and XA with recovery - you're going to be shelling out for an expensive app server (really WebLogic or WebSphere).

    My contention that the reason the Open Source community doesn't provide this yet is quite simple.

    Most people don't need any of that to build their Java/J2EE applications. When I say most, I mean the 98% of people who aren't banks and although they understand 2PC have never actually needed it in their lives. The other 2% are probably banks and pay for WebLogic or WebSphere as a part of an 'enterprise software license agreement' all-you-can-eat-buffet deal anyway.
    Mike commented privately that "98% may be sensational, but I wouldn't be surprised if it was well over 80%."

    The concept embodied here is interesting; Java EE is built for the heavier application needs (the "two percent" here), yet most of the changes to it are being pushed along by the 98% who "just don't need it." While that's certainly an exaggeration, as Mike admits, it's worth considering - and might explain why relatively simple frameworks such as Rails see many Java Enterprise applications as "low hanging fruit" to capture.

    Threaded Messages (287)

  2. 76.32% of all stats are made up on the spot.
  3. The 80-20 rule[ Go to top ]

    80% of the population don't trust politicians.
    20% of the population are politicians.

    Jokes aside, I hope people don't get hung up on the 98%.. Of course it's probably less.. I'm sure the author's point is just, "more than you think."
  4. The 80-20 rule[ Go to top ]

    80% of the population don't trust politicians.20% of the population are politicians.

    No way. Politicians know not to trust politicians. No honor among thieves.
  5. Moreover, 85,3% of all stats are utterly irrelevant. Like the one "quoted" by the OP. Because specifying a "full J2EE stack" would be still a good idea if only two percent of developers used it, as the single components of that stack are guaranteed to interoperate smoothly with each other. Providing a "full J2EE stack" out of one hand makes even more sense. Mike Cannon-Brookes' posting does not.

    Next: 99% of editorial postings on TSS are not worth reading -- let alone answering. :-(
  6. 76.32% of all stats are made up on the spot.

    LOL. I second that.
  7. Shoot. I would've seconded it, but I was only 59.2% sure.
  8. 98% seems kind of high, but...[ Go to top ]

    ...but I think the number of % of developers that actually knows what J2EE provides is slowly dwindling. I see so many new developers now that says "I know J2EE", and all they know is how to develop servlets and JSPs. There's just too many of those that says they know WebSphere,WebLogic,Jboss,etc, but many of them barely know most of the functions provided.

    I don't agree with the authors saying 98% of the people don't need the "advanced" technologies in J2EE. I haven't been to a real enterprise system that doesn't use JMS (or some sort of MOM), that doesn't use Transactions (be it JTA or CMT EJBs), that doesn't use XML, etc. etc.

    Let's just look at yourself and the people around you. Does everyone who say they know J2EE, really knows J2EE? :)
  9. 76.32% of all stats are made up on the spot.

    And 86.43% of readers don't believe them.
  10. I do agree. I am part of the 98%. I have been designing and developping J2EE apps since 1998.
    I never used JMS. I use JDBC transactions. I do not work for banks but for major international companies.
    The clustered architecture are not very common.
    Once I have designed a high availability architecture : Oracle Unix cluster and load balancing beetween two Websphere app servers (cookie/session affinity) and failover system.
    But it was not a real clustered architecture (the app server was not clustered; sessions were linked to servers).
    I did not used any cache system in this load-balanced system (not even Hibernate ehcache), so no need for a replicated cache like OpenSymphony or for a "solid transaction monitor".
    Moreover, in Europe, IT Managers don't trust Open Source for this kind of products (transaction monitor or app server). They prefer to pay in order to have a real maintenance and to be sure to have reliable products.
  11. Ups[ Go to top ]

    I was not aware that it doesn't work. I thought if you receive a message via JMS and insert the data into your database it would be one transaction managed by the server.
    Are there any informations available which servers support such a scenario? Or just an application with two databases?
  12. Ups[ Go to top ]

    I was not aware that it doesn't work. I thought if you receive a message via JMS and insert the data into your database it would be one transaction managed by the server.Are there any informations available which servers support such a scenario? Or just an application with two databases?

    If you have 2 different resources, like a JMS provider and a JDBC connection or 2 different JDBC connections, which you want to take part in a single atomic transaction then you typically need to use XA - which implies using a transaction manager and possibly your J2EE/JCA container. Due to the extra mandatory sync-to-disk steps in XA its also much slower.

    FWIW if you are using JMS and JDBC you don't need to use XA if you can do application level duplication detection...

    http://activemq.org/Should+I+use+XA

    James
    LogicBlaze
    Open Source SOA
  13. Ups[ Go to top ]

    In XA, your JMS provider is a resource the same as your database manager. When a transaction is committed, a database resource commits whatever updates you have made, but a JMS resource only commits the delivery of the message to its destination. What happens, if anything, at that destination is a separate unit of work. If there is a failure at that end after the message is delivered, then it occurs outside the XA transaction and their is no opportunity to rollback the original transaction. (You'd have to code that yourself.)

    Therefore, JMS is a great way for delivering messages to services and other end points that manage their own units of work, but if you want an end point to participate in your unit of work you will need to use RMI/IIOP instead of JMS.

    Also, in the real world, RMI/IIOP will only flow the transaction to the end point if you are using the same application server on both ends. The exception is where the application server is communicating to a non Java EE that it also sells, like IBM's WebSphere and CICS (perhaps also BEA's WebLogic and Tuxedo) where the vendor has implemented transaction flow.

    There have in the past as with CORBA promises of inter-vendor transaction flow support amongst servers of the same standard, but to my knowledge its never happened and I don't expect to see it in Java EE.
  14. Ups[ Go to top ]

    There have in the past as with CORBA promises of inter-vendor transaction flow support amongst servers of the same standard, but to my knowledge its never happened and I don't expect to see it in Java EE.

    Webservices transactions should support it, as long as the app servers support the webservices transaction spec.
  15. Ups[ Go to top ]

    There have in the past as with CORBA promises of inter-vendor transaction flow support amongst servers of the same standard, but to my knowledge its never happened and I don't expect to see it in Java EE.
    Webservices transactions should support it, as long as the app servers support the webservices transaction spec.

    I'll believe it when I see it. This has been promised before. So far even the major WS-I members aren't supporting all of the requirements of their own profiles!
  16. Ups[ Go to top ]

    FWIW if you are using JMS and JDBC you don't need to use XA if you can do application level duplication detection...http://activemq.org/Should+I+use+XAJamesLogicBlazeOpen Source SOA

    See also:

    http://dev2dev.bea.com/pub/a/2006/01/custom-mdb-processing.html
  17. Yes. 99.9999% of human being do not need programming.
    The customers of McDonalds are much more than the customers
    for expensive restaurants.

    Wei Jiang
    Perfecting Java EE!
  18. I'd say its probably somewhat accurate. After some recent reflections on my own projects, I question as to whether most of us in the J2EE world over engineer the design (and therby add alot of complexity and cost of projects). This is a worthwhile topic to discuss as our job, first and foremost, is to satisfy business requirements with software. I hear so many developers turn their noses up at the quality of application created by something like Visual Studio.NET or Java Studio Creator. These applications might not exhibit good design patterns and the code might not be the best, but they also allow you to deliver something that works...quickly. This is not something to be easily dismissed. I think we all tend to have rather grand visions of the future when building applications. There's alot to be said for fast and cheap apps that meet users *immediate* demands. I'm not saying good design and clean code are not important, but I've certainly been doing some some thinking about my approach to building these apps...
  19. I'd say its probably somewhat accurate. After some recent reflections on my own projects, I question as to whether most of us in the J2EE world over engineer the design (and therby add alot of complexity and cost of projects). This is a worthwhile topic to discuss as our job, first and foremost, is to satisfy business requirements with software. I hear so many developers turn their noses up at the quality of application created by something like Visual Studio.NET or Java Studio Creator. These applications might not exhibit good design patterns and the code might not be the best, but they also allow you to deliver something that works...quickly. This is not something to be easily dismissed. I think we all tend to have rather grand visions of the future when building applications. There's alot to be said for fast and cheap apps that meet users *immediate* demands. I'm not saying good design and clean code are not important, but I've certainly been doing some some thinking about my approach to building these apps...

    Me too.

    But I have found it is utterly trivial to set up Groovy to run PHP-like under Tomcat. And there you have a language which has built into it 80+% of the functionality any small web app will ever need. And regular Java is always available to you to supply the other 20%.

    Kit
  20. Even if 98% of the Java developers do not use it, it does not mean they should not use certain elements of J2EE architecture, such as JMS and transaction support.

    It's like saying: 98% of all multi-threaded programs does not need to avoid deadlocks...

    On the other hand, indeed the simple frameworks are the things I believe in. But still, if you have complexity in technical requirements, you will have complexity in technical solutions.
  21. Not being to survey every Java developer, I only have my experience and MHO to go on.

    From what I have seen, I would say quite "a lot don't use it." But more than quite a few need it. They just don't know it. Or don't know it yet. One can have a single db and a single set of APIs/UI accessing that db and still need JMS.
  22. 1.4% of world population finished University. Applying the authors logic, the veictims of next government budget cuts are obvious! Play smart at home - not on govt expense, you dirty insignificant academic minority! ;-)
    Oh, sometimes it is so obvious that 50% of world population has IQ below 100...
  23. It looks like an attempt to provoke old framework war on TSS:
    "and might explain why relatively simple frameworks such as Rails see many Java Enterprise applications ..."
  24. It looks like an attempt to provoke old framework war on TSS:"and might explain why relatively simple frameworks such as Rails see many Java Enterprise applications ..."
    Do you think it's really that simple? I would think that Rails' popularity is worth investigating. There has to be a reason for it; it seems to me that here's quite a good possible explanation.

    I'm not suggesting a "framework war." I'm merely pointing out something; note that I'm not saying Rails is "better" or "worse" or even a comparison point for debate outside of the basis for its existence and growing popularity.
  25. It looks like an attempt to provoke old framework war on TSS:"and might explain why relatively simple frameworks such as Rails see many Java Enterprise applications ..."
    Do you think it's really that simple? I would think that Rails' popularity is worth investigating. There has to be a reason for it; it seems to me that here's quite a good possible explanation.I'm not suggesting a "framework war." I'm merely pointing out something; note that I'm not saying Rails is "better" or "worse" or even a comparison point for debate outside of the basis for its existence and growing popularity.

    I don't know what's there to investigate. I did look into Ruby a few weeks/month ago. It's definitely clean and nicely thought out, though I didn't go in depth, but... I didn't because I don't have the time to look into platforms that don't even have a viable production deployment platform. What, lighttpd? Too unstable. Apache with FCGI? No longer actively supported/developed. Hmmm, very interesting. I wonder how the RoR enthusiasts sell this to management. Let's bet your business on an unstable platform. Untill there is a Weblogic/Websphere/JBoss, etc... equivalent for Ruby, or at least even what mod_perl/Apache used to be, I can't seriously even look into it.

    Ilya
  26. Stop the presses or TSS blog[ Go to top ]

    Stop the presses. We already know that..don't we?
  27. Stop the presses or TSS blog[ Go to top ]

    +1

    Well hashed topic for at least three years now. At least 92.3% of me thinks so (sorry, couldn't resist).
  28. While we can all quibble on his percentage claim, I heartily agree with the underlying thesis. In 10 years of writing Java and JEE apps I have only had to enter the land of XA and clustering a handful of times.

    However, when the moment came that I had to entered that "2%", I was happy that almost all of the issues that arose from this move had been considered when the JEE specification was written. The learning curve and the adjustements were minimal.

    One prime example was an app that I wrote that initially connected to a single database. The client loved the app so much that they wanted to add functionality that required a second database and XA transactions. The second database was of a different vendor as well, so XA was the way to go. All I had to do was to make some minor adjustments to the JDBC driver and my Hibernate implementation and we were good to go. JEE was able to grow with me.

    Other frameworks seem to handle the "happy path" requirements of a specific architecture. One app/presentation server, one database. But the thing I always ask is "Does it scale?". I always ensure that even the most trivial app can scale. I plan on the possibility of clustering, web services, mobile presentation, database changes. How many times have we seen something (be it software, website, physical product) become popular in the beginning but fold under the weight of trying to mass produce it.

    If I make something that takes off, I want to be able to cluster the bejesus out of it if it becomes popular. I want to start with a single JBoss server with MySQL. I want the flexability to move it to a Weblogic cluster with Coherence clustered data caching and an Oracle cluster without having to rebuild the entire app. JEE does it for me.

    John Murray
    Sobetech
  29. Thanks for speaking out my mind. :)

    One-database and one-application constraints are really what I had in mind for some time now without being able to put it into words.

    I wrote more about it here, too.
  30. Well - 98% of Java Developers just don't need what?... Java? J2EE? EJB? JMS? JDBC? JTA?

    In any technology - 20% of the available features are used for 80% of the applications built upon it - and rest of the 20% apps use remaining 80% technologies.. Is this something new we're quoting here?

    The problem is not with the technology - its with the overuse of it - and the blame goes to ... definitely us - the developer communitiy.

    Agreed, Ruby on Rails is excellent; but is it really impossible to come out with such a nice simple framwork based on Java/JSP? I don't think so. If we as a community keep on making J2EE more complex - keep on producing new Frameworks everyday (instead of trying to simplfy the what we have) - the last thing we should do is blame Java for it.

    Yes, 98% don't need it - they don't need unnecessary complexity (and rest 2% do it, just because they love complexity)

    Cheers,
    Viral Shah
    http://www.c-sam.com
  31. Well - 98% of Java Developers just don't need what?... Java? J2EE? EJB? JMS? JDBC? JTA?In any technology - 20% of the available features are used for 80% of the applications built upon it - and rest of the 20% apps use remaining 80% technologies.. Is this something new we're quoting here?The problem is not with the technology - its with the overuse of it - and the blame goes to ... definitely us - the developer communitiy. Agreed, Ruby on Rails is excellent; but is it really impossible to come out with such a nice simple framwork based on Java/JSP? I don't think so. If we as a community keep on making J2EE more complex - keep on producing new Frameworks everyday (instead of trying to simplfy the what we have) - the last thing we should do is blame Java for it.

    Well, firstly, I certainly don't agree that Ruby on Rails is excellent. (My view is that it is far too database-oriented and fragile). Secondly, I would not want to build some sort of equivalent framework with JSP, even if you could. I assumed that we as developers wanted to move away from heavily scripted web pages JSP-style. There are far better approaches, like Seam. Thirdly, I think we already are working to simplify frameworks - EJB 3.0 is an example of this. I don't see us making J2EE more complex - quite the reverse.
  32. Well, firstly, I certainly don't agree that Ruby on Rails is excellent. (My view is that it is far too database-oriented and fragile).

    Steve, I've not studied Rails in details - I'm a hardcore Java lover. I said it just to take an example - the point here is not to praise Rails - its just that ANY great advantages quoted for such emerging technologies are there with Java as well.
    Secondly, I would not want to build some sort of equivalent framework with JSP, even if you could. I assumed that we as developers wanted to move away from heavily scripted web pages JSP-style. There are far better approaches, like Seam.

    OK - you don't like that approach - don't build it. Somebody else may like that approach and may build it. As a developer, I just want things to be simpler.. so let's jump to the next point.
    Thirdly, I think we already are working to simplify frameworks - EJB 3.0 is an example of this. I don't see us making J2EE more complex - quite the reverse.

    Fully agreed - with each version EJB will become better - and simpler. But is everybody taking EJB as de-facto platform for Java? Unfortunatly not. Every other weak, I get to see a so-called 'New Approach'; things build parallel to EJB, things built on top of EJB, web-frameworks which tries to pretend that they are agnostic to EJB and/or agnostic to HTTP/Servlet!!!

    As a developer or a Development Manager - this makes my life hell. Are there any clear directions? NO. Are all claims made by all these competing frameworks correct? NO. EJB 3 is great - but when are all AppServer vendors are going to support it? I don't know. Once the EJB3 servers are out in the market - how much time would it take before my clients buy them/upgrade to the latest version? I don't know.

    The problem is: everybody is trying to make it better - with each guy pulling it in a different direction. This is what pisses-off developers - and they start thinking that may be Java is the problem - they try to switch to a simpler (and stupid) system.

    Viral Shah
    http://www.c-sam.com
  33. ... As a developer or a Development Manager - this makes my life hell. Are there any clear directions? NO. Are all claims made by all these competing frameworks correct? NO. EJB 3 is great - but when are all AppServer vendors are going to support it? I don't know. Once the EJB3 servers are out in the market - how much time would it take before my clients buy them/upgrade to the latest version? I don't know.The problem is: everybody is trying to make it better - with each guy pulling it in a different direction. This is what pisses-off developers - and they start thinking that may be Java is the problem - they try to switch to a simpler (and stupid) system. Viral Shahhttp://www.c-sam.com
    Hi Viral,

    I use to be a Development Manger too. I've got a suggestion for you. Set aside some budget an time for evaluating future technologies. Get your senior people to explore, investigate and even prototype solutions based on new emerging ideas.

    Then ask them what technologies they think you should be using in the future base on their investigations. In the old days all projects had a feasibility phase where technology evaluation and selection was a key activity.

    Why do you believe that it is up to standards committees like the JCP or up to to Application Server Vendors to do this type of ideas evaluation for you?

    I'm quite sure that your developers are capable of making technology choices for themselves if empowered to do so.

    Paul.
  34. In the enterprises I have worked we have made the ability to do things like what JMS, JTA and these other Java EE standards support (as well as XA) because sometimes we do need them and when we do need them its absolutely critical that we have them. We cannot always predict when or if within an application's or component's life cycle we will need one or more of these capabilities. So, we standardize on Java EE knowing we can do whatever we need to do and won't have to suddenly rip it out and rewrite applications when new demands are made.

    Also in these enterprises (insurance, credit cards, government, manufacturing) all our core value chain applications, our mission critical applications do need two or more of these capabilities. Once you've committed to a Java EE infrastructure, because your business depends on it, its easier to put other applications on it and have the flexiblity to shift your physical and human resources around as needed than it is to introduce some new platform with its own skill set requirements just because its "simpler".

    Considering that where I've worked about 80% of the backlog has been driven by changes in user interface requirements, once we achieved separation via tiers and/or services, it is easy to see that there is a lot of peripheral IT activty associated with just UI makeovers, data extractions and reporting. Certainly these efforts are many of the ones that are under-utilizing Java EE and might just as well be done with Ruby, .ASP or something else if your organization chooses to support/allow it.
  35. I use 2pc on current project[ Go to top ]

    As an exception is my current project. The current system runs on an informix C-based legacy platform. The new system which will gradually over the next 2 yrs replace the legacy system is being written in java+weblogic+oracle. This being the case there are situations where the new system has to write data back to the informix db as part of a distributed transaction.

    But eventually when the complete system is ported over to the new app we will not require 2pc.
  36. Going by my own experience[ Go to top ]

    Based on my own experience, I'd say 75% don't need it. Though in my case, I've been working in the Boston area for the last 5 years, so it's probably a skewed perspective.

    At the end of the day, I think many of the problems developers face on a day-to-day basis is the result of bad management making bad decisions. Too many MBA types that think using something based on PR is good. How about firing all those MBA types that haven't got a clue stick. That would go a long way to fixing a lot of the mis-uses of technology.

    peter
  37. Going by my own experience[ Go to top ]

    Based on my own experience, I'd say 75% don't need it. Though in my case, I've been working in the Boston area for the last 5 years, so it's probably a skewed perspective.At the end of the day, I think many of the problems developers face on a day-to-day basis is the result of bad management making bad decisions. Too many MBA types that think using something based on PR is good. How about firing all those MBA types that haven't got a clue stick. That would go a long way to fixing a lot of the mis-uses of technology.peter
    +1
    Agreed. I tend to agree with most of what you say Peter. Something I would add is that in my experience most technology choice decisions are made by managers long before they hire a development team and before understanding the full requirements. How is this possible?

    Sales, Marketing and PR seems to always win out over sound Engineering judgement. When I was a Manager I alwyas side stepped sales pitches from leggy blondes wearing low cut blouses :^). I'm sure I was in the minority though :^).

    It's a strange old game.

    Paul.
  38. Going by my own experience[ Go to top ]

    Well, that's just the real world. You cant afford to hire a developement team and pay them to sit around while the architecture (and all other pre-developement) is done.
    And the full requirements are hardly ever understood before the project is finished, and often not even than.
    +1Agreed. I tend to agree with most of what you say Peter. Something I would add is that in my experience most technology choice decisions are made by managers long before they hire a development team and before understanding the full requirements. How is this possible?Sales, Marketing and PR seems to always win out over sound Engineering judgement. When I was a Manager I alwyas side stepped sales pitches from leggy blondes wearing low cut blouses :^). I'm sure I was in the minority though :^).It's a strange old game.Paul.
  39. Going by my own experience[ Go to top ]

    Well, that's just the real world. You cant afford to hire a developement team and pay them to sit around while the architecture (and all other pre-developement) is done. And the full requirements are hardly ever understood before the project is finished, and often not even than.
    +1Agreed. I tend to agree with most of what you say Peter. Something I would add is that in my experience most technology choice decisions are made by managers long before they hire a development team and before understanding the full requirements. How is this possible?Sales, Marketing and PR seems to always win out over sound Engineering judgement. When I was a Manager I alwyas side stepped sales pitches from leggy blondes wearing low cut blouses :^). I'm sure I was in the minority though :^).It's a strange old game.Paul.
    What ever happened to the good old fashioned "Feasibility Study?" or what Agile people may call a "360 degree project view?".

    I agree this is the real world for a lot of companies. But it just doesn't have to be that way.

    Paul.
  40. It is certainly not as low as 2%, that is a gross overestimate. It is true that the majority of systems and therefore developers working on those systems are more than likely only using one database resource, and no other transactional resources at the same time, and therefore will not have a need for XA Transactions. But every developer should be aware of the purpose, need and usage of transactions in a system. Again not all systems will have a need for transactions (for example, single user desktop apps), and we have to appreciate that the the developer community is incredible vast and diverse in terms of systems that we work on and the areas that we tend to specialize in. Just because one developer has tended to work on low end single user applications does not mean that this is typical, and this would be a skewed view of the software development world if that were his opinion. The use and need of JMS for messaging and asynchronous processing is also a more specialized need that addresses a requirement and a problem that not all systems have.

    That said, I have had the experience of working on large systems ranging from 100s of concurrent users to 1000s of concurrent users, and in each case multiple database resources were being accessed requiring XA transactions, and also JMS was also being used for integration with other systems and/or for the use of asynchronous processing with queues. I have also worked with many developers who have also worked on these types of system, and even with developers who are integration specialists and whose whole career has centered around messaging systems - JMS and middleware such as MQ Series are their daily bread and butter - they live with this technology.

    To sumarize - yes, these are specialized needs, but the needs are out there. If you read the authors article and not knowing any better come away with the conclusion that 'I don't need to know stuff like that' then you will be ill prepared for when you do come across these needs. 2PC and asynchronous processing are tools that every developer should have in their back pocket for when a problem comes up that does need these solutions.
  41. Since 2003 I have been doing hardcore XP development. As A result I have jettisoned many of the Engineering ideals I use to hold dear, and I know see them as old baggage.

    The truth is most businesses want a solution Today for todays problems. Tomorrow will take care of itself.

    Also as the nature of projects change from technical deterministic problems (e.g payroll and billing) to people centric, complex and chaotic problems (get my business process to run more efficiently) then we do need a different approach.

    Tomorrow is becoming impossible to predict. All you know is that things are going to be different and that you need to be in a position to adapt to that difference. You will need to refactor, so tomorrows design will look very different to todays. So you design for today and refactor when you get there.

    From this perspective. The simplest thing that will possibly work today rarely requires distribution. Also redundancy may sound like a bad thing, but if it means that you get two applications out to the business both delivering a ROI today, rather than waiting for "OVER ENGINEERED" non-redundant solutions to materialise tomorrow, then the business is winning, and that is what counts.

    Incidently as I mentioned on another thread. Trying to get two applications to share common code, when both applications are unstable is a configuration nightmare. If after time the common code becomes stable, then it can be refactored out and shared. If the shared code is truly stable, then why not share it as a shared library rather than a shared service?

    With databases it is very easy for applications to share data. So why not just distribute the data?

    In my experience, unless you are willing to make a concerted long term investment, the case for service distribution in the context of a single project is a difficult one to justify.

    I have only worked in one organisation that had a proper END-TO-END Design team, coordinating the needs of several applications and ensuring that common services existed. This was a leading mobile phone operator that was commited to investing a lot of money into its Mobile Network and IT infrastructure (as you would expect). I think the Banks do the same. But outside Telecoms and Banking, who else makes this type of commitment to IT?

    Paul.
  42. Also as the nature of projects change from technical deterministic problems (e.g payroll and billing) to people centric, complex and chaotic problems (get my business process to run more efficiently) then we do need a different approach.

    Yes and no. The goal of the business is to make the chaotic, people centric process operate more efficiently (and often in a less chaotic fashion). But I think tackling the chaotic people centric process is generally a very bad idea.

    Hypothetical interview with someone from billing department before automation:
    Systems Analyst: What do you do?
    Billing Guy: Well, I track lots of orders and whether or not they've been paid. I also add up numbers, apply discounts, add tax, etc. etc. A lot of arithmetic over large sets of numbers. I also call customers who haven't paid and try to get them to pay, and talk to customers who feel they have been incorrectly billed.
    SA: Hmmm....computers are really good and tracking statuses and doing arithmetic. What would you say if I told you I could give you a machine that would do all this, so you could focus on customers?
    BG: That would be great! I would be a million times more efficient!
    SA: Ok, let's document all the information you track and formulas you apply to bills so we can automate it.

    -----------

    Today:
    Executive: I want a web-application to realize collaborative synergies in a multi-disciplined geographically distributed environment while ensuring regulatory compliance.
    SA: Huh?
    Project Manager: (to SA) Shh!!! (to Executive): We can do that!
    SA: (hides under table)

    ----------

    Somewhere buried in the executive's statement is one or more deterministic (sub)processes that involve tracking lots of little pieces of information and/or doing reams of math. Either that or email and a telephone are the best way to solve it.

    On a sane project, the processes with be identified, documented, and automated. The problem is this can take months and will make for very dry presentations. The results will also add directly to the company's bottom line.

    On a more typical project, a web application that "automatically" generates lots of pretty dashboards will be designed for the executive in a short period of time, so he can theoretically monitor and measure the process.

    Of course (almost) all the data will be manually entered, and will be largely subjective. Added staff will be needed to maintain this data, which is never even accurate because anything bad is accidently left out. So the business becomes less efficient and more delusional.

    Or, you can repeatedly risk destroying your career by telling the executive what he asking for is meaningless, will cost too much money, will make the business less efficient, and will in general be either a destructive force or shelfware. But, if he'll kindly define some tangible objectives, you'd be happy to spend a few months tying up his best people, figuring out where people are wasting time on tasks that could be automated.
  43. Hi Erik,

    I know exactly what you mean. The simple truth is that the client is always right. The trick is making your ideas look like their ideas and knowing how far to push them.

    A good example is workflow. I've noticed that in roles where people are use to being told what to do, workflow can work quite well. For example call centres and simple administrive rolls.

    For higher skilled people, more use to independent thought and autonomous decision making, workflow tends to be a harder sell. They just don't like being told what to do, especially by a computer.

    Any solution needs to take these people and cultural issues into account. We can't say what will work and what will not in any given organisational environment. At the end of the day if the user community do not like a system and spend all their time working around it, then from the business point of view the system has failed.

    Over the last 15 years or so us IT people have had a number of working assumptions when it has come to businesses; their people and their organisational processes. I list some of the key assumptions below:

    1. The assumption of order: that there are underlying relationships between cause and effect in human interactions and markets, which are capable of discovery and empirical verification...

    2.The assumption of rational choice: that faced with a choice between one or more alternatives, human actors will make a “rational” decision based only on minimizing pain or maximizing pleasure; and, in consequence, their individual and collective behavior can be managed by manipulation of pain or pleasure outcomes and through education to make those consequences evident.

    3.The assumption of intentional capability: that the acquisition of capability indicates an intention to use that capability, and that actions from competitors, populations, nation states, communities, or whatever collective identity is under consideration are the result of intentional behavior. In effect, we assume that every “blink” we see is a “wink,” and act accordingly. We accept that we do things by accident, but assume that others do things deliberately.

    These are taken from the following paper:

    http://www.research.ibm.com/journal/sj/423/kurtz.html

    From the Cynefin Centre:
    http://www.cynefin.net/

    If you think about your organisation you can see that the above assumptions are more often than not blatantly false. This is why IMO Business Process Re-Engineering as described in the early 90's has failed in anything but the most simplest of cases (e.g. beyond the call centre).

    So what should we do? In the Agile community through, the belief in close communication and teamwork with end-users and customers ideas on how to address this problem are emerging. There were a number of very interesting sessions at XPDay London earlier this year. I have documented them on my blog:

    http://pab-data.blogspot.com/2005/12/xpday5-knowing-your-customer.html
    http://pab-data.blogspot.com/2005/12/xpday5-getting-customers-to-know.html
    http://pab-data.blogspot.com/2005/12/xpday-5-gathering-requirements.html

    Some of these techniques are very different from what you would expect. I have tried a number of them and found them to work.

    (Sorry about the amount of reading, but it is a complex subject).

    Paul.
  44. Paul,

    Your post is very well thought out and I agree with almost all of it; however, there were other successes in BPR and workflow beyond what you give it credit for. By 1990 most business had PCs on many a desktop. A number of these PCs ran applications even beyond the usual wordprocessor and spreadsheet. Still PCs were primarily used as expensive combination typewriter, calculator and dumb terminal.

    Many business also had a number of server systems beyond their original primary host. These additional servers tended to do more specialized tasks. Their communications with other servers and PCs tended to be very limited.

    The problem was that businesses were only getting a fraction of the ROI that they should have by automatting a number of tasks. That was because the created islands of automation. Much of the successful BPR carried out in the 1990's and still being done today involved connecting these islands.

    Even knowledge workers appreciate not having to reenter data twice or more. They'd much prefer someone else enter it for them. They like not just file sharing, but information sharing and anything that saves them drudgery. Reducing the redundant entry of data into systems not only resulted in huge cost savings due to the savings of data entry labor, but reduced the errors which always occur when human type. Data entry and error correction were often the greatest application life cycle cost they encountered. (Studies at the time varied from 50 to 90% depending on the type of application.)

    So, yes taking workflow to the point where it is parental and overbearing may be resisted for many reasons, but efforts to reduce drudgery, work and errors are, in my experience, well received.

    What used to be touted as BPR is today repackaged as business process management, business process automation and similar phrases. It's worthwhile and it can be successful.
  45. I agree with everything you say.

    The point I was making is that BPR is neither good or bad, but must make-sense in the organisational context in which it is applied.

    In deciding what makes sense we need to look beyond technical and logical issues and get into the psyche of the people.

    BTW: if you look at the Cynefin KNOWN domain (as distinct from the COMPLEX, CHAOS and KNOWABLE domains), you will see that Business Process reengineering is viewed as an applicable approach.

    So the issue is deciding whether your problem space falls in the known domain or whether there is something the organisation can do to shift it into the KNOWN domain. If they can't then you will need to look at another approach (there are other approaches).

    I find the Cynefin sense-making framework quite powerful and it is well worth the long read.

    Thanks for the well reasoned response.

    Paul.
  46. Even knowledge workers appreciate not having to reenter data twice or more. They'd much prefer someone else enter it for them. They like not just file sharing, but information sharing and anything that saves them drudgery. Reducing the redundant entry of data into systems not only resulted in huge cost savings due to the savings of data entry labor, but reduced the errors which always occur when human type. Data entry and error correction were often the greatest application life cycle cost they encountered. (Studies at the time varied from 50 to 90% depending on the type of application.)

    You would think that, wouldn't you? And generally I agree, duplicate data entry is a major sin.

    But there's a catch. Businesses operate on an amazing quantity of dubious information. Information has an ethereal traits of accuracy and precision that are rarely captured. The wider a piece of information is disseminated, the more important it is that the information be accurate. Furthermore, if you're only going to have on definition of a piece of information, then it has to be to the highest precision requirements under which it is going to be used.

    In addition, there are problems of temporality and multiplicity. Think about the cost of an item. Most people need to know the cost maybe +/-5%. Costs change with time, as market conditions change. They also change with quantity needed and other pieces of contextual information. When a person makes a forward-looking budget, they usually want a single number that reasonably represents what it's going to cost, but they also might be concerned with historic data as backup if someone questions their estimate. The person who actually issues a PO and pays for the item needs to know the cost to the penny, but doesn't necessarily care about what the item used to cost or will cost the next time.

    So the simple questions "How much does X cost?" doesn't have a simple answer. For one person, a simple average of historic costs may be fine. Another requires something based on historic data but scaled to fit a context, and possibly checked for extreme circumstances like a supplier going out of business.

    As a result, people hoard data. When some else needs it, the figure out not only if they have the data, but if the data they have is adequate for it's intended use. They may refuse to provide information or supplement it when providing it to another person/group.

    One person's single data point is another person's entire database.
  47. An exaggeration? prove it.[ Go to top ]

    It's actually an understatement. I challenge anone to prove that more than 2% of applications developed in Java require a 2-phase commit. The actual figure is closer to 99.9% of applications do not need a 2-phase commit.
  48. How about a survey?[ Go to top ]

    It's actually an understatement. I challenge anone to prove that more than 2% of applications developed in Java require a 2-phase commit. The actual figure is closer to 99.9% of applications do not need a 2-phase commit.
    +1 Maybe it's the cynic in me. But this sounds as likely to be the truth as anything else.

    Rather than these pointless discussion threads, it would be nice if the TSS did some real surveys and collected some real data on what is actually going on out there in Java Land.

    With any luck they're listening. If you want a survey then add your voice to mine.

    Paul.
  49. How about a survey?[ Go to top ]

    It's actually an understatement. I challenge anone to prove that more than 2% of applications developed in Java require a 2-phase commit. The actual figure is closer to 99.9% of applications do not need a 2-phase commit.
    +1 Maybe it's the cynic in me. But this sounds as likely to be the truth as anything else.Rather than these pointless discussion threads, it would be nice if the TSS did some real surveys and collected some real data on what is actually going on out there in Java Land.With any luck they're listening. If you want a survey then add your voice to mine.Paul.
    BTW Before joining the thong and resorting to personal insults. I did make a humble post to see if there was any interest in a survey. See above.

    The funny thing is no one responded :^)

    Interesting,

    Paul.
  50. An exaggeration? prove it.[ Go to top ]

    It's actually an understatement. I challenge anone to prove that more than 2% of applications developed in Java require a 2-phase commit. The actual figure is closer to 99.9% of applications do not need a 2-phase commit.

    Prove it. What a silly waste of digits.

    BTW, the article included most of the Java EE facilities like JTA and JMS, not just 2-phase commit. Also XA is not just about 2-phase commit if that is what confused you. Its a standard API for managing transactions. Any resource managers that implements it can participate in a transaction without product specific coding. Also, not all resource managers are databases.
  51. An exaggeration? prove it.[ Go to top ]

    It's actually an understatement. I challenge anone to prove that more than 2% of applications developed in Java require a 2-phase commit. The actual figure is closer to 99.9% of applications do not need a 2-phase commit.

    It's hard to estimate the percentage of applications, but it would be low because you can whip up a thousand Java web apps that each use a single database in no time flat, and it doesn't need XA.

    Of course, we could take it a bit further and say that 99% of Java applications only need read-only database access, and JDBC shouldn't have to support batching, stored procs and "update" / "insert" statements.

    However, "by dollar", I would be fairly confident in saying that over half the "total total engineer wages" in the Java programming industry is spent on apps that do use XA. Therefore, having it available and knowing how to use it can be good for one's career prospects.

    All that said, we do try to steer customers toward more simple and / or more scalably performant solutions such as queueing, idempotency, corrective transactions (either for compensating or rolling back previous transactions) and even rules-based consistency resolution.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  52. "There are three kinds of lies: lies, damned lies, and statistics"
  53. So what?[ Go to top ]

    Who cares what percent of folks do or don't use some aspect of Java or J2EE. Does that invalidate the code or functionality itself? Not particularly.

    I use emacs daily. It does a crap load of stuff I never do, nor even really have much knowledge about. Once I got it to edit my Java and support my development, I never dug deeper in to it.

    If someone wants to write a Model 1 application in JSP with embedded SQL statements calling JDBC and DriverManager, hallelujah! More power to them. How is the rest of the stack getting in their way?

    It's not. If anything, it's giving them a glimpse of what may be coming down the pike in the lifecycle of an application, and how one goes about managing the issue.

    See, we've already been down this road. Look at PHP, and look at its growing pains as it struggles to break out of the JSP world and in to the application tier. You'll find that it's a struggle to build bottom up in this kind of world, and easier if you start at the top and work your way down.

    That's what J2EE does. It's this HUGE specification covering just gobs of high level issues with large scale application development. But it turns out that it's not so hard to dig in to the stack and pick and choose the pieces you want for your application, but still be able to leverage them later should the need arise.

    Starting without that overarching design means most every choice you're making is a blind choice compared to the big picture. Since you don't know what your final architecture will be, how can you choose the best option as you grow your application.

    In the past, we simply grew until we hit walls and then either tore the walls down, or built code around them.

    But J2EE IS the big picture, even if you're only working on a small corner of it. This gives you as designer solid information on better choices that will rather than prove to be walls later, will turn out to be ladders.

    Obviously it's never quite that simple, and you certainly shouldn't follow it blindly, but the fact that J2EE has thought much of the problem out, many of their choices have bubbled down even in to the lowliest JSP tier where you can leverage those decisions if you choose too.

    So, even though you may be writing a simple application using just a few of the services, if you follow some basic guidelines in structuring your application, then you may well be able to more easily incorporate the rest of the stack later.
  54. And this is news ?

    The same made-up-on-the-spot statistic could be applied to virtually everything - cell phones, cars, computers AND the human brain.

    So what ?

    Rich Sharples
    Sun Microsystems
    http://blogs.sun.com/theaquarium
  55. And this is news ?The same made-up-on-the-spot statistic could be applied to virtually everything - cell phones, cars, computers AND the human brain. So what ?Rich Sharples Sun Microsystemshttp://blogs.sun.com/theaquarium

    Of course it's rubbish - specifically, the kind of rubbish that causes controversy and generates lively discussions on TSS, which seems to be the point ever since TSS became a blog aggregation engine.

    Another shocking fact: most J2EE applications do not use the Java2D and Java Sound APIs and yet they're bundled in the JVM. Outrageous!
  56. Another shocking fact: most J2EE applications do not use the Java2D and Java Sound APIs and yet they're bundled in the JVM. Outrageous!

    +1
  57. Another shocking fact: most J2EE applications do not use the Java2D and Java Sound APIs and yet they're bundled in the JVM. Outrageous!
    And JDO is not bundled . Politics?
  58. Well said!
    And this is news ?The same made-up-on-the-spot statistic could be applied to virtually everything - cell phones, cars, computers AND the human brain. So what ?Rich SharplesSun Microsystemshttp://blogs.sun.com/theaquarium
  59. James Gosling once said in an interview in a German Java-Magazine: "In the J2EE-World there is a lot of material about how to build large applications. But it's not described how to build small applications."

    I think this is true. There are millions of MS-Access databases and Excel macros out there including millions of lines of crappy VB code. These applications are written for only a small group of people, maybe a team or a department. Why are such applications not written in Java ? Java has so many high-quality Open-Source components like databases, OR-Mappers that are available for free.

    Well, I would say because a) there is no real killer RAD tool like VS.Net, b) J2EE ignores Rich-Clients and c) a J2EE application-server is overkill for these applications.

    I once ported a MS-Access application to Java just using SWT, Hibernate, VJDBC and MySQL. Yes, I mean Hibernate-OR-Mapping on the client side with a JDBC-Proxy to the database. Yes, this is the awful old 2-tier approach, this is NOT good J2EE-Design, this is NOT usable for Web-Frontends, this is NOT good concerning security ... but it worked after just one week and the customer was happy. And I was happy to get rid of the crappy VB-Code.

    Are there any other "patterns" for small applications in Java ?

    Awaiting the flames ...

    Michael
    http://vjdbc.sourceforge.net
  60. Patterns for small applications[ Go to top ]

    James Gosling once said in an interview in a German Java-Magazine: "In the J2EE-World there is a lot of material about how to build large applications. But it's not described how to build small applications."I think this is true. There are millions of MS-Access databases and Excel macros out there including millions of lines of crappy VB code. These applications are written for only a small group of people, maybe a team or a department. Why are such applications not written in Java ? Java has so many high-quality Open-Source components like databases, OR-Mappers that are available for free.Well, I would say because a) there is no real killer RAD tool like VS.Net, b) J2EE ignores Rich-Clients and c) a J2EE application-server is overkill for these applications.I once ported a MS-Access application to Java just using SWT, Hibernate, VJDBC and MySQL. Yes, I mean Hibernate-OR-Mapping on the client side with a JDBC-Proxy to the database. Yes, this is the awful old 2-tier approach, this is NOT good J2EE-Design, this is NOT usable for Web-Frontends, this is NOT good concerning security ... but it worked after just one week and the customer was happy. And I was happy to get rid of the crappy VB-Code.Are there any other "patterns" for small applications in Java ?Awaiting the flames ...Michaelhttp://vjdbc.sourceforge.net

    1) IMO the JSF RAD IDEs are answers for a lot of your questions

    2) Your J2EE architecture/design is always OK in a case you mentioned all architecture/design options and their pros/cons in your architecture/design doc and you based your decisions on the business requirements ...

    3) If you do NOT have a proper architecture/design doc your architecture/design is always WRONG ... :)
  61. Patterns for small applications[ Go to top ]

    I once ported a MS-Access application to Java just using SWT, Hibernate, VJDBC and MySQL. Yes, I mean Hibernate-OR-Mapping on the client side with a JDBC-Proxy to the database. Yes, this is the awful old 2-tier approach, this is NOT good J2EE-Design, this is NOT usable for Web-Frontends, this is NOT good concerning security ... but it worked after just one week and the customer was happy. And I was happy to get rid of the crappy VB-Code.

    Are there any other "patterns" for small applications in Java ?

    I think that is the pattern. You could have used a local web server and done JSF or Echo2 or ... .

    Anyway, if you abstracted out the EAO (see another thread) you can easily switch to remote database access with Spring Remoting and webstart the application.
  62. Patterns for small applications[ Go to top ]

    I think using Hibernate in a rich client comes close to the programming model of MS Access. Indeed the Hibernate approach has a great advantage because you can add business logic to your domain classes (non-anemic domain model). That way the code gets much cleaner than the VB counterpart which only uses tabular concepts like Recordsets, Cursors etc.

    Embedding a webserver just to use JSF or other web-frameworks is like shooting sparrows with cannons (German saying :-); creating a Swing/SWT GUI is easier and faster (and comes closer to the GUIs of MS-RAD tools).

    Michael
  63. Patterns for small applications[ Go to top ]

    I think using Hibernate in a rich client comes close to the programming model of MS Access. Indeed the Hibernate approach has a great advantage because you can add business logic to your domain classes (non-anemic domain model). That way the code gets much cleaner than the VB counterpart which only uses tabular concepts like Recordsets, Cursors etc.Embedding a webserver just to use JSF or other web-frameworks is like shooting sparrows with cannons (German saying :-); creating a Swing/SWT GUI is easier and faster (and comes closer to the GUIs of MS-RAD tools).Michael

    U.S. version: Killing flies with a sledgehammer.
  64. Patterns for small applications[ Go to top ]

    I think using Hibernate in a rich client comes close to the programming model of MS Access. Indeed the Hibernate approach has a great advantage because you can add business logic to your domain classes (non-anemic domain model). That way the code gets much cleaner than the VB counterpart which only uses tabular concepts like Recordsets, Cursors etc.Embedding a webserver just to use JSF or other web-frameworks is like shooting sparrows with cannons (German saying :-); creating a Swing/SWT GUI is easier and faster (and comes closer to the GUIs of MS-RAD tools).Michael
    U.S. version: Killing flies with a sledgehammer.

    Chinese version: Killing chicken using a knife for the bull.
  65. Patterns for small applications[ Go to top ]

    I think using Hibernate in a rich client comes close to the programming model of MS Access. Indeed the Hibernate approach has a great advantage because you can add business logic to your domain classes (non-anemic domain model). That way the code gets much cleaner than the VB counterpart which only uses tabular concepts like Recordsets, Cursors etc.Embedding a webserver just to use JSF or other web-frameworks is like shooting sparrows with cannons (German saying :-); creating a Swing/SWT GUI is easier and faster (and comes closer to the GUIs of MS-RAD tools).Michael
    U.S. version: Killing flies with a sledgehammer.
    Chinese version: Killing chicken using a knife for the bull.
    +1
    UK Version: Using a sledgehammer to crack a nut.

    I just can't understand why the Java community can't be honest with itself. I still get programmers quoting the "Sun J2EE Blueprints" at me for the most trivial of applications.

    I've used all of the J2EE acronyms, and whilst I agree that JMS is a amongst the best , it is seldom needed.

    Why doesn't TSS have a survey to find out exactly what people are using and why? It would be a lot better than these pointless "discussions".

    The truth is most programmers need to get back to plain old OO programming basics. Rod Johnsons writings on this subject point this out very eloquently.

    In my experience good programmers use the J2EE toolkit sparingly when they have to. For the rest Sun as done a pretty good job at overselling. As a consequence, IMO many of todays J2EE apps are over-engineered, over complex, expensive and late. These apps will become tomorrows maintainance nightmares.

    What ever happened to KISS (Keep It Simple Stupid)?

    Paul.
  66. I've used all of the J2EE acronyms, and whilst I agree that JMS is a amongst the best , it is seldom needed.

    Actually JMS is such a nimble, all purpose communication API that my company uses it very successfully to build soft real-time distributed applications.

    My distributed applications are significantly event driven (though they have some traditional data form interaction as well) and indeed are designed much like an event-driven GUI application. Only the events flow as messages over the network and the event-driven application exist across numerous nodes instead of on a single computer.

    I used to program with synchronous object interfaces over the network for many years but came to the conclusion that doing such is very much an anti-pattern.

    synchronous RPC considered harmful
  67. Actually JMS is such a nimble, all purpose communication API that my company uses it very successfully to build soft real-time distributed applications
    My preferred approach to distribution is messaging, and I agree JMS is a good solution to this. My question though is why do you need to distribute in the first place? Could it be avoided?


    Paul.
  68. Patterns for small applications[ Go to top ]

    Unfortunately, small applications sometimes become big applications and then of course with unscalable technology they cant become big.

    Please dont ever ever use hibernate and MS Access in the same sentence again. There is nothing that comes close in MS Access to ORM related behavior.

    The C# forum is in need of posts if you feel the need to unburden yoursellf in that way.

    The original poster mentioned the integration aspeect of J2EE like JMS etc which holds little interest for anyone who is not up to their hips in legacy integration of some sort.

    The people who needd it know they need it. The ones who dont should know they dont.
  69. Patterns for small applications[ Go to top ]

    The original poster mentioned the integration aspeect of J2EE like JMS etc which holds little interest for anyone who is not up to their hips in legacy integration of some sort.The people who needd it know they need it. The ones who dont should know they dont.

    I would like to disagree. How do you send emails from your J2EE app??? From HTTP working thread???
  70. Patterns for small applications[ Go to top ]

    The original poster mentioned the integration aspeect of J2EE like JMS etc which holds little interest for anyone who is not up to their hips in legacy integration of some sort.The people who needd it know they need it. The ones who dont should know they dont.
    I would like to disagree. How do you send emails from your J2EE app??? From HTTP working thread???
    I would say it depends. Maybe.
    It is a matter of context and not of religion.
    And good code engineering will let you switch from one
    approach to the other in a breeze.
    As usual, the best tool on the market is alway few
    inches above your neck.....

    Guido.
  71. Patterns for small applications[ Go to top ]

    The original poster mentioned the integration aspeect of J2EE like JMS etc which holds little interest for anyone who is not up to their hips in legacy integration of some sort.The people who needd it know they need it. The ones who dont should know they dont.
    I would like to disagree. How do you send emails from your J2EE app??? From HTTP working thread???
    I would say it depends. Maybe.It is a matter of context and not of religion.And good code engineering will let you switch from oneapproach to the other in a breeze.As usual, the best tool on the market is alway fewinches above your neck.....Guido.

    Well, you have to use some asynch technique to send emails as it is quite slow ... you can implement some asynch queue by your self or just use JMS, which is usually running with your app server anyway ...

    any midle size app has usually 10-50% of code, which SHOULD be implemented in ASYNCH way ...
  72. any midle size app has usually 10-50% of code, which SHOULD be implemented in ASYNCH way ...

    well at least you don't make broad-stroke generalizations.I can't believe I'm actually about to use this cliche, but it seriously appears that the old "every problem looks like a nail" metaphore actually applies to your postings.
  73. JMS Fan[ Go to top ]

    Damian, here's a puzzle for you, in response to your incredulity that somebody might send an email from the HTTP working thread as opposed to queing it for "asynchronous" delivery.

    Let's consider the case where you are running Apache JAMES as the mail server. Obviously the mail server contains queue structures internally, and is very scalable, totally sufficient to handle outbound mails. (this is your use case, right?).

    So, when I use javamail to send an email from the HTTP working thread what happens? A TCP connection is opened to the mail server, the outbound message is queued, TCP connection to outbound mail server closes, and the email is asyncronously delivered. uhhmmm, sounds a lot like a JMS server doesn't it?

    So to understand your viewpoint, this would break the "rules" of J2EE so it should not be done. I suppose it would be better to use JMS as a useless proxy around the mail server. Is that it? Yeah, that would be a lot better. You build your system blinding following the "rules" (based on your own failure to understand asynchronous architectures and more importantly, the failure to understand approproiatness of a technology to a given set of requirements), and I'll build my system FASTER, CHEAPER, and MORE RELIABLY because I BREAK THE RULES when the rules do not apply.
  74. JMS Fan[ Go to top ]

    Damian, here's a puzzle for you, in response to your incredulity that somebody might send an email from the HTTP working thread as opposed to queing it for "asynchronous" delivery.Let's consider the case where you are running Apache JAMES as the mail server. Obviously the mail server contains queue structures internally, and is very scalable, totally sufficient to handle outbound mails. (this is your use case, right?).So, when I use javamail to send an email from the HTTP working thread what happens? A TCP connection is opened to the mail server, the outbound message is queued, TCP connection to outbound mail server closes, and the email is asyncronously delivered. uhhmmm, sounds a lot like a JMS server doesn't it? So to understand your viewpoint, this would break the "rules" of J2EE so it should not be done. I suppose it would be better to use JMS as a useless proxy around the mail server. Is that it? Yeah, that would be a lot better. You build your system blinding following the "rules" (based on your own failure to understand asynchronous architectures and more importantly, the failure to understand approproiatness of a technology to a given set of requirements), and I'll build my system FASTER, CHEAPER, and MORE RELIABLY because I BREAK THE RULES when the rules do not apply.

    The email example is a typical WAN RPC example. Slow and unreliable synchronous TCP connection. If you do not like email you can go for other one. E.g. remote Internet web service. In my case the email connection took always about 5-10 seconds for short emails (corporate mail server).

    I am happy that your email connection is fast and reliable and you do not need an asynch communication model. In this case (reliable and fast connection) JMS does not bring any value and I would not recommend it. You can check my "200ms" example posted in this thread, which describe the trade offs.

    IMO these phrases:
    > "Blinding following the rules"
    > "failure to understand asynchronous architectures"
    > "the failure to understand approproiatness of a technology"

    more describe these posts:
    > "98% of Java developers just don't need it"
    > JMS will be the next J2EE API that people realize they almost never need.

    than my posts.

    I stated my opinion that JMS/asynch is usefull in any middle size app in 20-50%. And I asked for an expert opinions.

    "98%" or "almost never need" sounds for me quite arogant, blind and as lack of understanding of basic IT principles ...
  75. I agree with Damian[ Go to top ]

    JMS is very important. It's very useful when developing Async apps. I just can't picture any large enterprise systems not having any JMS or MOM clients/receivers in their system. It's almost impossible. I dare say 100% of the Fortune 500 companies are using some sort of JMS or MOM based integration in their enterprise system. Whether it's WebSphere MQ, TIBCO, WebLogic JMS, SonicMQ, MSMQ, etc. etc. Messaging has been around for so long, you just can't live without it.

    Can someone name some big companies that they know for sure that aren't using JMS or some sort of MOM architecture? Please enlighten me. Heck, I know the United States Department of Defense surely uses it extensively. It's somehwere in their enterprise system. :)
  76. Patterns for small applications[ Go to top ]

    Please dont ever ever use hibernate and MS Access in the same sentence again. There is nothing that comes close in MS Access to ORM related behavior.

    Please describe, what comes close in Oracle to ORM related behavior???

    AFAIK I can use Hibernate to query MS Access by JDBC/ODBC driver ... Why not???
  77. Patterns for small applications[ Go to top ]

    Please dont ever ever use hibernate and MS Access in the same sentence again. There is nothing that comes close in MS Access to ORM related behavior.
    Please describe, what comes close in Oracle to ORM related behavior???AFAIK I can use Hibernate to query MS Access by JDBC/ODBC driver ... Why not???
    I believe the previous posters were not refering to the database engine of MS Access.
  78. Patterns for small applications[ Go to top ]

    I didn't say that MS Access has OR-Mapping. I said that the way Hibernate provides the objects for me on the client-side looks very natural, easy and intuitive. It's a simple programming model (and Access also has a simple model).

    Your statement about C# shows some of the arrogance I often encounter from Java-Developers when they hear .NET, C#, ADO.NET etc. I don't like religious wars, neither in politics nor in the IT industry. MS also researches the topic of OR-Mapping, just take a look at their LINQ-Project which I find really cool.

    It's always good to know the enemy ;-)
  79. Patterns for small applications[ Go to top ]

    I think using Hibernate in a rich client comes close to the programming model of MS Access. Indeed the Hibernate approach has a great advantage because you can add business logic to your domain classes (non-anemic domain model). That way the code gets much cleaner than the VB counterpart which only uses tabular concepts like Recordsets, Cursors etc.
    Having done plenty of VB and Access, I concur.
    Embedding a webserver just to use JSF or other web-frameworks is like shooting sparrows with cannons (German saying :-); creating a Swing/SWT GUI is easier and faster (and comes closer to the GUIs of MS-RAD tools).Michael
    Again, I agree. I meant to add - ".. But it isn't necessary. Especially what can be done with Swing and SWT."
  80. Patterns for small applications[ Go to top ]

    http://vjdbc.sourceforge.net
     It looks like there is no JNDI configuration and I assume this wrapper doe's not use "UserTransaction" to demarcate transactions. Doe's it support distributed transactions in some way ?
    This is similar stuff, but it is "transactional" http://www.weblogic.com/docs51/classdocs/JDBC_RMI.html#1063993
  81. Patterns for small applications[ Go to top ]

    In VJDBC you can easily use a DataSourceProvider to provide a DataSource that is registered in JNDI. VJDBC doesn't know UserTransactions, just the standard JDBC-Transactions.

    The WebLogic-Driver looks similar to VJDBC. Can it be used without using a WebLogic-Server, let's say in stand-alone RMI mode ? I would like to do some performance tests.
  82. and don't use JMS

    1) The reason is that asynchronic programming model is more difficult to understand/implement. But it offers features, which can NOT be ever delivered by synchronic architectures

    If the above mentioned experts get some time, they should look on the book: "enterprise integration patterns". Almost every middle size app can benefit from JMS ...

    I like this Rod Johnson's saying: "It's naive and arrogant (a dangerous combination!)" ...

    2) I have a strange feeling that people stating we do need 2PC, JMS, ... are same people stating that IT people do not need a formal education and my favorite one that EJB2 is an evil technology ... :)))
  83. Little's Law[ Go to top ]

    We had an enterprise application that used Oracle Advanced Queuing, later ported to OpenJMS. At some point I asked the dude responsible for the queing piece "why are you using a queue?".

    "Scalability"

    ...ahh yes, scalability. It turned out there were no transactions in his architecture, that is, there was no logical action to be taken in the event of a rollback and no logical atom of work. Because, the data being queued was ephemeral, the data was simply replaced by the next batch so there was no need to handle recovery if the system went down and came back online. So at least he didn't tell me "transactions".

    His onMessage method was just taking an object off the queue and putting it into the database. Hard to believe isn't it? A simple timing statement would have proven that the "service time" of the queue was longer than the time required to simply stuff the data into the database.

    It was weird because I was hearing echos of EJB's. Riddles in the dark. Facades to nothing. Remote methods.

    JMS will be the next J2EE API that people realize they almost never need. My point is this: JMS has it's time and place, but your average developer will never be there at that time. The fundamental behjavior of queues is neither intuitive nor obvious. If you've never heard of Little's Law, you probably should do a little reading before jumping into queueing as an answer to your scalability problems.
  84. Little's Law[ Go to top ]

    We had an enterprise application that used Oracle Advanced Queuing, later ported to OpenJMS. At some point I asked the dude responsible for the queing piece "why are you using a queue?". "Scalability" ...ahh yes, scalability. It turned out there were no transactions in his architecture, that is, there was no logical action to be taken in the event of a rollback and no logical atom of work. Because, the data being queued was ephemeral, the data was simply replaced by the next batch so there was no need to handle recovery if the system went down and came back online. So at least he didn't tell me "transactions".His onMessage method was just taking an object off the queue and putting it into the database. Hard to believe isn't it? A simple timing statement would have proven that the "service time" of the queue was longer than the time required to simply stuff the data into the database. It was weird because I was hearing echos of EJB's. Riddles in the dark. Facades to nothing. Remote methods.JMS will be the next J2EE API that people realize they almost never need.

    I suppose that you still do not understand a difference between synch and asynch architectures and their pros/cons. I am not sure, why you advertize your lack of knowledge here ...
  85. Little's Law[ Go to top ]

    +1000000000000000000000000000000000000

    Guido.
  86. Little's Law[ Go to top ]

    We had an enterprise application that used Oracle Advanced Queuing, later ported to OpenJMS. At some point I asked the dude responsible for the queing piece "why are you using a queue?". "Scalability" ...ahh yes, scalability. It turned out there were no transactions in his architecture, that is, there was no logical action to be taken in the event of a rollback and no logical atom of work. Because, the data being queued was ephemeral, the data was simply replaced by the next batch so there was no need to handle recovery if the system went down and came back online. So at least he didn't tell me "transactions".His onMessage method was just taking an object off the queue and putting it into the database. Hard to believe isn't it? A simple timing statement would have proven that the "service time" of the queue was longer than the time required to simply stuff the data into the database. It was weird because I was hearing echos of EJB's. Riddles in the dark. Facades to nothing. Remote methods.JMS will be the next J2EE API that people realize they almost never need. My point is this: JMS has it's time and place, but your average developer will never be there at that time. The fundamental behjavior of queues is neither intuitive nor obvious. If you've never heard of Little's Law, you probably should do a little reading before jumping into queueing as an answer to your scalability problems.

    If the point is that JMS is overused, I have to disagree. I think it is one of the most useful but underused APIs in the stack. IME using queuing can lead to massive increases in scalability.

    Kit
  87. If this is true, then frankly 98% of Java developers are working in small companies or departments doing very boring work with very little value.

    From my experience, this isn't true -- there's a lot of innovative work going on out there.

    I think more likely, the people that author ridiculous blog entries like this are doing very boring work with very little value. I am sorry to be so harsh, but I've seen this made up statistic so often that it is getting tiresome. It is also completely contrary to my experience as a consultant over 6 years (5 of which were independent, 1+ have been with BEA).

    The harsh reality is this: Most senior developers and architects doing important work don't really blog or post (they do lurk, however).

    Any medium to large sized telecom, retail bank or financial services company, for example, uses clustering and messaging, whether some flavour of JMS, IBM MQ, or TIBCO RV. And they have to integrate with many data sources (which often implies XA or two-phase transactions). And they all use clustering, nearly always. Frankly, anyone that has to bet their business on an application is going to use clustering. If you don't need clustering, it's not likely you're writing something that is very important (i.e. requires high availability).

    Nearly all companies seem to also be dealing with mainframe & packaged application integration challenges, or SOA, which is another thing I bet a blogger will say 98% of developers don't care about. But that's ok, if true -- it just means more success for the 2% that do care.
  88. If this is true, then frankly 98% of Java developers are working in small companies or departments doing very boring work with very little value. From my experience, this isn't true -- there's a lot of innovative work going on out there.

    And following on from this, you should bear in mind that the vast majority of developers who are working on large scale projects for large organizations probably have little interest or time to post replies to forum posts such as this, and even if they are interested, it is not unusual for an orgainization to have a corporate policy that prevents them from doing so... resulting in a skewed cross sample of responses from the developer community.
  89. If this is true, then frankly 98% of Java developers are working in small companies or departments doing very boring work with very little value.

    Huh? Developers have to use XA transactions and JMS to provide business value? Systems that don't use these technologies are boring???

    What happened to meeting business requirements? What about creating a rich, object-oriented model of the business domain? Is that boring? Easy? Not to me. Actually it's a lot more challenging than using XA.

    If you think using fancy technologies are what make your work interesting and how you provide value, then I think you've got your priorities mixed up.

    Steve
  90. I contend that most self-proclaimed J2EE developers don't know jack about most of what J2EE gives them. Granted, a lot of developers don't need everything that comes along with J2EE. However, many Java developers don't realize when they *do* need it or could use it to their benefit (JCA message inflow is a great example). The summary of this article seems to be that if you don't need JMS, you don't need J2EE. This would be like me saying if you don't need java.util.concurrent you don't need Java 1.5, it's orthogonal to the point. JMS != J2EE just like JSP != J2EE. Pick the righ tool people. Unfortunately, IMHO most people in this community don't/can't realize when JMS is a benefit to the architecture. As asynchronous apps become the norm, watch for JMS to become a backbone of the infrastructure.
  91. Hype?[ Go to top ]

    I wroked for a document management product using EJB
    and other J2EE gizmos, deployed in Websphere though it would have done with simple servlets, Hibernate deploying on Tomcat.
    When I expressed same opinion with my BA, he said it was because clients get impressed when u say, u used EJB. My opinion is most of the times market hype matters in choosing technologies for project.
  92. Hype?[ Go to top ]

    I wroked for a document management product using EJB and other J2EE gizmos, deployed in Websphere though it would have done with simple servlets, Hibernate deploying on Tomcat. When I expressed same opinion with my BA, he said it was because clients get impressed when u say, u used EJB. My opinion is most of the times market hype matters in choosing technologies for project.

    Maybe client wants protect their investments. The easiest migration way is from EJB2 to EJB3. Not from Spring/Hibernate to EJB3.

    BTW Gevin King just stated that Hibernate 3 focuses on the JPA1 APIs. Hibernate3/4 APIs will stay, but as "add new features, experiment with things, try things out"

    Probably your client is not ready for "experiment with things".

    Also SUN nor IBM supports Tomcat even they embedd it into their web/app servers ...

    I think you clearly demonstrate a difference between a developer and an architect ...
  93. I thought JBoss bought ArjunaTS for distributed transactions - Cause I always thought JMS did not make sense without distributed transaction support. (And I am not talking about ephemeral data )
  94. I thought JBoss bought ArjunaTS for distributed transactions - Cause I always thought JMS did not make sense without distributed transaction support. (And I am not talking about ephemeral data )

    Some activities do not require transaction demarcation. E.g. real time spread of the latest share value ... you just pick up the latest message
  95. some info on JMS[ Go to top ]

    JMS has gotten slammed around quite a bit in this thread. It's a perfectly fine distributed application development API, though, that can be used quite independently of JEE.

    However, the MDB of JEE makes for a fine solution for processing JMS messages in the middle-tier. Indeed, the MDB is by far my favorite EJB because it has been so simple and effective to implement from day one. Other than dependency injection there wasn't much for EJB 3.0 to fix in MDBs - because they've been so darn good all along.

    Well, I've written up quite a bit on JMS in the last month or so - it's my very favorite Java API and is the work horse underpinning all my distributed applications. For those that don't know much about it, it'd be worth expanding your horizons a wee bit:

    Using JMS For Distributed Software Development

    Why are Java developers ignorant of JMS and messaging in general?

    Discussion for: Using JMS For Distributed Software Development

    ah...been there done that - and its great!
  96. some info on JMS[ Go to top ]

    JMS has gotten slammed around quite a bit in this thread.

    No, just some TSS readers show they complete ignorance and lack of knowledge.

    Probably same poeple they believe that a formal education is uselless, becuase you must be born as a real IT GURU ...
  97. some info on JMS[ Go to top ]

    JMS has gotten slammed around quite a bit in this thread.
    No, just some TSS readers show they complete ignorance and lack of knowledge. Probably same poeple they believe that a formal education is uselless, becuase you must be born as a real IT GURU ...
    And you that are formally educated can teach us everything
    we need about IT.
    But, I think there is something else that goes beyond and that
    we don't want to learn from you, and it is your way to post comments.

    Guido.
  98. some info on JMS[ Go to top ]

    JMS has gotten slammed around quite a bit in this thread.
    No, just some TSS readers show they complete ignorance and lack of knowledge. Probably same poeple they believe that a formal education is uselless, becuase you must be born as a real IT GURU ...
    And you that are formally educated can teach us everythingwe need about IT.But, I think there is something else that goes beyond and thatwe don't want to learn from you, and it is your way to post comments.Guido.

    Well, TSS should keep some level of professionalism and ignoring of asynch architectures is definitely not the right way. This is same basic IT principle as e.g. OO. What do not you like about that?

    What do not you like about my comments? Facts are presented as facts. Opinions are presented as opinions. It sounds OK for me. Everybody has some opinions, which do not need to be let's say popular ...

    Nice to know that the TSS "we" is actually you ...

    BTW I have never stated that "formally educated can teach us everything we need about IT".

    I stated that a lack of formal education can cause a lack of basic IT principle knowledge, e.g asynch architectures. Do you disagree, it sounds like a general principle?
  99. some info on JMS[ Go to top ]

    BTW I have never stated that "formally educated can teach us everything we need about IT".I stated that a lack of formal education can cause a lack of basic IT principle knowledge, e.g asynch architectures. Do you disagree, it sounds like a general principle?
    A general principle you say ?
    Yes, and you are so full of general principles, coming from
    a formal education of course, that flow out naturally and
    turn into personal attacks (see your post to Little's Law).

    Guido.
  100. some info on JMS[ Go to top ]

    BTW I have never stated that "formally educated can teach us everything we need about IT".I stated that a lack of formal education can cause a lack of basic IT principle knowledge, e.g asynch architectures. Do you disagree, it sounds like a general principle?
    A general principle you say ?Yes, and you are so full of general principles, coming froma formal education of course, that flow out naturally andturn into personal attacks (see your post to Little's Law).Guido.

    1) No, I learned the asynch messaging my self.

    2) The "Little's Law" post is stating IMO that JMS does not offer better scalability than synch architectures. This is not true, one of asynch main advantages is the scalability (event driven model). Performance is worse. This should be a basic IT knowledge IMO.

    3) I have to admit, that my comment was too personal and I will calm down my temper in the future ...
  101. some info on JMS[ Go to top ]

    The "Little's Law" post is stating IMO that JMS does not offer better scalability than synch architectures.
    I don't thing that this was the aim.
    I like to think that the purpose of the post was to show
    how is frequent to discover that certain decisions are taken
    without serious analysis, but just because
    "asynch is always better, so let all be asynch".
    In the particular case, maybe it was right to have
    a process that simply reads the message from the queue and
    puts some data in a database.
    Or maybe it was right to add extra processing that has been
    left somewhere else.
    Saying simply "scalability" means nothing.
    For a lot of people (and I am not thinking at you :) ),
    it looks like complex systems can be easily built
    (I would say automagically) naming technologies:
    put an EJB here, a JMS Queue there, some sparse JTA
    et voila' it works!!!
    Remember that the devil is hidden in the details.
    And don't forget to use the tool above your neck....

    I have been recently aware of a project
    where the generic integration backbone was WebService.
    Blindly, regardless the systems being integrated.
    And it was natural for them to think to web services that
    acquired a certain (limited) amount of data from a web service, another (still limited) amount of data from
    another web service, finally the VAT from....a web service,
    and the invoice is cooked!!!
    In another solution, WebServices were put in a JBOSS
    container that provided HTTPS access too!!!
    Wonderful, XML parsing overhead was not enough and so
    let's add some encryption/decryption too!!!
    Just to make HW vendors happy.
    3) I have to admit, that my comment was too personal and I will calm down my temper in the future ...
    :)

    Guido.
  102. some info on JMS[ Go to top ]

    The "Little's Law" post is stating IMO that JMS does not offer better scalability than synch architectures.
    I don't thing that this was the aim.I like to think that the purpose of the post was to show how is frequent to discover that certain decisions are taken without serious analysis, but just because "asynch is always better, so let all be asynch".

    Well he stated: "JMS will be the next J2EE API that people realize they almost never need.".

    I still believe that a reason for a strong and wrong statement like that is the lack of asynch architetcure understanding.

    I stated already that in any midle size app you can find 20-50% of code, which should be asynch and I have not got any comment on that.
    ...I have been recently aware of a project where the generic integration backbone was WebService.Blindly, regardless the systems being integrated.And it was natural for them to think to web services thatacquired a certain (limited) amount of data from a web service, another (still limited) amount of data from another web service, finally the VAT from....a web service,and the invoice is cooked!!!In another solution, WebServices were put in a JBOSS container that provided HTTPS access too!!!Wonderful, XML parsing overhead was not enough and solet's add some encryption/decryption too!!!Just to make HW vendors happy.

    Well for an enterprise integrations you do not have too many options: file transfer, shared DB, RPC and messaging.

    For any bigger EAI is messaging usually the best option. JAVA messaging goes as JMS or WS-*(second generation).

    Orchestration of services (service calls other service) is also common practice. There is no other way, how to do it. The problem is if services are not coarse grained.

    XML parsing is an overhead, but for any bigger integration you have to go for the canonical data model, what requires a translation on all 4 levels: protocol, data, syntax and semantic.

    HTTPS is not probably the best option, but if you do no have some ws-security implementation, you do not have a choice. Any security will require some encryption ...

    --------------------------------------

    I do not say that WS in your example are good or bad choice as I do not have enough information, but from EAI perspective it looks OK. What do you suggest as a better option?
  103. some info on JMS[ Go to top ]

    Well for an enterprise integrations you do not have too many options: file transfer, shared DB, RPC and messaging.
    Are not too few, indeed. Expecially if you "open" RPC
    category (the world doesn't start and end with RMI).
    For any bigger EAI is messaging usually the best option. JAVA messaging goes as JMS or WS-*(second generation).Orchestration of services (service calls other service) is also common practice. There is no other way, how to do it. The problem is if services are not coarse grained.
    Bingo!!
    I stated already that in any midle size app you can find 20-50% of code, which should be asynch and I have not got any comment on that.
    Yes, it is reasonable range, even if a question arise: async wrt what ??? But the pb. is not the amount of code. The pb. is the path that leads to the decision of what have to be async.
    The advent of JMS is not a revolution, obviously. Async processing (queueing, Pub/Sub) is around since a long time.
    Again, there is a common (at least IME) bad habit to think that is sufficient to name technologies to define an architecture. The remaining is bare coding..
    XML parsing is an overhead, but for any bigger integration you have to go for the canonical data model, what requires a translation on all 4 levels: protocol, data, syntax and semantic.HTTPS is not probably the best option, but if you do no have some ws-security implementation, you do not have a choice. Any security will require some encryption
    What about having a front-end tier with Apache doing encryption stuffs?

    Guido.
  104. some info on JMS[ Go to top ]

    Well for an enterprise integrations you do not have too many options: file transfer, shared DB, RPC and messaging.
    Are not too few, indeed. Expecially if you "open" RPCcategory (the world doesn't start and end with RMI).

    RPC problem in EAI is tight coupling and synchronicity. For smaller integration RPC should be fine and easier.

    I had an issue that WebLogic was slowing down/hanging the Sun app server, because of 15 HTTP threads waiting in synchronous calls to WebLogic JNDI objects. But Weblogic team (of course from different department) was stating that everything is OK (from their side of course ...). Usually it is not a technical, but a political problem ...
    For any bigger EAI is messaging usually the best option. JAVA messaging goes as JMS or WS-*(second generation).Orchestration of services (service calls other service) is also common practice. There is no other way, how to do it. The problem is if services are not coarse grained.
    Bingo!!
    Also problem is the size of message. Some guys have 1MB XML messages. It is definetely coarse grained, but ... :)
    I stated already that in any midle size app you can find 20-50% of code, which should be asynch and I have not got any comment on that.
    Yes, it is reasonable range, even if a question arise: async wrt what ??? But the pb. is not the amount of code. The pb. is the path that leads to the decision of what have to be async.The advent of JMS is not a revolution, obviously. Async processing (queueing, Pub/Sub) is around since a long time.Again, there is a common (at least IME) bad habit to think that is sufficient to name technologies to define an architecture. The remaining is bare coding..
    I wanted to say "asynch" versus "synch".

    IMO HTTP requests should be responded as soon as possible. If you can not respond quickly you should consider asynch architecture (email, long SQL query, credit card check, etc). Lot of developers do not know, how few threads they have in web/app server JVM (typicaly 64) and what happens if you have 10000 concurrent users.
    XML parsing is an overhead, but for any bigger integration you have to go for the canonical data model, what requires a translation on all 4 levels: protocol, data, syntax and semantic. HTTPS is not probably the best option, but if you do no have some ws-security implementation, you do not have a choice. Any security will require some encryption
    What about having a front-end tier with Apache doing encryption stuffs?
    I see your point.
  105. some info on JMS[ Go to top ]

    Sorry for this f___ing "blockquote"ing ... drives me crazy ...
  106. some info on JMS[ Go to top ]

    Sorry for this f___ing "blockquote"ing ... drives me crazy ...
    Yes, it requires a lot of patience....
    IMO HTTP requests should be responded as soon as possible. If you can not respond quickly you should consider asynch architecture (email, long SQL query, credit card check, etc). Lot of developers do not know, how few threads they have in web/app server JVM (typicaly 64) and what happens if you have 10000 concurrent users.

    Yes, nice. But this implies a radically different user interaction paradigm, I guess.
    If you submit a form to run a query and you want to return as quick as possible, you are simply moving the pb. from the query submit thread to the result display thread.
    Otherwise, being totally async means that query result display request may return a "not ready yet, try again" page.
    And the user retries and retries and retries.
    A really challenging trade-off, as the challenging context suggests anyway.

    Guido.
  107. some info on JMS[ Go to top ]

    Sorry for this f___ing "blockquote"ing ... drives me crazy ...
    Yes, it requires a lot of patience....
    IMO HTTP requests should be responded as soon as possible. If you can not respond quickly you should consider asynch architecture (email, long SQL query, credit card check, etc). Lot of developers do not know, how few threads they have in web/app server JVM (typicaly 64) and what happens if you have 10000 concurrent users.
    Yes, nice. But this implies a radically different user interaction paradigm, I guess.If you submit a form to run a query and you want to return as quick as possible, you are simply moving the pb. from the query submit thread to the result display thread.Otherwise, being totally async means that query result display request may return a "not ready yet, try again" page.And the user retries and retries and retries.A really challenging trade-off, as the challenging context suggests anyway.Guido.

    No, you go too far ... :)

    I mean you have 1000 concurrent users.
    They should get response in 3 seconds.
    You have 64 working threads.
    About 16 users per thread.

    So one request/response can take 190ms max.

    So everything under 200ms should have synchronous UI - OLTP SQL queries, computing of horoscope, etc ..

    Everything more than 200ms should be asynch - OLAP SQL, sending email, checking credit card, generally any heavy remote RPC (especially based on HTTP like WS).

    These are 20-50% I was talking about.

    Everything, what does not require immediate CU attention should be also asynch to save rare synch JVM resources. Email – user does not care if you send email now or in 10 seconds, charging of your credit card, shipping your book, etc ....

    I was in J2EE support for 2 years and lot of developers do not understand this concept. They are only able to increase amount of working threads to something like 500. So JVM than just swap threads, does no real work.

    This is a typical example, where asynch technology like JMS gives you a better scalability, thread utilization and throughput ...

    And TSS publishes that 98% of us do not need JMS ... sorry but guy stating something like that just has no clue ...
  108. some info on JMS[ Go to top ]

    Sorry for this f___ing "blockquote"ing ... drives me crazy ...
    Yes, it requires a lot of patience....
    IMO HTTP requests should be responded as soon as possible. If you can not respond quickly you should consider asynch architecture (email, long SQL query, credit card check, etc). Lot of developers do not know, how few threads they have in web/app server JVM (typicaly 64) and what happens if you have 10000 concurrent users.
    Yes, nice. But this implies a radically different user interaction paradigm, I guess.If you submit a form to run a query and you want to return as quick as possible, you are simply moving the pb. from the query submit thread to the result display thread.Otherwise, being totally async means that query result display request may return a "not ready yet, try again" page.And the user retries and retries and retries.A really challenging trade-off, as the challenging context suggests anyway.Guido.
    No, you go too far ... :)I mean you have 1000 concurrent users.They should get response in 3 seconds.You have 64 working threads.About 16 users per thread.So one request/response can take 190ms max.So everything under 200ms should have synchronous UI - OLTP SQL queries, computing of horoscope, etc ..Everything more than 200ms should be asynch - OLAP SQL, sending email, checking credit card, generally any heavy remote RPC (especially based on HTTP like WS). These are 20-50% I was talking about.Everything, what does not require immediate CU attention should be also asynch to save rare synch JVM resources. Email – user does not care if you send email now or in 10 seconds, charging of your credit card, shipping your book, etc ....I was in J2EE support for 2 years and lot of developers do not understand this concept. They are only able to increase amount of working threads to something like 500. So JVM than just swap threads, does no real work.This is a typical example, where asynch technology like JMS gives you a better scalability, thread utilization and throughput ... And TSS publishes that 98% of us do not need JMS ... sorry but guy stating something like that just has no clue ...

    I saw it a year ago. Project for 3x10^6 $

    1) User starts an HTTP request to send emails to everybody
    2) HTTP request thread opens a cursor to DB
    3) same HTTP request thread reads a row from the cursor and sends an email (e.g. 3 seconds)
    4) same HTTP request thread does it again 500 times
    5) same HTTP request thread closes the connection after about 5 minites of a heavy work ... :)))

    you have 64 default HTTP working threads
    you have 32 DB connections in your connection pool
    you have 10000 concurrent users

    fortunetly this was an admin feauture ...
  109. decoupling request/response[ Go to top ]

    Yes, nice. But this implies a radically different user interaction paradigm, I guess.If you submit a form to run a query and you want to return as quick as possible, you are simply moving the pb. from the query submit thread to the result display thread.Otherwise, being totally async means that query result display request may return a "not ready yet, try again" page.And the user retries and retries and retries.A really challenging trade-off, as the challenging context suggests anyway.Guido.

    A maxim of desktop GUI application implementation (that web developers need to learn - and AJAX is the advent of that beginning to slowly happen), is never, never do a synchronous operation on the main GUI thread of the app. Especially any operation that accesses the network, given that the network is neither reliable or deterministic.

    There are various subtle ways that have been devised in GUI applications to indicate an asynchronous background operation is pending. So dealing with this user interaction approach is by no means rocket science.

    Software that becomes unresponsive to the user is very bad. That is why most web software is so disappointing to use relative to incarnations that have been designed for a highly fluid and interactive desktop GUI. Again, AJAX approach is providing a methodology that enables web software to escape from the "bad user experience" ghetto that it has become so notorious for.

    decoupling request/response in human interactive applications
  110. decoupling request/response[ Go to top ]

    Actually this is a better discussion of decoupling request from response:

    decoupling request/response
  111. Let's go straight.
    What is messaging? What is RPC ?
    Where are the differences ?
    I have read that the damage done by CORBA, DCOM and RMI will last for generations, because their RPC-ish. That the only reasonable way to do distribute systems is via messaging. That messaging technologies are JMS and WS-*.
    Strange.
    First comparing CORBA to DCOM and RMI is not so wise.
    DCOM, for MS admittance, is COM with a longer wire. That, in turn, is DDE with an "object" wrapper (this is mine).
    Now, how it has been possible to compare such a technology with CORBA (born with a different target) is a mistery.
    I will not comment on RMI for manifest inferiority of the contestant.
    About messaging and RPC comparison.
    I think that we are here discussing of distribute systems because of "RPC" existence.
    "Messaging" cannot live without "RPC".
    Why ?
    What is behind JMS Queue send method ?
    How can be 2PC protocol implemented without RPC ?
    CORBA is "RPC" ? Absolutely false. Dig into DII and AMI.
    JMS is "messaging"? Maybe. I can implement "RPC" on top of JMS queues.
    And a TCP connection what is ? That is transport !! Ah yes.
    IMO, "messaging" and "RPC" really means nothing.
    What is important is the interaction sytle of the peers, from ones perspective. Again, checkout async processing approach of ICE to see my point.
    Another common misconception is that WS/SOAP is the key to solve integration problem because achieve true decoupling. It succeeded where other technologies (read CORBA) failed.
    First, SOAP is not simple and there are no objectes. Let's call it AP from now on.
    About decoupling. I am still waiting for an example of such superiority of AP over other.
    Superiority here means "I can do this with AP that it is almost impossible to do with other tech".
    Again (yes, again), there commonly is a trend to name technologies to solve architectural problems, because these decisions are taken by wrong people.
    In this respect I have always found worth to read from time to time this http://www.cs.wustl.edu/~schmidt/editorial-5.html

    Guido
  112. Let's go straight.What is messaging? What is RPC ?Where are the differences ?I have read that the damage done by CORBA, DCOM and RMI will last for generations, because their RPC-ish. That the only reasonable way to do distribute systems is via messaging. That messaging technologies are JMS and WS-*.Strange.First comparing CORBA to DCOM and RMI is not so wise.DCOM, for MS admittance, is COM with a longer wire. That, in turn, is DDE with an "object" wrapper (this is mine).Now, how it has been possible to compare such a technology with CORBA (born with a different target) is a mistery.I will not comment on RMI for manifest inferiority of the contestant.About messaging and RPC comparison.I think that we are here discussing of distribute systems because of "RPC" existence."Messaging" cannot live without "RPC".Why ?What is behind JMS Queue send method ?How can be 2PC protocol implemented without RPC ?CORBA is "RPC" ? Absolutely false. Dig into DII and AMI.JMS is "messaging"? Maybe. I can implement "RPC" on top of JMS queues.And a TCP connection what is ? That is transport !! Ah yes.IMO, "messaging" and "RPC" really means nothing.What is important is the interaction sytle of the peers, from ones perspective. Again, checkout async processing approach of ICE to see my point.Another common misconception is that WS/SOAP is the key to solve integration problem because achieve true decoupling. It succeeded where other technologies (read CORBA) failed.First, SOAP is not simple and there are no objectes. Let's call it AP from now on.About decoupling. I am still waiting for an example of such superiority of AP over other.Superiority here means "I can do this with AP that it is almost impossible to do with other tech".Again (yes, again), there commonly is a trend to name technologies to solve architectural problems, because these decisions are taken by wrong people.In this respect I have always found worth to read from time to time this http://www.cs.wustl.edu/~schmidt/editorial-5.htmlGuido
    We start of with a simple statement on the use of 2PC and JMS and we end up with this. What does this say about our profession?

    To me the above is gibberish with the read-between-the-lines ascertion that "I know what I'm talking about and you don't". I would like to think that I know a fair bit about distribution comming from a telecoms background, but even I wouldn't try to make sense of this one :^)

    I know this is off point, but why do we as developers always feel the need to prove that we know it all?

    More often than not people are talking cross purposes because each party is making assumptions about the circumstances of the other that are probably false. RMI inferior to CORBA? When? in what context?

    Making such statements without context is meaningless IMO.

    I have started following TSS threads in recent months after many years away, and IMO the quality of the discourse when compared to the past as deteriorated significantly. Is this a sympton of Java's success?

    (Sorry about the insulting tone - but I just couldn't let this one go)

    Paul.
  113. We start of with a simple statement on the use of 2PC and JMS and we end up with this. What does this say about our profession?To me the above is gibberish with the read-between-the-lines ascertion that "I know what I'm talking about and you don't".
    No, I am sorry, it is not in my style to write so that other have to "read-between-the-lines".
    I can direct address persons if I have to, and it was not the case.
    I speak about facts, writings that can be easily found googling around, and you go personal.
    "I know what I'm talking about and you don't"
    Never said that, never used "you" meaning yourself or any other else here.
    More, I think that many know very well what they are talking about, but....
    RMI inferior to CORBA? When? in what context?
    Less capabilities, you know, but it doesn't mean unuseful.

    Said that, do you think that what I have called misconceptions, due to real ignorance (i.e., lack of knowledge) or deliberate market strategy, are not true ?
    Have you ever heard that SOAP (oops, AP) allows loosly coupling like no other ? Do you think it's true ?
    I have started following TSS threads in recent months after many years away, and IMO the quality of the discourse when compared to the past as deteriorated significantly. Is this a sympton of Java's success?(Sorry about the insulting tone - but I just couldn't let this one go)Paul.
    I think you would be able to do better than this. Maybe, it's a matter of will

    Guido.
  114. Hi Guido,

    I'm in no doubt that your intention was to some how dispel misconceptions. But if you read what you actually wrote - can you really claim to be successful at this?

    I shouldn't attribute motives to your writing that is true:
    RMI inferior to CORBA? When? in what context?
    Less capabilities, you know, but it doesn't mean unuseful.

    No I don't know what you mean. Most of the other stuff you wrote was meaningless to me too. If a given technology is better suited to my specific needs in my specific situation then for me it is not inferior, in my given context it is superior.

    I would suggest that you be a little more specific in your in future and try not to cover as much ground. Just some friendly advice :^).

    Paul.
  115. Hi Guido,I'm in no doubt that your intention was to some how dispel misconceptions. But if you read what you actually wrote - can you really claim to be successful at this?I shouldn't attribute motives to your writing that is true:
    RMI inferior to CORBA? When? in what context?
    Less capabilities, you know, but it doesn't mean unuseful.
    No I don't know what you mean. Most of the other stuff you wrote was meaningless to me too. If a given technology is better suited to my specific needs in my specific situation then for me it is not inferior, in my given context it is superior.
    Yes, of course, who says the contrary. Provided that you are aware of how far you can go with your choice. It's a matter of limits and the lack of certain server side concepts available with corba (POA, Servant, Interceptors), multilanguage support, portability layer etc. cannot bring you really far, if you have to.
    In this sense I mean inferiority.
    I would suggest that you be a little more specific in your in future and try not to cover as much ground. Just some friendly advice :^).Paul.
    I don't think that my post was really so generic, but surely I am biased by other things I have in mind, that I can clearly see :)

    Guido.
  116. decoupling request/response[ Go to top ]

    A maxim of desktop GUI application implementation (that web developers need to learn - and AJAX is the advent of that beginning to slowly happen), is never, never do a synchronous operation on the main GUI thread of the app. Especially any operation that accesses the network, given that the network is neither reliable or deterministic.
    Yes, I know.
    (Just to clarify, I work this way since the beginning of my
    working experience about 20 years ago -in C, with Xt Toolkit
    handling socket with callbacks..... - ).
    But, from the server side perspective, it doesn't matter if
    you have AJAX or not. You will be polled for response.
    It is not to suggest reading, which might be perceived as offensive, but I have found of a certain interest the approach to async processing followed by ICE team at ZeroC (http://www.zeroc.com).

    Guido
  117. How about a Survey[ Go to top ]

    Hi,

    All this I know more than you BS, and <pick a number>% of code should be asynch nonsense etc.

    What are these forums for? For people to strut their egos and make claims that they cannot possibly backup with imperical data? Or for us all to share experiences and perhaps learn a bit?

    I have been burnt in software enough times to know that each project is very different - and whilst there are reusuable prnciples and concepts, you need to tackle each project as unique. No assumptions.

    How about some real data? I've made a call for the TSS to do some thing useful and hold a survey on how people are using actually using J2EE in the real world.

    Does anyone else feel the same way?

    Paul.
  118. How about a Survey[ Go to top ]

    Hi,All this I know more than you BS, and <pick a number>% of code should be asynch nonsense etc. What are these forums for? For people to strut their egos and make claims that they cannot possibly backup with imperical data? Or for us all to share experiences and perhaps learn a bit?I have been burnt in software enough times to know that each project is very different - and whilst there are reusuable prnciples and concepts, you need to tackle each project as unique. No assumptions.How about some real data? I've made a call for the TSS to do some thing useful and hold a survey on how people are using actually using J2EE in the real world.Does anyone else feel the same way?Paul.

    I was asking people, how much code should be implemented in asynch way for a midle size app. My experience tells me about 20-50%, but I wanted to know other people opinions. I understand that it is going to be a project specific, but there must be some common patterns ...

    I strongly disagree that 98% of us do not need JMS (as a major asynch implementation). I strut my ego only in the case I read a nonsense like this one ...
  119. How about a Survey?[ Go to top ]

    Hi,All this I know more than you BS, and <pick a number>% of code should be asynch nonsense etc. What are these forums for? For people to strut their egos and make claims that they cannot possibly backup with imperical data? Or for us all to share experiences and perhaps learn a bit?I have been burnt in software enough times to know that each project is very different - and whilst there are reusuable prnciples and concepts, you need to tackle each project as unique. No assumptions.How about some real data? I've made a call for the TSS to do some thing useful and hold a survey on how people are using actually using J2EE in the real world.Does anyone else feel the same way?Paul.
    I was asking people, how much code should be implemented in asynch way for a midle size app. My experience tells me about 20-50%, but I wanted to know other people opinions. I understand that it is going to be a project specific, but there must be some common patterns ...I strongly disagree that 98% of us do not need JMS (as a major asynch implementation). I strut my ego only in the case I read a nonsense like this one ...
    I'm amazed you can offer a number. Let me correct you:

    In your experience 20-50% of code has been asynch.

    Well my question is, whether your experience is typical? I can't see how you can strongly agree or disagree with any figure based soley on your own experience. You could be the 2%. All your friends could be in the 2% too.

    So back to my point. Rather than pointless discussions based on personal opinion (I'll let ego go for now ;^)), shouldn't we be having a survey? That way we would all have a sample group > 1 from which to gain some real data.

    Do you agree?

    Paul.
  120. How about a Survey?[ Go to top ]

    Hi,All this I know more than you BS, and <pick a number>% of code should be asynch nonsense etc. What are these forums for? For people to strut their egos and make claims that they cannot possibly backup with imperical data? Or for us all to share experiences and perhaps learn a bit?I have been burnt in software enough times to know that each project is very different - and whilst there are reusuable prnciples and concepts, you need to tackle each project as unique. No assumptions.How about some real data? I've made a call for the TSS to do some thing useful and hold a survey on how people are using actually using J2EE in the real world.Does anyone else feel the same way?Paul.
    I was asking people, how much code should be implemented in asynch way for a midle size app. My experience tells me about 20-50%, but I wanted to know other people opinions. I understand that it is going to be a project specific, but there must be some common patterns ...I strongly disagree that 98% of us do not need JMS (as a major asynch implementation). I strut my ego only in the case I read a nonsense like this one ...
    I'm amazed you can offer a number. Let me correct you: In your experience 20-50% of code has been asynch.

    Exactly, it was stated as IMO. Therefore I asked for other opinions - expert opinions.

    The survey would be nice, but you should also ask, how much JMS/asynch should be used, not only IS used.

    Also please filter out junior developers. I have a whole team of guys, who do not see a difference between "synchronize" on the servlet "service" method and "SingleThreadModel". Lot of people on this level do not need to see a need for JMS at all.
  121. How about a Survey?[ Go to top ]

    Exactly, it was stated as IMO. Therefore I asked for other opinions - expert opinions.The survey would be nice, but you should also ask, how much JMS/asynch should be used, not only IS used.Also please filter out junior developers. I have a whole team of guys, who do not see a difference between "synchronize" on the servlet "service" method and "SingleThreadModel". Lot of people on this level do not need to see a need for JMS at all.
    OK. Agreed.

    I think what is actually happening is probably a lot easier to asertain then what should be happening. "Should be" at the end of the day is very subjective. Also if the questionaire is cleverly worded, we should be able to spot poor practice. E.g. Do you access more than a single transactional resource? and do you use distirubuted transactions? As for juniors, hopefully there experiences will be determined by their senior team members, we could also qualify the data by asking respondees to state number of years experience.

    So all we need to do is drum up more support and get TSS doing something useful for a change.

    Everyone in agreement, please indicate likewise.

    Paul
  122. How about a Survey[ Go to top ]

    Hi,All this I know more than you BS, and <pick a number>% of code should be asynch nonsense etc. What are these forums for? For people to strut their egos and make claims that they cannot possibly backup with imperical data? Or for us all to share experiences and perhaps learn a bit?I have been burnt in software enough times to know that each project is very different - and whilst there are reusuable prnciples and concepts, you need to tackle each project as unique. No assumptions.How about some real data? I've made a call for the TSS to do some thing useful and hold a survey on how people are using actually using J2EE in the real world.Does anyone else feel the same way?Paul.

    No, because each project is not necessarily THAT unique. First, the reason why there are patterns is cause people have discovered commonalities across different projects. If I am writting two wildly different projects that are both web based, I KNOW that I want to use connection pooling.
    I know that even for a new project there will be common elements that can be factored into a domain model so I will write them that way.
    I know I will want to externalized application configuration information like temp directories, email servers, or cache settings, so you absolutely can make assumptions.

    Two, just because your work doesn't involve a particular element of J2EE doesn't mean someone else doesn't need it.

    I don't see people lining up to have their appendix removed or throwing away insurance because they don't use it.
  123. How about a Survey[ Go to top ]

    Hi,All this I know more than you BS, and <pick a number>% of code should be asynch nonsense etc. What are these forums for? For people to strut their egos and make claims that they cannot possibly backup with imperical data? Or for us all to share experiences and perhaps learn a bit?I have been burnt in software enough times to know that each project is very different - and whilst there are reusuable prnciples and concepts, you need to tackle each project as unique. No assumptions.How about some real data? I've made a call for the TSS to do some thing useful and hold a survey on how people are using actually using J2EE in the real world.Does anyone else feel the same way?Paul.
    No, because each project is not necessarily THAT unique. First, the reason why there are patterns is cause people have discovered commonalities across different projects. If I am writting two wildly different projects that are both web based, I KNOW that I want to use connection pooling. I know that even for a new project there will be common elements that can be factored into a domain model so I will write them that way. I know I will want to externalized application configuration information like temp directories, email servers, or cache settings, so you absolutely can make assumptions.Two, just because your work doesn't involve a particular element of J2EE doesn't mean someone else doesn't need it.I don't see people lining up to have their appendix removed or throwing away insurance because they don't use it.
    Hi David,

    I think you missed the plot :^)

    The point was, rather than sounding off with pure subjective opinion, why not help each other out and by collecting some real data amongst ourselves?

    Do you agree?

    Paul.
  124. How about a Survey[ Go to top ]

    Hi,All this I know more than you BS, and <pick a number>% of code should be asynch nonsense etc. What are these forums for? For people to strut their egos and make claims that they cannot possibly backup with imperical data? Or for us all to share experiences and perhaps learn a bit?I have been burnt in software enough times to know that each project is very different - and whilst there are reusuable prnciples and concepts, you need to tackle each project as unique. No assumptions.How about some real data? I've made a call for the TSS to do some thing useful and hold a survey on how people are using actually using J2EE in the real world.Does anyone else feel the same way?Paul.
    No, because each project is not necessarily THAT unique. First, the reason why there are patterns is cause people have discovered commonalities across different projects. If I am writting two wildly different projects that are both web based, I KNOW that I want to use connection pooling. I know that even for a new project there will be common elements that can be factored into a domain model so I will write them that way. I know I will want to externalized application configuration information like temp directories, email servers, or cache settings, so you absolutely can make assumptions.Two, just because your work doesn't involve a particular element of J2EE doesn't mean someone else doesn't need it.I don't see people lining up to have their appendix removed or throwing away insurance because they don't use it.
    Hi David,I think you missed the plot :^)The point was, rather than sounding off with pure subjective opinion, why not help each other out and by collecting some real data amongst ourselves?Do you agree?Paul.

    Yes. However, consider having it also included tech that is one is planning to use. I do believe that JMS has a place in some of the projects that we have, but it won't be used for a few months.
  125. Hell YES[ Go to top ]

    Well, a survey from a site billing itself from the enterprise is going to be biased.

    I don't need a survey to know that many of the J2EE API's serve a very small niche. The problem is not with these API's, nor the niche.

    The problem is with the overselling of the J2EE API's beyond their niche. You've got these absolutely rabid J2EE guys who almost innevitably stand to benefit financially from the continued overselling of J2EE. The problem is that "J2EE" as a marketing focal point of server-side programming has really hurt Java.
  126. Hell YES[ Go to top ]

    Well, a survey from a site billing itself from the enterprise is going to be biased. I don't need a survey to know that many of the J2EE API's serve a very small niche. The problem is not with these API's, nor the niche. The problem is with the overselling of the J2EE API's beyond their niche. You've got these absolutely rabid J2EE guys who almost innevitably stand to benefit financially from the continued overselling of J2EE. The problem is that "J2EE" as a marketing focal point of server-side programming has really hurt Java.
    I tend to agree with your sentiments. Do you remember the Sun J2EE Blueprints? Use it all!

    The thing is that is just my opinion. Some hard data would help in changing attitudes.

    Are there any more YES's out there?

    Paul.
  127. Hell YES[ Go to top ]

    Well, a survey from a site billing itself from the enterprise is going to be biased. I don't need a survey to know that many of the J2EE API's serve a very small niche. The problem is not with these API's, nor the niche. The problem is with the overselling of the J2EE API's beyond their niche. You've got these absolutely rabid J2EE guys who almost innevitably stand to benefit financially from the continued overselling of J2EE. The problem is that "J2EE" as a marketing focal point of server-side programming has really hurt Java.
    I tend to agree with your sentiments. Do you remember the Sun J2EE Blueprints? Use it all!The thing is that is just my opinion. Some hard data would help in changing attitudes. Are there any more YES's out there?Paul.

    I think the reason is that companies and especially their managers are looking for some stable stuff. Not the latest one, not the fancy one, just something stable, which is going to work and is supported. Lot of skilled labour, not so expensive, lot of supliers. Something like Toyota Corolla ... :)

    Why should you burn your fingers if you can get 10 J2EE app servers, 10 J2EE developers and 10 Corollas ... :)
  128. Hell YES[ Go to top ]

    I think the reason is that companies and especially their managers are looking for some stable stuff. Not the latest one, not the fancy one, just something stable, which is going to work and is supported. Lot of skilled labour, not so expensive, lot of supliers. Something like Toyota Corolla ... :) Why should you burn your fingers if you can get 10 J2EE app servers, 10 J2EE developers and 10 Corollas ... :)
    I think this is it. Business is extremely conservative and in their attempts to offset risks, they walk willingly into the hands of software vendors. This has been true from back in the days when everyone bought IBM.

    The truth is that Business need to take responsibility for their own futures. You can't "outscource" your strategic IT strategy. At least they should trust the judgement of the IT professionals they hire over large Software Vendors. They don't even seem to be able to muster up even that much courage. I work in an account where the Oracle salesman has more sway with the "strategy" team then in-house developers (I mean independent developers that aren't Oracle consultants billing at $2000+ a day).

    IMO they (Companies) tend to get what they derserve. But after being scammed several times over (remember Y2K?) many are waking up and beginning to make their own decisions. Which is why opensource technologies like Linux and RoR are getting more of an hearing in Corporate IT then they would have done in the past.

    Paul.
  129. In light of the responses on this thread. I have sent a letter off to Joseph and I am awaiting his response.

    I enclose the the letter here for all to see.

    Paul.


    Hi Joe,

    In recent months TSS has started a number of discussion threads all centring on how people use Java today and on possible alternative technologies such as Ruby and RoR.

    As far as I can tell, all these discussion threads have been based on opinion pieces. Usually the opinion of a well known pundit in the Java community. They are also often promoted with "eye catching" headlines like: "Java Dead like Cobol - not like Elvis".

    Opinion on such a forum IMO is not a bad thing, but it would be niced to balance peoples opinions with some real data. I think the TSS is in a ideal position to do this.

    On a current thread with the headline: "98% of Java developers just don't need it", refering to the use of distributed transactions (two phase commit) and JMS, I an a number of others have expressed the idea that it would be good if the TSS performed a survey to find out Just how the development community is using J2EE and what is truly "hot" and what is "not" in the Java world.

    If you scan the thread:

    http://www.theserverside.com/tss?service=direct/0/PostNewsReply/postReply&sp=l39236&sp=F&sp=l202763

    and look for posts under the title: "How about a Survey?" and: "Hell YES" ( I know some where pretty excited about getting some real data :^)). You will see the ideas expressed.

    I think this would be a tremendous service to the Community and an opportunity for the TSS to lead the way in Developer Community lead information gathering, rather than the usual reliance on Vendor (mis)information. This type of survey could become a common theme, much like the Application Server evaluation matrix. Mining the data gathered and discussing what it means would provide ample discussion points and could be used to influence the JCP for instance.

    Please give the idea some thought and get back to me.

    Looking forward to hearing what you think.

    Regards,

    Paul Beckford.
  130. How about a Survey? - Request made[ Go to top ]

    This type of survey could become a common theme, much like the Application Server evaluation matrix. Mining the data gathered and discussing what it means would provide ample discussion points and could be used to influence the JCP for instance.Please give the idea some thought and get back to me.Looking forward to hearing what you think.Regards,Paul Beckford.

    As you have posted this openly here, I feel free to comment. I don't think such a survey would be of much use at all. It would be self-selecting - you would simply get responses from those who wanted to fill in surveys on TSS! There would be no reason to believe that such a survey would have much statistical meaning.

    There have been surveys performed by other sites or publications presented on TSS recently, and they have been substantially criticised (although not always entirely fairly, in my view).
  131. How about a Survey? - Request made[ Go to top ]

    This type of survey could become a common theme, much like the Application Server evaluation matrix. Mining the data gathered and discussing what it means would provide ample discussion points and could be used to influence the JCP for instance.Please give the idea some thought and get back to me.Looking forward to hearing what you think.Regards,Paul Beckford.
    As you have posted this openly here, I feel free to comment. I don't think such a survey would be of much use at all. It would be self-selecting - you would simply get responses from those who wanted to fill in surveys on TSS! There would be no reason to believe that such a survey would have much statistical meaning.There have been surveys performed by other sites or publications presented on TSS recently, and they have been substantially criticised (although not always entirely fairly, in my view).
    Good point. People say that there are lies, damed lies and statistics. Have you got any suggestions of your own on how we could gain some real data?

    You make mention to data collected by "other sites and publications", could you post the links? I would be more than happy to take a look.

    Technical issues aside it would be nice to have some real data, however questionable the quality may be. At the moment apart from opinion, I'm completely in the dark as I can only go by a sample group of one (myself).

    The surveys you mention have got to be worth a look.

    Regards,

    Paul.
  132. How about a Survey? - Request made[ Go to top ]

    Good point. People say that there are lies, damed lies and statistics. Have you got any suggestions of your own on how we could gain some real data?You make mention to data collected by "other sites and publications", could you post the links? I would be more than happy to take a look.

    http://www.theserverside.com/news/thread.tss?thread_id=38583

    http://www.theserverside.com/news/thread.tss?thread_id=38502
    At the moment apart from opinion, I'm completely in the dark as I can only go by a sample group of one (myself).The surveys you mention have got to be worth a look.Regards,Paul.

    That is my point - how can you tell if they are? I am really not sure how anyone can easily determine what technologies are in use or what developers really think of them. One way might be to go to conferences or meeting and talk to people....
  133. Instead of a survey[ Go to top ]

    How about allowing posters to fill out more detailed information about themselves that other people on TSS can see.

    For example, someone working for an ISV probably has a very different perspective from someone working in an internal IT department. For the ISV making their software compatible with multiple database systems may be important, while IT departments have probably all standardized on one or two database servers and could care less. (It can run on any database, so long as it's Oracle on Unix)

    I think this would put a lot more context behind posts.
  134. Hell YES[ Go to top ]

    Which is why opensource technologies like Linux and RoR are getting more of an hearing in Corporate IT then they would have done in the past.Paul.

    If these technologies are getting more of a hearing than in the past, I doubt it is anything at to do with them being open source or not. Making your own decision is (to me) about freedom from tie-in and the ability to source different parts of your IT strategy from different vendors. Open Source is not a single brand that somehow indicates quality or innovation - it is simply one aspect of software. Linux is widely used because it conforms to well established standards and can therefore easily be used as a replacement for commercial Unix, and is available from many sources. Assuming RoR is getting a wide hearing (and I am sceptical of much of the hype that suggests it really is), there are fundamentally different criteria at work.
  135. Hell YES[ Go to top ]

    Which is why opensource technologies like Linux and RoR are getting more of an hearing in Corporate IT then they would have done in the past.Paul.
    If these technologies are getting more of a hearing than in the past, I doubt it is anything at to do with them being open source or not. Making your own decision is (to me) about freedom from tie-in and the ability to source different parts of your IT strategy from different vendors. Open Source is not a single brand that somehow indicates quality or innovation - it is simply one aspect of software. Linux is widely used because it conforms to well established standards and can therefore easily be used as a replacement for commercial Unix, and is available from many sources. Assuming RoR is getting a wide hearing (and I am sceptical of much of the hype that suggests it really is), there are fundamentally different criteria at work.
    Hi Steve,
    You rebuke many supposed claims for Linux and RoR than were not in my post. The point I was making is a lot simpler.

    Lots of organisations like to back a big vendor and go with the vendors strategy because it makes them feel safe. IBM, Microsoft and now IMO the "Java Cartel" have benefited from this over the years.

    Some companies seem more willing to define their own strategies today. Good or bad OSS is rarely a vendor strategy (especially when the vendor has a competing product). So the adoption of OSS technology as part of strategic IT policy to me does indicate a willingness to make technical choices that haven't been prescribed by some preferred Software vendor (e.g Microsoft, Oracle, IBM etc).

    This doesn't mean that any particular OSS is actually better then any give vendor product. That wasn't the point I was making.

    Paul.
  136. Hell YES[ Go to top ]

    Lots of organisations like to back a big vendor and go with the vendors strategy because it makes them feel safe. IBM, Microsoft and now IMO the "Java Cartel" have benefited from this over the years.

    Ah, well this is where I disagree with you. Defining your own strategy is about choice - freedom from a single vendor. This is why it does not make sense to lump Java in with the above, as it provides choice and vendor independence. This is why Java is so successful.
    Some companies seem more willing to define their own strategies today. Good or bad OSS is rarely a vendor strategy (especially when the vendor has a competing product). So the adoption of OSS technology as part of strategic IT policy to me does indicate a willingness to make technical choices that haven't been prescribed by some preferred Software vendor (e.g Microsoft, Oracle, IBM etc).This doesn't mean that any particular OSS is actually better then any give vendor product. That wasn't the point I was making.Paul.

    Sorry, but I still don't get it. The issue of independence from a vendor has no relevance one way or another with OSS. The reason why open systems and UNIX gained popularity in the 80s was because companies wanted this independence, but this had nothing whatsoever to do with open source. The ability to make technical choices not defined by vendors does not seem to me to be related to OSS, as it has been around long before OSS was taken seriously.
  137. Hell YES[ Go to top ]

    Lots of organisations like to back a big vendor and go with the vendors strategy because it makes them feel safe. IBM, Microsoft and now IMO the "Java Cartel" have benefited from this over the years.
    Ah, well this is where I disagree with you. Defining your own strategy is about choice - freedom from a single vendor. This is why it does not make sense to lump Java in with the above, as it provides choice and vendor independence. This is why Java is so successful.
    Some companies seem more willing to define their own strategies today. Good or bad OSS is rarely a vendor strategy (especially when the vendor has a competing product). So the adoption of OSS technology as part of strategic IT policy to me does indicate a willingness to make technical choices that haven't been prescribed by some preferred Software vendor (e.g Microsoft, Oracle, IBM etc).This doesn't mean that any particular OSS is actually better then any give vendor product. That wasn't the point I was making.Paul.
    Sorry, but I still don't get it. The issue of independence from a vendor has no relevance one way or another with OSS. The reason why open systems and UNIX gained popularity in the 80s was because companies wanted this independence, but this had nothing whatsoever to do with open source. The ability to make technical choices not defined by vendors does not seem to me to be related to OSS, as it has been around long before OSS was taken seriously.
    Hi Steve,
    The company I'm at today is an Oracle shop. So initially they wanted to write the whole application in PL/SQL and Oracle Designer. After being persuaded this wasn't a good idea and perhaps they should use Java, they then wanted to insist that we use Oracle JDeveloper rather than Eclipse.

    I've worked in companies where they have bought into the BEA strategy. From BEA Commerce Server right down to BEA Weblogic. They wasted a lot of time and money before they became convinced that EJB's just weren't needed. So we ended up using PicoContainer inside BEA Weblogic Server. The Weblogic Server was redundant, but they delivered everything through weblogic, so we were glad that we could just stop using EJB's and use Weblogic just as a WebServer (i.e. like Tomcat which we could have downloaded for free).

    I could go on. As a contractor I see this all the time. I think I understand your argument. With the J2EE paper specs you can pick and choose implementations, OSS or vendor specific. In 15 years I don't think I've seen this happen once.

    Usually if the "preferred supplier" as deemed by strategy team provides an "implementation" of a J2EE spec then that is the implementation we use. Often it is the only implementation worth considering because it integrates the easiest with the remainder of the technology stack from the same vendor (which of course we have already bought).

    Personally, I think BEA Tuxedo is a real good product. Using it with BEA Weblogic is dead easy. But suppose if I wanted to avoid those EJB's and use Tuxedo from Spring. Maybe I could, and then again maybe I can't. I think that BEA do supply a J2EE JCA interface to Tuxedo, but the proprietry API in Weblogic was the one they pushed.

    Vendors have all sorts of ways of tying clients in once they make that "strategic" decision. IBM and Microsoft have been doing for years. I have seen both Oracle and BEA do it. IBM, Oracle and BEA are all J2EE vendors.

    To be fair the same can happen in open source. For example AFAIK the new Seam API's in JBoss are "proprietary" to JBoss even though they build on open J2EE API's. So youv'e built your app in JBoss Seam and you decide you want to move it to BEA Weblogic. Is this possible or are you tied in?

    Tying in customers is a software vendor trick as old as the hills. In my experience (about 10 years J2EE)J2EE hasn't stopped this. If anything it gives the pretence of openness that allows companies to settle on a single source supplier comforted that in the final resort they could move, when in reality it would be extremely expensive if they did. The amount of contracts that I got because I specifically knew BEA Weblogic and the ones I lost because I didn't know IBM Websphere. These companies had invested heavily in a given implementation. Changing would mean changing their people too (actually I used Websphere for a while and whilst there were significant differences most developers could move from one to the next, but the clients clearly didn't see things that way).

    So back to open source. If you accept that once you invest in a given implementation, moving will always be an expensive and difficult exercise, then OSS begins to look more attractive. No seamless integration with your encumbant technology stack out of the box, no guaranteed support, and no industry wide accepted paper spec to fall back on should your chosen implementation faulter in popularity.

    Despite this many are willing to bet on open source solutions, simply because they feel that a specific OSS solution is better suited to purpose than the other options on the table. In the Java world you only need to look to the success of Spring and Hiberante over App. Servers and EJB's to see this in action.

    I see Linux as the same. OK Linux is sort of standards based, but what all Linux's have in common is a common kenerel implementation. No one relies on Linux meeting a given POSIX spec version (in fact I think a lot of the Kernal is still BSD but I could be wrong).

    This is an interesting discussion to have over a Pint. I know our views differ. Perhaps we'll meet some day and we can thrash it out down the Pub :^)

    Cheers,

    Paul.
  138. Hell YES[ Go to top ]

    I think I understand your argument. With the J2EE paper specs you can pick and choose implementations, OSS or vendor specific. In 15 years I don't think I've seen this happen once.

    Well, I have. I am working in a situation where both Oracle application servers and Tomcat will be used for different aspects of the same project.
    In my experience (about 10 years J2EE)

    I suspect you mean Java - is J2EE 10 years old?
    So back to open source. If you accept that once you invest in a given implementation, moving will always be an expensive and difficult exercise, then OSS begins to look more attractive. No seamless integration with your encumbant technology stack out of the box, no guaranteed support, and no industry wide accepted paper spec to fall back on should your chosen implementation faulter in popularity.Despite this many are willing to bet on open source solutions, simply because they feel that a specific OSS solution is better suited to purpose than the other options on the table.

    Sorry, but I don't recognise this situation. My experience with Linux is that I really have had seamless integration with existing technology (it works beautifully as a Windows Server replacement in my situation) With RedHat and Dell, I have had guaranteed support.

    This, again, is why I think your generalisations about open source aren't useful.
    In the Java world you only need to look to the success of Spring and Hiberante over App. Servers and EJB's to see this in action.

    Sprint and Hibernate don't compete with App servers or EJBs. They can be used to make app servers and some aspects of EJB easier to work with (such as CMP). Hibernate provides no alternative for session beans or messaging.
    I see Linux as the same. OK Linux is sort of standards based, but what all Linux's have in common is a common kenerel implementation. No one relies on Linux meeting a given POSIX spec version.

    Linux is very standards based. Just look at (for example) the integration with NFS servers and clients. The common kernel implementation provides a lot of compliance with open standards and protocols.
    .This is an interesting discussion to have over a Pint. I know our views differ. Perhaps we'll meet some day and we can thrash it out down the Pub :^)Cheers,Paul.

    Our views differ strongly, but debate is healthy :)
  139. Hell YES[ Go to top ]

    Well, I have. I am working in a situation where both Oracle application servers and Tomcat will be used for different aspects of the same project.
    Me too. I've worked at a large bank and a large telecom (well known names in the US) and at both places we developed on one set of servers and deployed to another.
  140. Hell YES[ Go to top ]

    Well, I have. I am working in a situation where both Oracle application servers and Tomcat will be used for different aspects of the same project.
    Me too. I've worked at a large bank and a large telecom (well known names in the US) and at both places we developed on one set of servers and deployed to another.

    Frequent situation too in any government. Usually you develop having in mind the application should be shareable, at least some parts of it so a sibling organization or departement can use it as a model or as a quick startup. Plus, you avoid vendors lock-in.
  141. Hell YES[ Go to top ]

    Well, I have. I am working in a situation where both Oracle application servers and Tomcat will be used for different aspects of the same project.
    Me too. I've worked at a large bank and a large telecom (well known names in the US) and at both places we developed on one set of servers and deployed to another.

    I routinely have to do it. We have to support Tomcat, JRun, Websphere, and Oracle9iAS.
  142. When was it born ?[ Go to top ]

    I suspect you mean Java - is J2EE 10 years old?

    Erf, I just spotted the same sentence :-)

    No, as far as I can remember in '98 I discovered Java (1.1) and the only stuff you had for web things was... Servlet Engines (BTW 95 is the birth of W3C if I remember well, so I don't think J2EE was even on Sun's timetable then) !

    At that time, the marketing point was performance ! And guess why ? Because of the servlet thread model compared to one-process-per-CGI !!! This is pretty funny when you think about this. In 10 years, what a giant step...

    BTW, I've just tried to look on the Web to find J2EE's birthdate (I owe her a present), but I didn't find...

    Any idea ?

    Have fun,

    Remi - Yet Another Poll
  143. Hell... really ?[ Go to top ]

    Defining your own strategy is about choice - freedom from a single vendor.

    Strange perception. You said you replaced EJBs with Pico stuff... Aren't you now "locked" into Pico whereas following the STANDARDS (in this case, EJBs) is supposed to guarantee higher portability ?

    I mean, OpenSource is something. Being able to maintain a dead OSS project is something else, that no-one (or almost) can afford. Will you maintain Pico tomorrow if they stop, just 'cause you think it rocks ? Sounds like vendor lock-in to me :-P

    I think there's a confusion between STANDARDS and OPEN-SOURCE here.

    Get my point ?
    So the adoption of OSS technology as part of strategic IT policy to me does indicate a willingness to make technical choices that haven't been prescribed by some preferred Software vendor (e.g Microsoft, Oracle, IBM etc).

    Erf. How to say it simple...
    Think about SQL ! Postgres vs Oracle !!!

    The fact that SQL is the standard guarantees portability ands easy replacement. Wether the DB engine is OSS or not is a different story, doesn't it ?

    Also, and it's pretty sad, but I really think what pushes OSS the most is the "free as in beer" side of the stuff. At least I directly know decision makers that clearly have this in mind, and don't feel the need to ask technical persons for advices before going for some gratis Open Source, just because that lowers the right column on their dumb XL spreadsheet.
    Cause if there's something we all agree on here, that's the skills of the average manager (I've met great ones too, and my current team leader is one of them) when it comes to technical issues !
    In the Java world you only need to look to the success of Spring and Hiberante over App. Servers and EJB's to see this in action.

    Really ? Feck, I did not know EJBs were dead. I have to read TSS more often...
    :-P

    Do you have any serious figures to illustrate what you say ? Seriously ! I'd be interested !

    Have fun,

    Remi - I want my poll too
  144. Hell... really ?[ Go to top ]

    Strange perception. You said you replaced EJBs with Pico stuff... Aren't you now "locked" into Pico whereas following the STANDARDS (in this case, EJBs) is supposed to guarantee higher portability ?I mean, OpenSource is something. Being able to maintain a dead OSS project is something else, that no-one (or almost) can afford. Will you maintain Pico tomorrow if they stop, just 'cause you think it rocks ? Sounds like vendor lock-in to me :-P I think there's a confusion between STANDARDS and OPEN-SOURCE here.Get my point ?

    time will tell with EJB3, but I can tell you that EJB2.x applications were not that portable between containers. Did you ever port a reasonably large app from one to another, for instance WebLogic to WebSphere? My last employer did. It took us about a year to get the whole thing ironed out.

    On the other hand, with Pico / Spring / Hibernate / WebWork / etc. you can just drop the jar file in your app and it works the same across app servers.

    I think this is a problem we'll see with JSF too, as it will be required in JEE 1.5 and each different implementation in each container will have its own quirks.
    Erf. How to say it simple...Think about SQL ! Postgres vs Oracle !!!The fact that SQL is the standard guarantees portability ands easy replacement. Wether the DB engine is OSS or not is a different story, doesn't it ?

    Surely you're joking? Do you really think you can drop an app from Oracle to PostgreSQL, or vice versa, with no changes? You really think that everything that a database does, with triggers, stored procs, etc. is covered by the SQL spec? Much less the fact that each of them implement different subsets of SQL, etc.
    Also, and it's pretty sad, but I really think what pushes OSS the most is the "free as in beer" side of the stuff. At least I directly know decision makers that clearly have this in mind, and don't feel the need to ask technical persons for advices before going for some gratis Open Source, just because that lowers the right column on their dumb XL spreadsheet.Cause if there's something we all agree on here, that's the skills of the average manager (I've met great ones too, and my current team leader is one of them) when it comes to technical issues !

    Sure it does. Can you blame them? Especially if you're planning on scaling up your application, you have to look at every incremental cost of adding more capacity. Free licensing is cheaper than not free, once you learn how to manage and operate your environment.
  145. J2EE portability is a myth[ Go to top ]

    I agree with your sentimments. We've seen EJB/JMS ports from one appserver to another take months, with very skilled developers working on it.

    Only trivial apps (i.e. example apps) would port from one app server to another without modification. One of the most highly touted benefits of the application server has not paned out. Not by a long shot.
  146. J2EE portability is a myth[ Go to top ]

    We've seen EJB/JMS ports from one appserver to another take months, with very skilled developers working on it.Only trivial apps (i.e. example apps) would port from one app server to another without modification.

    OK.

    On my left, the ones that build software using devel. OSS AppServer A and deploy in commercial production AppServer B.

    On my right, the ones that shout loud that "J2EE portability is a myth" (!).

    Guys ? Need a survey ? ;-P
     One of the most highly touted benefits of the application server has not paned out. Not by a long shot.

    I remember working in insurance software development, for a huge application.
    The architecture was about "everything in stored procs", "home-made middleware" and "proprietary user interface building tools".
    It was only a few years ago (6 to be precise).
    Please consider thinking again about your statement with this in mind...

    IMHO, Java as a whole, including J2EE, has broken the myth of portability, at the language and programming/execution environment levels !

    Have fun,

    Remi
  147. Support nightmare[ Go to top ]

    I've seen an entire product line stagnate, customers going nuts, support people in a hell they cannot understand, and engineers morassed in configuration issues because a customer wants to run a supposedly portable J2EE application in a different app server.

    Now we can sit here and argue that the people who built the app did it wrong, and didn't follow *all* the best practices that would have lead to 100% portability. But at some point experience in the real world is just too orthogonal to theory.

    On the other hand, I've had wonderful experiences with applications built on servlets and component web frameworks. Portability has been an absolute cake walk. Runs on Tomcat, runs on Jetty, runs on whatever.

    To a large extent these successes are simply because we chose the right tool for the task. If our acrhitecture had *needed* queues, we would have looked to a solution for queuing using Java. BTW, that would NOT mean immediately choosing an application server. But if we blindly followed best practices we'd have been using an app server where it was not required. So, keep your eyes open and pick and choose the J2EE interfaces you need, as well as the J2EE environment (meaning "to AS or not to AS"). It's just common sense.
  148. Support nightmare[ Go to top ]

    I've seen an entire product line stagnate, customers going nuts, support people in a hell they cannot understand, and engineers morassed in configuration issues because a customer wants to run a supposedly portable J2EE application in a different app server.Now we can sit here and argue that the people who built the app did it wrong, and didn't follow *all* the best practices that would have lead to 100% portability. But at some point experience in the real world is just too orthogonal to theory.On the other hand, I've had wonderful experiences with applications built on servlets and component web frameworks. Portability has been an absolute cake walk. Runs on Tomcat, runs on Jetty, runs on whatever.To a large extent these successes are simply because we chose the right tool for the task. If our acrhitecture had *needed* queues, we would have looked to a solution for queuing using Java. BTW, that would NOT mean immediately choosing an application server. But if we blindly followed best practices we'd have been using an app server where it was not required. So, keep your eyes open and pick and choose the J2EE interfaces you need, as well as the J2EE environment (meaning "to AS or not to AS"). It's just common sense.
    +1
    First a correction. I started looking at EJB's in 97/98 (Weblogic 3.2 and EJB0.9 I think) which is less than 10 years as many have pointed out.

    It is hard to generalise about this stuff. I agree that a lot of what we have been promised hasn't been delivered. If you think about it, vendors have a legal responsibility to their shareholders, so tying us in and overselling is what they are there to do. Does anyone remember the Sun J2EE Blueprints? We were told that we needed to use almost everything in J2EE even for a simple PetStore application.

    In my original post I didn't blame the vendors. IMO they are just taking care of their shareholders and their businesses. The blame must lay with Businesses who try to outsource their strategic IT policy to suppliers.

    IMO the rise of open source has been like a breath of fresh air. Most open source projects have a very simple motive, namely to scratch an itch. If a number of other developers share the same itch, then adoption grows.

    This a very different marketing model than J2EE vendor software. For example compulsion. AFAIK all J2EE App Servers will have to support EJB3.0 and EJB2.1. Why? From what someone else has said your App Server will need to support JSF too in order to wear the J2EE badge.

    So what ever happended to lightwieght and fast? What if you don't want or don't need most of this stuff? You just need a lightweight framework, what options do you have other than open source?

    It doesn't sound to me that Developers are in control of the JCP. These decisions sound as though they are there to serve the interests of vendors, helping them hold on to existing clients with encumbant App Servers.

    I could be wrong, but time will tell. In the end people will vote with their feet.

    Paul.
  149. Support nightmare[ Go to top ]

    "This a very different marketing model than J2EE vendor software. For example compulsion. AFAIK all J2EE App Servers will have to support EJB3.0 and EJB2.1. Why? From what someone else has said your App Server will need to support JSF too in order to wear the J2EE badge."

    Actually this is something that was asked at the Symposium back in 2004 when the whole EJB 3.0 thing was announced. I personal think it would be much better to have a light weight version of the containers that support EJB 3.0 and then have full blown EJB 2.1/EJB 3.0 containers. Each one can be certified accordingly. It makes no sense to have people stuck waiting for a container that supports EJB 2.1 to start up when they only want to use the EJB 3.0 features.
  150. Support nightmare[ Go to top ]

    I simply don't believe you are correct. In all the "heavyweight" talk I've ever participated in, none, myself included have ever complained about the API. The "heavy" in heavyweight has always been the reliance on the container, not the inclusion of things like JMS.

    A support nightmare woudl be trying to 50 odd versions of say WebSphere by trying to tailor one for every conceivable project.

    The lightweight movement, as far as I see, was to remove the dependency on the container, its APIs, its interfaces and classes.

    The reason why Spring, for example and by their own admission don't included say an JMS server is because it isn't a value add. Instead they plug into everyone elses.

    And doesn't JBoss, an open source project support basically the same things as say Weblogic, excluding, perhaps things like high-end cluster and failaover support?

    Have you noticed that you seem to be the only one complaining, and you don't even use J2EE.
  151. Support nightmare[ Go to top ]

    I simply don't believe you are correct. In all the "heavyweight" talk I've ever participated in, none, myself included have ever complained about the API. The "heavy" in heavyweight has always been the reliance on the container, not the inclusion of things like JMS.A support nightmare woudl be trying to 50 odd versions of say WebSphere by trying to tailor one for every conceivable project.The lightweight movement, as far as I see, was to remove the dependency on the container, its APIs, its interfaces and classes.The reason why Spring, for example and by their own admission don't included say an JMS server is because it isn't a value add. Instead they plug into everyone elses.And doesn't JBoss, an open source project support basically the same things as say Weblogic, excluding, perhaps things like high-end cluster and failaover support? Have you noticed that you seem to be the only one complaining, and you don't even use J2EE.

    One other thing, we've been using C3P0, an open-source connection pooler. I don't think app server should drop this because an open source version exists.
  152. Support nightmare[ Go to top ]

    Have you noticed that you seem to be the only one complaining, and you don't even use J2EE.
    Hi,

    I was avery early adopter of Java and J2EE. I was using App. Servers when they where still written in C++ and based on Corba (anyone remember OAS 0.x?). In fact I was the Java/J2EE Champion back then. I still use Java for 70% of my coding today.

    Things change and times move on. I don't subscribe to the all good or all bad attitude that many on this forum have adopted. Java/J2EE has delivered a lot of positives over the years, and still has many good points (for e.g. the servlet container model works very well as a standard, so does JDBC and JMS when needed).

    For Agile development using the latest software development ideas, IMO Java is just not where it's at today. As you can see since I first posted this, many have responded in broad agreement.

    Like I said, in the end people will vote with their feet, so I guess we will just have to wait and see (I was right back in 97/98 and I think I'm going to be proved right again).

    Paul.
  153. Support nightmare[ Go to top ]

    For Agile development using the latest software development ideas,

    Sorry, this is just false. Java is very suited to agile development - more suited in some ways than languages like Smalltalk and Ruby, as it can do more refactorings and more forms of code analysis faster. I was only recently convinced of this when I was shown that static type safety is actually an important tool for some refactorings.

    As for the latest software Java is showing exciting practical implementations of software development idea. Take ORM for example - while Rails is stuck on relational systems, and uses SQL, Java has approaches like JDO 2.0 which is rich, powerful, portable and can persist to just about anything. Which is more innovative? While other web frameworks can require tedious hand scripting for HTML output, Java has JSF which can make web development as fast as using VB or Delphi, and render to many types of presentation. Which is more innovative?
    IMO Java is just not where it's at today.

    There may be justifiable reasons for someone to think that Java is not still innovative. Personally, I haven't heard any that have convinced me.

    Where things are at today includes high-performance portable computing and (increasingly) highly multi-threaded work. The latter will become very important as processors go multi-core to overcome other limits to increased performance. Java excels at this, but fashionable languages like Ruby really don't.
    As you can see since I first posted this, many have responded in broad agreement.

    Even if they agree, they are wrong, I humbly suggest. See above. Many like me respond in broad disagreement :)
  154. Support nightmare[ Go to top ]

    For Agile development using the latest software development ideas,
    Sorry, this is just false.
    Hi Steve,
    I think you're just plain wrong on this one. I know little about JDO, but many of the new OSS Java tools where inspired at least in part as an attempt to make Java development more Agile. I believe JMock, Hibernate, PicoContainer etc all fall into this category to some degree. What killed EJB2.1 for me is that EJB's were very difficult to test.
    Java is very suited to agile development - more suited in some ways than languages like Smalltalk and Ruby, as it can do more refactorings and more forms of code analysis faster. I was only recently convinced of this when I was shown that static type safety is actually an important tool for some refactorings.
    There as been a long discussion on TSS about Refactoring and dynamic vs static before. I won't go into it again, but the real point about refactoring, is being able to do a little and change and evolve the code in response to real tests.

    Productivity using something like Seaside, Smalltalk and The Refactoring Browser trumps Eclipse and Tomcat. Even with Ruby with minimal IDE support, people are saying that manual refactors are actually quicker than using Eclipse and starting and stoping tomcat to perform tests.

    In XP/Agile development there are three steps to the programming cycle:
    TEST, CODE, REFACTOR - this cycle needs to be as fast as possible. If you stand back and look at the bigger picture you will see that often Java is just not Agile in this regard (imagine having to start and stop your App. Server before each test).

      
    As for the latest software Java is showing exciting practical implementations of software development idea. Take ORM for example - while Rails is stuck on relational systems, and uses SQL, Java has approaches like JDO 2.0 which is rich, powerful, portable and can persist to just about anything....
    There may be justifiable reasons for someone to think that Java is not still innovative. Personally, I haven't heard any that have convinced me....
    As you can see since I first posted this, many have responded in broad agreement.
    Even if they agree, they are wrong, I humbly suggest. See above. Many like me respond in broad disagreement :)There are split views out there. It really depends on your perspective. From much of what you've written above, I can see that your exposure to Agile development and Agile ideas is limited. In which case Ruby will not appeal. I don't think Ruby and RoR today is perfect, but it does hold tremedous promise (along with a number of other dynamic languages). Agility has little to do with flash tools like JSF. Agile developers have specific concerns like doing thing "once and once only" (the Ruby guys call this DRY) to minimise the code base and refactoring/maintenance costs. Incidently the key mechanism for this is pure OO design rather than procedural programming. There are many OO concepts that cannot be implemented in Java (e.g closures) so Java developers are at an immediate disadvantage when it comes to DRY and true OO programming. The other key issue for Agility is testablity. How will you unit test your JSF controllers and views? Key to Agile too is automation. How do you automate unit and user acceptance tests that are tied to containers? You will need to run your tests all the time.

    The Agile community are not waiting on vendors. They are busy producing OSS tools to solve their own problems. The search for better Agile tools are leading many Agile practioners to dynamic languages like Ruby.

    Paul.
  155. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    Don't just take my word for it. I've heard recently that ThoughtWorks are pushing Ruby heavilly (ThoughtWorks are a leading Agile Consultancy, headed up by Martin Fowler).

    http://www.thoughtworks.com/ruby.html

    Dave Thomas of the Programatic Programmers is Pushing Ruby heavilly too.

    As I said previously, I have already been approached by an Agent for an Agile Ruby position. A lot is going on in the Agile Community when it comes to dynamic languages. IMO it is only a matter of time untill it spills out into main stream development (just like like JUnit, Refactoring, Mocking, IoC, etc in the past).

    Paul.
  156. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,Don't just take my word for it. I've heard recently that ThoughtWorks are pushing Ruby heavilly (ThoughtWorks are a leading Agile Consultancy, headed up by Martin Fowler). Dave Thomas of the Programatic Programmers is Pushing Ruby heavilly too.As I said previously, I have already been approached by an Agent for an Agile Ruby position. A lot is going on in the Agile Community when it comes to dynamic languages. IMO it is only a matter of time untill it spills out into main stream development (just like like JUnit, Refactoring, Mocking, IoC, etc in the past).Paul.

    Sorry, but repeating the same names over and over again does not convince.

    IT development is not like a religion where we have to believe everything one of our great leaders says!

    I am sure that a lot of ideas from dynamic languages will contribute to the on-going progress of static languages. And also ideas from static languages will pass on to dynamic languages. Like AOP.

    As I have said again and again, there has been an interesting difference of views between static and dynamic approaches for decades. Neither will win.
  157. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    OK, I give up. I really can't win. If I'm specific I'm acused of of being too specific when slating a whole language. If I'm general then I need to be more specific :^)

    My goal isn't to slag off Java. I think I've said one several occasions that Java is a great language with lots of first and many great APIs.

    I was responding to your statement that you couldn't see what dynamic languages like Ruby had to offer.

    JSP and Tomcat hot deploy (when it works) as fast to develop web apps as Seaside? So you've tried Seaside and you actually believe this?

    Sounds like willful ignorance to me.

    I can see that you've made up your mind, so I'll drop the subject, and let others discuss JMS and 2PC.

    Paul.
  158. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,OK, I give up. I really can't win. If I'm specific I'm acused of of being too specific when slating a whole language.

    You are slating a whole language but only giving serious examples based on legacy J2EE - such as saying that the language isn't agile because of the way EJBs used to work.
    If I'm general then I need to be more specific :^)My goal isn't to slag off Java.

    Then I must have misinterpreted statements like
    For Agile development using the latest software development ideas, IMO Java is just not where it's at today

    and
    There are many OO concepts that cannot be implemented in Java (e.g closures) so Java developers are at an immediate disadvantage when it comes to DRY and true OO programming.
    I think I've said one several occasions that Java is a great language with lots of first and many great APIs.I was responding to your statement that you couldn't see what dynamic languages like Ruby had to offer.

    And I hope I have politely responded.
    JSP and Tomcat hot deploy (when it works) as fast to develop web apps as Seaside?

    Yes.
    So you've tried Seaside and you actually believe this?

    Yes. I have tried Seaside. It is awesome, and huge fun. But I don't believe for substantial apps, development is faster.

    Let me tell you why. When you have to test large amounts of code it can take time to get to the state where tests are complete. Functional tests can take time. With Java I can get some functional tests performed a lot faster than I can with Smalltalk or Ruby. This is my experience of why it can be as fast to develop some web apps.

    Also, continuation-based development like with Seaside may be great for development, but....

    http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&entry=3261069762

    "Seaside is memory intensive. Trading memory for ease of use. There are apps that you cannot make that trade-off."

    Indeed.
    Sounds like willful ignorance to me.I can see that you've made up your mind, so I'll drop the subject, and let others discuss JMS and 2PC.Paul.

    I won't comment further, except to say that I think it is a shame that you have posted this statement. Rigorous debate is fine, but I also think that some degree of politeness is important.
  159. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    Didn't want to come across as rude. But we sx eem to occupy completely different worlds. I do believe I have been pretty specific with my critisims of Java. Yet in your opinion ANY criticism is slaging off the whole language.

    There is a bigger a picture. Bigger then any given programming language, bigger then even any given programming approach. I've tried to engage this big picture on a number of occasions and have been critisied for being too general.

    Well IMO, there is a reason why many companies are chosing to outsource software development to India. To me it is a desperate attempt to get value for money from their IT investments. IMO this is an indictment on the software industry, and Java/J2EE, .NET along with C++/CORBA in the past must all take their fair share of responsibility for this situation.

    My view is that the motives driving new technologies has been primarily commercial over the last 20 years, and as a consequence many of the best ideas have not really seen the light of day, and hence the situation we have today where our customers no longer believe in our ability to deliver.

    I believe that the Agile Community (it does exists just look on yahoo groups, there are several agile forums - also look on the web for XP/Agile User Groups, they exist all around the world) is attempting to adress this problem at root. I also believe that OSS is proving to be a great tool in focusing development effort on the real issues facing our customers rather than using our best brains to expend intellectual effort on the commerical priorities of software vendors.

    I aplogise if my assertion of willful ignorance is false. But other than attacking my position you have offered no vision for the future of your own. it is very easy to throw stones - but it takes a bit more thought to offer solutions.

    No technology is perfect. That Includes Ruby, Seaside and as strange as it may sound to you Java. The question is what are the challenges facing us today and in the future, and what technologies and communities are offering the most promise in comming up real solutions.

    I've outline my view of the way forward in detail (and in general), many people out there agree (see the Agile forums). So what's yours?

    Paul.
  160. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,Didn't want to come across as rude. But we sx eem to occupy completely different worlds.

    I suspect this is the case - different situations for software development, perhaps.
    I do believe I have been pretty specific with my critisims of Java. Yet in your opinion ANY criticism is slaging off the whole language.

    Not at all. I totally accept that the way that J2EE has been often set up leads to testing issues. But to me, statements that '

    There is a bigger a picture. Bigger then any given programming language, bigger then even any given programming approach. I've tried to engage this big picture on a number of occasions and have been critisied for being too general.Well IMO, there is a reason why many companies are chosing to outsource software development to India. To me it is a desperate attempt to get value for money from their IT investments. IMO this is an indictment on the software industry, and Java/J2EE, .NET along with C++/CORBA in the past must all take their fair share of responsibility for this situation.My view is that the motives driving new technologies has been primarily commercial over the last 20 years, and as a consequence many of the best ideas have not really seen the light of day, and hence the situation we have today where our customers no longer believe in our ability to deliver.I believe that the Agile Community (it does exists just look on yahoo groups, there are several agile forums - also look on the web for XP/Agile User Groups, they exist all around the world) is attempting to adress this problem at root.

    Java should not take the blame. It is a pragmatic response to lessons learned during the previous decades of development.
    I also believe that OSS is proving to be a great tool in focusing development effort on the real issues facing our customers rather than using our best brains to expend intellectual effort on the commerical priorities of software vendors.

    And I believe vendors in combination with standards are vital as they have the commercial imperative to deliver quality. Competitive implementation of standards is what I favour - I have been let down too often by other approaches. OSS alone is simply one aspect of software. As I have said before, innovation has gone on fine before OSS, and there are great brains working within the commercial field.
    I aplogise if my assertion of willful ignorance is false.

    I think you should apologise for the assertion unconditionally, as it should not be made anyway, but fair enough.
    But other than attacking my position you have offered no vision for the future of your own. it is very easy to throw stones - but it takes a bit more thought to offer solutions.

    I saw no evidence of a vision - simply statements that Java isn't truly OOP or agile..
    No technology is perfect. That Includes Ruby, Seaside and as strange as it may sound to you Java.

    When have I said Java is perfect? There is much that I would change.
    The question is what are the challenges facing us today and in the future, and what technologies and communities are offering the most promise in comming up real solutions.I've outline my view of the way forward in detail (and in general), many people out there agree (see the Agile forums). So what's yours?Paul.

    My way forward is simple - get more people better trained in fundamental principles of reasonably modern software design. There are still a very large number of developers still using non-OOP C. There are a very large number who think that PHP is the ultimate web development system. There are still developers who can't see the advantages of OOP. (I am not saying everyone should use it - but at least know what it is). I have recently seen a debate on another (well-known) forum in which developers were talking about the huge problems writing portable database interfacting code. They had no idea that Hibernate, JDO or EJB 3.0 existed! There are Rails developers who put the data model in the database, (counter to all the years of experience of developers who have been working to get portability and vendor independence) and think this is the ultimate way to do things (I realise there are Rails developers who understand that this approach is simply a fast way to implement applications, but that is not my point).

    Because of this (and many other things), my view is that Java has a long way to go before its job is done. It will be years (if not decades) before the majority of code runs in secure managed languages, and we move away from the insecure buggy disaster that was the mass use of C and C++.

    Until then, there is a need for a language that is safe, high-performance and with the solid backing of developers and vendors - not exciting OSS projects that are fun and cool, but solid multi-threaded performance, compatibility, portability and security. For me, Java is that language. We need it to replace as much C and C++ is possible.
  161. Agility and Dynamic Languages[ Go to top ]

    Sorry, but there is no way to develop posts here in an Agile manner, and test :)
    Not at all. I totally accept that the way that J2EE has been often set up leads to testing issues. But to me, statements that '

    I should have finished....

    statements like 'For Agile development using the latest software development ideas, IMO Java is just not where it's at today' sounds like they are 'slagging off the whole language'.
  162. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    I understand your view. This sums it up for me:
    Java should not take the blame. It is a pragmatic response to lessons learned during the previous decades of development.

    I strongly disagree. I've seen too many over Engineered non OO (read DTO pattern) J2EE solutions that are destined to become the C++/CORBA/DCOM like maintenance nightmares of tomorrow (infact I've had to maintain the odd J2EE app myself and it wasn't fun).

    I agree that education is the biggest issue. Other than that we disagree on the solution.

    But at least I understand your vision now.

    Paul.
  163. First I don't agree DTO is an anti OO pattern. It is overkill for a lot of applications but beside remote communication it has proven useful.
    Couple of cases :
    1) You don't want to load a full graph of objects. Well lazy loading can be a solution, but DTO can also be one.

    2) DTO can track modifications and reduce the cost of many updates. SDO is an implementation of this concept.

    3) DTO is a neutral information representation that can be share across multiple layers or components. Once again take a look at SDO

    The problem in my opinion is lot of times DTO is just not needed or wrongly implemented (using strong typed objects instead of using a graph data structure).

    Secondly, I like Java because it has find a good balance between being powerful and yet easy to maintain. For our previous posts, I guess your favorite language is SmallTalk. While I agree it is very powerful, it is still a nightmare to get started in someone else code. A language isn't just effective because it is powerful, is also has to be simple enough, something Smalltalk has always lacked in my mind.

    Beside, Smalltalk is more OO oriented in certain facets but less in other. For instance, Smalltalk is based on a 4 levels OO metamodel instead of a 3 one's like Java do. This way you don't need any static stuff, template or creational patterns but it is way harder to understand especially when it isn't your code. Human brain is more used to think in the Java way. Classes and object are a natural concept but have you ever seen any Meta-class in the real world eh?. Also Smalltalk doesn't support normal values wich I think is a big minus. As defined in the UML specification, a value has no notion of identity : a 5 is the same as any other number 5. I don't need to differentiate them like I need to with objects. Hence primitives in Java weren't a bad idea after all. Finally, wich is better between strongly typed language vs weak typed language has been an outgoing debate in the last 30 years so I guess there isn't a definitive answer.

    So to summarize, I think Java is a good balance between power and simplicity. Well since it is a long post, sorry for my english. I always try to improve!
  164. Paul by the way, you always seem to imply agility = XP (I could be wrong) but agility isn't just about "test, compile, refactoring". RUP is considered a semi-agile method since it is iterative and incremental and SCRUM doesn't enforce you to design your software this way either. As you guess, I am not a big fan of XP but I like agile processes. I always taught that TDD was good once a basic architecture is set off and the big components have been identified. In sumary, I think TDD is good at a micro level but you still need to care about the macro level or you can end up running in circle. Just my 2 cents.
  165. Paul by the way, you always seem to imply agility = XP (I could be wrong) but agility isn't just about "test, compile, refactoring". RUP is considered a semi-agile method since it is iterative and incremental and SCRUM doesn't enforce you to design your software this way either. As you guess, I am not a big fan of XP but I like agile processes. I always taught that TDD was good once a basic architecture is set off and the big components have been identified. In sumary, I think TDD is good at a micro level but you still need to care about the macro level or you can end up running in circle. Just my 2 cents.
    Agreed. But I woudn't class RUP as Agile myself (RUP tends to be what ever you want it to be). The thing with XP is that out of all the agile methodologies it prescribes the most technical practices. Scrum just says let the team self organise and follow the technical practices they see fit. Most Scrum teams do XP as their technical practice and most XP teams do Scrum as their management practice.

    Since we are talking about technology, I've been focusing on XP.

    Paul.
  166. First I don't agree DTO is an anti OO pattern. It is overkill for a lot of applications but beside remote communication it has proven useful. Couple of cases :1) You don't want to load a full graph of objects. Well lazy loading can be a solution, but DTO can also be one. 2) DTO can track modifications and reduce the cost of many updates. SDO is an implementation of this concept.3) DTO is a neutral information representation that can be share across multiple layers or components. Once again take a look at SDOThe problem in my opinion is lot of times DTO is just not needed or wrongly implemented (using strong typed objects instead of using a graph data structure).
    Hi Alexandra,

    I said that DTO is non OO. Many OO concepts have been diluted and mis-represented in hybrid languages like C++ and Java. OO is about sending messages to objects. OO is not about data transfer. DTO's are just a manifestation of what we use to call structures in C. DTO is procedural programming.

    Why is this a problem? Well one of the goals of both Agile and OO design is "once and once only". With DTO's you tend to repeat yourself several times. Your struts forms are a sort of DTO that then needs to be copied into your real DTO, that then needs to be copied into a value object for persisitence using say a DAO. So you say the same thing three times. This means three times as much code, which means that any chnage will take three times as long which makes you less Agile.
    Secondly, I like Java because it has find a good balance between being powerful and yet easy to maintain. For our previous posts, I guess your favorite language is SmallTalk. While I agree it is very powerful, it is still a nightmare to get started in someone else code. A language isn't just effective because it is powerful, is also has to be simple enough, something Smalltalk has always lacked in my mind.Beside, Smalltalk is more OO oriented in certain facets but less in other. For instance, Smalltalk is based on a 4 levels OO metamodel instead of a 3 one's like Java do. This way you don't need any static stuff, template or creational patterns but it is way harder to understand especially when it isn't your code. Human brain is more used to think in the Java way. Classes and object are a natural concept but have you ever seen any Meta-class in the real world eh?. Also Smalltalk doesn't support normal values wich I think is a big minus. As defined in the UML specification, a value has no notion of identity : a 5 is the same as any other number 5. I don't need to differentiate them like I need to with objects. Hence primitives in Java weren't a bad idea after all. Finally, wich is better between strongly typed language vs weak typed language has been an outgoing debate in the last 30 years so I guess there isn't a definitive answer.So to summarize, I think Java is a good balance between power and simplicity. Well since it is a long post, sorry for my english. I always try to improve!

    I understand this view, but again I think this is due mainly to mis-information. I have been doing OO programming for over 12 years. In that time I can count on one hand the number of programmers I've come across with a full grasp of OO concepts, and most of those were Smalltalk programmers at some time. I learnt Smalltalk myself because I just was not getting OO with C++.

    Like I said OO has been misrepresented through languages like C++ for years. OO is an amazing powerful technique, but it does require real experience to fully grasp it. Unfortunately with a language like C++ or Java (and even Ruby to a lesser degree) it is difficult to know when you are transfering between procedural and OO programming hence the difficulty in fully understanding OO concepts, and the resulting difficulty with a language like Smalltalk where there are no procedural constructs at all (even program control in Smalltalk is performed by sending messages).

    I hope this doesn't sound arrogant. But this is my experience. I would suggest that you forget everything you know about objects and look at them afresh through the lense of a language like Smalltalk. Your may find that your perception of OO changes drastically.

    Paul.
  167. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,I understand your view. This sums it up for me:
    Java should not take the blame. It is a pragmatic response to lessons learned during the previous decades of development.
    I strongly disagree. I've seen too many over Engineered non OO (read DTO pattern) J2EE solutions that are destined to become the C++/CORBA/DCOM like maintenance nightmares of tomorrow (infact I've had to maintain the odd J2EE app myself and it wasn't fun).I agree that education is the biggest issue. Other than that we disagree on the solution.But at least I understand your vision now.Paul.

    Yet again you are taking one aspect of Java and extrapolating! I did not say that some J2EE solutions are a pragmatic response to decades of experience. I said Java was the reponse. Java the language, not how some use (or misuse) it in one particular area of development.

    You are disagreeing with something I was not saying.
  168. Agility and Dynamic Languages[ Go to top ]

    I said Java was the reponse. Java the language, not how some use (or misuse) it in one particular area of development.
    Yeah. No one would missuse, say, Ruby to create a framework that uses the database as the foundation for applications. ;)

    Anyway, I agree the problem being training, etc. Well part of it. I don't anything short of magic will solve the issue. Using Ruby or Java or .. won't solve it. Instead of trying to do development better, management has decided that they'll just try to do it cheaper. Or so they think. (gotta run so I can't finish my though - same issue as Remi :) )
  169. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,I understand your view. This sums it up for me:
    Java should not take the blame. It is a pragmatic response to lessons learned during the previous decades of development.
    I strongly disagree. I've seen too many over Engineered non OO (read DTO pattern) J2EE solutions that are destined to become the C++/CORBA/DCOM like maintenance nightmares of tomorrow (infact I've had to maintain the odd J2EE app myself and it wasn't fun).I agree that education is the biggest issue. Other than that we disagree on the solution.But at least I understand your vision now.Paul.
    Yet again you are taking one aspect of Java and extrapolating! I did not say that some J2EE solutions are a pragmatic response to decades of experience. I said Java was the reponse. Java the language, not how some use (or misuse) it in one particular area of development.You are disagreeing with something I was not saying.

    His Steve,

    I initially said:
    IMO this is an indictment on the software industry, and Java/J2EE, .NET along with C++/CORBA in the past must all take their fair share of responsibility for this situation.

    Your response was that java isn't to blame. Java as a language isn't good or bad what matters is the use, so in this regard I have to agree. My point is that in the realm of so called "enterprise development" Java/J2EE has had its fair share of carbuncles along with the other technologies I mentioned.

    So back to solutions. I don't see everyone using Java/J2EE as a solution. It really has got to start with the people. We both agree on the issue of education. I would also expand that to include how projects are envisioned and managed and the degree of developer access to end-users.

    I can see with the move to outsourcing to India even more project failures. They will be using technologies like J2EE and .NET and following the book (J2EE Core patterns). They will also be developing from paper specs and not talking to real users.

    This "do it by the book" approach will lead to even more IT disasters in my view.

    IMO we have to get back to basics and the fundamentals of good programming. We need to focus on simple, clean OO design and small human scale incremental development (no big projects). We also need to involve our customers much more in what we do.

    I don't believe the JCP sees this goal as its primary concern. I believe the Agile community does.

    Paul.
  170. Agility and Dynamic Languages[ Go to top ]

    >His Steve,I initially said:
    IMO this is an indictment on the software industry, and Java/J2EE, .NET along with C++/CORBA in the past must all take their fair share of responsibility for this situation.
    Your response was that java isn't to blame. Java as a language isn't good or bad what matters is the use, so in this regard I have to agree. My point is that in the realm of so called "enterprise development" Java/J2EE has had its fair share of carbuncles along with the other technologies I mentioned.So back to solutions. I don't see everyone using Java/J2EE as a solution. It really has got to start with the people. We both agree on the issue of education. I would also expand that to include how projects are envisioned and managed and the degree of developer access to end-users.I can see with the move to outsourcing to India even more project failures. They will be using technologies like J2EE and .NET and following the book (J2EE Core patterns). They will also be developing from paper specs and not talking to real users.This "do it by the book" approach will lead to even more IT disasters in my view.IMO we have to get back to basics and the fundamentals of good programming. We need to focus on simple, clean OO design and small human scale incremental development (no big projects). We also need to involve our customers much more in what we do. I don't believe the JCP sees this goal as its primary concern. I believe the Agile community does. Paul.

    You do seem to have a stereotyped view of development! There have been phenomenal J2EE successes as well as failures - I don't have statistics for the ratio? do you? To blame things like J2EE for Indian outsourceing is an extrapolation way beyond anything that is reasonable in my view. Is this just opinion, or do you have hard figures?

    I also thing you are, yet again, wildly simplifying. Are you objecting to J2EE as a whole (I suspect not), or just CMP? Do you think that J2EE messaging is part of the reason for outsourcing?

    My opinion is that not doing things 'by the book' will take us back to the horrors of everyone implementing their own solutions to common problems, groups of developers using non-standard solutions and then having to face the consequences of those solutions ceasing development.

    APIs like EJB 3.0 are a dramatic step forward in develop productivity and agility - and it is part of J2EE!

    Also, I would like to see the result of anyone walking into a major bank and corporation and saying 'stop developing large projects'.... the fact is, that some projects are large, and that is a plain fact.
    I don't believe the JCP sees this goal as its primary concern. I believe the Agile community does.

    Right - I am not going to let this stand. This is a serious claim, and I want you to back it up. Please provide evidence of this. Please name specific people or vendors involved on the JCP who have come out against 'good programming', or 'incremental development' or 'clean OO design'. Have you looked in detail at EJB/JPA for example? If you have, perhaps you could explain how it is contrary to these principles.

    Sorry to sound so harsh, but I have this thing against such broad statements :)
  171. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    Perhaps you are at work and very busy. Please read what I have said and re-consider your response. I haven't made any of the claims about J2EE you state.

    As regards "doing it by the book". Many of the J2EE Core Patterns intially devised by Sun have widely been denounced as anti-patterns. See Bitter EJB by Bruce Tate and J2EE without EJB by Rod Johnson - amongst others.

    This is the problem with premature standardisation for commercial reasons. It can lead to poor standards and poor standard approaches. In recent years through real world experience developers have found new patterns that work much better. These new patterns are now becoming the standard through EJB3.0.

    This IMO is the way standardisation should occur. Not create the standard by committee first, have a whole community use it for years then decide that the standard doesn't actually work that well.

    So has the JCP learned the lessons of EJB? Well they seem to be repeating the same mistake again with JSF. A paper spec with no proven implementations will become the industry wide standard. Vendors, developers and customers will invest millions developing implementations and learning the standard - yet this standard approach is unproven. No one has any real world experience with it. It is just a paper spec.

    This is ludicrous IMO. There is no other mature industry where this occurs. I worked in Telecoms for years and their standards are based on years of research and investigation, followed in many cases by working solutions that are proven in the real world and as such become candidates for universal standardisation.
     
    You missed the point I was making about India entirely. The Indians could choose to program in assembly and they would do it the same way - Waterfall. They will require a big requirement spec up front. Forcing customers to specify requirements in detail when they aren't even sure what they really need and what will actually add business value (how could they be?). They will not work with the customer iteratively, so no chance for real user feedback ("actually this isn't quite what we envisioned perhaps we should move the next iteration in a slightly different direction" etc). They will build the spec and they will use "the recommended approach" whether it is appropriate to their specific problem or not (often leading to over complex systems that are over engineered). This will forfil their contract and more often then not result in low value unmaintainable systems that do not adress the real business needs.

    As for the JCP. My view is based on their output over the last 7 or so years. Many on this same forum have aired opinions that tend to agree mine.

    Paul.
  172. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,Perhaps you are at work and very busy. Please read what I have said and re-consider your response. I haven't made any of the claims about J2EE you state.

    Ah - the good old 'if you disagree with me you can't have understood me' argument - back to that sort of level are we?
    As regards "doing it by the book". Many of the J2EE Core Patterns intially devised by Sun have widely been denounced as anti-patterns. See Bitter EJB by Bruce Tate and J2EE without EJB by Rod Johnson - amongst others.This is the problem with premature standardisation for commercial reasons.

    Look - just because some aspects of J2EE have been denounced by some people as antipatterns does not mean that the whole approach is entirely, or even mostly, wrong.

    Yet again you are wildly generalising based on a small sample
    Well they seem to be repeating the same mistake again with JSF. A paper spec with no proven implementations will become the industry wide standard. Vendors, developers and customers will invest millions developing implementations and learning the standard - yet this standard approach is unproven. No one has any real world experience with it. It is just a paper spec.

    Ah - so the views of experts like McClanahan who, in case you didn't realise HAS had years of experience producing highly successful APIs - don't count?

    If you read about JSF, you would realise it was based on existing (proven) technologies.
    This is ludicrous IMO. There is no other mature industry where this occurs.

    It is ludicrous, and it doesn't happen in Java.
    They will build the spec and they will use "the recommended approach" whether it is appropriate to their specific problem or not (often leading to over complex systems that are over engineered). This will forfil their contract and more often then not result in low value unmaintainable systems that do not adress the real business needs.

    So, by implication, using "not recommended approaches" can lead to high value maintainable systems? That sounds wild to me.
    As for the JCP. My view is based on their output over the last 7 or so years. Many on this same forum have aired opinions that tend to agree mine.Paul.

    Ok, then if your views are based on their output, give specific examples of their output, and name the guilty people. I don't care who agrees with you - I like to make my own mind up based on evidence (after all, many on this same forum have aired opinions that disagree with yours - why shouldn't I listen to them?). You accused the JCP as being against good programming, clean OO design, and incremental development. Unless you can back up that claim with actual examples (naming individuals, vendors and specific things they have said), I think you should take it back.

    I'll respond if you finally come up with specifics, otherwise this is just a vague personal opinion piece, and not something I find useful, Sorry.
  173. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,
    If you focused more on the argument that I'm trying to make rather than just trying to pick holes (too general, too specific, too general etc). Then you would see that there is a consistent coherent argument. You may disagree, but that doesn't invalidate my view.
    You accused the JCP as being against good programming, clean OO design, and incremental development.
    I said no such thing.
     
    Unless you can back up that claim with actual examples (naming individuals, vendors and specific things they have said), I think you should take it back.I'll respond if you finally come up with specifics, otherwise this is just a vague personal opinion piece, and not something I find useful, Sorry.
    You are right. It is just a personal opinion piece. Give up on me :^)

    Paul.
  174. Agility and Dynamic Languages[ Go to top ]

    You accused the JCP as being against good programming, clean OO design, and incremental development.
    I said no such thing.

    Yes, you did. Let me quote:
    IMO we have to get back to basics and the fundamentals of good programming. We need to focus on simple, clean OO design and small human scale incremental development (no big projects). We also need to involve our customers much more in what we do.

    I don't believe the JCP sees this goal as its primary concern. I believe the Agile community does.

    Maybe it is just me, but not having something as its primary concern suggests being at least somewhat against that thing...
    Unless you can back up that claim with actual examples (naming individuals, vendors and specific things they have said), I think you should take it back.I'll respond if you finally come up with specifics, otherwise this is just a vague personal opinion piece, and not something I find useful, Sorry.
    You are right. It is just a personal opinion piece. Give up on me :^)Paul.

    OK - I'll let you off for now!!!!
  175. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    You would have been better off asking me to clarify what I meant.
    You accused the JCP as being against good programming, clean OO design, and incremental development.
    I said no such thing.
    Yes, you did. Let me quote:
    IMO we have to get back to basics and the fundamentals of good programming. We need to focus on simple, clean OO design and small human scale incremental development (no big projects). We also need to involve our customers much more in what we do.I don't believe the JCP sees this goal as its primary concern. I believe the Agile community does.
    Maybe it is just me, but not having something as its primary concern suggests being at least somewhat against that thing...

    A lot of assumptions built up in software development IMO and in the opinion of many in the Agile community have been proven false. From what I can see the JCP seems to assume that high abstraction tools that do the programming for you are the best root to success.

    if you look at the most successful J2EE standards they have been rather constrained in their ambitions. Examples that come to mind are the Servlet API, JDBC and JMS as I have mentioned before. The Servlet API is a thin rapper around CGI, incorporating many of the web development techniques like URL encoding that had been tried and tested with Perl and CGI over years. Likewise JDBC stuck pretty close to the tried and tested ODBC API. JMS is merely a common interface to MOM systems that have been around for ages.

    Where J2EE standards have got into trouble is when they have attempted to be ambitious and cut new ground. I think this applies to all EJB's (with the acception of MDB), but the worst example IMO is Entity EJB's CMR (how did this ever see the light of day?).

    So these big heavyweight swiss army knife containers are meant to help, but time has proven in a lot of situations a lot simpler solution will do (have you ever tried to get classloaders to work across differing EARS inside your App. Server? I worked on a project that stalled for weeks because of this). I don't see the JCP comming up with simple solutions. For example, with JSF they appear to have gone down the complex tool root, similiar to the original EJB phylosophy.

    In contrast I see simpler, cleaner solutions comming from the OSS community. Seaside is one such example (although not Java). I like WebWork simply because it is more OO than struts and you can access real objects from your views.

    Paul.
  176. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,You would have been better off asking me to clarify what I meant.

    You had the chance.

    A lot of assumptions built up in software development IMO and in the opinion of many in the Agile community have been proven false. From what I can see the JCP seems to assume that high abstraction tools that do the programming for you are the best root to success.

    Another mass generalisation. Right - list which of the hundreds of JSRs assume this, please. Or perhaps, don't bother (as I say, I don't have time to follow this anymore!), although others may be interested to see you try and justify this.
    if you look at the most successful J2EE standards they have been rather constrained in their ambitions. Examples that come to mind are the Servlet API, JDBC and JMS as I have mentioned before. The Servlet API is a thin rapper around CGI, incorporating many of the web development techniques like URL encoding that had been tried and tested with Perl and CGI over years.

    Apart from 'minor' matters like security, performance, the ability to preserve data in memory in application and session scope.
    I think this applies to all EJB's (with the acception of MDB), but the worst example IMO is Entity EJB's CMR (how did this ever see the light of day?).So these big heavyweight swiss army knife containers are meant to help, but time has proven in a lot of situations a lot simpler solution will do (have you ever tried to get classloaders to work across differing EARS inside your App. Server? I worked on a project that stalled for weeks because of this).

    OK, fair enough. This is a reasonable issue.
    I don't see the JCP comming up with simple solutions.

    EJB 3.0 is simple. JDO is simple.
    For example, with JSF they appear to have gone down the complex tool root, similiar to the original EJB phylosophy.

    Not this tired old chestnut again.
    In contrast I see simpler, cleaner solutions comming from the OSS community. Seaside is one such example (although not Java). I like WebWork simply because it is more OO than struts and you can access real objects from your views.Paul.

    Er - you can do exactly that from JSF. So much for 'complex tool'!

    And, Seaside is great, but just isn't practical for high volume websites because of the memory requirements. Even Smalltalk developers admit this. So in those cases, it is neither clean or simple.

    Sorry, but I am having to give up on this - it is taking too much time.

    Can I suggest that you take a really close look at JSF, JDO and EJB 3.0, assuming you already haven't? You will find clear, simple, easy OOP techniques in use, which counter (in my view) your arguments.

    Have fun!
  177. Agility and Dynamic Languages[ Go to top ]

    .Can I suggest that you take a really close look at JSF, JDO and EJB 3.0, assuming you already haven't? You will find clear, simple, easy OOP techniques in use, which counter (in my view) your arguments.Have fun!
    Hi Steve,

    I have recently taken another look at JSF (in response to your support for it), and I must admit it isn't as bad as I first thought. I do need to look into it further, but it still seems over complex in some areas (the view templating for instance). I will suspend judgement and investigate further. BTW as far as "component' based (session) web frameworks goes, a close colleague as told me that Wicket very promising and passes the simple test in his opinion. So I'll look at that too.

    I once looked at JDO years ago (before I saw hibernate), and I remember thinking this was a much better approach than Entity Beans. I'm curious to know the history of JDO, because like you say it could be an example of the JCP delivering innovative and simple standard solutions.

    As for EJB's, I just think that the whole concept is flawed. Why should all your business logic be inside distributable objects? I need to look at the latest work on EJB3.0, but the last time I looked they were using annotations to hide all the ugly EJB2.1 deployment descriptors and remote/local interfaces etc.

    A component need only be an object (or should I say POJO since that is the fashionable term for it these days). The assumption of distribution is flawed, and if you are wise you will avoid distributing objects 99% of the time.

    So the real issue for App Servers and EJB's IMO is late binding, not distribution. How do you assemble components written and compiled at different times. In a static language like Java you need a load of meta info that just isn't available in the object byte code, hence the need for EJB descriptors. You also need a late binding dynamic environment where you can assemble your components. Hence the need for an App Server with containers, JNDI, Naming Service, EAR's multiple classloaders etc.

    In a dynamic language all your objects are automatically components. You get late binding within the language for free (no descriptors) and your App. Server becomes redundant (consumed by the language). This is the main reason why I think dynamic languages will one day dominate enterprise development. Simply because they provide a very simple and compelling component model out of the box.

    I'm going to try and open my mind to JSF. Think about what I've said about EJB's and we'll catch up when you've got more time.

    Paul.
  178. Agility and Dynamic Languages[ Go to top ]

    As for EJB's, I just think that the whole concept is flawed. Why should all your business logic be inside distributable objects? I need to look at the latest work on EJB3.0, but the last time I looked they were using annotations to hide all the ugly EJB2.1 deployment descriptors and remote/local interfaces etc.

    A component need only be an object (or should I say POJO since that is the fashionable term for it these days). The assumption of distribution is flawed, and if you are wise you will avoid distributing objects 99% of the time.

    It's rare to find applications that use EJB for remoting. It is possible, and even handy (when Java-to-Java or even CORBA remoting of a business interface is needed), but most apps just use EJBs inside their local JVM.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  179. Agility and Dynamic Languages[ Go to top ]

    As for EJB's, I just think that the whole concept is flawed. Why should all your business logic be inside distributable objects? I need to look at the latest work on EJB3.0, but the last time I looked they were using annotations to hide all the ugly EJB2.1 deployment descriptors and remote/local interfaces etc.A component need only be an object (or should I say POJO since that is the fashionable term for it these days). The assumption of distribution is flawed, and if you are wise you will avoid distributing objects 99% of the time.
    It's rare to find applications that use EJB for remoting. It is possible, and even handy (when Java-to-Java or even CORBA remoting of a business interface is needed), but most apps just use EJBs inside their local JVM.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    Hi Cameron,

    Agreed. This is my point. The whole App. Server and EJB container infrastructure is built on the assumption of distribution, when 99% of the time that isn't what you want. All you want is loosely couple (optionally late bound) components. PicoContainer for example gives you a component model without all the other bagage in a very lightweight way.

    Why use JNDI to lookup objects running in the same VM?

    Paul.
  180. As for EJB's, I just think that the whole concept is flawed. Why should all your business logic be inside distributable objects? I need to look at the latest work on EJB3.0, but the last time I looked they were using annotations to hide all the ugly EJB2.1 deployment descriptors and remote/local interfaces etc.A component need only be an object (or should I say POJO since that is the fashionable term for it these days). The assumption of distribution is flawed, and if you are wise you will avoid distributing objects 99% of the time.
    It's rare to find applications that use EJB for remoting. It is possible, and even handy (when Java-to-Java or even CORBA remoting of a business interface is needed), but most apps just use EJBs inside their local JVM.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    Hi Cameron,Agreed. This is my point. The whole App. Server and EJB container infrastructure is built on the assumption of distribution, when 99% of the time that isn't what you want. All you want is loosely couple (optionally late bound) components. PicoContainer for example gives you a component model without all the other bagage in a very lightweight way.Why use JNDI to lookup objects running in the same VM?Paul.

    I really think AOP is the savior there. Instead of having a full-fledged robust component that support XA transactions, security, pooling, remote access, AOP can let you pick whatever you need and you don't have to understand what you actually don't need.

    In my opinion, the J2EE problem has always come from the fact that robustness implied complexity (especially with EJB 2). For instance, you couldn't have an EJB component wich was just caring about remote access. No, you had to understand security, transactions, ...

    Well, enter the AOP world: you still have this great robustness wich has always caracterized J2EE, you are still sure your application will be able to scale whatever happen but yet you don't have to pay the price of the things you don't use, the complexity isn't mandatory with AOP. Complexity suddently disappear :)

    AOP make this possible because it doesn't enforce you to polluate your code with several meaningful interfaces. With AOP, theorically you don't need a container anymore, just a microkernel wich can be bootstrapped in your own application (Spring AOP is a good example).

    JPA is a step in this direction. I just hope JME, JSE and JEE will disappear in the future for one true Java standard environment or they at least that they will only be different from the number of standard libraries they include.

    I think Spring has been a major proof of AOP efficiency. Just my two cents and sorry for my english! It is a long post afterall ;)
  181. As for EJB's, I just think that the whole concept is flawed. Why should all your business logic be inside distributable objects? I need to look at the latest work on EJB3.0, but the last time I looked they were using annotations to hide all the ugly EJB2.1 deployment descriptors and remote/local interfaces etc.A component need only be an object (or should I say POJO since that is the fashionable term for it these days). The assumption of distribution is flawed, and if you are wise you will avoid distributing objects 99% of the time.
    It's rare to find applications that use EJB for remoting. It is possible, and even handy (when Java-to-Java or even CORBA remoting of a business interface is needed), but most apps just use EJBs inside their local JVM.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    Hi Cameron,Agreed. This is my point. The whole App. Server and EJB container infrastructure is built on the assumption of distribution, when 99% of the time that isn't what you want. All you want is loosely couple (optionally late bound) components. PicoContainer for example gives you a component model without all the other bagage in a very lightweight way.Why use JNDI to lookup objects running in the same VM?Paul.
    I really think AOP is the savior there. Instead of having a full-fledged robust component that support XA transactions, security, pooling, remote access, AOP can let you pick whatever you need and you don't have to understand what you actually don't need.In my opinion, the J2EE problem has always come from the fact that robustness implied complexity (especially with EJB 2). For instance, you couldn't have an EJB component wich was just caring about remote access. No, you had to understand security, transactions, ... Well, enter the AOP world: you still have this great robustness wich has always caracterized J2EE, you are still sure your application will be able to scale whatever happen but yet you don't have to pay the price of the things you don't use, the complexity isn't mandatory with AOP. Complexity suddently disappear :) AOP make this possible because it doesn't enforce you to polluate your code with several meaningful interfaces. With AOP, theorically you don't need a container anymore, just a microkernel wich can be bootstrapped in your own application (Spring AOP is a good example).JPA is a step in this direction. I just hope JME, JSE and JEE will disappear in the future for one true Java standard environment or they at least that they will only be different from the number of standard libraries they include. I think Spring has been a major proof of AOP efficiency. Just my two cents and sorry for my english! It is a long post afterall ;)
    Hi Alexandre,
    I agree that AOP helps out. But my view is that bot IoC and AOP as used commonly with frameworks such as Spring are mostly solving problems we have created for ourselves. They offer a better solution than EJB's granted, but there is a bigger picture.

    The issue is as I outlined in my post:
    In a static language like Java you need a load of meta info that just isn't available in the object byte code, hence the need for EJB descriptors. You also need a late binding dynamic environment where you can assemble your components. Hence the need for an App Server with containers, JNDI, Naming Service, EAR's multiple classloaders etc.In a dynamic language all your objects are automatically components. You get late binding within the language for free (no descriptors) and your App. Server becomes redundant (consumed by the language). This is the main reason why I think dynamic languages will one day dominate enterprise development. Simply because they provide a very simple and compelling component model out of the box.


    We want loosely coupled components that we can bind together at deployment time (EJB). We also want to intercept message sends and add advice (AOP). You can do all of this in a dynamic language for free. For example to create a proxy in Smalltalk all you need do is subclass the nil class. Your proxy will recieve every message from a sender and can add what ever advice it likes before sending the message on to the target object.

    You can do all this just using plain old OO techniques. The reason why you can't do this in Java is because Java is static and as a consequence not fully OO (now I'll get a backlash from a load of ill-informed Java programmers, but what I'm saying is correct. Ask the team that invented Object Orientated programming, people like Dan Ingalls, Adele Goldberg and Alan Kay).

    OO is extremely powerful, but static hybrid OO implementations like Java have eliminated much of that original power that still exists in Smalltalk.

    Now some will argue that dynamic languages come with problems of their own. I would disagree with most of the point that are commonly made (the benefits of type safety etc), but even if they were true, can anything be as bad as what we've gone through with EJB's over the last 7 or so years? :^)

    Paul.
  182. Agility and Dynamic Languages[ Go to top ]

    Your proxy will recieve every message from a sender and can add what ever advice it likes before sending the message on to the target object.You can do all this just using plain old OO techniques. The reason why you can't do this in Java is because Java is static and as a consequence not fully OO (now I'll get a backlash from a load of ill-informed Java programmers, but what I'm saying is correct. Ask the team that invented Object Orientated programming, people like Dan Ingalls, Adele Goldberg and Alan Kay)

    You had better label me an ill-informed Java programmer :)

    What you are saying is incorrect - you do realise that the ability to create dynamic proxies in a language is not a necessary criterion for a language being OOP?

    OOP has also nothing whatsoever to do with whether a language is dynamic or static. In fact, the first true OOP language by modern standards was a static language - Simula, even though the term 'OOP' was first introduced by Smalltalk.

    Java, like many other static OOP languages, fulfills all the criteria of full OOP systems: encapsulation, inheritance and polymorphism.

    Of course, if you wish to insist that Java is not a full OOP language, you could always provide us with a direct quote from Kay, Goldberg or Ingalls saying it isn't, or perhaps you should edit the Wikipedia entries describing OOP and Java :)
  183. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,
    Use google and search for interviews by Alan Kay. Read a number of exisitng ACM OOPSLA papers. Lookup Squeak and the Squeak Swiki and you will see that the original team that invented OO programming are still in business and they have given a number of explanations of why C++ and Java are not fully OO. Read "Squeak Open Peronal Computing and Multimedia" by Mark Guzdail and you will see many quotes from the original team that invented OO programming.

    I'm tired and it's late so I'll won't lookup specific references myself. The fact that Wikipedia is inaccurate doesn't surprise me. Bjarne Stroustrup did a good job at propogating his own take on OO, namely "C with Classes".

    I'll leave you and anyone else who is genuinely interested to lookup the references themselves. I'll provide a detailed technical explanation tomorrow of why your require dynamic behaviour to be fully OO, but tonight I'm tired and I'd rather watch some TV.

    Regards,

    Paul.
  184. Why Java Isn't fully OO[ Go to top ]

    Hi Steve,

    Whilst watching TV. Your words were bugging me. So here we go a quote from the man himself:
    "Java is the most distressing thing to hit computing since MS-DOS." – Alan Kay

    It could be out of context, I got it from the thought for the day archive on the Squeak Wiki.

    In this interview Alan Kay explains the history fo Smalltalk, C++ and his view on the birth of Java.

    http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273

    In this interview he makes it quite clear that Simula was a preprocessor on top of Algol, a block procedural language much like C. He also points out that Strousop used the same idea in C++. Originally C++ (or C with Classes) was a preprocessor on top of C.

    Smalltalk is very different. OOP as defined by Alan Kay and his team (not Bjarne Strousup) is the sending of messages between objects. When a sender sends a message to a reciever, the sender is merely making a request. What the reciever does in response is determined by the recieving object not the sender.

    This is very different from a function call in C. In C the caller of the function decides the precise implementation that the function call will execute (the function call is in fact a hardwired pointer to a specific implementation).
     
    C with Classes takes this function idea and extends data abstraction by adding function pointers to C structures. The use of a VTable gives the reciever object some degree of latitude of the precise implementation of the function call but this is limited to subclasses of the class that the sender thinks he is referencing.

    Adele Goldberg calls this message sending concept the "Ask, don't touch" principle. This decoupling allows Smalltalk to truly implement the proper OO messaging. C++ and Java perform an indirect function call through the VTable. A function call is not a message send.

    This message sending facility in Smalltalk allows for duck typing, which means that any object that satisfies the message protocol being used by the sender can be sent messages. The sender does not need to know the class heirachy of the reciever at compile time.

    If you spend some time and think about it, you will realise that pure message sending is very powerful. You will also realise that it calls for dynamic behaviour. The omission of this facility in C++ and Java has lead to several powerful OO language feature ommisions such as closures and continuations.

    Dynamic behaviour itself allows for more flexibility over determining what is and what isn't an object. In dynamic languages classes are first class objects themselves and are instances of a special type of class called a Metaclass. To create instance objects you merely send the appropriate class object the message "new". To create a subclass of a class, you send the class the message "subclass".

    This ability opens up a whole world of object orientated programming that just isn't available in C++ and Java where classes are not first class objects.

    To me OOP is all about encapsulation (hiding) and message sending between senders and recievers. On top of this the concept of classes comes second. Some OO languages like Self have no classes at all just prototypical objects. Infact one of the inherent weaknesses of OOP is the mis-use of inheritance and subclassing.

    IMO Stroustrup changed the focus of OOP from message sending between objects to the use of classes and polymorphism. Not surprising since his preprocessor on top of C does not support true message sending. In pure OO languages classes are not special they are just another kind (class) of object (akin to the a factory object as used in C++ and Java) and they aren't even needed. The real power of OO comes from message sending between objects and the hiding of state and chosen behaviour inside the reciever object, thus removing any dependency between the sender and receiver other than the actual message sent.

    Paul.
  185. Of course Java is fully OO[ Go to top ]

    Hi Steve,Whilst watching TV. Your words were bugging me. So here we go a quote from the man himself:
    "Java is the most distressing thing to hit computing since MS-DOS." – Alan Kay
    It could be out of context, I got it from the thought for the day archive on the Squeak Wiki.In this interview Alan Kay explains the history fo Smalltalk, C++ and his view on the birth of Java.

    Just because some of the architects of Smalltalk don't like Java, does not make it OOP.
    In this interview he makes it quite clear that Simula was a preprocessor on top of Algol, a block procedural language much like C.

    True but irrelevant.
    He also points out that Strousop used the same idea in C++. Originally C++ (or C with Classes) was a preprocessor on top of C.Smalltalk is very different.

    True but irrelevant.

    OOP as defined by Alan Kay and his team (not Bjarne Strousup) is the sending of messages between objects. When a sender sends a message to a reciever, the sender is merely making a request.

    True but irrelevant.
    What the reciever does in response is determined by the recieving object not the sender. This is very different from a function call in C.

    True but irrelevant.
    In C the caller of the function decides the precise implementation that the function call will execute (the function call is in fact a hardwired pointer to a specific implementation).&nbsp;C with Classes takes this function idea and extends data abstraction by adding function pointers to C structures. The use of a VTable gives the reciever object some degree of latitude of the precise implementation of the function call but this is limited to subclasses of the class that the sender thinks he is referencing.Adele Goldberg calls this message sending concept the "Ask, don't touch" principle.

    True but irrelevant.
    This decoupling allows Smalltalk to truly implement the proper OO messaging.

    False. This allows Smalltalk to implement duck typing.

    C++ and Java perform an indirect function call through the VTable. A function call is not a message send.

    Nonsense. It is simply a matter of interpretation.
    This message sending facility in Smalltalk allows for duck typing, which means that any object that satisfies the message protocol being used by the sender can be sent messages.

    True but irrelevant.
    The sender does not need to know the class heirachy of the reciever at compile time.If you spend some time and think about it, you will realise that pure message sending is very powerful.

    True but irrelevant.

    You will also realise that it calls for dynamic behaviour.

    True but irrelevant.
    The omission of this facility in C++ and Java has lead to several powerful OO language feature ommisions such as closures and continuations.

    True but irrelevant.
    Dynamic behaviour itself allows for more flexibility over determining what is and what isn't an object. In dynamic languages classes are first class objects themselves and are instances of a special type of class called a Metaclass. To create instance objects you merely send the appropriate class object the message "new". To create a subclass of a class, you send the class the message "subclass".This ability opens up a whole world of object orientated programming that just isn't available in C++ and Java where classes are not first class objects.

    True but irrelevant.
    To me OOP is all about encapsulation (hiding) and message sending between senders and recievers. On top of this the concept of classes comes second. Some OO languages like Self have no classes at all just prototypical objects. Infact one of the inherent weaknesses of OOP is the mis-use of inheritance and subclassing.

    True. Java, C++, Delphi, C#, VB.NET etc. all have encapsulation, of course.
    IMO Stroustrup changed the focus of OOP from message sending between objects to the use of classes and polymorphism.

    IMO this is flat wrong. Smalltalk made full use of classes and polymorphism.
    Not surprising since his preprocessor on top of C does not support true message sending. In pure OO languages classes are not special they are just another kind (class) of object

    True but irrelevant.
    The real power of OO comes from message sending between objects and the hiding of state and chosen behaviour inside the reciever object, thus removing any dependency between the sender and receiver other than the actual message sent.Paul.

    True, which is why this is available in Java. (Hiding behaviour does not mean hiding the class hierarchy).

    Sorry, but you can't just use words as you want to.

    I have been following the history of OOP languages with great interest since the mid 1980s, and have read much of the writings of Kay and Goldberg. Not once have I seen them state 'Java is not OOP', or even 'C++ is not OOP'.

    You can't redefine OOP as requiring duck typing, or simply use it in a way that makes more sense to you.

    I'll respond if you can come up with direct quotes from say, Kay or Golberg stating that Java is not an OOP language :)
  186. Of course Java is fully OO[ Go to top ]

    Hi Steve,

    I'm not going to get stuck in a pointless debate over the precise meaning of a term that even wikipedia says different people interpret to mean different things. The wikipeida definition of OOP that you mentioned states quite clearly that static language people vs dynamic language people tend to disagree on precisely what language features are required for OOP.

    The fact that a language can be can be completely OO without classes to me kills the static language perspective on OO (but that just me). Perhaps you haven't heard of the fragile base class problem.

    Anyway. Back to the real issue, writing software and component model solutions. I note that you haven't disagreed with my main asertion in my original post on EJB. Appservers, JNDI Naming Services, containers, multiple classloaders etc are an attempt to bring late binding of objects to the static world of Java.

    Incidently one of the points made by the team that invented OOP is that a key principle of OOP is making decisions at the latest possible point. This is much bigger than polymorphism, it is late binding.

    You have not responded to my assertion either that IoC and AOP can all be achieved in a dynamic OOP language without the need for special containers or AspectJ post compilation byte code manipulation or the need for a "special" language feature like the Java Dynamic Proxy API.

    As I said before I'm not going to attempt to prove my arguments to you. I have given a detailed technical explanation which IMO stands on its own merits without needing direct quotes from people that are too polite to "slag offf" other peoples work directly.

    Please respond to the substance of my arguments as they apply to EJB and OOP. I will assume that your lack of response in this regard is a tacit agreement with the points I've made.

    Paul.
  187. Of course Java is fully OO[ Go to top ]

    Hi Steve,

    A long with the long list of "Yes, but not relevant" responses to my arguments. I noticed one response where you actually offered a counter technical opinion:
    This decoupling allows Smalltalk to truly implement the proper OO messaging.
    False. This allows Smalltalk to implement duck typing.
    about servers

    So you beleive that a virtual function call is the same as messaging. OK lets look at other messaging examples, JMS for example. When you post a message on a JMS queue what do you know about the reciever? Nothing. This is the main reason why messaging systems are more flexible and less brittle than remote object systems. Clients need to know nothing about servers when you send messages.

    As a consequence it is true that Smalltalk relies on duck typing, but that is not the goal of OO messaging. The goal of full messaging is the removal of coupling, a program design technique as old as the hills.

    Incidently this is why advance OO languages removed classes and replaced them with prototypes. This reduces coupling even further. Sun knew this when they invented Java. The Self language was produced at Sun Research.

    Sun made a pragmatic decision not to include many advance OO features in Java for practical (and IMO commercial) reasons.

    If you want to try again with another technical retort to what I've said, i'll happily respond to that too :^).

    Paul.
  188. Of course Java is fully OO[ Go to top ]

    Hi Steve,A long with the long list of "Yes, but not relevant" responses to my arguments.

    Because they were not relevant to the issue of whether or not a language could be defined as OOP.
    I noticed one response where you actually offered a counter technical opinion:
    This decoupling allows Smalltalk to truly implement the proper OO messaging.
    False. This allows Smalltalk to implement duck typing.
    So you beleive that a virtual function call is the same as messaging.

    No, I believe that a virtual function call can be interpreted as if it was a message send.
    OK lets look at other messaging examples, JMS for example.

    Well, OK, but this has nothing whatsoever to do with OOP.
    Clients need to know nothing about servers when you send messages.

    And neither has this.
    Incidently this is why advance OO languages removed classes and replaced them with prototypes. This reduces coupling even further. Sun knew this when they invented Java. The Self language was produced at Sun Research. Sun made a pragmatic decision not to include many advance OO features in Java for practical (and IMO commercial) reasons.

    Not having advanced OO features does not make a language not fully OOP.

    As I understood it, Sun left out 'advanced OOP' features from Java for practical reasons - experience of the mess that many developers had made of using such features in the previous decade. It was very wise in my view (having made such messes myself).
    If you want to try again with another technical retort to what I've said, i'll happily respond to that too :^).Paul.

    What you have said is technically correct, but has not relevance to the issue of whether or not Java is a true OOP language.

    All I am after is some facts to back up your assertion, not a distraction consisting of a discussion of 'messaging', duck typing, or the personal language preferences of Alan Kay.

    So, what I ask from you (and here is the technical question!) is either proof that, in Java, you can't do inheritance, you can't use polymorphism and you can't encapsulate data and behaviour in classes. Either that or a statement that you accept that Java is a true OOP language by internationally accepted definitions, even though it may not be according how you personally wish that OOP were defined.
  189. Of course Java is fully OO[ Go to top ]

    Hi Steve,

    As I said dynamic people and static people tend to disagree over the definition of OOP. Your reference to wikipedia (which I took the time to read) says the same.

    I agree with the view of the dynamic camp on what si required for OOP.

    Taking this disucssion any further is pointless IMO since as you've said many times the static versus dynamic debate has been raging for years.

    Incidently prototype OOP is an attempt to fix a core weakness in class based OOP, namely the fragile base class problem (when you make a change in a base class you can break the subclasses). It gets rid of classes all together and just use objects. Each object has its on method dictionary and will respond to its own set of messages. Should you want to create a new instance all you need to do is ask the prorotype to copy itself and then intialise the new copy:

    <code>
    b = a.copy();
    b.initialise();
    </code>

    If you want to change the behaviour of b (equivalent to inheritance and subclassing that you seem to think is a prerequisite for OOP) what you can do is:

    <code>
    message = isTrue;
    method = [ return true];
    b.addMethod(message, method);

    b.isTrue();
    </code>

    No classes, no polymorphism, no inheritance in sight. So are you sayig that this is not OOP?

    Let's drop this and talk about EJB's and the possible benefits of dynamic languages when it comes to a component model. IMO it is a much more fruitful discussion :^).

    Paul.
  190. Of course Java is fully OO[ Go to top ]

    Hi Steve,As I said dynamic people and static people tend to disagree over the definition of OOP. Your reference to wikipedia (which I took the time to read) says the same.

    No, it doesn't. It says "Object-oriented programming (OOP) emphasizes the following concepts:".. Class, Object, Encapsulation, Inheritance, Abstraction and Polymorphism. Nowhere does it state that there are substantial differences over the definition of OOP between supporters of static and dynamic languages.

    The entry on object-oriented programming refers to Java as an OOP language four times

    You were wrong. Java is a full OO language.
    Taking this disucssion any further is pointless IMO since as you've said many times the static versus dynamic debate has been raging for years.

    That is nothing to do with whether or not languages are OOP - it is to do with the nature of dynamic vs static typing, which is a completely orthogonal matter. I am sure LISP and Algol60 developers were debating this issue before OOP was truly invented.
    Incidently prototype OOP is an attempt to fix a core weakness in class based OOP, namely the fragile base class problem (when you make a change in a base class you can break the subclasses). It gets rid of classes all together and just use objects. Each object has its on method dictionary and will respond to its own set of messages. Should you want to create a new instance all you need to do is ask the prorotype to copy itself and then intialise the new copy:<code>b = a.copy();b.initialise();</code>If you want to change the behaviour of b (equivalent to inheritance and subclassing that you seem to think is a prerequisite for OOP) what you can do is:<code>message = isTrue;method = [ return true];b.addMethod(message, method);b.isTrue();</code>No classes, no polymorphism, no inheritance in sight. So are you sayig that this is not OOP?

    Yes, I would certainly say it isn't OOP. There are established faults with OOP, like any technique, but one can't simply take away some of the fundamental features and still call it OOP. It fails the test of the Wikipedia definition.
  191. Of course Java is fully OO[ Go to top ]

    Hi Steve,As I said dynamic people and static people tend to disagree over the definition of OOP. Your reference to wikipedia (which I took the time to read) says the same.
    No, it doesn't... Nowhere does it state that there are substantial differences over the definition of OOP between supporters of static and dynamic languages.
    I do not agree that Wikipedia is the definitive reference. But for the record this is what it says:

    OP itself has been used to market many products and services and the actual definitions and benefits attributed to OOP have often been colored by commercial marketing goals. Similarly, many programming languages have a specific view to OOP that is less general in certain aspects from the more general definition.
    Widely-used terminology distinguishes object-oriented programming from object-based. The former is held to include inheritance (described below), while the latter does not.
    The exact definitions of these have some variation depending on point of view. In particular, languages with static typing often have slightly different views of OO than languages with dynamic typing, caused by focus on compile-time vs. run-time properties of the programs.
    Incidently prototype OOP is an attempt to fix a core weakness in class based OOP, namely the fragile base class problem (when you make a change in a base class you can break the subclasses). It gets rid of classes all together and just use objects. Each object has its on method dictionary and will respond to its own set of messages. Should you want to create a new instance all you need to do is ask the prorotype to copy itself and then intialise the new copy:<code>b = a.copy();b.initialise();</code>If you want to change the behaviour of b (equivalent to inheritance and subclassing that you seem to think is a prerequisite for OOP) what you can do is:<code>message = isTrue;method = [ return true];b.addMethod(message, method);b.isTrue();</code>No classes, no polymorphism, no inheritance in sight. So are you sayig that this is not OOP?
    Yes, I would certainly say it isn't OOP. Ok this is what your source, wikipedia has to say about prototype OOP:
    Prototype-based model -
    Other than using classes, prototyping is another, less popular, means of achieving object-oriented behavior sharing. After an object is defined, another similar object will be defined by referring to the original one as a template, then listing the new object's differences from the original. Perhaps the most popular prototype-based language is JavaScript, which is an implementation of ECMAScript; Self, a programming language developed by Sun Microsystems

    It does not say that prototype based behaviour sharing is not OOP.

    All these quotes where taken from wikipedia under the title "Object-orientated Programming". IMO OOP is a much confused subject. Influences from various areas have impinged on the central idea of objects and message sending.

    Let's move on from who is right or wrong when it comes to an imprecise definition of a confused term. I just tend to take the view of the inventors of the concept. Let's move on to the practical implications of dynamic behaviour and how it relates to the design goals of EJB. After all this was my main point.

    Paul.
  192. Of course Java is fully OO[ Go to top ]

    ormatting problems again...
    Hi Steve,As I said dynamic people and static people tend to disagree over the definition of OOP. Your reference to wikipedia (which I took the time to read) says the same.
    No, it doesn't... Nowhere does it state that there are substantial differences over the definition of OOP between supporters of static and dynamic languages.

    I do not agree that Wikipedia is the definitive reference. But for the record this is what it says:
    OOP itself has been used to market many products and services and the actual definitions and benefits attributed to OOP have often been colored by commercial marketing goals. Similarly, many programming languages have a specific view to OOP that is less general in certain aspects from the more general definition. Widely-used terminology distinguishes object-oriented programming from object-based. The former is held to include inheritance (described below), while the latter does not.The exact definitions of these have some variation depending on point of view. In particular, languages with static typing often have slightly different views of OO than languages with dynamic typing, caused by focus on compile-time vs. run-time properties of the programs.

    I mentioned prototype OOP. Which IMO is the most advance OOP approach to date:
    Incidently prototype OOP is an attempt to fix a core weakness in class based OOP, namely the fragile base class problem (when you make a change in a base class you can break the subclasses). It gets rid of classes all together and just use objects. Each object has its on method dictionary and will respond to its own set of messages. Should you want to create a new instance all you need to do is ask the prorotype to copy itself and then intialise the new copy:<code>b = a.copy();b.initialise();</code>If you want to change the behaviour of b (equivalent to inheritance and subclassing that you seem to think is a prerequisite for OOP) what you can do is:<code>message = isTrue;method = [ return true];b.addMethod(message, method);b.isTrue();</code>No classes, no polymorphism, no inheritance in sight. So are you sayig that this is not OOP?
    Yes, I would certainly say it isn't OOP.

    Ok this is what your source, wikipedia has to say about prototype OOP:
    Prototype-based model -Other than using classes, prototyping is another, less popular, means of achieving object-oriented behavior sharing. After an object is defined, another similar object will be defined by referring to the original one as a template, then listing the new object's differences from the original. Perhaps the most popular prototype-based language is JavaScript, which is an implementation of ECMAScript; Self, a programming language developed by Sun Microsystems

    It does not say that prototype based behaviour sharing is not OOP.

    All these quotes where taken from wikipedia under the title "Object-orientated Programming".

    IMO OOP is a much confused subject. Influences from various areas have impinged on the central idea of objects and message sending. Let's move on from who is right or wrong when it comes to an imprecise definition of a confused term. I just tend to take the view of the inventors of the concept (the views of the original Smalltalk team are widely published if you take the time to look them up).

     Let's move on to the practical implications of dynamic behaviour and how it relates to the design goals of EJB. After all this was my main point.

    Paul.
  193. Of course Java is fully OO[ Go to top ]

    I do not agree that Wikipedia is the definitive reference.But for the record this is what it says:
    OOP itself has been used to market many products and services and the actual definitions and benefits attributed to OOP have often been colored by commercial marketing goals. Similarly, many programming languages have a specific view to OOP that is less general in certain aspects from the more general definition. Widely-used terminology distinguishes object-oriented programming from object-based. The former is held to include inheritance (described below), while the latter does not.The exact definitions of these have some variation depending on point of view. In particular, languages with static typing often have slightly different views of OO than languages with dynamic typing, caused by focus on compile-time vs. run-time properties of the programs.

    Exactly. As I said, "Nowhere does it state that there are substantial differences over the definition of OOP between supporters of static and dynamic languages."

    I choose my words carefully.
    It does not say that prototype based behaviour sharing is not OOP.All these quotes where taken from wikipedia under the title "Object-orientated Programming".

    IMO OOP is a much confused subject. Influences from various areas have impinged on the central idea of objects and message sending. Let's move on from who is right or wrong when it comes to an imprecise definition of a confused term.

    Sorry, but I think this sort of thing matters. FUD is an insidious thing, and Java is one of the languages most subject to it. My view is that, whatever its faults, Java (and languages like it) have an important long-term job to do in the IT industry. To to that, its strengths need to be recognised in addition to its faults. Part of the strength of Java is that it is indeed a true full OOP language in ways that languages it has competed with (such as pre-.NET versions of VB) aren't. Which is why I think that trying to distort the meaning of 'full OOP' in ways which exclude Java is FUD (unintentional, perhaps, but still FUD). It is misinformation. And, when this misinformation turns up on a high-traffic well-known international forum that may have some influence on developers, I think it needs to be corrected.
    I just tend to take the view of the inventors of the concept (the views of the original Smalltalk team are widely published if you take the time to look them up).

    So do I. I have looked up their views, and have read definitive articles (my favourite being the original Byte article on Smalltalk). Nowhere that I know of has any of these authors declared that C++ is not an OOP language, or that Java is not an OOP language.

    For the final time - if you take their views, and their views are that Java is not an OOP language, then provide evidence of that.
    Let's move on to the practical implications of dynamic behaviour and how it relates to the design goals of EJB. After all this was my main point.Paul.

    You see, I think there is a problem: if you refuse to accept common terms in the way that they are accepted by almost everyone else, what is the point? I am not trying to be petty here - how can we possibly debate if we are allowed to re-define common terms?
  194. Of course Java is fully OO[ Go to top ]

    OK Java is an OOP language. Can we move on now?

    Paul.
  195. As for EJB's, I just think that the whole concept is flawed. Why should all your business logic be inside distributable objects? I need to look at the latest work on EJB3.0, but the last time I looked they were using annotations to hide all the ugly EJB2.1 deployment descriptors and remote/local interfaces etc.A component need only be an object (or should I say POJO since that is the fashionable term for it these days). The assumption of distribution is flawed, and if you are wise you will avoid distributing objects 99% of the time.
    It's rare to find applications that use EJB for remoting. It is possible, and even handy (when Java-to-Java or even CORBA remoting of a business interface is needed), but most apps just use EJBs inside their local JVM.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    Hi Cameron,Agreed. This is my point. The whole App. Server and EJB container infrastructure is built on the assumption of distribution, when 99% of the time that isn't what you want. All you want is loosely couple (optionally late bound) components. PicoContainer for example gives you a component model without all the other bagage in a very lightweight way.Why use JNDI to lookup objects running in the same VM?Paul.
    I really think AOP is the savior there. Instead of having a full-fledged robust component that support XA transactions, security, pooling, remote access, AOP can let you pick whatever you need and you don't have to understand what you actually don't need.In my opinion, the J2EE problem has always come from the fact that robustness implied complexity (especially with EJB 2). For instance, you couldn't have an EJB component wich was just caring about remote access. No, you had to understand security, transactions, ... Well, enter the AOP world: you still have this great robustness wich has always caracterized J2EE, you are still sure your application will be able to scale whatever happen but yet you don't have to pay the price of the things you don't use, the complexity isn't mandatory with AOP. Complexity suddently disappear :) AOP make this possible because it doesn't enforce you to polluate your code with several meaningful interfaces. With AOP, theorically you don't need a container anymore, just a microkernel wich can be bootstrapped in your own application (Spring AOP is a good example).JPA is a step in this direction. I just hope JME, JSE and JEE will disappear in the future for one true Java standard environment or they at least that they will only be different from the number of standard libraries they include. I think Spring has been a major proof of AOP efficiency. Just my two cents and sorry for my english! It is a long post afterall ;)
    Hi Alexandre,I agree that AOP helps out. But my view is that bot IoC and AOP as used commonly with frameworks such as Spring are mostly solving problems we have created for ourselves. They offer a better solution than EJB's granted, but there is a bigger picture.The issue is as I outlined in my post:
    In a static language like Java you need a load of meta info that just isn't available in the object byte code, hence the need for EJB descriptors. You also need a late binding dynamic environment where you can assemble your components. Hence the need for an App Server with containers, JNDI, Naming Service, EAR's multiple classloaders etc.In a dynamic language all your objects are automatically components. You get late binding within the language for free (no descriptors) and your App. Server becomes redundant (consumed by the language). This is the main reason why I think dynamic languages will one day dominate enterprise development. Simply because they provide a very simple and compelling component model out of the box.
    We want loosely coupled components that we can bind together at deployment time (EJB). We also want to intercept message sends and add advice (AOP). You can do all of this in a dynamic language for free. For example to create a proxy in Smalltalk all you need do is subclass the nil class. Your proxy will recieve every message from a sender and can add what ever advice it likes before sending the message on to the target object.You can do all this just using plain old OO techniques. The reason why you can't do this in Java is because Java is static and as a consequence not fully OO (now I'll get a backlash from a load of ill-informed Java programmers, but what I'm saying is correct.

    I totally disagree. Type safety is useful to desccribe your business concerns but not in other places. Most of the times if type safety is encumbering, it is because you are trying to handle a cross-cutting concern best handled by AOP or maybe you are trying to use some functional programming notions wich can be handled quite beautifuly by anonymous classes.

    Type safety is very cool because it allows you to get a grasp over a program abstractions quite quickly something Smalltalk has always had problems to deal with. You just have to be careful to use meaningful business interfaces and adress the other concerns using AOP or anonymous classes. You should not use special interfaces as Hibernate and Spring have proved. Suddently type safety issues disappear.

    And like I said before it is hard for a human to think in term of Metaclasses, it is just not natural. Your brain doesn't picture reality this way whereas Classes and Objects feel very natural.
  196. Hi Alexandre,

    I agree that AOP has it's use independent of OOP and is a powerful concept in itself. I was pointing out that much of what you get with AOP can be performed using dynamic OOP, reducing the need for true AOP.
    Type safety is very cool because it allows you to get a grasp over a program abstractions quite quickly something Smalltalk has always had problems to deal with.
    I don't understand you here. I find the Smalltalk class browser quite powerful in understanding my program abstractions. if you look at the latest release of Dolphin Smalltalk, they have incorporated a graphical class browser that allows you to browse your clas hierachy as a graphical graph, very useable. Please explain what you mean.
    And like I said before it is hard for a human to think in term of Metaclasses, it is just not natural. Your brain doesn't picture reality this way whereas Classes and Objects feel very natural.

    I agree that Metaclass thinking is counter-intuitive, but you can do a lot with classes as first class objects without having to go deep into the realms of Metaclasses.

    Also you can use a Prototype approach which I agree is much simpler and cleaner than using Metaclasses and classes. Prototypes and classes as first class objects both rely on dynamic behaviour.

    Paul.
  197. Hi Alexandre,I agree that AOP has it's use independent of OOP and is a powerful concept in itself. I was pointing out that much of what you get with AOP can be performed using dynamic OOP, reducing the need for true AOP.
    Type safety is very cool because it allows you to get a grasp over a program abstractions quite quickly something Smalltalk has always had problems to deal with.
    I don't understand you here. I find the Smalltalk class browser quite powerful in understanding my program abstractions. if you look at the latest release of Dolphin Smalltalk, they have incorporated a graphical class browser that allows you to browse your clas hierachy as a graphical graph, very useable. Please explain what you mean.

    Yeah, I guess I wasn't clear. By the way, I could be wrong because I haven't used SmallTalk in the last three years.
    Like you said, it is indeed quite simple to get a good graph but since the language is dynamic, the resulting graph is only a class hierarchy snapshot, ie the class hierarchy can change at any given time and become totally different. I found it was always really difficult to read other people programs because I was never sure of it structure. Note I haven't written a lot of SmallTalk except while I was still in university since I am only 23 so maybe you get used to it.

    In my opinion, the strongest point of using static typing in your business model is not the time compile-time safety it provides (it is just a nice secondary effect), it is a comprehension tool.
  198. Hi Alexandre,

    I get you. Being of the Eclipse generation I can see how you could find a typical Smalltalk-80 IDE, well a little primitive :^). I grew up on vi and Emacs so when I saw Smalltalk-80 for the first time it looked positively advanced.

    Mordern Smalltalks are trying to address this. Dolphin Smalltalk IMO approaches Eclipse on useablity (including auto-completion). You can down load a copy for free and check it out from their website:

    http://www.object-arts.com/content/navigation/home.html

    BTW. Tim Mackinnon has a plug-in for Dolphin Smalltalk that makes it even nore like Eclipse. Check out his website too:

    http://www.macta.f2s.com/Thoughts/dolphin.html

    Paul.
  199. Agility and Dynamic Languages[ Go to top ]

    Mordern Smalltalks are trying to address this. Dolphin Smalltalk IMO approaches Eclipse on useablity (including auto-completion). You can down load a copy for free and check it out from their website:

    I'd like to second that. Dolphin Smalltalk is superb. If only it was cross-platform.....
  200. Hi Alexandre,I get you. Being of the Eclipse generation I can see how you could find a typical Smalltalk-80 IDE, well a little primitive :^). I grew up on vi and Emacs so when I saw Smalltalk-80 for the first time it looked positively advanced.Mordern Smalltalks are trying to address this. Dolphin Smalltalk IMO approaches Eclipse on useablity (including auto-completion). You can down load a copy for free and check it out from their website:http://www.object-arts.com/content/navigation/home.htmlBTW. Tim Mackinnon has a plug-in for Dolphin Smalltalk that makes it even nore like Eclipse. Check out his website too:http://www.macta.f2s.com/Thoughts/dolphin.htmlPaul.

    But even with a good IDE, the class hierarchy can always change no? I think the problem comes from the language itself so tools can't really fix it.
  201. Hi Alexandre,I get you. Being of the Eclipse generation I can see how you could find a typical Smalltalk-80 IDE, well a little primitive :^). I grew up on vi and Emacs so when I saw Smalltalk-80 for the first time it looked positively advanced.Mordern Smalltalks are trying to address this. Dolphin Smalltalk IMO approaches Eclipse on useablity (including auto-completion). You can down load a copy for free and check it out from their website:http://www.object-arts.com/content/navigation/home.htmlBTW. Tim Mackinnon has a plug-in for Dolphin Smalltalk that makes it even nore like Eclipse. Check out his website too:http://www.macta.f2s.com/Thoughts/dolphin.htmlPaul.
    But even with a good IDE, the class hierarchy can always change no? I think the problem comes from the language itself so tools can't really fix it.
    Hi Alexandre,

    People don't write code that writes code everyday. Metaprogramming is an advance feature of the language, and should really be reserved for the use of framework builders IMO. Application developers should never really have to involve themselves with it. This is consistent with a general phylosophy of simplicity.

    I haven't written loads of production Smalltalk code either. But in my understanding of normal Smalltalk development use, the concern you mention shouldn't materialise.

    Languages like Smalltalk liberate the developer. With power comes responsibility. If developers use that power to do over-complex and silly things then it will lead to poor comprehension as you describe.

    Paul.
  202. Agility and Dynamic Languages[ Go to top ]

    I haven't written loads of production Smalltalk code either. But in my understanding of normal Smalltalk development use, the concern you mention shouldn't materialise.Languages like Smalltalk liberate the developer. With power comes responsibility. If developers use that power to do over-complex and silly things then it will lead to poor comprehension as you describe.Paul.

    This is part of my concern with dynamic languages. I have written substantial production code in Smalltalk in the late 80s and early 90s. My experience is that developers can do overly complex and silly things! I know that this is a cynical attitude, but my view is that dynamic languages are too simply powerful in terms of features for general development. I have seen much use of metaprogramming that has led to indecipherable code, especially when different groups of developers have used different techniques and then try and combine code.
  203. Agility and Dynamic Languages[ Go to top ]

    I haven't written loads of production Smalltalk code either. But in my understanding of normal Smalltalk development use, the concern you mention shouldn't materialise.Languages like Smalltalk liberate the developer. With power comes responsibility. If developers use that power to do over-complex and silly things then it will lead to poor comprehension as you describe.Paul.
    This is part of my concern with dynamic languages. I have written substantial production code in Smalltalk in the late 80s and early 90s. My experience is that developers can do overly complex and silly things! I know that this is a cynical attitude, but my view is that dynamic languages are too simply powerful in terms of features for general development. I have seen much use of metaprogramming that has led to indecipherable code, especially when different groups of developers have used different techniques and then try and combine code.

    Exactly my point, I am always afraid of the NIH syndrome. With Smalltalk, it so easy to create a DSL (Domain specific language) but the problem I have is that a language has to be standard and stable first to be useful. Like I said earlier, I prefer to stick to static typing with my core business objects, where it isn't cumbersome. I use AOP and functional programming to get ride of those pesky meaningless interfaces (Comparable, argh). I don't think it is a hack to mix some paradigm to handle each type of problems, using only a purist OOP approach sounds more like a hack to me.

    BTW, you also need some hacks in SmallTalk . For instance, it doesn't have any support for primitives data types so you get a really weird syntax just to perform a simple addition. Then if you want to emulate a primitive data type, you have to use the value object design pattern, something you don't have to do in Java unless you need a new primitive type. Any purist approaches has its shortcomings, Java combine a lot of approaches and that is why I like it :)
  204. I haven't written loads of production Smalltalk code either. But in my understanding of normal Smalltalk development use, the concern you mention shouldn't materialise.Languages like Smalltalk liberate the developer. With power comes responsibility. If developers use that power to do over-complex and silly things then it will lead to poor comprehension as you describe.Paul.
    This is part of my concern with dynamic languages. I have written substantial production code in Smalltalk in the late 80s and early 90s. My experience is that developers can do overly complex and silly things! I know that this is a cynical attitude, but my view is that dynamic languages are too simply powerful in terms of features for general development. I have seen much use of metaprogramming that has led to indecipherable code, especially when different groups of developers have used different techniques and then try and combine code.
    Exactly my point, I am always afraid of the NIH syndrome. With Smalltalk, it so easy to create a DSL (Domain specific language) but the problem I have is that a language has to be standard and stable first to be useful. Like I said earlier, I prefer to stick to static typing with my core business objects, where it isn't cumbersome. I use AOP and functional programming to get ride of those pesky meaningless interfaces (Comparable, argh). I don't think it is a hack to mix some paradigm to handle each type of problems, using only a purist OOP approach sounds more like a hack to me. BTW, you also need some hacks in SmallTalk . For instance, it doesn't have any support for primitives data types so you get a really weird syntax just to perform a simple addition. Then if you want to emulate a primitive data type, you have to use the value object design pattern, something you don't have to do in Java unless you need a new primitive type. Any purist approaches has its shortcomings, Java combine a lot of approaches and that is why I like it :)
    Oops instead of a simple addition, it should have been simple mathematical operation like 3 + 4 * 5 wich is evaluated like this (3 + 4) * 5 because mathematical operators are considered object messages and not primitives operators.
  205. Agility and Dynamic Languages[ Go to top ]

    I have seen much use of metaprogramming that has led to indecipherable code, especially when different groups of developers have used different techniques and then try and combine code.
    Exactly my point, I am always afraid of the NIH syndrome. With Smalltalk, it so easy to create a DSL (Domain specific language) but the problem I have is that a language has to be standard and stable first to be useful.</blockquotes>

    Yes! When I look at the way some dynamic languages are being used and promoted these days, I see exactly the NIH attitude you mention. For example, instead of making use of a well-established and well-designed technology like XML, which can be extended and re-used in safe ways that won't break existing applications, I often see approaches that consist of using yet another DSL.... which, of course, will sooner or later become legacy and unsupported which is exactly what XML was designed to avoid.
    For instance, it doesn't have any support for primitives data types so you get a really weird syntax just to perform a simple addition.

    Actually, I don't think it is that bad. It simply doesn't have the same operator priority (the are all the same). I don't think that having to use brackets counts as weird syntax.
  206. Agility and Dynamic Languages[ Go to top ]

    I have seen much use of metaprogramming that has led to indecipherable code, especially when different groups of developers have used different techniques and then try and combine code.
    Exactly my point, I am always afraid of the NIH syndrome. With Smalltalk, it so easy to create a DSL (Domain specific language) but the problem I have is that a language has to be standard and stable first to be useful.</blockquotes>Yes! When I look at the way some dynamic languages are being used and promoted these days, I see exactly the NIH attitude you mention. For example, instead of making use of a well-established and well-designed technology like XML, which can be extended and re-used in safe ways that won't break existing applications, I often see approaches that consist of using yet another DSL.... which, of course, will sooner or later become legacy and unsupported which is exactly what XML was designed to avoid.
    For instance, it doesn't have any support for primitives data types so you get a really weird syntax just to perform a simple addition.
    Actually, I don't think it is that bad. It simply doesn't have the same operator priority (the are all the same). I don't think that having to use brackets counts as weird syntax.

    Yeah well at first, I was thinking about something else because I had forgot about binary operators. But I still find it strange that two integers, although equals, don't have the same identity. A 5 is a 5! Remind me of the problems they faced when they were implementing autoboxing. Well it's another debate but the point is every language need some *hacks* ;)
  207. Hi Guys,

    I've read through your critique of Smalltalk and I feel that most of the points you make are valid. I tend to worry less about the possiblity of abuse since I feel that I have a development approach that can manage this (namely XP).

    But the risks you highlight are real and do need to be managed. The other side of the coin are the benefits:
    Let's move on to the practical implications of dynamic behaviour and how it relates to the design goals of EJB. After all this was my main point.

    I believe that many of the DSL/framework pitfalls that have dogged us over the las 10-15 years would have been largely eliminated if the industry had chosen to go down a dynamioc approach (I'm thinking of C++ frameworks like Commonpoint and OpenDoc and Java frameworks like EJB).

    The world is a dynamic place. Things change all the time, so I believe that a dynamic language is much better suited to modelling the real world in which we all live. We have tried to conponsate for language facilities using various "add-on" approaches but they have all failed.

    IMO the most powerful tool programmers have at their disposal is their programming language, and that language needs to have the flexibility to address the problem domains in which it will be applied.

    Engineering is alwayus about trade-offs. I feel we have explored the trade offs involved in the static model and found it wanting:
    Anyway. Back to the real issue, writing software and component model solutions. I note that you haven't disagreed with my main asertion in my original post on EJB. Appservers, JNDI Naming Services, containers, multiple classloaders etc are an attempt to bring late binding of objects to the static world of Java.

    I'm hoping that you guys will tend to agree with me that the design trade offs represented by a dynamic language like Smalltalk will in the long term prove more beneficial in adressing the types of problems us as enterprise developers now face.

    BTW. Work on language work benches (see Martin Folwers website) means that automated developer policing could be applied to dynamic languages too. Language work benches allow you to have the safety of external DSLs (e.g. XML) whilst still retaining the flexiblity of internal DSLs (as applied in languages like Smalltalk and LISP). Imaging a language based on Smalltalk that allowed you to project differing views of an abstract representation of the program (the Image) to a code browser/editor that limited developers to specific language features and specific DSLs. Advanced user could use a more open browser to create the DSL's in the first place. All this is possible today.

    Paul.
  208. Agility and Dynamic Languages[ Go to top ]

    I believe that many of the DSL/framework pitfalls that have dogged us over the las 10-15 years would have been largely eliminated if the industry had chosen to go down a dynamioc approach (I'm thinking of C++ frameworks like Commonpoint and OpenDoc and Java frameworks like EJB).

    And I think the exact reverse. The dynamic approach would have led to a proliferation of incompatible approaches. The huge variety of implementations of Smalltalk, with largely incompatible class libraries, is good evidence of this.
    The world is a dynamic place. Things change all the time, so I believe that a dynamic language is much better suited to modelling the real world in which we all live.

    Sorry, but I think this is of no relevance at all, unless you assume that the data model has to change in real time. Does the real world change so fast that a developer does not have time to refactor a Java class in an IDE and recompile?
    We have tried to conponsate for language facilities using various "add-on" approaches but they have all failed.

    All failed. Yet another unjustified broad generalisation. The huge success of Java as a productive language with lightweight approaches (Hibernate, Spring) etc. Is proof that this is wrong.
    Engineering is alwayus about trade-offs. I feel we have explored the trade offs involved in the static model and found it wanting

    And I also feel we have looked at the many of the trade-offs of dynamic languages and found them wanting: such as lack of many refactorings, problems with unit testing of code as a result of features such as duck typing, and (with a few exceptions) performance.
    Anyway. Back to the real issue, writing software and component model solutions. I note that you haven't disagreed with my main asertion in my original post on EJB.

    Appservers, JNDI Naming Services, containers, multiple classloaders etc are an attempt to bring late binding of objects to the static world of Java.

    They are? I thought they were about serving applications, and having services which are named and loadable from multiple sources and so transparently clusterable.
    I'm hoping that you guys will tend to agree with me that the design trade offs represented by a dynamic language like Smalltalk will in the long term prove more beneficial in adressing the types of problems us as enterprise developers now face.

    As I said, from considerable experience of developing with Smalltalk and other dynamic languages, I certainly don't agree.
    BTW. Work on language work benches (see Martin Folwers website) means that automated developer policing could be applied to dynamic languages too. Language work benches allow you to have the safety of external DSLs (e.g. XML) whilst still retaining the flexiblity of internal DSLs (as applied in languages like Smalltalk and LISP). Imaging a language based on Smalltalk that allowed you to project differing views of an abstract representation of the program (the Image) to a code browser/editor that limited developers to specific language features and specific DSLs. Advanced user could use a more open browser to create the DSL's in the first place. All this is possible today.Paul.

    This does not address issues that have been raised. This is all very well, until the developer team is changed and perhaps new people (with their own DSLs and ideas) try to support work already done. The learning curve could be phenomenal. I have also yet to be convinced by the quality of code generators!
  209. Agility and Dynamic Languages[ Go to top ]

    BTW. Work on language work benches (see Martin Folwers website) means that automated developer policing could be applied to dynamic languages too. Language work benches allow you to have the safety of external DSLs (e.g. XML) whilst still retaining the flexiblity of internal DSLs (as applied in languages like Smalltalk and LISP). Imaging a language based on Smalltalk that allowed you to project differing views of an abstract representation of the program (the Image) to a code browser/editor that limited developers to specific language features and specific DSLs. Advanced user could use a more open browser to create the DSL's in the first place. All this is possible today.Paul.
    This does not address issues that have been raised. This is all very well, until the developer team is changed and perhaps new people (with their own DSLs and ideas) try to support work already done. The learning curve could be phenomenal. I have also yet to be convinced by the quality of code generators!
    Hi Steve,

    I read what you had to say. I just can't help feeling that your perspective is firmly rooted in what has happened in the past (early commercial Smalltalk) rather than what is possible today (XP and modern dynamic languages) and what could be possible in the near future (XP, dynamic languages and language work benches).

    Our differences I believe just come down to a difference in experience and perspective. My agile experience has convinced me that you cannot protect developers from themselves. What is required is a management and organisational environment that encourages developers to solve problems for themselves in the most simplest ways possible.

    So the key to success for me is development team empowerment and teams being able to do the simplest thing that will possibly work.

    I really want to talk specifically about EJB (once the jewel of J2EE). EJB tries to solve a specific problem. Yet the solution to date has been extremely complex. The point I am making is that the use of a dynamic language would vastly simplify the creation of a late bound component model, meeting many of the EJB design goals. I just can't see how this can be refuted.

    So the issue then is if this increased simplification is a positive trade-off when compared to the potential pitfalls of using a dynamic language. My view
    is that it is if a disciplined structured development environment exists. This is based on my experience of using Ruby in an XP environment, and also on the quality of some of the solutions now emerging from the dynamic language community (Croquet, Seaside etc).

    I don't think you can make a decision freeze it in time and never revisit it when it comes to technology. As I said before, no technology is perfect. Choosing the right technology is about trade-offs. Over time and in differing scenarios those trade-offs change.

    Paul.
  210. I really want to talk specifically about EJB (once the jewel of J2EE). EJB tries to solve a specific problem. Yet the solution to date has been extremely complex. The point I am making is that the use of a dynamic language would vastly simplify the creation of a late bound component model, meeting many of the EJB design goals. I just can't see how this can be refuted.

    As I said, for my part, I think AOP is the middleware solution we have been looking for. Why? Because AOP is like a menu à la carte. You can choose whatever you want without having to deal with the complexities of things you don't want and don't care. You gain the same advantages as with a dynamic typing approach while keeping your business model static. To me, it is way better then a pure dynamic approach and it is certainly not a hack.

    I might be wrong but dynamic-typing programming languages have been around for a long time now and even if there was a lot of hype surrounding them, they didn't win a decent amount of market share. Why? In my opinion, it is because a language is always a tradeoff between being POWERFUL but EASY TO USE AND UNDERSTAND (and the program created with it). People always seem to throw up the later one out of the window without any consideration. Remind me of linux zealots who always pretend a good GUI isn't necessary, only stupid people care about it and everyone should stick to the terminal ;) Well Ubuntu seems to prove the inverse.

    Smalltalk is very powerful but like you said conterintuitive, I have yet to see some metaclasses running around in the real world. And yet you think the complexities of JEE can be allieved by using SmallTalk or other dynamical languages ? Smalltalk programs are way more complex then Java's ones in my mind.

    On the other hand, Java seem to mix in a lot of different paradigms while still being simple. My wish is that true AOP support and some functionnal programming constructions are going to be made part of the core language in the near future without changing the core syntax we all have come to love :p
  211. Agility and Dynamic Languages[ Go to top ]

    Smalltalk programs are way more complex then Java's ones in my mind.On the other hand, Java seem to mix in a lot of different paradigms while still being simple. My wish is that true AOP support and some functionnal programming constructions are going to be made part of the core language in the near future without changing the core syntax we all have come to love :p

    +1
  212. Hi Alexandre,

    I agree that AOP offers a lot when it comes to adding cross cutting concerns to existing components. Having said this in the real world few cross cutting concerns are actually needed (such as transactions and security - both are seldom really needed at the component level for non distributed components).

    AOP doesn't help with the late-binding of components. The common lightwieght Java approach to latebinding is Depenency Injection using a bean factory. Bean factories use reflection to lookup classes and instantiate objects on demand (that dreaded metaprogramming technique you dislike in Smalltalk :^)).

    As I said before I am assuming that 99% of the time your components are not distributed. In this scenario the benefit of components is re-use.

    So what offers the best late bound component model? Spring or a late bound language like Ruby or Smalltalk?

    Paul.
  213. Agility and Dynamic Languages[ Go to top ]

    The common lightwieght Java approach to latebinding is Depenency Injection using a bean factory. Bean factories use reflection to lookup classes and instantiate objects on demand (that dreaded metaprogramming technique you dislike in Smalltalk :^)).

    I guess that the difference for me is that this sort of metaprogramming is usually done by well-known and well-documented packages (such as Spring). It may be 'dreaded', but at least it is somewhat under control :)

    The issue with dynamic languages is, as previously mentioned, the NIH syndrome, which leads to a tendency for individual developers or teams to get involved in heavy metaprogramming.
  214. Agility and Dynamic Languages[ Go to top ]

    The common lightwieght Java approach to latebinding is Depenency Injection using a bean factory. Bean factories use reflection to lookup classes and instantiate objects on demand (that dreaded metaprogramming technique you dislike in Smalltalk :^)).
    I guess that the difference for me is that this sort of metaprogramming is usually done by well-known and well-documented packages (such as Spring). It may be 'dreaded', but at least it is somewhat under control :)The issue with dynamic languages is, as previously mentioned, the NIH syndrome, which leads to a tendency for individual developers or teams to get involved in heavy metaprogramming.
    I agree. But I would say that whether this happens or not is team dependent rather than static/dynamic dependent.

    I have seen teams go to town with the reflection API in Java. This is metaprogramming. I agree that heavy metaprogramming is best reserved for DSL's and frameworks like Spring. But this issue is just as valid in a static language as it is in a dynamic one.

    If you look into XP and it's roots you will see that the Smalltalk community have learned the hard way that it is best to do "the simplest thing that can possibly work".

    The point I've being trying to make for a while now is that EJB's are anything but simple. And even though much of the complexity is hidden within the App Server (with much metaprogramming), in practice the inherent complexity of EJB still tends to rear it's head (XML descriptors, or annotations, Named resources, packaging, deploying etc).

    And in my experience the moment you move beyond the simple app. server tutorial example you are burdened with the need to understand the detailed inner workings of your app server implementation intimately (I have spent many hours reading EJB specifications and Weblogic Server documentation, trust me on this one).

    Paul.
  215. Agility and Dynamic Languages[ Go to top ]

    I agree. But I would say that whether this happens or not is team dependent rather than static/dynamic dependent.I have seen teams go to town with the reflection API in Java. This is metaprogramming. I agree that heavy metaprogramming is best reserved for DSL's and frameworks like Spring. But this issue is just as valid in a static language as it is in a dynamic one.

    I largely agree with you. My concern is that the 'barrier to entry' of metaprogramming in dynamic language is hugely lower - in fact there seems to be an increasing attitude that metaprogramming is something to be encouraged rather than something to be careful of.
    If you look into XP and it's roots you will see that the Smalltalk community have learned the hard way that it is best to do "the simplest thing that can possibly work". The point I've being trying to make for a while now is that EJB's are anything but simple.

    Yes, but the problem that EJBs are trying to solve - distributed services and distributed access to persistence - is not simple. If you don't want to do this, you don't have to use EJBs. There are far simpler solutions in Java. For persistence in Java, there is JDO and JPA - which are very simple.

    And even though much of the complexity is hidden within the App Server (with much metaprogramming), in practice the inherent complexity of EJB still tends to rear it's head (XML descriptors, or annotations, Named resources, packaging, deploying etc).

    Because of the complexity of the solution. I have recently been briefly looking at app servers in dynamic languages. My impression is that they are sometimes not that simple either! It is the problem that is complex. Also, doesn't EJB 3.0 remove the need for such complexity to be as visible as in in earlier implementations (at least for those who don't want to use earlier EJB versions)?

    And anyway, if the inherent complexity can be very effectively hidden by great tools (such as NetBeans), and deployment is no more than the click of a button, who cares?
    And in my experience the moment you move beyond the simple app. server tutorial example you are burdened with the need to understand the detailed inner workings of your app server implementation intimately (I have spent many hours reading EJB specifications and Weblogic Server documentation, trust me on this one).Paul.

    I will! Do you have any details of how high-performance clustered app servers work in dynamic languages? I have no experience of these, and I am sure it must have been done in Smalltalk.
  216. Agility and Dynamic Languages[ Go to top ]

    I agree. But I would say that whether this happens or not is team dependent rather than static/dynamic dependent.I have seen teams go to town with the reflection API in Java. This is metaprogramming. I agree that heavy metaprogramming is best reserved for DSL's and frameworks like Spring. But this issue is just as valid in a static language as it is in a dynamic one.
    I largely agree with you. My concern is that the 'barrier to entry' of metaprogramming in dynamic language is hugely lower - in fact there seems to be an increasing attitude that metaprogramming is something to be encouraged rather than something to be careful of.

    Totally agree with you on this one Steve, the less metaprogramming I see, the better I am :) but those languages seem to encourage this approach. Well I am still waiting Lisp to take on the world as it was stated several times...
  217. I agree. But I would say that whether this happens or not is team dependent rather than static/dynamic dependent.I have seen teams go to town with the reflection API in Java. This is metaprogramming. I agree that heavy metaprogramming is best reserved for DSL's and frameworks like Spring. But this issue is just as valid in a static language as it is in a dynamic one.
    I largely agree with you. My concern is that the 'barrier to entry' of metaprogramming in dynamic language is hugely lower - in fact there seems to be an increasing attitude that metaprogramming is something to be encouraged rather than something to be careful of.
    Totally agree with you on this one Steve, the less metaprogramming I see, the better I am :) but those languages seem to encourage this approach. Well I am still waiting Lisp to take on the world as it was stated several times...

    Barrier to entry? Why is it any harder to use and abuse the reflection API in Java then it is to abuse Metaprogramming in say Ruby, Smalltalk, LISP, Python or any other language?

    The most important ingredient in software development is the fleshy blob driving the keyboard :^).

    This just sounds like language bigotry to me, with no technical basis in fact(maybe some of that NIH mentioned earlier?).

    Some one else made the point quite elequently on this same thread:
    ...They write in PHP, or Perl, or some other such nonsense that we scoff at.Perhaps the old addage "use the right tool for the job" applies.

    I'll look into EJB3.0 further. It strikes me that DI as described in the article is adding late binding to the Java runtime. If this is compatible with EJB3.0 so much the better.

    My point all along as been that for a proper component model you really do require late binding. Adding late binding to Java has got to be beneficial.

    BTW. Does anyone know whether the JCP is looking at AspectJ? IMO inclusion of AspectJ within Java itself will much improve the Java runtime.

    Incidently, I now understand the point you made earlier Alexandre with regards to the support of multiple paradigms within a single language (OOP, AOP, Funtional, Aspects etc). I'm not that keen on XML as a DSL though, but I agree with the idea of several paradigms.

    To me the real software design issues have allways been cohesion and coupling. Anything that improves cohesion and reduces coupling has got to be worth a look.

    Paul.
  218. I agree. But I would say that whether this happens or not is team dependent rather than static/dynamic dependent.I have seen teams go to town with the reflection API in Java. This is metaprogramming. I agree that heavy metaprogramming is best reserved for DSL's and frameworks like Spring. But this issue is just as valid in a static language as it is in a dynamic one.
    I largely agree with you. My concern is that the 'barrier to entry' of metaprogramming in dynamic language is hugely lower - in fact there seems to be an increasing attitude that metaprogramming is something to be encouraged rather than something to be careful of.
    Totally agree with you on this one Steve, the less metaprogramming I see, the better I am :) but those languages seem to encourage this approach. Well I am still waiting Lisp to take on the world as it was stated several times...
    Barrier to entry? Why is it any harder to use and abuse the reflection API in Java then it is to abuse Metaprogramming in say Ruby, Smalltalk, LISP, Python or any other language?The most important ingredient in software development is the fleshy blob driving the keyboard :^).This just sounds like language bigotry to me, with no technical basis in fact(maybe some of that NIH mentioned earlier?).Some one else made the point quite elequently on this same thread:
    ...They write in PHP, or Perl, or some other such nonsense that we scoff at.Perhaps the old addage "use the right tool for the job" applies.

    Well, my problem is that metaprogramming is an essential part of those languages, it is supported directly in its syntax. If you don't use it, you loose a lot of the language powerfulness and you don't gain as much of it dynamic nature. I remember when I was learning Smalltalk, it didn't take long before the teacher showed us how to use metaprogramming.

    I don't think the reflective API in Java is better, but it was a necessary pain indeed (maybe not anymore with all the recent AOP/DI development, we shall wait and see ;)). But at least it isn't a fundamental part of the language; Java reflective API is an advanced subject and isn't part of the language core. In fact, it may be a gross generalization but most Java programmers I know try to avoid using it at all cost while most Smalltalk programmers always seem to always want to use metaprogramming.

    Is it a language issue or it is just a matter of the people developing the software? Your answer is probably as good as mine.

    I just agree with the way Java is evolving, always trying to limit the use of metaprogramming even if it means the language is going to be more *cumbersome* to the developer. Dynamic languages get ride of those annoyances because of their dynamic typing and metaprogramming facilities. We all agree there, those are powerful features but at what cost? They can have some nasty effects that have been well documented in the past.

    On the other hand, Java technologies and frameworks try to get ride of those difficulties by exploring new ways of thinking and programming paradigm, all of it without dumping the static typing system. They seem to have found some very decent solutions in the end.
  219. I just want to moderate a little bit my comment about Spring embracing EJB3. After having done some reading, I think a better word would be *support* Let's put it on my basic english skills.

    Paul, I have no idea about AspectJ integration but it doesn't seem it is going to happen soon after reading this post :
    http://weblogs.java.net/blog/kgh/archive/2006/03/aop_madness_and.html
    I think the author is part of the Java language team, isn't he? His comprehension of AOP seems limited, just read the different replies. Well at least they are considering AOP, so it is positive :) By the way, is AspectJ still owned by IBM ? If yes, I don't think it will be integrated in Java any time soon seeing how IBM is crazy about JCP ...
  220. I just want to moderate a little bit my comment about Spring embracing EJB3. After having done some reading, I think a better word would be *support* Let's put it on my basic english skills.Paul, I have no idea about AspectJ integration but it doesn't seem it is going to happen soon after reading this post :http://weblogs.java.net/blog/kgh/archive/2006/03/aop_madness_and.htmlI think the author is part of the Java language team, isn't he? His comprehension of AOP seems limited, just read the different replies. Well at least they are considering AOP, so it is positive :) By the way, is AspectJ still owned by IBM ? If yes, I don't think it will be integrated in Java any time soon seeing how IBM is crazy about JCP ...
    Hi Alexandre,

    I thought that AspectJ was open source. One thing that was said is that AOP is essentailly another form of Metaprogramming and as such is best reserved for DSLs and frameworks. I've heard that there has been many attempts to incorporate AspectJ into Java, but there is strong resistence. Personally, given the track record of the JCP I don't think it will ever happen.

    Incidently, it seems intrenched in the Java community that compile time type checking is some how superior to runtime type checking, and that it leads to increased "type-safety". My view as I explained previously is that it leads to increased coupling.

    Java is a hybrid language, and the over all design goals of Java are unclear to me. Recent changes in Java 5.0 makes them even less clear.

    The reason why I like open source dynamic languages like Ruby and Squeak, is because there are clear design goals in play and a community driven to achieve them, unencumbered by comerical interests.

    From an Agile perspective Java and C Sharp are pretty much the same IMO, with pretty much the same limitations. In fact C Sharp seems to provide more freedoms then Java, beginning to adopt the mulit-pradigm approach you adhere to in C Sharp 3.0.

    To move into the world of advanced DSLs many Agile developers are looking at languages like Ruby. My view is that Ruby is a trojan horse for dynamic languages in general, and in the future even Squeak could become popular on the back of 3D collaborative networked operating environments like Croquet.

    Paul.
  221. Hi Alexandre,I thought that AspectJ was open source. One thing that was said is that AOP is essentailly another form of Metaprogramming and as such is best reserved for DSLs and frameworks.
    Yeah but a very clean and clear and somehow restricted way to do metaprogramming. In my opinion, metaprogramming is just an OOP way to adress cross-cutting concern. I think AOP is better at that.
    I've heard that there has been many attempts to incorporate AspectJ into Java, but there is strong resistence. Personally, given the track record of the JCP I don't think it will ever happen.
    I think AOP had to get some succes first. Spring and JBoss are giving some seriousness to AOP now so it more obvious it a good technology. Java is a production language first before a research language.
    Incidently, it seems intrenched in the Java community that compile time type checking is some how superior to runtime type checking, and that it leads to increased "type-safety".
    I can speak for myself, like I said earlier I don't care about the type safety, it is only a nice side effect. What I like about it is that a new developer can read the Javadoc and get a grasp very quickly of the system. The static types give a lot of information about a program structure, even the generics.
    My view as I explained previously is that it leads to increased coupling.
    Partly true, you can always push in the objects later using your favorite paterrn (factory, builder, DI, whatever, ...).

    Java is a hybrid language, and the over all design goals of Java are unclear to me. Recent changes in Java 5.0 makes them even less clear.
    I don't understand why people are so scared of generics. Generics are not a hack, they are more like regular expressions facilities applied to a static type system. They complement it nicely. From a theorical point of view, it makes sense.They believe in a static typing system and they just try to make it more powerful and versatile.
    The reason why I like open source dynamic languages like Ruby and Squeak, is because there are clear design goals in play and a community driven to achieve them, unencumbered by comerical interests.
    There are always commercial interests, people writting Ruby program still have to pay their bills and want it to succed. The difference is Java given its succes has to deal with a lot more commercial pressures, Ruby doesn't have to deal with giants like Oracle, IBM, BEA and in the OSS field Apache. A succesful language will always attrack a good amout of the commercial sector and of course some OSS initiatives.

    To say OSS languages are not-driven by commercial interest and Java is totally driven by commercial interests is just plain wrong in my opinion. The company behind Interface 21 want Spring to suceed after all. Commercial and technical successes go hand-to-hand. Spring and JBoss companies all got bigger and richer because of their very good solutions. The problem is when political issues become too big like in the JCP process sometimes. Unless you allow different flavors of Java (something I'm against) à la Linux, you will see those kind of troubles.
    From an Agile perspective Java and C Sharp are pretty much the same IMO, with pretty much the same limitations. In fact C Sharp seems to provide more freedoms then Java, beginning to adopt the mulit-pradigm approach you adhere to in C Sharp 3.0.

    Java has the upper hand right now and while still innovating, has to be careful to remain a production language and simple. The task of research and innovation is let to OSS solutions and once those solutions have make their proof, it will be standardized in the language. In my opinion, it is a very healty ecosystem.

    By the way, C Sharp is just going the natural Microsoft way, using their customers as beta testers.
  222. Hi Alexandre,

    You paint a very rosy picture of what is going on in the Java Ecosystem at the moment. Let's hope you're right :^) Personally I've got very strong doubts based on what has occurred in the past. An interesting test will be how EJB3.0 pans out over time.

    I like the sound of Spring 2.0 and you say that JBoss do something similar. JBoss seem very cosy with the JCP knowadays, so hopefully their approach will be compliant with any new standard. I'll look be looking into JBoss.

    I agree that experimentation and proof of concept should occur prior to standardisation (it is a shame that Sun never took this approach when creating EJB1.0 :^)). Languages share ideas from each other and cross populate all the time. This is why I keep an open mind and follow trends and patterns across all languages.

    In time some of the best ideas from other languages could find their way into Java. This can only be a good thing. At the moment I see the JCP as an obstacle and a barrier to a lot of good ideas. I also see a lack of overall vision and purpose.

    This is my issue with Generics, a lot of work, but it solves very little (semantic sugar). I see the new for loop constructs in the same way. Now if they had provided closures you could say, yeah that's going to make a big difference.

    Java 6.0 is/has added the odd byte code, but you still can't run a dynamic language like Ruby on the JVM, so what's the point?

    Do you know where Java is going? I certainly don't.

    Paul.
  223. Hi Alexandre,

    You paint a very rosy picture of what is going on in the Java Ecosystem at the moment. Let's hope you're right :^) Personally I've got very strong doubts based on what has occurred in the past. An interesting test will be how EJB3.0 pans out over time.

    I like the sound of Spring 2.0 and you say that JBoss do something similar. JBoss seem very cosy with the JCP knowadays, so hopefully their approach will be compliant with any new standard. I'll look be looking into JBoss.

    I agree that experimentation and proof of concept should occur prior to standardisation (it is a shame that Sun never took this approach when creating EJB1.0 :^)). Languages share ideas from each other and cross populate all the time. This is why I keep an open mind and follow trends and patterns across all languages.

    In time some of the best ideas from other languages could find their way into Java. This can only be a good thing. At the moment I see the JCP as an obstacle and a barrier to a lot of good ideas. I also sense a lack of overall vision and purpose.

    This is my issue with Generics, a lot of work, but it solves very little (semantic sugar). I see the new for loop constructs in the same way. Now if they had provided closures you could say, yeah that's going to make a big difference.

    Java 6.0 is/has added the odd byte code, but you still can't run a dynamic language like Ruby on the JVM, so what's the point?

    Do you know where Java is heading? I certainly don't.

    Paul.
  224. It's not the language stupid[ Go to top ]

    Hi Alexandre,You paint a very rosy picture of what is going on in the Java Ecosystem at the moment. Let's hope you're right :^) Personally I've got very strong doubts based on what has occurred in the past. An interesting test will be how EJB3.0 pans out over time.

    My impression is that you are judging the entire Java ecosystem based on your experience with EJB pre 3.0. That is a very narrow way to judge an entire ecosystem. The same ecosystem that produced EJB CMP also produced Spring and Hibernate.

    As for EJB 3.0, why not try it? There are many free preview or evaluation versions around. You will see how different it is immediately.
    I agree that experimentation and proof of concept should occur prior to standardisation (it is a shame that Sun never took this approach when creating EJB1.0 :^)).

    Nonsense. EJB used well-established and tested principles. Multi-threading. Object request brokers. Remoting. Transactions.
    Languages share ideas from each other and cross populate all the time. This is why I keep an open mind and follow trends and patterns across all languages.In time some of the best ideas from other languages could find their way into Java. This can only be a good thing.

    They already have. Many Java 1.5 features were already present in .NET.
    At the moment I see the JCP as an obstacle and a barrier to a lot of good ideas.

    Yet again, a vague and wrong generalisation. There have been some tremendous good ideas that come out of the JCP that I have already pointed out to you. One of my favourites is JDO - a portable, store-neutral and rich persistence mechanism that has some very high-peformance implementations. It is far better than anything I have used in other languages (like Smalltalk).
    I also sense a lack of overall vision and purpose.

    All we seem to be getting here is vague opinions without justification or evidence. I don't think they are useful in this sort of debate. Do you have statements or quotes which indicate lack of vision?

    I see a lot of purpose. One of the most exciting visions is shown by features starting to appear in Java 1.6 - the idea that Java could become not just a highly portable client-side development language, but also have superb (portable) integration with features of host operating systems. Swing could finally become what developers have wanted for decades - the first GUI which combines high-performance, portablity and well-integrated to the host OS. Together with great tools like NetBeans/Mattisse, this could really revolutionise portable client-side development.

    Another great vision (for me at least) is the potential of JSF - the idea of generalising server-side UIs, with components that can potentially render all sorts of client-side interfaces. I find this exciting!

    Then there is the increasing development of mobile Java, of real-time Java etc.

    One of the great things about Java is that it does not have a single purpose - it forms the basis for so many projects and ideas.

    While many other languages and frameworks are trying to be quick tools for doing old things (producing HTML, persisting to relational databases), the JCP is producing standards that open up possibilities and allow the developer to look forward to new technologies.
    This is my issue with Generics, a lot of work, but it solves very little (semantic sugar). I see the new for loop constructs in the same way.

    For me generics have solved a lot of issues. They have significantly improved my ability to check type safety in large projects. Together with boxing/unboxing they have made my code far more concise and readable, meaning I rarely have to use casting. Far more than just 'semantic sugar'.
    Now if they had provided closures you could say, yeah that's going to make a big difference.Java 6.0 is/has added the odd byte code, but you still can't run a dynamic language like Ruby on the JVM, so what's the point?Do you know where Java is heading? I certainly don't.Paul.

    Why should such a large platform head in any one direction? As I have described with Java 1.6 - there are many ways that Java is moving forward in exciting ways.

    Oh, and by the way - of course you can run dynamic languages on the JVM! You can run BeanShell, Groovy, Ruby, Python, Smalltalk, LISP, Scheme, TCL, and many, many others.
  225. Well, my problem is that metaprogramming is an essential part of those languages, it is supported directly in its syntax. If you don't use it, you loose a lot of the language powerfulness and you don't gain as much of it dynamic nature. I remember when I was learning Smalltalk, it didn't take long before the teacher showed us how to use metaprogramming.

    I strongly disagree with this statement Alexandre. This maybe the way Smalltalk is taught knowadays, but it is definateky not the way it is used. Most modern Smalltalk developers adhere to XP, which promotes simplicity.

    Also metaprogramming is metaporgramming what ever language you use. You don't need to use it anymore in Smalltalk than you do in Java. The fact is that when you do need/want to use it in Smalltalk, the metaprogramming facilities are a lot more powerful (this alos applies to Ruby, LISP etc).

    Where Metaprogramming comes into it's own is in the generation of DSLs and frameworks. You may like or hate RoR, but RoR is an example of a DSL that heavilly uses Metaprogramming and would be difficult (practically impossible?) to achieve in a static language like Java.

    If you think of an OO program as containing language layers, each layer extending the one below. At the bottom is byte code and the VM, the next layer is your standard class library, the layer on top of this is your internal DSL targetting the type of application you wish to write, and finally the last layer is your application specific code. IMO Metaprogramming should be reserved for internal DSL's. I follow many Smalltalk blogs, and I haven't heard any Smalltalk developer say anything to the contrary (or no Ruby developer either for that matter).

    Paul.
  226. Agility and Dynamic Languages[ Go to top ]

    Yes, but the problem that EJBs are trying to solve - distributed services and distributed access to persistence - is not simple. If you don't want to do this, you don't have to use EJBs. There are far simpler solutions in Java. For persistence in Java, there is JDO and JPA - which are very simple.

    Hi Steve,

    The problem with EJB's are that they are a swiss army knife. You get a whole load of "features" as part of the deal whether you want them or not, and it is all premised on the assumption that your components more often than not will be distributed across a network.

    Real world experience has shown that very often you don't want or need to distribute your components. There are better ways to scale applications (central hardware load balancer, sticky sessions, add servers running the same applicaion). Whaty people want to do is re-use components that they perhaps have already or use standard components off the shelf, but all within a single JVM.

    EJB1.0 only allowed for remote interfaces between components. This meant that without implementation specific optimisation the standard way to communicate between two EJB's running in the same VM was to lookup the server EJB using JNDI, marshall requests over RMI, and serialise and send value objects. This ridiculous state of affairs wasn't corrected until EJB2.1 with the addition of local interfaces, but even then you still needed a naming service and JNDI.

    Why use a JNDI lookup to access a componet on the same VM? Why assume that persistent objects are going to be remote?

    IMO the whole EJB concept is flawed. IMO EJB is a victim of premature standardisation for commerical reasons. Sun wanted to come up with an enterprise wide runtime platform to compete with Windows NT on the server, and came up with a half backed standard as a consequence.

    So what do we do? Well after years of telling the industry that this is the prefferred approach (see the published J2EE core patterns recommended by Sun), they are know admitting that perhaps they got it wrong.

    So we've got EJB3.0 in the offing, but they want to maintain backward compatibility with a flawed concept. The result IMO will be an improved programming model through the use of DI and annotations, but the same over complex component model at runtime.

    Incidently the best approach to distributed objects is don't distribute your objects. If you do need distribution then use messaging.
    will! Do you have any details of how high-performance clustered app servers work in dynamic languages? I have no experience of these, and I am sure it must have been done in Smalltalk.

    I don't, but I do know that GemStone was an enterprise scale distributed OO system for Smalltalk based on the use of an OODMS. Fromwhat I've read it worked quite well, but as you know OODBMS's didn't take off.

    Messaging is a much better approach to distribution then remote objects. If you think about the discussion we had earlier about OOP, Smalltalk and messaging, then you can see how distribution in a Smalltalk environment is a lot more natural using a messaging solution than when using a static language. Squeak has distribution between Images and to all accounts it works seamlessly (haven't really tried it myself).

    Also CORBA had a dynamic API targetted at languages like Smalltalk, but due to the prevailing preference for static languages I don't think it really took off.

    Paul.
  227. Agility and Dynamic Languages[ Go to top ]

    Yes, but the problem that EJBs are trying to solve - distributed services and distributed access to persistence - is not simple. If you don't want to do this, you don't have to use EJBs. There are far simpler solutions in Java. For persistence in Java, there is JDO and JPA - which are very simple.
    Hi Steve,The problem with EJB's are that they are a swiss army knife. You get a whole load of "features" as part of the deal whether you want them or not, and it is all premised on the assumption that your components more often than not will be distributed across a network.Real world experience has shown that very often you don't want or need to distribute your components.

    So don't use the features you don't need. I don't see the problem here. If you don't want clustered persistence, use an API that doesn't force it, like JDO or JPA.
    There are better ways to scale applications (central hardware load balancer, sticky sessions, add servers running the same applicaion).

    As I understand things you are missing something important here. All these things work, but only for limited types of scaling. J2EE can provide so much more. with J2EE you can transparently use different sorts of scaling and clustering, invisibly to the developer, it can also provide transactions, and security. J2EE containers can also provide different approaches to failover.

    These are phenomenally powerful and important features, all provided within a standard API. Simply saying 'use sticky sessions' or 'run the same application on multiple servers' does not deal with these issues in a manner required for many serious applications.
     
    Why use a JNDI lookup to access a componet on the same VM? Why assume that persistent objects are going to be remote?

    You are missing the point. It doesn't assume that the persistent objects are going to be remote. It means you don't have to know whether or not they are remote. Linking things up with JNDI is trivially easy with EJB 3.0 - it is done by dependency injection. So where is the problem?
    IMO the whole EJB concept is flawed.

    The concept of transparent clustering, security and transactions is flawed?
    IMO EJB is a victim of premature standardisation for commerical reasons. Sun wanted to come up with an enterprise wide runtime platform to compete with Windows NT on the server, and came up with a half backed standard as a consequence.

    So you say, but it was been widely implemented and deployed. Whatever the problems, it has been highly successful. If EJB is a victim, I am sure that there are many other vendors out there would would pay good money for their products to be victims! J2EE/EJB dominates serverside. If it was designed to compete with Microsoft on the server, it succeeded.
    So what do we do? Well after years of telling the industry that this is the prefferred approach (see the published J2EE core patterns recommended by Sun), they are know admitting that perhaps they got it wrong.

    No. They are admitting it wasn't perfect and evolving the system.
    So we've got EJB3.0 in the offing, but they want to maintain backward compatibility with a flawed concept.

    Which is the reponsible and only sensible thing to do, with so many existing (successful) deployments.

    You see, unlike other vendors, Sun don't take the much-hated approach of changing direction and leaving angered developers behind with unsupported systems.
    The result IMO will be an improved programming model through the use of DI and annotations, but the same over complex component model at runtime.

    Why do you care? You need not see the complex model.
    Incidently the best approach to distributed objects is don't distribute your objects. If you do need distribution then use messaging.

    But that involves a lot of extra work for the developer. The point about EJBs is transparency - the work is done by the app server.
    Do you have any details of how high-performance clustered app servers work in dynamic languages? I have no experience of these, and I am sure it must have been done in Smalltalk.
    I don't, but I do know that GemStone was an enterprise scale distributed OO system for Smalltalk based on the use of an OODMS. Fromwhat I've read it worked quite well, but as you know OODBMS's didn't take off.

    I used (or rather did some substantial evaluation of) Gemstone in the 90s. It was a nice system, but was not trivial to configure and use. Not much simpler than a modern App server, as I recall. So where is the advantage of dynamic languages in this respect?
    Messaging is a much better approach to distribution then remote objects. If you think about the discussion we had earlier about OOP, Smalltalk and messaging, then you can see how distribution in a Smalltalk environment is a lot more natural using a messaging solution than when using a static language. Squeak has distribution between Images and to all accounts it works seamlessly (haven't really tried it myself).Also CORBA had a dynamic API targetted at languages like Smalltalk, but due to the prevailing preference for static languages I don't think it really took off.Paul.

    I disagree. Clustering should be transparent to the developer. I don't want to handle messaging (with all the work involved) unless I have a specific reason for using messaging. This does not deal with the issues of security or transactions, for example.
  228. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    From your response I can tell that you haven't had much experience actually developing EJB distributed applications this cooment says a lot:
    .. with J2EE you can transparently use different sorts of scaling and clustering, invisibly to the developer

    So if this stuff is invisible to the developer; who did it on your project? The application assembler or the deployer or the system adminstrator? Or perhaps one of the other made up roles that show up in the EJB/J2EE specifications. All this stuff is fiction. Anyone who as had to do it knows this.

    With J2EE developers need to be intimately knowleageable about the implementation details of their app server to do simple things, never mind clustering. This is why no one will empoy a Weblogic developer to do harcore work on Websphere. A lot of stuff is implementation specific despite so called standards.

    The approach to scaling I mentioned is the prefferred apporach of companies that have been burnt by the failed promises of App Servers and have learned through experience to go for a much simpler solution that gets the job done. Name me a scenario where such an approach wouldn't work.
    I disagree. Clustering should be transparent to the developer. I don't want to handle messaging (with all the work involved) unless I have a specific reason for using messaging. This does not deal with the issues of security or transactions, for example.

    The messaging I spoke about with distributed Smalltalk does not need to form part of the programming model. It can be transparent to the programmer. I believe all the Smalltalk distribution solutions perform remote message sends in a transparent way. I'm not sure, but like I said I believe all these solutions are pretty seamless. You can check for yourself they are all well documented on the web.

    Steve,

    The problem with EJB is that it is vastly over complex for 99% of the cases. The problem is that even if you do not want to use the features they still intrude on your application (still need to use JNDI, still need to configure your naming service, still have to explicitly switch off transactions, security etc in EJB2.1 although EJB3.0 should remove this need by using sensible defaults).

    The complexity of the component model runtime (App Server, containers, JNDI, Naming Service, descriptors etc) is a massive burden. Picocontainer and Spring have shown that all this is just not needed most of the time.

    Dynamic languages deliver an object component model straight out of the box, built into the language and the VM. They meet a large percentage of the design goals of EJB for free.

    I can't see why you've got a mental block on this one. EJBs where a mistake; period. We are still paying for that mistake today with EJB3.0 IMO. What is needed is a fresh approach. Spring and the other IoC containers offer this. So does late depency Injection using AOP as described by Alexandre. I doubt that these solutions willl be fully EJB3.0 compliant.

    Dynamic languages offer a fresh approach to components. I once read an article by a developer of CommonPoint; a C++ component framework from 1997ish. He made a very good argument that it was the insistance by management that they had to write it in C++ that finally killed the project. Trying to get a static language to link together components dynamically at runtime is very difficult. SOM and DSOM from IBM suffered the same difficulty along with COM and DCOM from Microsoft. Also OpenDoc from Apple failed for a similar reason IMO. EJB is one of a long line of failures.

    Looking forward to large scale enterprise applications; building solutions from components will be very important IMO. I stand by my view that a dynamic language is inherently better suited for this purpose (even if it is used to wrap and script together components written in a static language).

    Paul.
  229. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,From your response I can tell that you haven't had much experience actually developing EJB distributed applications this cooment says a lot:
    .. with J2EE you can transparently use different sorts of scaling and clustering, invisibly to the developer

    You are right. I haven't had much practical experience of this for large enterprise stuff in Java with WebSphere.
    So if this stuff is invisible to the developer; who did it on your project? The application assembler or the deployer or the system adminstrator? Or perhaps one of the other made up roles that show up in the EJB/J2EE specifications. All this stuff is fiction. Anyone who as had to do it knows this.

    Give me evidence. Practical examples. I know that for some app servers you need to provide additional XML for deployment. Perhaps you could show how this requires intimate knowledge of the implementation. I would be interested.

    As for fiction, let me quote from JBoss documentation:

    "JNDI is a fundamental aspect of the J2EE specifications. One key usage is the isolation of J2EE component code from the environment in which the code is deployed. Use of the application component's environment allows the application component to be customized without the need to access or change the application component's source code."

    With J2EE developers need to be intimately knowleageable about the implementation details of their app server to do simple things, never mind clustering. This is why no one will empoy a Weblogic developer to do harcore work on Websphere.

    I have just looked and seen such jobs advertised on dice.com. There are a huge number of WebSphere jobs that have WebLogic as a required skill. The skills would seem to be transferrable.
    A lot of stuff is implementation specific despite so called standards.

    Ok, so I am relatively inexperienced. Teach me. Give me an actual example of how an EJB developer needs to know about the details of the clustering. I would be interested.

    My impression is that the situation is similar to say, a large database app. The DBA may have to do a lot of work setting up the database, but most of this complexity is not passed on to the developer.

    Prove me wrong.
    The approach to scaling I mentioned is the prefferred apporach of companies that have been burnt by the failed promises of App Servers and have learned through experience to go for a much simpler solution that gets the job done. Name me a scenario where such an approach wouldn't work.

    Well, for example, sticky sessions alone don't handle transactions. Or security. They are simply a way of distributing work.
    I disagree. Clustering should be transparent to the developer. I don't want to handle messaging (with all the work involved) unless I have a specific reason for using messaging. This does not deal with the issues of security or transactions, for example.
    The messaging I spoke about with distributed Smalltalk does not need to form part of the programming model. It can be transparent to the programmer. I believe all the Smalltalk distribution solutions perform remote message sends in a transparent way.

    But remote message sends alone don't handle issues of transactions, security etc.
    I'm not sure, but like I said I believe all these solutions are pretty seamless. You can check for yourself they are all well documented on the web.Steve,The problem with EJB is that it is vastly over complex for 99% of the cases.

    So you keep saying.
    The problem is that even if you do not want to use the features they still intrude on your application (still need to use JNDI, still need to configure your naming service, still have to explicitly switch off transactions, security etc in EJB2.1 although EJB3.0 should remove this need by using sensible defaults).

    Why not try it before commenting? A you talking about setting up the app server, or being a J2EE developer? Setting up app servers in any language can be complex.
    The complexity of the component model runtime (App Server, containers, JNDI, Naming Service, descriptors etc) is a massive burden. Picocontainer and Spring have shown that all this is just not needed most of the time.

    My impression is that this burden is hugely reduced by EJB 3.0. Why not take a look? There is no point in going on about the complexity if it is about to be removed.
    Dynamic languages deliver an object component model straight out of the box, built into the language and the VM. They meet a large percentage of the design goals of EJB for free.

    No, they don't provide scalability, transactions, security out of the box. These are the design goals of EJB.
    I can't see why you've got a mental block on this one.

    Back to this level of debate are we? :)
    EJBs where a mistake; period.


    They weren't. They were widely and successfully used. They still are. How is this a mistake?
    We are still paying for that mistake today with EJB3.0 IMO.

    Have you tried and evaluated EJB 3.0?
    What is needed is a fresh approach. Spring and the other IoC containers offer this. So does late depency Injection using AOP as described by Alexandre. I doubt that these solutions willl be fully EJB3.0 compliant.

    And you are wrong. EJB 3.0 can use late dependency injection using AOP.
    Dynamic languages offer a fresh approach to components.

    No they don't. Nothing has changed in this respect for a long time.
    I once read an article by a developer of CommonPoint; a C++ component framework from 1997ish. He made a very good argument that it was the insistance by management that they had to write it in C++ that finally killed the project. Trying to get a static language to link together components dynamically at runtime is very difficult.

    No, it isn't. It is difficult in C++. It is easy in Java, through things like IoC and AOP. Have you tried Spring?
    EJB is one of a long line of failures.

    A 'flawed' approach in some ways, perhaps. But by no stretch of the imagination could it be called a 'failure'.
    Looking forward to large scale enterprise applications; building solutions from components will be very important IMO.

    True.
    I stand by my view that a dynamic language is inherently better suited for this purpose (even if it is used to wrap and script together components written in a static language).Paul.

    And unless you can provide a technical reason, there is no point in saying this. Thousands of developers are successfully building component solutions in Java using Spring, for example. Using a dynamic language in place of the XML is simply equivalent, not better - a matter of personal preference, not quality. IMO.
  230. EJB Component Model[ Go to top ]

    Hi Steve,

    I'm not in the business of proving. I'm in the business of sharing experiences and opinions.

    I have read through EJB3.0 articles, but I'm aware that the spec is a moving target, and the last time I checked was over a year ago. So I do intend to get updated soon. But many of the ideas I've recently repeated I've tested earlier in this same thread with people that are up to date and their understanding seemed to agree with mine, so I don't think that much as changed.

    BTW Many agree that backward compatibilty with EJB2.1 is a mistake. That's been mentioned on this thread by others too.

    I suggest you search TSS for discussions about EJB3.0 to get a wider set of opinions and views. In terms of my critique you will find that the criticisms I make are common. Also a good reference is "J2EE without EJB" by Rod- Johnson and "The Elephant" article by Bruce Tate.

    I've also given a detailed example in response to alexandre of class loader problems with EJB2.1. It wouldn't surprise the exact same problem will occur with EJB3.0 implementations, since the problem wasn't to do with the programming model, but the underlying runtime environment.

    Websphere and Weblogic interchangeable? Well again others on this very same thread have testified that this just isn't the case.

    late dependency injection using AspectJ as described in the article supplied by Alexandre is very different from standard DI in Spring 1.0. I can see this impacting the EJB runtime which will possibly break backward compatibility with EJB2.1

    As for your view of late binding and dynamic languages. Well if you think XML descriptors are just as good, you are entitled to your opinion.


    For me the discussion wasn't a total waste. I've clarified a few of my own ideas and AspectJ does seem to old out the promise of bringing true late binding and metaprogramming to Java. Thanxs for this insight Alexandre.

    I'm done guys.

    Cheers,

    Paul.
  231. EJB Component Model[ Go to top ]

    Hi Steve,I'm not in the business of proving. I'm in the business of sharing experiences and opinions.I have read through EJB3.0 articles, but I'm aware that the spec is a moving target, and the last time I checked was over a year ago. So I do intend to get updated soon. But many of the ideas I've recently repeated I've tested earlier in this same thread with people that are up to date and their understanding seemed to agree with mine, so I don't think that much as changed.BTW Many agree that backward compatibilty with EJB2.1 is a mistake. That's been mentioned on this thread by others too.I suggest you search TSS for discussions about EJB3.0 to get a wider set of opinions and views. In terms of my critique you will find that the criticisms I make are common. Also a good reference is "J2EE without EJB" by Rod- Johnson and "The Elephant" article by Bruce Tate.I've also given a detailed example in response to alexandre of class loader problems with EJB2.1. It wouldn't surprise the exact same problem will occur with EJB3.0 implementations, since the problem wasn't to do with the programming model, but the underlying runtime environment.Websphere and Weblogic interchangeable? Well again others on this very same thread have testified that this just isn't the case.late dependency injection using AspectJ as described in the article supplied by Alexandre is very different from standard DI in Spring 1.0. I can see this impacting the EJB runtime which will possibly break backward compatibility with EJB2.1As for your view of late binding and dynamic languages. Well if you think XML descriptors are just as good, you are entitled to your opinion.For me the discussion wasn't a total waste. I've clarified a few of my own ideas and AspectJ does seem to old out the promise of bringing true late binding and metaprogramming to Java. Thanxs for this insight Alexandre.I'm done guys.Cheers,Paul.
  232. EJB Component Model[ Go to top ]

    Hi Steve,I'm not in the business of proving. I'm in the business of sharing experiences and opinions.

    Well, I don't go by opinions for this kind of thing. If I make technical decisions, I want edvidence, not politics. I guess this is because I have a background as a research scientist. I don't see the point of technical debates if you aren't willing to provide evidence.
    I have read through EJB3.0 articles, but I'm aware that the spec is a moving target, and the last time I checked was over a year ago.

    It was a moving target a year ago.
    So I do intend to get updated soon. But many of the ideas I've recently repeated I've tested earlier in this same thread with people that are up to date and their understanding seemed to agree with mine, so I don't think that much as changed.BTW Many agree that backward compatibilty with EJB2.1 is a mistake.

    Any many don't. The word 'many' by itself is meaningless.
    In terms of my critique you will find that the criticisms I make are common.


    Again, must be my scientist background. I don't accept that just because a criticism is common that it is right. There is a common criticism from the developer community that Java is slow. This is out of date, and false.
    Also a good reference is "J2EE without EJB" by Rod- Johnson and "The Elephant" article by Bruce Tate.

    Yes, I know. But, even though I have a lot of respect for these people, there are always alternative views.

    I agree that EJBs as previously implemnted have flaws. What I don't accept was that they failed.
    I've also given a detailed example in response to alexandre of class loader problems with EJB2.1. It wouldn't surprise the exact same problem will occur with EJB3.0 implementations, since the problem wasn't to do with the programming model, but the underlying runtime environment.

    Yes, but how is one issue with classloading relevant to the whole issue of the Java environment and J2EE?
    Websphere and Weblogic interchangeable? Well again others on this very same thread have testified that this just isn't the case.

    I didn't say they were interchangable.
    late dependency injection using AspectJ as described in the article supplied by Alexandre is very different from standard DI in Spring 1.0.

    True, but irrelevant.
     
    I can see this impacting the EJB runtime which will possibly break backward compatibility with EJB2.1

    If it breaks backward compatibility, then the EJB runtime will use different approaches to DI and AOP.
    As for your view of late binding and dynamic languages. Well if you think XML descriptors are just as good, you are entitled to your opinion.

    I am indeed. I would rather have descriptors in a standard form which can be analysed and processed, and even automatically generated, by tools than some hand-written script in a dynamic language that can't be.
    For me the discussion wasn't a total waste. I've clarified a few of my own ideas and AspectJ does seem to old out the promise of bringing true late binding and metaprogramming to Java. Thanxs for this insight Alexandre.I'm done guys.Cheers,Paul.
  233. Hi Alexandre,I agree that AOP offers a lot when it comes to adding cross cutting concerns to existing components. Having said this in the real world few cross cutting concerns are actually needed (such as transactions and security - both are seldom really needed at the component level for non distributed components).AOP doesn't help with the late-binding of components. The common lightwieght Java approach to latebinding is Depenency Injection using a bean factory. Bean factories use reflection to lookup classes and instantiate objects on demand (that dreaded metaprogramming technique you dislike in Smalltalk :^)).As I said before I am assuming that 99% of the time your components are not distributed. In this scenario the benefit of components is re-use.So what offers the best late bound component model? Spring or a late bound language like Ruby or Smalltalk?Paul.

    I see bean wiring as an aspect. Afterall, it is the primary purpose of any J2EE container no? JBoss does it this way­. Spring don't because they don't want the core framework module to depend on the AOP module (I think the AOP module was added afterward anyway, eh?) In my opinion, binding is better handled by an aspect (DI) then putting the features directly in the metaclasses. With an aspect oriented language, you can still have the strength of an early bound component model (a clear class structure) while weaving in the components later. Best of both world!


    Metaclasses just look like a hack to perform some kind of AOP :) AOP is so clear compare to meta-programming and it is so easier to combine aspects together. AOP readability is very good compared to dynamic languages.
  234. The EJB Component Model[ Go to top ]

    I see bean wiring as an aspect.

    Interesting. Please explain further. I think if I give an example you'll understand the type of issues I'm talking about with regards to EJB.

    I once worked on a project where we bought a 3rd party EJB based workflow solution for incorporation into the rest of our EJB application as a component.

    Well the 3rd party component came in its own EAR file. We were using Weblogic 8.1. Our EJB's needed to call the third party workflow component, and the workflow component need to call us back.

    Sounds simple, untill you realise that weblogib builds an hierachy of class loaders with the assumption that wars will need to call EJBs. So your war class loader will call the ejb class loader if needed. We had a situation where we wanted EJB's in different EAR's to be mutually dependent. We spent weeks if not monhts on this problem.

    In the end the only solution was to unpackage the third party workflow EAR into EJB jars (about 20 of them) and to repackage those EJB's into our application EAR.

    Hardly an effect late bound component model.

    We were promised a market in third party EJB components. It never materialised. This type of problem IMO partially explains why.

    If your AOP approach solves such problems, I'm more than interested.

    Paul.
  235. The EJB Component Model[ Go to top ]

    I see bean wiring as an aspect.
    Interesting. Please explain further. I think if I give an example you'll understand the type of issues I'm talking about with regards to EJB.I once worked on a project where we bought a 3rd party EJB based workflow solution for incorporation into the rest of our EJB application as a component.Well the 3rd party component came in its own EAR file. We were using Weblogic 8.1. Our EJB's needed to call the third party workflow component, and the workflow component need to call us back.Sounds simple, untill you realise that weblogib builds an hierachy of class loaders with the assumption that wars will need to call EJBs. So your war class loader will call the ejb class loader if needed. We had a situation where we wanted EJB's in different EAR's to be mutually dependent. We spent weeks if not monhts on this problem.In the end the only solution was to unpackage the third party workflow EAR into EJB jars (about 20 of them) and to repackage those EJB's into our application EAR. Hardly an effect late bound component model.We were promised a market in third party EJB components. It never materialised. This type of problem IMO partially explains why.If your AOP approach solves such problems, I'm more than interested.Paul.

    I understand the issue and it is one of the reason I like AOP : you have the control over what is executed instead of having to rely on a heavy specification and pray the container implements it correctly.

    Well I just found out Spring 2.0 is going that way, I am more then happy :) The blog entry announcing this new feature was posted on TSS a couple months ago but the original site seems to have problem handling old links. Google once again comes to the rescue :
    http://groups.google.ca/group/EtoE/browse_thread/thread/cac1eafe15f06f5b/7db829b9dacc59ab%237db829b9dacc59ab?sa=X&oi=groupsr&start=0&num=3
    It adresses a different kind of problems but it is based on the same idea, performing DI using some aspects.
  236. The EJB Component Model[ Go to top ]

    I understand the issue and it is one of the reason I like AOP : you have the control over what is executed instead of having to rely on a heavy specification and pray the container implements it correctly.Well I just found out Spring 2.0 is going that way, I am more then happy :)

    I like it. It looks like Spring is moving Java further in the right direction. This approach doesn't sound EJB3.0 compliant though. AFAIK the EJB3.1 component model runtime environment is pretty much the same as the EJB2.1. The differences between EJB2.1 and EJB3.1 AFAIK are in the programming model. The use of late dependency injection (I've just coined a new term :^)) as described in your article, would definately require changes to EJB I believe and most certainly break backward compatipility with EJB2.1.

    I've watched AspectJ for a while, and while it excites me it has also left me slightly concerned. As I understand it AspectJ uses post compilation byte code manipulation to weave advice. It would be wonderful if Aspectj was incorporated into Java (much more needed than Generics IMO :^)). That way Aspectj wouldn't need to be a Java post proccessor and would become integral to the language.

    Are the JCP looking into this? I'll be taking more of an interest in Spring.

    Thanks for this info.

    Paul.
  237. The EJB Component Model[ Go to top ]

    I understand the issue and it is one of the reason I like AOP : you have the control over what is executed instead of having to rely on a heavy specification and pray the container implements it correctly.Well I just found out Spring 2.0 is going that way, I am more then happy :)
    I like it. It looks like Spring is moving Java further in the right direction. This approach doesn't sound EJB3.0 compliant though. AFAIK the EJB3.1 component model runtime environment is pretty much the same as the EJB2.1. The differences between EJB2.1 and EJB3.1 AFAIK are in the programming model. The use of late dependency injection (I've just coined a new term :^)) as described in your article, would definately require changes to EJB I believe and most certainly break backward compatipility with EJB2.1.I've watched AspectJ for a while, and while it excites me it has also left me slightly concerned. As I understand it AspectJ uses post compilation byte code manipulation to weave advice. It would be wonderful if Aspectj was incorporated into Java (much more needed than Generics IMO :^)). That way Aspectj wouldn't need to be a Java post proccessor and would become integral to the language.Are the JCP looking into this? I'll be taking more of an interest in Spring.Thanks for this info.Paul.

    The Spring folks have stated several times that Spring 2 are fully embracing EJB 3 so I am sure there won't be any serious issues. I haven't had a lot of times to invest Spring 2.0 but it looks promising to me. Maybe some Spring developpers can answer the question.
  238. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,I read what you had to say. I just can't help feeling that your perspective is firmly rooted in what has happened in the past (early commercial Smalltalk)

    Are VisualWorks, Dolphin and Squeak 'early commercial Smalltalk'? I think not. I have used earlier systems (Digitalk), but that is just because I have been using Smalltalk for various projects over nearly 20 years.
    I believe just come down to a difference in experience and perspective. My agile experience has convinced me that you cannot protect developers from themselves.

    My experience (which, I have to tell you includes modern development languages and techniques) is that you can go a very long way to protecting developers by choosing the right language and tools. The difference in protection between, say, Visual Basic (with many dynamic features) and Java or Delphi is phenomenal.
    What is required is a management and organisational environment that encourages developers to solve problems for themselves in the most simplest ways possible.So the key to success for me is development team empowerment and teams being able to do the simplest thing that will possibly work.

    Sorry, this doesn't work. It doesn't work because of tight deadlines, and shifting management priorities and skills (I am trying to put this diplomatically :)

    We have to deal with the real world, not some Agile ideal where all developers are highly skilled and perfectly managed.
    I really want to talk specifically about EJB (once the jewel of J2EE). EJB tries to solve a specific problem. Yet the solution to date has been extremely complex. The point I am making is that the use of a dynamic language would vastly simplify the creation of a late bound component model, meeting many of the EJB design goals. I just can't see how this can be refuted.

    Ok, I won't. Perhaps you would like to remind me of why the creation of a late bound component model specifically is important.
    So the issue then is if this increased simplification is a positive trade-off when compared to the potential pitfalls of using a dynamic language.

    My view is that it isn't.
    My viewis that it is if a disciplined structured development environment exists. This is based on my experience of using Ruby in an XP environment, and also on the quality of some of the solutions now emerging from the dynamic language community (Croquet, Seaside etc).

    We have already discussed such things and they have raised issues that you have not responded to, such as the way that some of these solutions (such as Seaside) have potential scaling issues, which even dedicated Smalltalkers admit. If you are going to present solutions with quality, you need to present solutions with the quality of being practical solutions for general use, not just demonstrations of (great) technologies.
    I don't think you can make a decision freeze it in time and never revisit it when it comes to technology.

    Who is doing that?
    As I said before, no technology is perfect. Choosing the right technology is about trade-offs. Over time and in differing scenarios those trade-offs change.Paul.

    Yes, and my view is that the idea that you can on high-quality developers and managers all working efficiently using Agile development is not making a trade-off. Life isn't that simple.

    What works for a high-quality small team for individual projects, does not work (in my experience and view) for large long-term distributed projects with developer teams of variable skills and experience. There is an advantage that static, safe language like Java have here that I believe is hard to refute, as it unquestionably does protect projects from many developer mistakes, or at least helps to diagnose and fix them.
  239. AOP make this possible because it doesn't enforce you to polluate your code with several meaningful interfaces.
    "meaningful" should have been "meaningless". Please, in the name of every non-native english speakers who need to correct their mistakes afterward, I ask for an edit button :)
  240. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,

    I think the persistence solution I looked at years ago was called Castor (is that JDO compliant?), anyway it was miles better then Entity Beans.

    I think there was another similar implementation around at the time too. Again when you get time an outline of the history of JDO would be appreciated.

    Paul.
  241. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,I think the persistence solution I looked at years ago was called Castor (is that JDO compliant?),
    anyway it was miles better then Entity Beans.

    It was much better, but not compliant with the JDO spec.
    I think there was another similar implementation around at the time too. Again when you get time an outline of the history of JDO would be appreciated.Paul.

    I really think that the best place to look is the JCP site - the long and interesting political history is there!

    JDO 1.0: JSR 12 (it started way back!)

    http://www.jcp.org/en/jsr/detail?id=12
     
    JDO 2.0:

    http://www.jcp.org/en/jsr/detail?id=243

    Although I used it, I was not a great fan of JDO 1.0 - I used it because it was a 'standard', even though Hibernate was easier to use in some respects. However, JDO 2.0 is a vast improvement, with a far better query language, and a more practical approach with things like attach/detach (to avoid the use of DTOs) and delete-by-query - it really is a pleasure to use. The RI of JDO 2.0 is an open-source implementation: www.jpox.org.
  242. Agility and Dynamic Languages[ Go to top ]

    I really think that the best place to look is the JCP site - the long and interesting political history is there!

    Thanxs.

    Did you get a chance to read what I had to say about EJB3.0? Interested in hearing your views when you've got time.

    Paul.
  243. How effective is the JCP?[ Go to top ]

    Hi Steve,

    I tracked down this article on the history of JDO. Makes real interesting reading. I think it confirms my concern that the JCP standardisation process has been heavilly influenced by commercial interests over the years. Politically JDO really has had a hard time:

    http://www.devx.com/Java/Article/20422

    I hope we can agree; the price of standardisation as been an expensive one for JDO (assuming the article by Bruce Tate is an accurate reflection of events).

    If a company adopted say Castor, or another OSS solution back in 1999 or even built and evolved their own simple OO persistence solution on top of JDBC would they be better off than a company that stuck to the J2EE standard?

    I mean EJB1.0, EJB2.0, EJB2.1, JDO1.0, JDO2.0?

    or even: JBDC/DAO, JDO1.0, JDO2.0?

    Personally I think the company that went with the simplest OO thing that could possibly work, would have delivered much more value to the business over the years than the company that stuck to the J2EE standards.

    I also think that their legacy code would be much easier to maintain, and easier to migrate/refactor to a modern OO persistence mechanism like Hibernate, EJB3.0 or JDO2.0 if that is what was needed.

    This is why I think sticking to a poor standard is counter productive. I think standards are a good thing, but we should be standardising proven best practice. We should not be devising political standards that merely satisfy the commercial interests of influencial vendors but do not deliver technically.

    I tend to use the best tool for the Job whether it is a standard or not. If it is truly the best approach normally the standards will catch up. You could end up burnt this way, but given the alternatives I tend to think it is a risk worth taking.

    Paul.
  244. How effective is the JCP?[ Go to top ]

    I tracked down this article on the history of JDO. Makes real interesting reading. I think it confirms my concern that the JCP standardisation process has been heavilly influenced by commercial interests over the years.

    No. I would say it confirms that some persistence JSRs have been heavily influenced by commercial interests over the years. Actually, JDO 2.0 is a good example of the JCP working right - technical excellence won, and it got through. If you want to say something general about the JCP, you will need to do an analysis of the history of hundreds of JSRs.

    I tend to use the best tool for the Job whether it is a standard or not. If it is truly the best approach normally the standards will catch up. You could end up burnt this way, but given the alternatives I tend to think it is a risk worth taking.

    And, unless it is a special case - something that isn't intrusive in my code - like Spring, I really, really don't think it is a risk work taking, as I have been badly burned by this approach several times in the past, and I have learned from my experience.
  245. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,I have recently taken another look at JSF (in response to your support for it), and I must admit it isn't as bad as I first thought. I do need to look into it further, but it still seems over complex in some areas (the view templating for instance).

    Well, that is pluggable (an advantage of JSF) - which allows the use of Facelets - which I (or rather a co-worker) is now doing.
    I will suspend judgement and investigate further.

    Always wise :)
    BTW as far as "component' based (session) web frameworks goes, a close colleague as told me that Wicket very promising and passes the simple test in his opinion.

    It passes that test for me too, and it looks good, but I am a standards nut, so prefer JSF.
    I need to look at the latest work on EJB3.0, but the last time I looked they were using annotations to hide all the ugly EJB2.1 deployment descriptors and remote/local interfaces etc.A component need only be an object (or should I say POJO since that is the fashionable term for it these days). The assumption of distribution is flawed, and if you are wise you will avoid distributing objects 99% of the time.So the real issue for App Servers and EJB's IMO is late binding, not distribution. How do you assemble components written and compiled at different times. In a static language like Java you need a load of meta info that just isn't available in the object byte code, hence the need for EJB descriptors. You also need a late binding dynamic environment where you can assemble your components. Hence the need for an App Server with containers, JNDI, Naming Service, EAR's multiple classloaders etc.In a dynamic language all your objects are automatically components. You get late binding within the language for free (no descriptors) and your App. Server becomes redundant (consumed by the language). This is the main reason why I think dynamic languages will one day dominate enterprise development. Simply because they provide a very simple and compelling component model out of the box.I'm going to try and open my mind to JSF. Think about what I've said about EJB's and we'll catch up when you've got more time.Paul.

    EJB 3.0 is about far more that just hiding the widely-agreed ugliness of EJB 2.x. It uses things like dependency injection, allowing the automatic (late) binding of POJOs.

    As I understand it, many of the valid criticisms you have put forward about EJB 2.x have been looked into and have been address in EJB 3.0.
  246. Agility and Dynamic Languages[ Go to top ]

    Hi Steve,
    I always thought we tended to agree, and perhaps we where just taking a slightly different perspective. I do need to catch up with the lastest in EJB3.0.
    EJB 3.0 is about far more that just hiding the widely-agreed ugliness of EJB 2.x. It uses things like dependency injection, allowing the automatic (late) binding of POJOs.As I understand it, many of the valid criticisms you have put forward about EJB 2.x have been looked into and have been address in EJB 3.0.Yes. I was aware that they had adopted IoC, but I remember that the beans where still in seperate jars and all the EJB2.1 infrastructure to link across jars (local Interfaces, JNDI, Naming Service, containers, classloaders etc) where still bean used under the surface within the IoC bean factory. So an EJB2.1 client could still access an EJB3.0 server in the old way.

    I could be wrong on this so I must check. If I am correct, than it is a vast over complication for the simple non-distributed case. It does have the advantage though of being backward compatible with EJB2.1.

    I'll shut up now and let you get on with the rest of your life. BTW - I understand your view on standards, especially if you have been burnt. Life is full of risks (following the standard as an associated risk too), I guess it just comes down to individual judgement on which risks are woth taking.

    I agree that most companies will tend the make the risk call the way you see things.

    Thanks for taking the time to debate. I appreciate it.

    Regards,

    Paul.
  247. Agility and Dynamic Languages[ Go to top ]

    The original was a formatting nightmare. So hear goes again..

    Hi Steve,
    I always thought we tended to agree, and perhaps we where just taking a slightly different perspective. I do need to catch up with the lastest in EJB3.0.
    EJB 3.0 is about far more that just hiding the widely-agreed ugliness of EJB 2.x. It uses things like dependency injection, allowing the automatic (late) binding of POJOs.As I understand it, many of the valid criticisms you have put forward about EJB 2.x have been looked into and have been address in EJB 3.0.

    Yes. I was aware that they had adopted IoC, but I remember that the beans where still in seperate jars and all the EJB2.1 infrastructure to link across jars (local Interfaces, JNDI, Naming Service, containers, classloaders etc) where still bean used under the surface within the IoC bean factory. So an EJB2.1 client could still access an EJB3.0 server in the old way.

    I could be wrong on this so I must check. If I am correct, than it is a vast over complication for the simple non-distributed case. It does have the advantage though of being backward compatible with EJB2.1.

    I'll shut up now and let you get on with the rest of your life. BTW - I understand your view on standards, especially if you have been burnt. Life is full of risks (following the standard as an associated risk too), I guess it just comes down to individual judgement on which risks are worth taking.I agree that most companies will tend the make the risk call the way you see things.

    Thanks for taking the time to debate. I appreciate it.

    Regards,

    Paul.
  248. Agility and Dynamic Languages[ Go to top ]

    I agree that most companies will tend the make the risk call the way you see things.Thanks for taking the time to debate. I appreciate it.Regards,Paul.

    No problem.
  249. Agile Employment ?[ Go to top ]

    there is a reason why many companies are chosing to outsource software development to India. To me it is a desperate attempt to get value for money from their IT investments.

    Is this related by any mean to Agile methodologies ? Are Indian folks more Agile than us when it comes to programming ? Because of the Yoga maybe ? ;-P

    I would have imagined it was not the question about what they do, but for how much.
    I would have imagined firms outsource the developments 'cause an idian guy is cheaper than a US or European one.
    I would have imagined the methodological and technical choices were still the client's responsability (the client beind a US or European firm).

    BTW, not only IT is outsourced...
    IMO this is an indictment on the software industry, and Java/J2EE, .NET along with C++/CORBA in the past must all take their fair share of responsibility for this situation.

    The manager :
    "The project has failed because of CORBA : we outsource everything !"

    Do you think this is realistic ?
     
    I also believe that OSS is proving to be a great tool in focusing development effort on the real issues facing our customers rather than using our best brains to expend intellectual effort on the commerical priorities of software vendors.

    For this I agree, but once again, what's the link with Agile or Not Agile and outsourcing ???

    Cheers

    Remi
  250. Agile Employment ?[ Go to top ]

    Hi Remi,

    You make some sound and interesting points. If we were having a dialogue face to face it would be easier to explain what I mean. But as it is all we can do is exchange monologues, so I'll try my best.
    there is a reason why many companies are chosing to outsource software development to India. To me it is a desperate attempt to get value for money from their IT investments.
    Is this related by any mean to Agile methodologies ? Are Indian folks more Agile than us when it comes to programming ? Because of the Yoga maybe ? ;-PI would have imagined it was not the question about what they do, but for how much. I would have imagined firms outsource the developments 'cause an idian guy is cheaper than a US or European one.I would have imagined the methodological and technical choices were still the client's responsability (the client beind a US or European firm).BTW, not only IT is outsourced...
    For businesses the issue is price (upfront costs). If they paused though they would realise that the real issue is value. So you get a lot of cheap software (I'm using the term cheap here relatively. Bespoke software is never cheap), but it arrives a year later than when you really needed it, and your business has changed and it doesn't really offer any value today, and the users can't stand using it etc...

    What do you do? Start all over again, or live with it? Either choice could prove pretty expensive.

    I'm not saying that Indians can't do Agile, but one of the main prerequisites for Agile development is close communication with the customer. That is a tall task when your customer is thousands of miles away (despite what Agile Consultancies like ThoughtWorks may say).
    IMO this is an indictment on the software industry, and Java/J2EE, .NET along with C++/CORBA in the past must all take their fair share of responsibility for this situation.
    The manager :"The project has failed because of CORBA : we outsource everything !"Do you think this is realistic ?&nbsp;I don't think the conversation would go something exactly like that :^) But if you just been fleeced by a load of IBM consultants (or BEA or Oracle) at $2000 a day to fix Y2K bugs that didn't exist, you may be a bit taintative the next time they turn up with their new bang whiz all singing all dancing App. Server promising that SOA will solve all your problems. You may say OK I need an App. Server and apparently I need SOA, but I can read a spreadsheet as good as anyone else, and Indian Consultants at $100 a day means massive savings over IBM consultants at $2000.
    I also believe that OSS is proving to be a great tool in focusing development effort on the real issues facing our customers rather than using our best brains to expend intellectual effort on the commerical priorities of software vendors.
    For this I agree, but once again, what's the link with Agile or Not Agile and outsourcing ???CheersRemi
    OK, the link. Agile people tend to take a different spin on how to develop software than the mainstream. The vendor community hasn't really tapped into this yet, so if you're not doing big upfront design and you want to test everything that could possibly break, there sin't many vendor tools out there to support you. So what the Agile community has done is to write the tools they need themselves. Examples of this are XUnit, XMock, Watir, Fitnesses, Cruise Control(.NET) etc. Other OSS tools that I also consider Agile are (N)Hibernate, Webwork, PicoContainer, Spring(.NET), although it could be argued that these last group of tools are valued by non Agile people too.

    Incidently much of this "Agile" OSS tool set is cross platform and cross language. I'm not a C Sharp and .Net developer, but I take it on good advice that you can do Agile development in C Sharp just as well as with Java using pretty much the same Agile toolset.

    Paul.
  251. Agile Employment ?[ Go to top ]

    I still don't see no link between outsourcing and agile technologies. IMHO, Indians develop exactly like us and have nothing to envy to Euro or US folks. The only problem I see is distance between actors... which is definitly a problem, in many domains.

    Mmmmh, shall we outsource the customer then ? This would be pretty practical :
    "Dear customer, here's your ticket for the plane to bombay. You understand, it's important you're close to the development team, that's Agile you know, your software will be far better ! Moreover you'll get a lot of miles, with all these iterations !! No no, don't thank me..."

    :-)

    Cheers

    Remi
  252. Agile Employment ?[ Go to top ]

    I still don't see no link between outsourcing and agile technologies. IMHO, Indians develop exactly like us and have nothing to envy to Euro or US folks. The only problem I see is distance between actors... which is definitly a problem, in many domains.Mmmmh, shall we outsource the customer then ? This would be pretty practical :"Dear customer, here's your ticket for the plane to bombay. You understand, it's important you're close to the development team, that's Agile you know, your software will be far better ! Moreover you'll get a lot of miles, with all these iterations !! No no, don't thank me...":-)CheersRemi
    Our customer is just up the road, and to get him down to see us more than once every other week is hard enough as it is.

    If the Indians pull this one off then they deserve the business :^)

    Paul.
  253. Agile Employment ?[ Go to top ]

    Hi Remi,

    I think I only answered on of your questions in part. So I'm going to have another go:
    The manager :"The project has failed because of CORBA : we outsource everything !"Do you think this is realistic ?&amp;nbsp;
    I don't think the conversation would go something exactly like that :^) But if you just been fleeced by a load of IBM consultants (or BEA or Oracle) at $2000 a day to fix Y2K bugs that didn't exist, you may be a bit taintative the next time they turn up with their new bang whiz all singing all dancing App. Server promising that SOA will solve all your problems. You may say OK I need an App. Server and apparently I need SOA, but I can read a spreadsheet as good as anyone else, and Indian Consultants at $100 a day means massive savings over IBM consultants at $2000.

    The bit I missed is that middleware technologies like CORBA and App. Server and .NET have been mightily oversold by vendors. They are useful in some circumstances but are not always.

    I've worked on several J2EE projects when the decision to use BEA Weblogic was made way up front even before the requirements were clear on the advice of a BEA salesman. One one such project they used a french consultancy (I and some other indpendents were brought in to rescue things when it had all gone pear shaped). This french consultancy won the project on the basis that it had a J2EE framework that could be used to do rapid J2EE development.

    The framework consisted of wrappers around JNDI, EJB's, Datasources etc which enforced the J2EE Core Design Patterns (J2EE Blueprints). So all business logic was within EJB's. We used local references within the business tier, we used remote references to the web tier. Fortunately the client had a load of stored procedures in the database, so we accessed them using DAO's and were saved from having to use Entity beans.

    After wasting over 18 months, we finally convinced the client to strip all this stuff out, replacing it with a web container (still weblogic) and PicoContainer. Productivity increased dramatically.

    So who does all this technology serve? BEA did pretty well out of it. So did the french consultancy. The client didn't get much for his money though. This type of situation is common place in our industry. My view for a long while is that this type of carry on is unsustainable and there is bound to be a back lash. I think the move by some companies to outsource everything to India is part of that backlash.

    Paul.
  254. Support nightmare[ Go to top ]

    For Agile development using the latest software development ideas,
    Sorry, this is just false.
    Hi Steve,I think you're just plain wrong on this one. I know little about JDO, but many of the new OSS Java tools where inspired at least in part as an attempt to make Java development more Agile.

    If you find out about JDO you will see that there were varied reasons for its development.
    What killed EJB2.1 for me is that EJB's were very difficult to test.


    Yes, but you were talking about the Java language in general.
    There as been a long discussion on TSS about Refactoring and dynamic vs static before. I won't go into it again, but the real point about refactoring, is being able to do a little and change and evolve the code in response to real tests. Productivity using something like Seaside, Smalltalk and The Refactoring Browser trumps Eclipse and Tomcat.

    No, it really doesn't. With many Java technologies (JSP) you can change things in-place in running apps just like any dynamic language, secondly, I can re-deploy my Java apps on Tomcat with changes in seconds.

    Secondly, if you are going to criticise a language in general, stop picking on highly specific technologies. I can, for example, make changes in a Swing application on NetBeans and get very fast response to the results.

    If you want to argue about legacy J2EE, argue about that, but you can't use that to discuss Java in general.
    Even with Ruby with minimal IDE support, people are saying that manual refactors are actually quicker than using Eclipse and starting and stoping tomcat to perform tests.

    They can say what they like, but as this generally comes from supporters of the languages, I am not surprised.
    Firstly, manual refactors simply aren't faster than using Eclipse - that is plain nonsense, as manual refactoring involved using some form of text editor, to search and replace, Eclipse involves a few menu selections. Secondly,
    anyone with experience would know that you don't have to start and stop tomcat to re-deploy or restart applications to perform tests.
    In XP/Agile development there are three steps to the programming cycle:TEST, CODE, REFACTOR - this cycle needs to be as fast as possible. If you stand back and look at the bigger picture you will see that often Java is just not Agile in this regard (imagine having to start and stop your App. Server before each test).

    Firstly, you don't need to start and stop your app server. Secondly, if you are generalising to the whole language, you need to stop talking about app servers, and thirdly, there are two parts of that cycle where Java wins hugely - test and refactor. Test, because it can often perform tests (which can be extensive on large apps) an order of magnitude faster than many dynamic languages, and refactor because almost any refactoring is only a menu item away against the primitive use of 'manual refactoring'.
    There are split views out there. It really depends on your perspective. From much of what you've written above, I can see that your exposure to Agile development and Agile ideas is limited.

    You can't tell about my exposure to agile development and agile ideas. You are wrong about it, and to claim that because someone disagrees with you they must be ignorant or inexperienced is not the best way to put forward an argument, I would suggest.

    However, I am going to fall into the same trap! Please learn about modern Java APIs before commenting. There is a lot about approaches like JDO that show that Java is ahead of the pack in my view, and Rails seems primitive to me.
    Agility has little to do with flash tools like JSF. Agile developers have specific concerns like doing thing "once and once only" (the Ruby guys call this DRY) to minimise the code base and refactoring/maintenance costs.

    JSF is not a flash tool. It can be used with flash tools for high-speed design. JSF can be as DRY as Ruby (see Seam).
    Incidently the key mechanism for this is pure OO design rather than procedural programming.

    JSF is OO design. See Seam.
    There are many OO concepts that cannot be implemented in Java (e.g closures) so Java developers are at an immediate disadvantage when it comes to DRY and true OO programming.

    No, these are not connected. Java is a true OO language, and DRY has nothing to do with closures etc.
    The other key issue for Agility is testablity. How will you unit test your JSF controllers and views?

    Yes, testing JSF controllers and views is an issue. However, unlike backward-looking frameworks like Rails, modern approaches are to avoid putting logic in views in the style of PHP or JSP. The logic should be in POJOs which can be easily tested out-of-container.
    Key to Agile too is automation. How do you automate unit and user acceptance tests that are tied to containers?

    They aren't tied to containers. In JSF you develop your logic as POJOs. This logic can be tested out of containers.
    You will need to run your tests all the time.

    Why?
    The Agile community are not waiting on vendors.

    What is this obsession with vendors? What is this 'Agile community?'. You do realise that some of the most agile development is done in commercial Smalltalk?
    They are busy producing OSS tools to solve their own problems.

    Like Eclipse?
    The search for better Agile tools are leading many Agile practioners to dynamic languages like Ruby.Paul.

    And the search for better tools is leading an increasing number of developers to Eclipse. And there are many Agile practicioners who work in Java.

    So what?
  255. Support nightmare[ Go to top ]

    We were told that we needed to use almost everything in J2EE even for a simple PetStore application.

    We were? When? As I remember, such applications were simply a demonstration of all the facilities of J2EE. Just because things were in a demonstration does not mean that you always need to use them all.
    What if you don't want or don't need most of this stuff? You just need a lightweight framework, what options do you have other than open source?It doesn't sound to me that Developers are in control of the JCP. These decisions sound as though they are there to serve the interests of vendors, helping them hold on to existing clients with encumbant App Servers.I could be wrong, but time will tell. In the end people will vote with their feet.Paul.

    Woah! Big leap there, and unjustfied in my opinion. You are making all sorts of connections between lightweight, open source and non-JCP that don't seen to stand up to even the simplest analysis in my view.

    Let's look at some recent JCP reference implementations: the JSF RI is open source. The RI for JDO 2.0 is open source. As for J2EE, the RI for JSP/Servlets is, of course, open source. I'm sure there are plenty more!

    As for the so-called vendor-driven nature of the JCP, well take a look at EJB 3.0 - strongly influenced by Hibernate!

    As for lightweight - a few years back, while many open source organisations were implementing the heavier features of EJBs, I was using a much lighter closed source solutions - JDO 1.x implementations.

    So, we have clear examples of non-vendor-driven JCP specs, JCP specs with open source RIs that allow developers all the freedom they want, and lightweight vendor solutions contrasting with heavyweight open source alternatives.

    Sorry, but I really do think you are hugely over-simplifying things.
  256. Support nightmare[ Go to top ]

    We were told that we needed to use almost everything in J2EE even for a simple PetStore application.
    We were? When? As I remember, such applications were simply a demonstration of all the facilities of J2EE. Just because things were in a demonstration does not mean that you always need to use them all.
    What if you don't want or don't need most of this stuff? You just need a lightweight framework, what options do you have other than open source?It doesn't sound to me that Developers are in control of the JCP. These decisions sound as though they are there to serve the interests of vendors, helping them hold on to existing clients with encumbant App Servers.I could be wrong, but time will tell. In the end people will vote with their feet.Paul.
    Woah! Big leap there, and unjustfied in my opinion. You are making all sorts of connections between lightweight, open source and non-JCP that don't seen to stand up to even the simplest analysis in my view.Let's look at some recent JCP reference implementations: the JSF RI is open source. The RI for JDO 2.0 is open source. As for J2EE, the RI for JSP/Servlets is, of course, open source. I'm sure there are plenty more!As for the so-called vendor-driven nature of the JCP, well take a look at EJB 3.0 - strongly influenced by Hibernate!As for lightweight - a few years back, while many open source organisations were implementing the heavier features of EJBs, I was using a much lighter closed source solutions - JDO 1.x implementations.So, we have clear examples of non-vendor-driven JCP specs, JCP specs with open source RIs that allow developers all the freedom they want, and lightweight vendor solutions contrasting with heavyweight open source alternatives.Sorry, but I really do think you are hugely over-simplifying things.

    Totally, agree. The only thing we can say is spec standardises innovations while OSS mostly and some proprietary solutions seem to drive the innovations.

    So you want the latest top-notch features, well cool there are a lot of choices out there. You boss doesn't want your company to depends on a custom solution supported by a community, standard specs are there and were inspired by the best products on the market.

    In the end, it all come to one thing : lastest innovations vs uncertainty and it depends of your employer and corporation nature. So why complain about standards ? It just give more credibility to creative new projects.
  257. Support nightmare[ Go to top ]

    We were told that we needed to use almost everything in J2EE even for a simple PetStore application.
    We were? When? As I remember, such applications were simply a demonstration of all the facilities of J2EE. Just because things were in a demonstration does not mean that you always need to use them all.

    Well, Sun's early J2EE blueprints did show the complete stack. It was really a disservice to the community in a lot of ways.
  258. Support nightmare[ Go to top ]

    Well, Sun's early J2EE blueprints did show the complete stack. It was really a disservice to the community in a lot of ways.

    Erf, would you release a technology and only show how to use half of it ?
    Of course Sun has given recommendations for every bit of the whole stack. Then, Architects picked what they need in there.

    I don't think it's a disservice to the community. Especially Sun's blueprints which are very helpful for someone that does not understand regular architectural patterns.

    They never told you to use everything. They just told you how to do so.

    Have fun,

    Remi
  259. Hell... really ?[ Go to top ]

    time will tell with EJB3, but I can tell you that EJB2.x applications were not that portable between containers.

    Of course nothing is perfect at first sight. CORBA suffered the same painful beginnings for example, but now it's been widely accepted by those who needed such technology.

    Same goes for every "new" technology.

    I was just talking about general facts, not examples.
    It took us about a year to get the whole thing ironed out. On the other hand, with Pico / Spring / Hibernate / WebWork / etc.

    Sorry dude, you won't make me thing Hibernate/Spring/etc. 's more portable than entity beans. I would fully agree it's far more usable and powerful, but EJBs are *by essence* portable, that's in the definition you know... whereas Hibernate is *one* vendor's solution, like it or not.
     you can just drop the jar file in your app and it works the same across app servers.

    Come on, I was talking about portable component models, portability across execution platforms, not across one single vendor's libraries (OSS or not).
    Sure, java bytecode is portable, thanks for the info !
    Surely you're joking? Do you really think you can drop an app from Oracle to PostgreSQL, or vice versa, with no changes?

    Well far easier than from "my-own-proprietary-data-structures" to "my-other-proprietary-data-structures".
    The most representative example for a Java programmer being JDBC.
    I see this as an obvious fact. Don't you (once again I don't talk about a particular example but about general principles) ???
    Sure it does. Can you blame them?

    Yes, of course. Because some non-gratis and non-free solutions sometimes make you save money (and finally gets the end customer satisfied) where you could spend a lot by adopting a 100% gratis stuff. Paradoxical, but definitly true IMHO. I've experienced this many times and once again, I see this as an obvious fact. Don't you ?
    Free licensing is cheaper than not free, once you learn how to manage and operate your environment.

    I precisely told you that the problem IS they don't have another clue about it than the price !
    And also, "managing and operating your environment has a cost"... which can be far higher than just buying something packaged. This was what I meant.

    I hope I've been more clear this time !

    Cheers

    Remi
  260. Hell... really ?[ Go to top ]

    time will tell with EJB3, but I can tell you that EJB2.x applications were not that portable between containers.
    Of course nothing is perfect at first sight. CORBA suffered the same painful beginnings for example, but now it's been widely accepted by those who needed such technology.Same goes for every "new" technology.I was just talking about general facts, not examples.

    By what yardstick would you measure CORBA to be "widely accepted"?
    It took us about a year to get the whole thing ironed out. On the other hand, with Pico / Spring / Hibernate / WebWork / etc.
    Sorry dude, you won't make me thing Hibernate/Spring/etc. 's more portable than entity beans. I would fully agree it's far more usable and powerful, but EJBs are *by essence* portable, that's in the definition you know... whereas Hibernate is *one* vendor's solution, like it or not.

    It depends on what you're talking about porting across. If you're talking about porting across persistence implementations, then sure. If you're talking about porting across deployment environments / application servers, then Hibernate and Spring are DEFINITELY more portable, since it's the same implementation in either app server.
    &nbsp;you can just drop the jar file in your app and it works the same across app servers.
    Come on, I was talking about portable component models, portability across execution platforms, not across one single vendor's libraries (OSS or not). Sure, java bytecode is portable, thanks for the info !

    Hey, thanks for the sarcasm! What I think you're missing is that if you want to port between deployment platforms and application servers, the less you use their implementations and can bring the implementation along with you. The most compatible server services are exactly those that are the simplest, for example Servlets, whereas more complicated and under-specified specs are much less portable, for example JMS. Entity beans are another example, where features needed to really make them work aren't part of the spec.

    If your app sticks to only using Servlets, JTA, and possibly JNDI from the app server, (especially if you use a really nice web framework to handle the little differences in Servlet containers) then you'll have a pretty easy time porting between servers.

    Again, this is EJB2.x. Time will tell how well EJB3 locks down the specifics so that different implementations have to behave the same.

    Sure it does. Can you blame them?
    Yes, of course. Because some non-gratis and non-free solutions sometimes make you save money (and finally gets the end customer satisfied) where you could spend a lot by adopting a 100% gratis stuff. Paradoxical, but definitly true IMHO. I've experienced this many times and once again, I see this as an obvious fact. Don't you ?

    Sure, there are commercial vendors who provide a lot of value, and I definitely agree that where they provide more value than they cost, it's a no-brainer to pay up. Assuming you can get management to spend the $$$.
    Free licensing is cheaper than not free, once you learn how to manage and operate your environment.
    I precisely told you that the problem IS they don't have another clue about it than the price ! And also, "managing and operating your environment has a cost"... which can be far higher than just buying something packaged. This was what I meant.I hope I've been more clear this time !CheersRemi

    Sure, people who are clueless end up spending more time and money than they should. Yes, managing and operating your environment is expensive in time and money. The key point is to minimize the incremental cost of scaling your environment. This includes using open source infrastructure where possible, but also in automating and simplifying as much and as many of your administrative and operational processes as possible. Remember, "a penny saved is a penny earned".
  261. Hell... really ?[ Go to top ]

    By what yardstick would you measure CORBA to be "widely accepted"?

    It's not because you don't use it that other's don't too...
    CORBA is the foundation of many Telco software. And yes, people who need a real middleware just go for this one since... there's no other choice !
    BTW, your JDK includes an ORB, every AppServer supports CORBA, and to be in the thread's initial context, talking about JTA and 2PC... ever heard of OTS ?
    It depends on what you're talking about porting across.

    Portability is a simple concept : you take the code as is and it runs in another environment with no modifications (or almost).
    Aren't we f*cking flies once again here ?
     If you're talking about porting across persistence implementations, then sure.

    I'm talking about portability across execution platforms. And Hibernate/Spring, IMHO, are good examples.

    Try replacing Hibernate with another ORM in your apps and tell me if it was so easy.
    Damnit, throwing all these mapping files and Spring descriptors (not to mention using hibernate or spring specific interceptors etc. !) away to rewrite it with another syntax can't be easier than moving an ejb-jar from a container to the other.
    Sorry mate, I cant believe this. And honestly I don't think you do either.
     If you're talking about porting across deployment environments / application servers, then Hibernate and Spring are DEFINITELY more portable, since it's the same implementation in either app server.

    Great.
    Intra-vendor portability inside one single framework.
    It rocks dude !
    Great idea :)
    Hey, thanks for the sarcasm!

    The worst is I wasn't even really sarcastic : read what you say, you really talk about bytecode portability again :
    "it's the same implementation in either app server"
    !
    What I think you're missing is that if you want to port between deployment platforms and application servers, the less you use their implementations and can bring the implementation along with you.

    I don't know a company that can afford to develop an ORM 'cause there are 2 or 3 features in Entity beans that aren't portable, or because you have to change one line or two in the DD...
    The other way to go is to get some OSS components (e.g. Hibernate) to do the job.
    But, and don't get me wrong I really love Hibernate and I think it's one of the biggest step forward in a few years when it comes to productivity, when you start using it you really get bound to it very quick.

    I mean, I have no problems being locked in Hibernate since the tool is great, and open (I could maintain it by myself, in theory). But at least I know it !
    Time will tell how well EJB3 locks down the specifics so that different implementations have to behave the same

    Well, once again, and here I fully agree with you, nothing's perfect at first shot. But the goal of a spec is to allow people to be vendor-independant.

    I remember the painful times of CORBA, where two different ORBs would not communicate even on basic stuff... and now it's quite stable, almost everything works fine (and CORBA's definitions of "portable" are far more advanced than anything else I've seen in the middleware arena).

    I'm sure that J2EE's component models in general have also reached a higher and higher level of interop. and portability, with increased usability and functionality.

    Hey, after all, J2EE's just a baby, she's too young to be perfect... Experience matters :-)

    Cheers

    Remi
  262. Hell... really ?[ Go to top ]

    It's not because you don't use it that other's don't too...CORBA is the foundation of many Telco software. And yes, people who need a real middleware just go for this one since... there's no other choice !BTW, your JDK includes an ORB, every AppServer supports CORBA, and to be in the thread's initial context, talking about JTA and 2PC... ever heard of OTS ?

    Hmm.. could be. I don't build Telco software, but I'm guessing NEW systems aren't being built on it. Everyone I know who built on CORBA has either replaced it or gone out of business.

    Yes, I know OTS. I'd be willing to bet that the copy of it called "JTS" is used a lot more frequently though.
    Portability is a simple concept : you take the code as is and it runs in another environment with no modifications (or almost). Aren't we f*cking flies once again here ?

    Apparently not, because your definition of an environment differs from mine. My application bundles Spring and Hibernate in the application archive. They are PART of my application, not part of the environment. The environment, to me, includes the operating system, JDK, and Servlet Container / App Server.
    I'm talking about portability across execution platforms. And Hibernate/Spring, IMHO, are good examples.Try replacing Hibernate with another ORM in your apps and tell me if it was so easy. Damnit, throwing all these mapping files and Spring descriptors (not to mention using hibernate or spring specific interceptors etc. !) away to rewrite it with another syntax can't be easier than moving an ejb-jar from a container to the other.Sorry mate, I cant believe this. And honestly I don't think you do either.

    I'm not talking about replacing Hibernate or Spring. I'm talking about moving from one app server to another. In your case you have to figure out how to do the non-standard things you did with WebLogic's EJB implementation with corresponding non-standard things in WebSphere.

    At the end of the day we're trying to solve a problem, right? If Hibernate solves the problem for me, why do I need to replace it? Just because business requirements change and I'm forced to change app servers? In your case you're in for a world of pain (I've been there). In my case, my persistence implementation is exactly the same.

    Oh, and BTW, the standards you keep touting? They're moving the same way. You can already plug in different JMS providers to an app server using JCA, and you can plug Hibernate in as a JCA provider. I'm betting you'll be able to bring your JPA provider along with you when you have to move to a new app server in the future.

    <ockquote>The worst is I wasn't even really sarcastic : read what you say, you really talk about bytecode portability again :"it's the same implementation in either app server"!
    What I'm talking about is my same application archive being able to be dropped into different application servers and just work. You, for some reason, are focusing on API portability and calling that an "execution platform".
    I don't know a company that can afford to develop an ORM 'cause there are 2 or 3 features in Entity beans that aren't portable, or because you have to change one line or two in the DD...The other way to go is to get some OSS components (e.g. Hibernate) to do the job. But, and don't get me wrong I really love Hibernate and I think it's one of the biggest step forward in a few years when it comes to productivity, when you start using it you really get bound to it very quick.I mean, I have no problems being locked in Hibernate since the tool is great, and open (I could maintain it by myself, in theory). But at least I know it !

    Well, there's some amount of truth to that, but we minimize this by coding to interfaces and putting Hibernate-specific implementations behind them.
    Well, once again, and here I fully agree with you, nothing's perfect at first shot. But the goal of a spec is to allow people to be vendor-independant.I remember the painful times of CORBA, where two different ORBs would not communicate even on basic stuff... and now it's quite stable, almost everything works fine (and CORBA's definitions of "portable" are far more advanced than anything else I've seen in the middleware arena).I'm sure that J2EE's component models in general have also reached a higher and higher level of interop. and portability, with increased usability and functionality. Hey, after all, J2EE's just a baby, she's too young to be perfect... Experience matters :-)CheersRemi

    Not a baby really... It's past the point where it's changing every six months now. I think maybe with EJB3 it's going through a big change... puberty?
  263. Hmm.. could be. I don't build Telco software, but I'm guessing NEW systems aren't being built on it.

    Well, I wouldn't bet on this.
    You know, there's a strong focus on a particular kind of applications, here on TSS.
    We almost all use J2EE here, cause it's the most appropriate solution for building "regular" transactional webapps, which is the type of applications we develop.
    We rarely talk about GRID for example, even if, IMHO, is could drastically change the way we architecture applications...
    Just check the thread's subject, that's pretty revelatory : a big percentage of Java apps don't need the whole J2EE stack, including JMS !
    Well referring to CORBA I'd say that "98% of regular applications developers just don't need it".
    What kind of applications do the people you know usually build ? I would bet that it's not real-time monitoring of some sensors embedded in a plane, or military combat simulations, or other exotic stuff... :-)

    I think you have this perception that CORBA is abandoned because you precisely don't need what it can offer you.
    You actually find it more simple to do everything in Java (which of course makes the need for real interop pretty useless), and you probably break a few OO principles from one time to another (e.g. using EJBs and/or WebServices) because it's actually more convenient.
    Your "neighborhood" probably also obeys the same rules, which makes you think CORBA is the past.
    This is not everyone's situation.
    Some have legacy code to interact with, and need the full power of CORBA. These ones are glad it exists !

    Get my point ?
    Yes, I know OTS. I'd be willing to bet that the copy of it called "JTS" is used a lot more frequently though.

    I think you are right, and IMHO the reasons are the ones I gave you above.
    It's just a question of market shares : "regular" webapps represent an outrageous majority in the software development market, so of course the technologies are more popular (at least you've heard about it).
    But it never means that other stuff is dead. It's just that you don't even know it's used, cause it's not your domain.
    Apparently not, because your definition of an environment differs from mine. My application bundles Spring and Hibernate in the application archive. They are PART of my application, not part of the environment. The environment, to me, includes the operating system, JDK, and Servlet Container / App Server.

    Interesting ! This looks like a useless discussion but still I like it :-)

    To me, an execution environment is everything you need to get your program running.
    I get your point, and I would expect you to ask me :
    "OK then you consider that all libs that you depend on are part of the execution environment ? Is log4j part of the execution environment for example ?"
    Mmmmmh, that's a good question Jason, for sure ! :-)
    Actually I'm not sure about what I'd answer !

    But when it comes to Hibernate for example I clearly see it as part of the programming/execution environment. I mean, the ORM is (more or less) supposed to replace CMP isn't it ?
    At run-time, you rely on it just like you'd rely on the container.
    Same goes for Spring of course. They (Interface21) call it a "lightweight container" after all !
    I'm not talking about replacing Hibernate or Spring. I'm talking about moving from one app server to another.

    Well, we were talking about migration issues.
    And wether Hibernate or Spring are part of the execution environment or not has nothing to do with this.

    Remember, my point was that standards ensure vendor independance, not OSS.
    In your case you have to figure out how to do the non-standard things you did with WebLogic's EJB implementation with corresponding non-standard things in WebSphere.

    Well, that's out of scope, since a standard is supposed to be followed, by definition.
    It's your problem if you use proprietary features in a component that is supposed to implement a standard.
    Once again, CORBA has suffered a lot of this in the past, but we've seen the improvements through the years, and now all the basic issues that, believe it or not, are exactly the ones EJBs have faced in their early beginnings, have been solved.
    Even Java (before it was called "SE") has gone through the same issues at its early beginnings. It's something every new technology has to pass through.
    At the end of the day we're trying to solve a problem,
    right?

    Fully agreed. And don't get me wrong : it's even hard for me to take time to look at EJB3 ! I just love Hibernate, and I must admin I don't see how you can do better, except through a real OO database (but this stills look like a dream or I don't know it).

    Anyway, standards are great when they allow you to save time and build better software, on this I fully agree with you.
    Nobody forces you to use them if you have a better option and you can afford to use it.
     If Hibernate solves the problem for me, why do I need to replace it?

    You don't, if you are sure that you can afford maintaining it in case it stops.
    This is actually one of the major concerns in OSS.
    What when an OSS project dies ?
    Can you afford to maintain all this yourself instead of focusing on your own business problematics ?
    Oh, and BTW, the standards you keep touting? They're moving the same way. You can already plug in different JMS providers to an app server using JCA, and you can plug Hibernate in as a JCA provider. I'm betting you'll be able to bring your JPA provider along with you when you have to move to a new app server in the future.

    Then, as someone who trusts in standards and common efforts in general, I'm a happy person :-)
    What I'm talking about is my same application archive being able to be dropped into different application servers and just work. You, for some reason, are focusing on API portability and calling that an "execution platform".

    That was the subject of my post (portability of applications thanks to standard specs).

    If I tro to follow your reasoning and exagerate it a bit : why do you even use app servers ?
    Why don't you embed everything in your JAR (including the execution platform, sorry to insist on this) ? This way you don't care about the freakin' JCP, unstable specs, evil vendors that modify standard APIs...
    A good old main() and we're done.
    :-P
    Well, there's some amount of truth to that, but we minimize this by coding to interfaces and putting Hibernate-specific implementations behind them.

    You could do this with EJBs as well don't you ?

    Another level of indirection is not a real remedy for such a big concern. You still have ONE single option when it comes to persistence. If Hibernate dies you're in trouble (and we'll be a lot in this situation I'm afraid). If you have old JDBC or entity beans, you don't have this problem. You still have other options.
    Not a baby really... It's past the point where it's changing every six months now. I think maybe with EJB3 it's going through a big change... puberty?

    I love it :-)

    Have fun,

    Remi
  264. I just love Hibernate, and I must admin I don't see how you can do better...

    I admit many of the following points are hotly debated, but my view is that you can do better than Hibernate. You can have finer control of what parts of an object are retrieved (fetch groups and plans), rather than expressing explicitly what is retrieved in a query language, to give a more OOP way of working. You can have finer control of object states in order to help with tuning use of high-volume transactions and batch use. You could have the ability to persist to more than just relational stores - a general purpose object persistence mechanism.

    It is called JDO.
  265. Remember, my point was that standards ensure vendor independance, not OSS.
    This is not always true. It depends on the amount of proprietary code vendors want you to use to lock in.
    Or the hurry EG has to come out with a spec.
    Try to think to server side of web services and compare to
    CORBA server side.
    It is possible to build a complete load balancer with
    standard CORBA features while it is almost impossible to get
    the name of the target operation from a jaxrpc MessageContext in a portable way.
    And try to think at SAX.
    I just love Hibernate, and I must admin I don't see how you can do better, except through a real OO database (but this stills look like a dream or I don't know it).
    Steve already replied: JDO.
    I would just bring an experience on portability of a little application (a timecard).
    It has been developed using Kodo JDO on HSQL and I have used also on MySQL and Oracle with, obviously, no change.
    Then I moved to Versant Open Access on HSQL and at the end I switched to objectdb. Neither a line of code was change.
    Ah, I forget. I have also used the same (simple) report with JasperReport with plain JDBC or full JDO.
    I already posted somewhere about this scenario, in case you must use a RDBMS: use objectdb (or any other JDO implementation requiring no mapping info) to develop your application and defer to later time (or different team) your OR mapping.
    This is impossible with JPA/Hibernate/EJB3.


    Guido
  266. <blockquoteThis is not always true. It depends on the amount of proprietary code vendors want you to use to lock in.
    Of course... But as I already said, you're supposed to stay in the standard, not to find deviated paths !
    If the standard does not allow you to do what it's supposed to do then yes, it's bad or incomplete.
    Or the hurry EG has to come out with a spec.

    Yep. Funny, everybody always said the OMG was too freakin' slow in releasing specs. I always thought that I prefer to wait a bit and have something reliable than to go through youth mistakes !
    Try to think to server side of web services and compare toCORBA server side.

    Erf. I may try hard, I can't figure out where you can compare both...
    But no worries, I fully get your point ;-P
    Steve already replied: JDO.

    So few time, so many things to learn... I don't know anything about this one, but for sure, you're tempting me guys ! I'll give it a try (I think my girlfriend's gonna get mad with me and my f*ckin' computers !!).
    I would just bring an experience on portability of a little application (a timecard).It has been developed using Kodo JDO on HSQL and I have used also on MySQL and Oracle with, obviously, no change.

    Well, Hibernate would have been equivalent here doesn't it ?
    I mean, all of these are RDBMS, so you only have to change the driver & dialect and you're done.
    Also, and you said it, it's a small app. Some folks out here could tell you the example does not stand, since you have no stored procs in there ;-P
    Then I moved to Versant Open Access on HSQL and at the end I switched to objectdb. Neither a line of code was change.

    Hmmm, this reveals a far more powerful persistence mechanism, for sure, HB is limited to Relational DBs...
    objectdb (or any other JDO implementation requiring no mapping info) to develop your application and defer to later time (or different team) your OR mapping.

    ...and it could help me to jump over the gap of OODBMS in the same time...
    Definitly interesting, to say the least ! I have to check this out !

    Have fun,

    Remi - "Why don't you marry that damn stupid computer ??? Apparently you love it more than me !" (c) my girl
  267. Hell... really ?[ Go to top ]

    The fact that SQL is the standard guarantees portability ands easy replacement.

    SQL is not a standard. It is many standards, none of which is fully implemented by any vendor as far as I know.

    As one of my current (long-term) projects is the port of a substantial legacy database system using its own dialect of SQL to a more modern system, I would strongly dispute that use of SQL guarantees portability. In fact, this is why for my part of the project I have virtually abandoned SQL altogether and am using JDO/JDOQL instead.
    Also, and it's pretty sad, but I really think what pushes OSS the most is the "free as in beer" side of the stuff.

    I agree, but I don't think it is sad. This "free" aspect has meant that countless users and companies have been able to install high-quality software with minimal cost.
    Really ? Feck, I did not know EJBs were dead.

    Indeed.
  268. Hell... really ?[ Go to top ]

    SQL is not a standard. It is many standards, none of which is fully implemented by any vendor as far as I know.

    Come on guys, please stop "fucking the flies" (a French expression) !

    Yes, you're right, porting an application into a new environment has never been an easy and straightforward task.

    But do you really think what tends to come out your writings ? I mean, do you really think the industry (IT included) does not need common standards to rely on ???
    Do you really think industrials are ready to switch from Hibernate to I-don't-know what each year 'cause it's new and it's better ?
    I don't.

    And AFAIK, I use an standard abstraction layer (JDBC) to interact with any database from Java applications. The best of the story is that I also have PHP and .NET apps querying the same database...

    Isn't that a proof that lots of things are let's say "compatible" thanks to SQL ?

    Last but not least, I don't think stored procs and triggers represent the future of Software Development... but that's another story.
    I agree, but I don't think it is sad.

    It's sad 'cause the "theory" behind it is so great you know... Of course it's an utopia, but hey, I still have dreams :-)
      This "free" aspect has meant that countless users and companies have been able to install high-quality software with minimal cost.

    Agreed. I'm amongst them btw...

    Have fun,

    Remi
  269. Hell... really ?[ Go to top ]

    SQL is not a standard. It is many standards, none of which is fully implemented by any vendor as far as I know.
    Come on guys, please stop "fucking the flies" (a French expression) !Yes, you're right, porting an application into a new environment has never been an easy and straightforward task.

    But having actually implemented SQL standards would help.
    I mean, do you really think the industry (IT included) does not need common standards to rely on ???

    To paraphrase an old joke: Q. "What do you think of SQL standards?" A. "They would be a nice idea".
    Do you really think industrials are ready to switch from Hibernate to I-don't-know what each year 'cause it's new and it's better ?I don't.And AFAIK, I use an standard abstraction layer (JDBC) to interact with any database from Java applications.

    JDBC is a standard application layer for interfacing with databases, but when it comes to SQL it is largely a 'pass through' system. It has a wide range of functions that allow you to find out what the various differences are between database products. JDBC does not hide these differences. This is why JDBC has methods like DatabaseMetaData.doesMaxRowSizeIncludeBlobs() and DatabaseMetaData.getDateTimeFunctions().
    The best of the story is that I also have PHP and .NET apps querying the same database...Isn't that a proof that lots of things are let's say "compatible" thanks to SQL ?

    No, it isn't. There may be some minimal subset of SQL that is portable across some databases, but 'minimal' is certainly the word. Using such a minimal subset on powerful databases like Oracle is a waste of time.

    The industry may not have been ready to switch widely to Hibernate, but I suspect it may well be willing to switch widely to EJB 3.0/JPA, which has a full-featured and rich vendor-independent query language that can be converted by the JPA-implementing product to vendor-specific optimised SQL, not some poor minimal subset, giving you transparent portability.

    Many developers have been using exactly this combination of power and portability with standards such as JDO for years. Now, with JPA, even more will take advantage of it and free many projects from the frequent horrors of SQL incompatibilities.
    Last but not least, I don't think stored procs and triggers represent the future of Software Development... but that's another story.

    Neither do I! But there are a lot of them out there, and sooner or later they have to be ported to something (like one of my projects). And, this porting reveals exactly how incompatible SQL implementations are.
    I agree, but I don't think it is sad.
    It's sad 'cause the "theory" behind it is so great you know... Of course it's an utopia, but hey, I still have dreams :-)

    I feel the same :)
  270. Hell... really ?[ Go to top ]

    [...] I suspect it may well be willing to switch widely to EJB 3.0/JPA, which has a full-featured and rich vendor-independent query language that can be [...]
    [...] Many developers have been using exactly this combination of power and portability with standards such as JDO for years. [...]

    Well so we agree.
    OK, you are right with JDBC and SQL, I probably talked too fast, but you've just stated what I try to express since my first post !! I mean, everyone needs common agreements (standards) to rely on. It just makes our life easier and avoids spending energy on sporadic things (is there anything more boring and useless than rewriting a working piece of code ?).
    We are "vendor-unlocked" only because they implement standards...
    Neither do I! But there are a lot of them out there, and sooner or later they have to be ported to something (like one of my projects). And, this porting reveals exactly how incompatible SQL implementations are.

    Once again, my mistake, I did not meant portability in implementations. Btw, PL/SQL is not SQL, and stored procs are not part of the standard AFAIK, it's always been different on different engines.
    But querying a DB using SQL (or an API over it, like JDBC) is pretty much the same thing with every database on the market...
    Anyway, apparently you've had very bad experiences with SQL, and I also remember pretty hard times with this freakin' PL/SQL sh*t, actually I hated this since I saw it too !
    I'm not tryin' to convince you that SQL rocks, believe me !!!
    Hopefully the era of RDBMSs will soon be an old story... ;-P

    Have fun,

    Remi
  271. Hell... really ?[ Go to top ]

    The best of the story is that I also have PHP and .NET apps querying the same database...
    I am glad you think so. All I can think of is all that triplicate code to maintain.
    Last but not least, I don't think stored procs and triggers represent the future of Software Development... but that's another story.
    I know they are not. But I am curious how you get away with 3 different (at least) applications accessing the same data store and not have stored procs, etc.
  272. Hell... really ?[ Go to top ]

    This was an example... I don't deal with PHP and not even .NET actually !

    I was just meaning that SQL allowed - at least partial - interoperability across technologies and/or vendors.

    Have fun,

    Remi
  273. missed my point[ Go to top ]

    The "Little's Law" post is stating IMO that JMS does not offer better scalability than synch architectures. This is not true, one of asynch main advantages is the scalability (event driven model). Performance is worse. This should be a basic IT knowledge

    In fact, I was not at all saying that JMS does not offer better scalability. My point was simply that it only offers increased scalability under a certain set of conditions, and failure to undersand these conditions is very, very common.
  274. I am one of the 2% who tend to work on large end integration projects and not in web development. My current project has a whole set of interfaces that are used by multiple front end clients from different vendors.

    JMS Queuing works for us as some transactions we offer both sync and async (off line) processing depending on if third parties are currently down. Also we require distributed transactions as we update multiple databases in single transactions as well as a way to model transactions in systems that do not support JTA.

    We use a mixture of open source Spring, Hibernate, Quartz, Castor, Axis running on Weblogic.

    The one thing I have noticed is it is very difficult to find J2EE developers with integration experience. Most of the people we interview generally have done nothing but MVC websites backed off and Oracle Database or and XML integration layer.
  275. 98% of Java developers just don't need it[ Go to top ]

    I agree with you. One of the areas where J2EE works fine is integration with the existing non-J2EE applications.

    Many in TSS equate J2EE development to MVC and retrieving some data from Database and displaying on the web page. J2EE does this and much more.

    That is one of the reasons why the Ruby backers claim J2EE can be replaced with Ruby.
  276. 98% of Java developers just don't need it[ Go to top ]

    I agree with you. One of the areas where J2EE works fine is integration with the existing non-J2EE applications.Many in TSS equate J2EE development to MVC and retrieving some data from Database and displaying on the web page. J2EE does this and much more.That is one of the reasons why the Ruby backers claim J2EE can be replaced with Ruby.
    I Agree. Incidently Ruby can be used to do Integration too. The breath and depth of Interfaces to other systems isn't no where near as well established as Java, granted. But that caould all changed very quickly.

    I am one of those that believe dynamic languages hold out a lot of promise (Ruby included). My reasons for thinking this are broad ranging and are not soley based on RoR. IMO RoR is an example of what dynamic language make possible. In many ways RoR may turn out to be a Trojan horse.

    Paul.
  277. C'mon now Websphere is probably the most complex of the major app server vendors and it takes about 10 minutes to install a clustered j2ee environment. With a few more clicks of the button you get memory-to-memory session failover. A couple more clicks and you set up your JMS messaging. A couple more and your data sources and XA drivers.

    Within an hour you have a bullet proof, scalable, redundant, load balanced, transactionable infrastructure and you don't have to scurry around like some frenetic little dufus from one framework du jour to the next (rails, spring, blah blah blah bs).
  278. 98% of my friends who create web sites tell me Java and J2EE themselves are too heavyweight and complicated for what they are doing. They write in PHP, or Perl, or some other such nonsense that we scoff at.

    Perhaps the old addage "use the right tool for the job" applies.
  279. 98% of my friends who create web sites tell me Java and J2EE themselves are too heavyweight and complicated for what they are doing. They write in PHP, or Perl, or some other such nonsense that we scoff at.Perhaps the old addage "use the right tool for the job" applies.
    +1
  280. 98% of my friends who create web sites tell me Java and J2EE themselves are too heavyweight and complicated for what they are doing. They write in PHP, or Perl, or some other such nonsense that we scoff at.Perhaps the old addage "use the right tool for the job" applies.
    It would be useful to know what their actual Java experience is. I had a conversation with a .Net guy about a year ago and he was saying slow Java was and how difficult it was and how much faster developing .Net apps were. I asked about his Java experience - he had used Visual Cafe (and that era of IDEs). Not what came after that (VAJ/JBuilder) and definitely not what came after that. Too many people think you have to have an app server and EJBs and DTOs and Struts to do Java Web Applications.

    If they develop nothing but Web Sites (not web apps) - then they probably have a point.

    100% of my close friends think PHP is a very bad way to develop web apps. :)
  281. Choosing Friends[ Go to top ]

    100% of my close friends think PHP is a very bad way to develop web apps. :)

    So do you give people technical interviews before you become friends with them?
  282. Choosing Friends[ Go to top ]

    100% of my close friends think PHP is a very bad way to develop web apps. :)
    So do you give people technical interviews before you become friends with them?

    Or, I have no friends. :(
  283. EJBs will die in spec[ Go to top ]

    I think that sun in EJB3.0 tried to adopt to the changing world, but it's too late the backward compatibility will kill EJB from the programming paradigm.
    Most programmers now uses Hibernate, Spring and other lightwight containers, these are much more transparent than the HEAVYWEIGHT, COUPLED, COMMERCIAL specifications like EJB.
  284. EJBs will die in spec[ Go to top ]

    I think that sun in EJB3.0 tried to adopt to the changing world, but it's too late the backward compatibility will kill EJB from the programming paradigm.Most programmers now uses Hibernate, Spring and other lightwight containers, these are much more transparent than the HEAVYWEIGHT, COUPLED, COMMERCIAL specifications like EJB.

    No.

    EJB 3.0 has learned from Hibernate, Spring and other lightweight solutions. It is lightweight, the beans can be tested outside a container (so are not coupled) and (assuming that 'COMMERCIAL' is a disadvantage for some mysterious reason) there are open-source implementations. You can use the backward compatibility if you want to, but you don't have to, so it is no disadvantage for the developer, only for the app server implementor.
  285. EJBs will die in spec[ Go to top ]

    Some people forgive that when EJB first came out AOP and DI were still mainly research subjects and had not shown yet how great they were at reducing complexity. That's why EJB2 components were complex. I do think the component model wasn't that bad at that time.

    Entity beans ORM model was the real show stopper, the ideas were great but there were too many limitations (EJBQL had some limitations as well).

    Session beans have bean successful and still are widely used. They solve a good amout of problems but it is now time to make them lighter and decouple them from the container. Simple evolution, it is easy to laugh at EJB now knowing what we know but at that time they were indeed a true revolution.

    My opinion as I have stated several times is the same as most JBoss guys (btw I have never used it, I just want to give the credit to the people who deserve it ), let's standardize some aspects and stop trying to standardize a component model. Please no more JME, JSE and JEE (unless it is for storage requirements)! No more container! With standard aspects, you would only need to include a small microkernel wich can be bootstraped in your code like you already do with Spring.
  286. EJBs will die in spec[ Go to top ]

    I think that sun in EJB3.0 tried to adopt to the changing world, but it's too late the backward compatibility will kill EJB from the programming paradigm.Most programmers now uses Hibernate, Spring and other lightwight containers, these are much more transparent than the HEAVYWEIGHT, COUPLED, COMMERCIAL specifications like EJB.
    No. EJB 3.0 has learned from Hibernate, Spring and other lightweight solutions. It is lightweight, the beans can be tested outside a container (so are not coupled) and (assuming that 'COMMERCIAL' is a disadvantage for some mysterious reason) there are open-source implementations. You can use the backward compatibility if you want to, but you don't have to, so it is no disadvantage for the developer, only for the app server implementor.
    Yes. The problem was not [so much] EJBs as it was people, namely the people involve in and around IT. From what I can tell, most people are just not that good at it.

    Instead of looking at the Pet Shop as a demo, they looked at it as a blue print.

    Instead of avoiding App server specific code, they do it (cause they paid good money for it and/or that's what the vendor says they should do) and then blame J2EE when it is tough to move from, say, Websphere to Weblogic.

    Instead of genercizing db code, they write tons of stored procs and db specific sql and then say no moves between databases so why shouldn't they (well, they "can't" after doing that").

    And so on.

    So to those who think things like Ruby "walk on water", wait till the Peters and Doubting Thomases of the programming world get ahold of them (I know you've pointed this out before Steve). And people say EJBs were misused. :)
  287. EJBs will die in spec[ Go to top ]

    Yes. The problem was not [so much] EJBs as it was people, namely the people involve in and around IT. From what I can tell, most people are just not that good at it.

    This is a big issue in IT - lots of clever techniques and ideas tend to neglect the general level of incompetence of... well... a lot of people (I include myself in that).
    So to those who think things like Ruby "walk on water", wait till the Peters and Doubting Thomases of the programming world get ahold of them (I know you've pointed this out before Steve). And people say EJBs were misused. :)

    [I have actually detected the first signs of a RoR backlash. I have seen posts on popular forums from developers who have tried RoR and found - guess what? That performance of Ruby isn't that good - what a surprise! I have also seen comments from developers who are starting to realise that Rails can potentially raise issues of lock-in to databases unless you use SQL with care, and they ask 'if only there was a way to get the full power of a relational store and remain portable'. When I mention JDO 2.0 and EJB 3.0, a surprising number of developers don't realise these things are possible. I have seen people start to promote alternatives to Rails such as Nitro - the advantage being that you handle everything in one place - the code . Wow! What a revolutionary idea! :)]

    This is why, as I posted earlier, my vision for the future is not so much wider use fabulous new languages, but better developer education about what is available and how it can be used safely and effectively.
  288. EJBs will die in spec[ Go to top ]

    This is why, as I posted earlier, my vision for the future is not so much wider use fabulous new languages, but better developer education about what is available and how it can be used safely and effectively.

    And management/decision maker education too. Or at least a little rounding of the point of the pointy-headed ones. :)

    It really is incredible how little people about what is available in Java. Mostly what is heard is the whining about the little that isn't available.