TSS Asks: Are standards a bad thing?

Home

News: TSS Asks: Are standards a bad thing?

  1. TSS Asks: Are standards a bad thing? (60 messages)

    A discussion on the recent (2005) JCP elections brought up a question of relevance for standards, with one poster saying:
    Specifications have hurt Java more than they've helped. Is it any wonder that NONE of the most popular frameworks conform to any sort of specification? And what's a Java standard anyway? None of it is standard JCP/JSR or not. Any CIO looking to build an application on JCP/JSR "standards" is on glue. Java itself is not a standard!!!
    For all intents and purposes, some specifications are unavoidable; while it's possible to service HTTP requests without the servlet API, very few would attempt to ignore servlets. Even JSP is optional in few containers - Jetty is notable in this regard, and Your Editor is unaware offhand of any other containers that have JSP as an option (as opposed to being built-in and bundled with the container).

    Hani Suleiman, in the same discussion, suggested that standards are indeed important and relevant:
    Hibernate and toplink (and even JDO) resulted in EJB3, which will (pretty safe bet) become the standard persistence solution, instead of the current proprietory API's that hibernate/toplink offer. The differentiator will no longer be the API, it'll be the extra vendor-add features on top of the baseline.

    Without EE, there'd be no Spring. Spring's value-add is that it piggybacks on top of Java EE and makes the easy stuff easy, and the hard stuff less painful.
    Another point Hani implied in passing was that development communities can certainly have their own internal standards, formal or otherwise. For example, an informal group of developers hacking away at an IRC bot for amusement might have no interest in a standard API (such as a XMPP implementation), but a Fortune 100 working on an automated messaging client (i.e., a bot) might refuse to use anything not based on XMPP.

    What do you think? Where does Java take standardization too far, and why do you think that's the case? What can or should be done about it?

    Threaded Messages (60)

  2. Standard is all[ Go to top ]

    Standard is all, without standards Java wouldn't have been in this power, for instance what made Java a distenguished language at it's early days is that is had a powerful and well defined VM and language specs.
  3. Usually standards are used to reduce a multitude of existing designs to one design. For example screws: There were many different types of screws. After the standardization there are just a few types of screws. And you can choose those types that is best.

    In the Java world much too often a standard is created without these many existing designs. The result is that not a standard is created but rather design by commitee is done. This is a bad thing.

    The result? Let's try to solve the problems in the project using the tools that fit best - be they standardized, Open Source or whatever. Judging the solution of course must take into account things like investment risk, availability of skilled people and so on besides the technological quality. Often Open Source can be a viable solution - despite the possible lock in. It is also one of the strong sides in the Java community.
  4. ...In the Java world much too often a standard is created without these many existing designs. The result is that not a standard is created but rather design by commitee is done. This is a bad thing.

    EXCELLENT point.
  5. Usually standards are used to reduce a multitude of existing designs to one design. For example screws: There were many different types of screws. After the standardization there are just a few types of screws. And you can choose those types that is best.In the Java world much too often a standard is created without these many existing designs. The result is that not a standard is created but rather design by commitee is done. This is a bad thing.The result? Let's try to solve the problems in the project using the tools that fit best - be they standardized, Open Source or whatever. Judging the solution of course must take into account things like investment risk, availability of skilled people and so on besides the technological quality. Often Open Source can be a viable solution - despite the possible lock in. It is also one of the strong sides in the Java community.

    +1, could not say it better!
  6. While I agree to your post in general, I don't get why most people assume that There Must Be Only One standard (to rule them all, I guess). What's wrong with having multiple committees design a myriad of standards, duplicating and enhancing each others work, and thus progressing towards the optimum -- and let consumers THEN choose the standard that satisfies their individual needs at hand the best?

    TCP/IP was mentioned -- well, it was not the only standard for networking, but it is the one that prevailed, and that meets most people's demands, so it gained the most popularity. On the other hand, it is not perfect, that's why it still has to be improved -- which brings me to the other error most people make: They assume that once a standard is ratified, it cannot be changed anymore. Why shouldn't it? It is just not that easy to avoid cruft (see Intel's A-20 gate).

    As Mr. Andrew Tanenbaum once said: "The good thing about standards is that there are so many to choose from." Let me add: "... and that they keep improving."

    Cheers, Lars

    --
    The Mind Mill
  7. While I agree to your post in general, I don't get why most people assume that There Must Be Only One standard (to rule them all, I guess). What's wrong with having multiple committees design a myriad of standards, duplicating and enhancing each others work, and thus progressing towards the optimum -- and let consumers THEN choose the standard that satisfies their individual needs at hand the best?

    I have a friend whose father is in radio. Once my father asked "what happened to AM?" In other words "why did radio stations almost all move to FM?" in the US. He said that when Am radio's governing body was figuring out how to go stereo with AM, they decided to 'let the market decide' similar to what you propose. Because there was no single standard, no one was willing to risk choosing one and AM never went stereo. FM on the other hand did choose a single standard and thrived.

    That's an example of why letting the market decide isn't always a good idea. Look at the debacle between Blue-ray and HD-DVD. Very few consumers are going to purchase players for either standard until the vendors get that settled.
     TCP/IP was mentioned -- well, it was not the only standard for networking,

    No one said it was the only standard.
    but it is the one that prevailed, and that meets most people's demands, so it gained the most popularity. On the other hand, it is not perfect, that's why it still has to be improved

    No one said it was perfect.
    -- which brings me to the other error most people make: They assume that once a standard is ratified, it cannot be changed anymore. Why shouldn't it? It is just not that easy to avoid cruft (see Intel's A-20 gate).As Mr. Andrew Tanenbaum once said: "The good thing about standards is that there are so many to choose from." Let me add: "... and that they keep improving."Cheers, Lars-- The Mind Mill

    Standards are rarely very useful unless they are widely accepted. That's generally the key feature one is looking for in a standard. For example, XML is fairly flawed standard, at least for much of the way it is used. But the depth and breadth of support is so great it's worth it even with the problems.

    Everyone in the world could define their own 'standard'. But it's not really much of a standard if it's not widely accepted.
  8. That's an example of why letting the market decide isn't always a good idea. Look at the debacle between Blue-ray and HD-DVD. Very few consumers are going to purchase players for either standard until the vendors get that settled.

    I think that the real problem with many of the "standards" in consumer electronics is that they do not differ enough from a technological viewpoint. There are no obvious advantages in both alternatives -- it is all marketing and sales pitch. So customers and potential partners believe none of the adversaries, leading to a stalemate situation. A specification therefore must not be composed of fluffy marketing speak, and should name its limitations as well as the optional features, but not the wishlist of things that may be possible in 3 years time.

     TCP/IP was mentioned -- well, it was not the only standard for networking,
    No one said it was the only standard.

    I didn't say that somebody said it was the only standard. ;-) I merely stated that it was an example of a standard that prevailed in a competition against many others.

    but it is the one that prevailed, and that meets most people's demands, so it gained the most popularity. On the other hand, it is not perfect, that's why it still has to be improved
    No one said it was perfect.

    Then again, I didn't say that somebody said it was perfect... :-)

    Standards are rarely very useful unless they are widely accepted. That's generally the key feature one is looking for in a standard. [...] Everyone in the world could define their own 'standard'. But it's not really much of a standard if it's not widely accepted.

    Point well taken. But before it can be adopted, a standard has to be specified. And as all standards in Javaland have to be specified following a JSR, by a JCP committee -- which I think is the real problem actually -- there's not much to choose from.

    Just my .02$, Lars

    The Mind Mill"
  9. That's an example of why letting the market decide isn't always a good idea. Look at the debacle between Blue-ray and HD-DVD. Very few consumers are going to purchase players for either standard until the vendors get that settled.
    I think that the real problem with many of the "standards" in consumer electronics is that they do not differ enough from a technological viewpoint. There are no obvious advantages in both alternatives -- it is all marketing and sales pitch. So customers and potential partners believe none of the adversaries, leading to a stalemate situation. A specification therefore must not be composed of fluffy marketing speak, and should name its limitations as well as the optional features, but not the wishlist of things that may be possible in 3 years time.

    I disagree that between Blue-Ray vs. HD-DVD that there is no clea technological advantage. BR has a much higher data density. On the other hand HD-DVD is more easily produced with current equipment. But from a consumers point of view, I would think Blue-Ray has clear advantage (assuming everything else is equal.)

    Other than that I agree but I fail to see how there is a difference in the IT market. If there is no organization to pick 'the one true spec.' as you call it, then you can easily end up with many technically equivalent specs and no clear reason to coose one over the other. So just letting the market decide doesn't always work. Sometimes it does because one standard hits a critical mass (TCP) but if one solution doesn't get out ahead of the others, you can end up with no clear standard. This almost happened with Web-Services. Several players had come up with equivalent but different solutions. They reached a compromise but at the cost of redundancy in the spec.
  10. If there is no organization to pick 'the one true spec.' as you call it, then you can easily end up with many technically equivalent specs and no clear reason to coose one over the other.

    You also need 'the one true organization' to pick the 'one true spec' in order for it to work.

    IBM could start cranking out "standards" and claim that it had to do it because Sun has failed in it's stewardship of Java by failing to release it under an open-source license (in other words, by continuing to charge IBM money). It could then use it's legions of consultants and purchased CIOs to ensure its "standards" are adopted.
  11. TSS Asks: Are standards a bad thing?[ Go to top ]

    I think JCP/JSR standards do a slightly different thing to wider, industry standards. Whereas industry standards try to force compliance, Java standards (most of the time) seem to be more about crystallising and drawing together the parallel developments of multiple vendors, making a technology gain traction, rather than forcing compliance to the technology specs themselves.

    What often results is a lowest-common-denominator standard which by itself is not much use without vendor extensions.

    So you end up with a technology that is 80% standardised, but the difficult 20% is still proprietary.

    WRT Spring: Spring was the first project to really bring IoC to the masses and make it shine. Before that, there wasn't really a widely recognised IoC market, so it is no surprise there were no standards there. It was definitely in the right place at the right time (disparate components, difficult unit testing, disaffection with J2EE). These are the best "standards". They solve a definite problem. As mentioned elsewhere, trying to develop specifications in isolation from real-world problems produces camels "designed by committee".

    So I would say the best JSRs are those with people with knowledge of the real pain points of a problem, and with the fewest number of big vendors to screw it up for the rest of us. IMHO.

    Kit
  12. Arrogance vs Emergence[ Go to top ]

    Standards are not a bad thing, of course.

    The problem is huge, morose and arrogant consortia forcing standards into existence, with all sorts of assumptions and political compromises, instead of letting them emerge naturally.

    See you, Klaus.

    "SYNTHESIS is precisely the force that counterbalances the chaos created by millions of sovereign parties publishing tons of information any way they please. You have access to all this information not directly, if you don't want to, but through syntheses - and syntheses by the people you trust the most on each subject." The Sovereign Computing Manifesto - http://www.advogato.org/article/808.html
  13. TSS Asks: Are standards a bad thing?[ Go to top ]

    IMHO.
    Extracting a standard out of commonly used and/or accepted tools/frameworks/protocols/behavior is generally a positive endeavor. Fabricating a standard by decree because ‘experts’ feel that it’s the way it should be, usually leads to unappealing situations.
    Maybe that’s the difference between de-facto standards and the so-called “industry” standards.

    Cheers,
    Dom.
  14. XP versus waterfall standards[ Go to top ]

    In committee-produced standards, standard is the result of a waterfall process: big upfront design, with very smart people thinking of kewl and shiny features (EJB 2 anyone). These standards are never developer friendly, because they do not take developers problem into account.

    De facto standard evolve organically, incrementally. You start something small to solve a particular problem, and the solution grows naturally as you solve more problems. It is coded to be simple to use, embracing the KISS principle, it solves real problems and leaves shiny features for spec designers. It follows the XP principle: the code is the design, and design refines during the whole coding process.
  15. XP versus waterfall standards[ Go to top ]

    committee-produced standards... De facto standard ...

    Reminds of the line, "Democracy is the worst form of government next to all the others." Pick out the tyrant in a lineup of Linus Torvalds, Scott McNealy, Bill Gates.

    I would think that defacto standards and .Net are now driving the committeee standards (EJB3...). Sun licensing is pretty liberal now so that you can get the Java VM and library source and have at it.
  16. TSS Asks: Are standards a bad thing?[ Go to top ]

    Having participated in many standards committees, I have witnessed some fall to the "design by committee" antipattern whereas others were very successful. I feel that standards have their pros and cons however conversely, situations where there is a lack of standards usually aren't very appealing. The only benefit I have seen is possibly fostering some creativity. Standards tend to suppress new ideas since they will often violate the standard.
  17. Gathered Standards[ Go to top ]

    I liken standards to their distant cousin from back in the old country: the design pattern. Like design patters, when a standard expresses the collective wisdom and experience of the community, it is a useful tool for defining the broad strokes in a design. When someone with more clout than sense looks at his or her code and says, "That looks neat. I declare it a standard/pattern," it is a nightmare waiting to happen. Done right, both patters and standards provide a common language and set of well known conceptual components from which to build systems. Those conceptual components are more than APIs. They must also include a common understanding of the expected role of the component, the pros and cons of applying them, and the trade-offs one must make. This deeper understanding cannot be handed down from a standards body by fiat. It can only come from the community of working developers drawing on their own experience.

    The distinction between "gathered standards" and "declared standards" is important. When a standard is derived from existing implementations, its costs, benefits, and proper applications are known. A standard created out of whole cloth is really just an idea with powerful backers pushing it. Consider the specs that everyone loves to pick on: entity beans in EJB 1 and 2. As best I can tell, the entity component model described in the spec really did not fit the paradigm for data manipulation actually in use at the time. Everyone, including Sun, now agrees that as soon as EJB was released it was roundly misapplied. I hope Sun can forgive us ignorant savages for finding their advanced technology on the beach and guessing how we might use it to solve our real problems rather than their vision. In contrast, the entity model in EJB 3 is based on what is actually being done in the JEE community. By synthesizing a number of tools and practices into a coherent standard, the EJB expert group has gathered a standard from the community instead of imposing one on it. This way, we know what to expect and how to use EJB 3 because we are already doing it.

    Another example of a gathered standard was JDBC. Who was excited when they first saw JDBC? Probably no one. The concepts are all old hat, and the interface is pretty much what one would expect. Therein lies the power. Because JDBC just standardized a data access pattern that was already in use and already implemented by other tools, we all knew when and how to use it and what the consequences would be. JDBC was ready to be a standard. It may continue to evolve because we never stop learning better ways to solve the problem, but at this point the revolution was over.

    Much like design patterns, if a standard is new and exciting, it is probably suspect. The idea itself may be great, the next revolution in slicing bread. However, when it is still new and exciting it is much too young to standardize. We as a community need to poke and prod and see if there is a better way before anyone declares that this is the way. This is admittedly at odds with marketing desire to create new buzzwords and define the future of the industry to look suspiciously like ones one products, and that is why it is so important that developers take part in defining and approving standards rather than leaving it entirely in the hands of vendors.

    In short, standardize by consensus, not by fiat.

    Vince Frisina
    ePlus Consulting
    vfrisina@eplus.com
  18. Of course standards are bad. Just look at how TCP/IP ruined the internet.
  19. On the lighter side[ Go to top ]

    As forrest gump would say "standars is as standard does."

    Standards are necessary good and evil. When a standard works, it's great. When standards becoming a pissing match between companies looking to monopolize the market, it can quickly degenerate into gibberish.

    Just like anything else, not all standards are going to be good. I would argue, 50%+ of the standards are bad, questionable, barely acceptable and completely brain dead. Frankly, it takes time for a great standard to emerge and beat the bad ones down to valhalla.

    peter
  20. For example, an informal group of developers hacking away at an IRC bot for amusement might have no interest in a standard API (such as a XMPP implementation),
    If they have no interest, did not study existing API and standards, and try to implement something then I call them ignorant.
    And I think they must stop till they fill the blanks in this template:
    1. I(we) had a need to do: <Two phrases to describe>
    2. I(we) have tried the following frameworks/api-s/standards: <insert names> before starting to develop my own
    3. They are supposed to address my needs but I was not happy with them because: <reasons why those frameworks/api-s/standards are not satisfactory>
    4. I(we) decided not to contribute to any of the existing frameworks/api-s/standards because: <describe why>
  21. totally disagree[ Go to top ]

    If they have no interest, did not study existing API and standards, and try to implement something then I call them ignorant.

    That's like telling a painter that he should not paint a sunflower because van gough already did it. Or telling someone not to dance because he has not seen films of baryshnikov. If you are coder on a production line on an outsourced project, well then I'd agree with you. But to a Hacker (someone who codes for fun and art and creativity) it's more about the doing than anything else.

    -geoff
  22. totally disagree[ Go to top ]

    But to a Hacker (someone who codes for fun and art and creativity) it's more about the doing than anything else.-geoff

    Such hackers should be bitten with a big baseball bat.
    They are double guilty because they want to build this thing, they might be bright and capable, therefore they must study and improve upon.

    And yes painters should study how Van Gogh (not van gough) did that.

    Proliferation of ignorance is not limited to software, visit to art museums shows that very clearly. Malevich’s “black square” and such are really different than works of Bosh, Michelangelo, Tiziano...
  23. u are soooo smart[ Go to top ]

    But to a Hacker (someone who codes for fun and art and creativity) it's more about the doing than anything else.-geoff
    Such hackers should be bitten with a big baseball bat. They are double guilty because they want to build this thing, they might be bright and capable, therefore they must study and improve upon. And yes painters should study how Van Gogh (not van gough) did that. Proliferation of ignorance is not limited to software, visit to art museums shows that very clearly. Malevich’s “black square” and such are really different than works of Bosh, Michelangelo, Tiziano...
  24. Specifications have hurt Java more than they've helped.
    Even if this is true, it doesn't necessarily make standards a bad thing. Not having any specifications would probably have hurt even more!

    Whether specifications have hurt Java is one discussion and whether standards are good or bad is entirely different.

    Chintan
    http://chintanrajyaguru.com
  25. It's all about timing[ Go to top ]

    I think what makes a standard work is timing. When standards are invented in a 'new' area for a technology that is not well used. The standard will probably fail.

    If a standard emerges after well established best practices have been developed, it can usually be pretty good.

    Along these lines of thinking that's why EJB2 failed and why EJB3 will probably end up being okay.

    I'd be dubious around any standard for AJAX emerging right now, its better that people innovate for a little while.
  26. Specifications have been very important to Java. Take J2EE, for example. J2EE is painful for the developer at first. All the XML files, all the things to learn, there is a LOT going on and it is often overwhelming. This is why you sometimes hear developers complain about J2EE. And then, once you learn it all, you realize that the specification still doesn't cover a lot of things that you need for your project. So, in the end, you wonder about the usefulness of J2EE? But, it has been of vital importance to Java as a whole.
    Just take a step back and look at the big picture. Because of J2EE, CIOs and other executives/managers felt the warm and fuzzies to embrace Java in the enterprise. Big companies like IBM, BEA, Oracle, etc could produce J2EE containers, giving management even more fuzzies. Because of J2EE, you had something around which companies could rally. And because of all this, Java won a huge share of the enterprise market and of developer mind share. Now, we have tons and tons of Java developers (which is both good and bad in some ways). Even so, with all these developers we now have a huge Java community. And because of this huge community, you see things like Spring, Hibernate, Struts, and other such open source projects arise from the dust. And now we are seeing the next round of specs borrow and learn from these newcomers: the next J2EE will have persistence similar to Hibernate and IoC similar to Spring, etc. When you look at the big picture, specifications have been extremely important to Java.
    Honestly, there have been times that I have wanted to leave Java for something "better", but the only thing holding me back is the wealth of community and open source projects available for Java. These end up being more valuable, for my projects anyway, than what alternative languages/platforms have offered.
  27. The point of standards to today's IT managers is to manage risk: "I can safely buy WebSphere because tomorrow I could replace it with WebLogic". This is because commercial vendors have a strong incentive to keep people locked in.

    Apache and other open-source projects have no such incentive. However, they can still be risky because of low supportability. You need to pick open-source projects that have a large following.

    Open-source projects also suffer less from the problem of design-by-committe, because an open-source project without a strong leader does not survive as such.

    Guglielmo
  28. Re[ Go to top ]

    I think only most common things are standardized. If you are writing a simple CRUD web application it is hard to write it in many different ways because you will use EJB, Hibernate or just JDBC for persistence or bare Servlets or some more advanced framework for it. But if you are developing application with a rich domain model, persistence and UI is only front end and back end and you have full freedom in organizing your domain classes. I think it is very good that this things are standardazied because it is easy to predict development time of front end and back end, because it is easy to find developer who can do this thing, and rest of team will work on domain model.

    Of course early versions of EJB looks daunting but because it is only small part of big application you can ignore it, in addition current EJB 3.0. much more easier to use then previous ones.

    I think most common frameworks which can be used in most programs has to be standardized even they looks daunting because programmer who has already learned early version EJB can write part of product which uses them faster then any other programmer who isn't familar whith the most productive persistence API in the world.
  29. Did anyone else take notice...[ Go to top ]

    Looking at the original post and follows, just curious if anyone else noticed that Hani had something useful to say, and it apparently did not involve any sexual acts or bathroom humor? ;)
  30. I trust Hani[ Go to top ]

    So whatever he says is fine with me. In fact, there should be no JCP and Hani should be anointed King of All Java.
  31. I trust Hani[ Go to top ]

    Well, he does FEEL JAVA...
  32. I trust Hani[ Go to top ]

    ewwwwwwwwww....

    Seriously, it is hard for me to agree with the words of a man insane enought to oppose almost any tool that comes along, particularly when it does not conform to his preconveived notions of how the world ought to work. But if the guy was voted onto the JCP, someone must have thought he had something worthwhile to contribute. Let's just hope that it does not end up being the Java Steeming Pile of Crap JSR. Enough of the personal attack...sorry!
  33. I trust Hani[ Go to top ]

    So whatever he says is fine with me. In fact, there should be no JCP and Hani should be anointed King of All Java.

    At least the langauge would be a lot funnier. I can only imaging what the names of all of his API's and Protocols would be.

    Would he be able to ban frantic arm waving at JavaOne. that would be cool.
  34. I trust Hani[ Go to top ]

    By the way isn't haveing Hani in the JCP, kind of like having a actor for a governor?
  35. In my experiecne, standards are always a good thing for matured technologies, for which enough vendor implementations are already available. Abstracting them with stndard interfaces helps prevent vendor lock in, but trying to develop standards for newly emerging technologies, which are still in innovation phase is like putting the cart before the horse.

    Also, standardization of low level, infrastructure providing technologies (like jdbc, messaging, transaction management) is more likely to be successful than attempts to standardize higher level technologies (like business components).

    Anil Bhatt
  36. Also, standardization of low level, infrastructure providing technologies (like jdbc, messaging, transaction management) is more likely to be successful than attempts to standardize higher level technologies (like business components).Anil Bhatt
    Standards like jdbc solve integration problem and they are successful for this reason. "business components" or "framework" standard like EJB are not pragmatic, same problems can be solved without standard, it can not be successful in long term becouse standard produces some problems itself.
  37. I agree, JDBC is a great standard and a real blessing. Just imagine if you had to learn a new API for every toolkit out there. That would be a nightmare.
  38. Standards like jdbc solve integration problem and they are successful for this reason. "business components" or "framework" standard like EJB are not pragmatic, same problems can be solved without standard, it can not be successful in long term becouse standard produces some problems itself.

    EJB (and JDO) aren't necessarily 'business components' or 'frameworks'. They can be used simply as high level abstractions allowing interaction with information in a database using portable query languages and an object model. They are extremely pragmatic, both allowing a range of query languages (including native SQL) and direct database features if you don't want the abstractions. The same problems can be solved without standards (Hibernate and TopLink are very successful), but there is no reason why having standards should be any barrier to success.
  39. The same problems can be solved without standards (Hibernate and TopLink are very successful), but there is no reason why having standards should be any barrier to success.
    We will se it a few years later, but all "framework" standards fail i npractice, see "old" EJB, JDO, ODMG, CCM, COM+, ...
  40. BTW JDBC 4 did the same mistake too.
  41. The same problems can be solved without standards (Hibernate and TopLink are very successful), but there is no reason why having standards should be any barrier to success.
    We will se it a few years later, but all "framework" standards fail i npractice, see "old" EJB, JDO, ODMG, CCM, COM+, ...

    I don't know all of those, but from those I do know about, I can say you have picked bad examples. EJB has hardly failed - it is very widely used. If you look back to debates earlier in the year about JCP decisions you will see that JDO is far more widely used that most seem to think, and that finding was reflected in the changed votes of some members of the JCP. Your 'in practice failures' are nothing of the sort.
  42. EJB has hardly failed - it is very widely used.
    I know popular application servers, but I am talking about "standard EJB programking model", not about products with EJB support.
    Probably JDO was popular too, but it has the same future as ODMG ( an attempt to sell OODBMS ).
    I think standard must be usefull to be success.
  43. EJB has hardly failed - it is very widely used.
    I know popular application servers, but I am talking about "standard EJB programking model", not about products with EJB support.

    That standard EJB programming model is widely used. There have certainly been many valid criticisms of it, that does not counteract the fact that this programming model has been (and still is) successfully used in a wide range of projects.
    Probably JDO was popular too, but it has the same future as ODMG ( an attempt to sell OODBMS ).I think standard must be usefull to be success.

    It is not a case of JDO having been popular - it still is. Of course, this depends on how you define 'popular'. It certainly comes nowhere near Hibernate in terms of use, but many tens of thousands of developers use JDO and do indeed find it very useful. You may be right in terms of it's future, although I suspect not. My view is that the because there will be many products that provide joint support for EJB 3.0 and JDO 2.0 (even in the same application) this will encourage more developers to take a look at JDO 2.0 which has (in my view) a wider range of applicability than EJB (for example, it does not require Java 5.0). I believe that EJB and JDO will progress further in the future and evolve into a combined broader standard.

    However, this is off topic. I think although there are criticisms of the JCP, I strongly support standards. One of the reasons I selected JDO over alternatives for my POJO persistence mechanism was because it was a JSR and had multi-vendor support.
  44. I do not believe EJB 3 will be successful too. I can delpoy hibernate on any application server without this standard (I do not believe you need to replace JDO implementations too). Standard slows down innovation and adds no value in this case(O/R mapping has the same value without standard)
  45. I do not believe EJB 3 will be successful too. I can delpoy hibernate on any application server without this standard (I do not believe you need to replace JDO implementations too). Standard slows down innovation and adds no value in this case(O/R mapping has the same value without standard)

    You can deploy Hibernate, but surely there is an advantage in having at least a common API that you can use in Hibernate but also use in alternative EJB 3.0 implementations.

    Standards don't slow down innovation, as they are not supposed to be where innovation happens. Standards are supposed to formalise features of innovations that have proved to be successful. (Which is why EJB 3.0 has features of Hibernate, TopLink, JDO etc).

    Standards certainly add value. They provide at least some security for the developer, in that they can obtain the same feature set from more than one vendor. I have recently taken advantage of this. I have switched my JDO development tool from one vendor and I am evaluating alternatives. I have done this with virtually no changes to my code. I am currently evaluating JDO 2.0 implementations. I am switching between different vendor's products with absolutely no code changes at all. That is the beauty, and the significant added value, of standards.

    I believe you are a strong supporter of SQL. Although there has been questionable support for SQL standards, would you rather there were no standards at all, and each DB vendor went entirely it's own way with its own 'innovative' query language?
  46. It just an opinion based on my practice, it is not "the truth". If you are switching between different vendor's products and it is a typical evaluation process then standard makes sence.
  47. It just an opinion based on my practice, it is not "the truth". If you are switching between different vendor's products and it is a typical evaluation process then standard makes sence.

    This is not to do with evaluation. It is insurance against a vendor changing support or licensing at any time in the future. This is what has happened in my case. I can switch existing deployed projects, and not just projects under development, to a different ORM vendor with minimal effort - providing their product implements a JCP standard.
  48. It is insurance against a vendor changing support or licensing at any time in the future.
    I prefer to solve this problem using open source software and I think standards are usefull for integration only. Most JCP standards are very usefull and there are not so many useless standards ( frameworks or programming models).
  49. It is insurance against a vendor changing support or licensing at any time in the future.
    I prefer to solve this problem using open source software and I think standards are usefull for integration only. Most JCP standards are very usefull and there are not so many useless standards ( frameworks or programming models).

    I have no idea why you would think standards are only useful for integration, as I don't understand what you mean by that. However, there is no need to avoid using standards because you want to use open source - these are not exclusive. Hibernate will provide an open source implementation of EJB 3.0 POJO persistence. So will JPOX, which will also provide a full-open source JDO 2.0 (it will be the reference implementation).

    I think you (and many others) are setting up false opposites: JCP Standards vs Open Source; JCP Standards vs Innovation etc.
  50. Standards good/evil[ Go to top ]

    IMHO there is no real answer to this. It really depends on which side you are (make everyone talk the same language, or try to profit because you're the only solution). As I see it a standard is a solution to a problem. When such solution is accepted by majority of participants trying to solve that problem, solution can become a standard. For instance SyncML standard managed by OMA. In a short way SyncML is a proved synchronization solution accepted by most of the giants in this industry. It has its downsides (XML based can be one of them) but it definitely has its great benefits.
  51. JCO oblivion[ Go to top ]

    Well, there are many messages posted on the subject and I don't have the time to read all, so, sorry if I am just repeating what one already has written.. However, Rod Johnson has long ago identified the problem with the JCP years ago. Basically, JCP fails because of the process model. Waterfall software engineering process approach is a loser and everyone in this industry knows that. However, JCP insists on working in this fashion, preparing huge and bloated specifications that has not been tried and adopted before. On the other hand, opensource projects in the community tend to follow more agile practices, iterating on with small releases and getting constant feedback from the community, evolving continiously, and listening to them. That's the process model which JCP should adopt as well I think. Running with small iterative releases and reference implementations... it's just that simple... The standardization issue will find its way through along the run I think, if just everyone knows to learn from mistakes just on time... Not two or three years later, as everyone has adopted their own solution, because the standars just does "fail"...
  52. this tread it self ..shows .. why "standards" or "sepecification" in this context is very much required. we all have our own openions so we all have to come at one common point .. that point will be standard, isnt it ??

    anyways! nice discussion... :)
  53. Interesting discussion! I'd like to suggest that standards are good when they fill a need and outline a workable (not necessarily a good) solution.

    Several people have contrasted TCP/IP and OSI, and concluded that standards based on experience are good, and those designed by committees, without any basis in experience, are bad. In general, I think that's right. But where does EJB fit?

    I think there is general agreement that EJB fits the latter description and that EJB before 3.0 was pretty horrible. (Many of us have the scars!) On the other hand, there was no acknowledged alternative and, bad as they were, the early EJB standards were better than any of the non-standard alternatives. At least they brought all the big manufacturers together and avoided the plethora of incompatible systems that would have held the Java server market back for years. And, because they served a need, there was a lot of pressure towards EJB 3, which may become a very good standard (although I think it's still too early to be sure).

    Also, EJB engendered Spring, as a reaction to all that was bad about EJB.

    On the other hand, I think there is no doubt that standards inhibit innovation. Just as no-one gets fired for buyng IBM, no-one gets fired for using the standard rather than the new innovative approach that doesn't fit the standard -- perhaps because the new approach has leapfrogged the problems that the standard was built to solve.

    But, looking at EJB again, didn't EJB spur innovation (in the form of Spring)?

    So what am I trying to say? Well, perhaps the only conclusion we can draw is that every generalization has an exception.

    But, hold on. That would mean that there is at least one generalization that doesn't ...

    Tony Walker
    www.persistentjavaobjects.com
  54. But where does EJB fit?I think there is general agreement that EJB fits the latter description and that EJB before 3.0 was pretty horrible.

    Actually Session EJBs were based on lessons and patterns from other technologies such as Tuxedo. I don't think they are or ever were horrible or bad especially compared to what they replaced. They were misrepresented by a lot of brain dead vendor consultants, but once you recognized they were service components intended to provide communications and transaction support for POJO business logic and you made their methods large grained service operations, you were o.k. Improvements to classloading in J2EE 1.3 further improved their effective design, deployment and use as well.

    Enitity EJBs on the other hand - what a stupid idea. I know where they came from and those guys needed to get out and work in the real world more. Why would anyone want to do relational operations outside the database, esp. in middlware? No one who even vaguely understands dbms internals for sure. Why would anyone whose ever worked with either legacy databases or had to tune (denormalize, etc.) a relational database ever get the idea that tables were entities much less objects?

    As to standards in Java: I like standards when they formalize something so we know we are talking about the same thing and give us confidence we can integrate. I don't like them when the eliminate other options. I also don't think committees ever produce the best standards.
  55. Is this a troll ???

    Just think about your everyday life before posting such silly things : your are relying on standards in every move you make !
    You computer is nothing but an assy of standards.
    Your house is built upon standards.
    Your car is all about standards.
    Power plugs... ha ha, think about non-standard plugs for a second and the adaptors nightmare !
    The music you hear...
    Even your food...

    I think people who has this pitiful opinion about standards should consider stopping coding for 5 minutes and have a look to the oustide world. They should have a quite expressive answer to their questions.

    Standards are not a barrier to innovation, and they're not even "frozen". It's the task of the R&D to improve them and propose new ones. But if you're not a resarcher, I would strongly recommend to stick as most as possible to existing standards. Cause anyway, you'll face the sa

    Have fun,

    Remi
  56. I think that about the time .NET came out in 2001, Sun decided to strengthen and give new life to the JCP. Since then things in the java world have got better: compare j2ee 1.3 (largely created outside of the jcp) width j2ee 1.5 that is coming out, or the new great features of jdk 1.5.
  57. Not at all[ Go to top ]

    Most of those "popular frameworks" are all either build on top of, or provide their most valuable integration functionality with JCP standards.

    As such, the proper way to view things is that standards, at least the good ones, are what steer the the majority of the industry's direction.

    The best frameworks on the other hand, incorporate compatibility with these existing/upcoming standards and then build on top of them to provide additional value. If enough momentum builds for a particular framework, it becomes inevitable that eventually a "standard" version of that framework will be developed.

    Both standards and "non standard" frameworks have their place in the IT ecosystem and they are not by necessity competing against each other.
  58. Standards is a good thing when they are real standards.

    The problem with the Java community today is that too many smart guys that have no real meaningful job dream up standards in vacuum and force that upon the user community with impunity.

    Someone mentioned the power-plug standard, which is a great thing. But, if you extend that analogy to Java, it would be like we have to change all our power-plugs every year because we now have a better and newer standard power-plug.

    By definition, a standard has to have an implementation (usually more than one) that actually does works (and not a demoware, thank you). By definition, a standard has to have a lifespan that is a bit longer than time to take up the standard. For many Java and J2EE standards today, neither is true.

    Another shameful practice is typified by EJB, where they go through EJB, EJB2, EJB3, .. like "Nightmare on Elm Street", yet none of them is an evolution of the previous one. You have to rewrite your app for every new "standard" release.

    So, Java/J2EE standards have been a bad thing because in reality they are not standards. These smart guys just insist they are -- And people believe them.
  59. Standards are a bad thing[ Go to top ]

    Standards are for corporations who want to make integration ware and not really for the rest of us. Look at the standards we have today. HTTP possibly the worst protocol in existence running the internet. Almost every Java standard is outdated and not worth using. Only huge corporations who are trying to sell millions of dollars of licenses could possibly move so slowly and in the wrong direction all at once.

    Hmmm shall we talk about the boat anchors that most of the J2EE app servers now are? Is one better than the other? Is the tech outdated and quaint? Is J2EE the end of the line for Java since it cant seem to focus on anything productive outside of J2EE containers as if that were the holy grail?

    How many of the specs that have been issued in the past 6-7 years have been dismissed as pure tripe by the intelligent, and simultaneously implemented by fortune 500 unwitting fools with hordes of corporate consultants on hand to light the fire of monumental software disasters and run before the explosions?

    Standards:

    Stifle innovation

    Provide integration lockin

    Automatically reduce competition to the lowest common demoninator usage

    Provide architectural copouts for bad design. Oh the spec doesnt make anything work, it just tells you how to fail and suggests that that failure is better than your hand rolled success.

    Provide implementation copouts...well the API cant do that and we cant (or wont) deviate.

    Anybody interested in standardization please stop hurting America and just go out there and solve a problem.

    By the time your done writing, amending and evangelizing your spec its probably either been dismissed as junk or as obvious as the paint on the wall and about as fun to watch dry.

    Can the software industry please throw away its crutches and walk forward?
  60. Standards are a bad thing[ Go to top ]

    Standards:

    [snip]

    Provide integration lockin

    I disagree with what you are saying in a lot of ways but the above is particularly queer.

    What exactly is 'integration lockin'? One of the great benefits of standards is that they help you avoid vendor lock-in. I'm not sure how a standard locks you into anything anymore than not having a standard. We use a proprietary tool at my job right now. It sucks. Because all of the code is in a proprietary language (of sorts) the cost to move to a different tool is extremely prohibitive.

    How did not using standards help us exactly?

    Another thing is that I need to communicate with 100s of different companies. How do you suggest we handle this without standards?

    You bag on HTTP, but what do you think you are using when you post to this site? Maybe it isn't perfect, but if there was no such standard, how would the Web work? There is no web without a standard. Browsers can't support a different protocol for every website. What you are arguing makes no sense to me.
  61. EJB[ Go to top ]

    les EJB c de la balle