Opinion: JCP needs to be sped up to keep Java competitive


News: Opinion: JCP needs to be sped up to keep Java competitive

  1. Newsfactor.com published a somewhat sensationalist "special report" claiming that of Sun does not get its act together and speed up the JCP process, it might find itself losing the tiny battles that make up its competition with .NET.

  2. I agree[ Go to top ]

    ...The JDO 2.0 JCP process was finally "kicked-off", but do any of us expect the improved specification to exist in final form very much earlier than 2005?

    Rather sad, considering how badly it is needed.
  3. I do not think that the 2.0 spec will take that long to get here.
    The spec itself will not be the bottle neck either. It is the TCK and RI that takes up a lot of the time.

  4. claiming that of Sun does not get its act together and speed up the JCP process,

    > it might find itself losing the tiny battles that make up its competition with
    > .NET.

      Well, the article misses the point and a better title would be "Is a 10000 % Sun Certified API Java Finished?" for example. That is to say the Java Cartel Process (TM) is increasingly irrelevant and if I dare to say so is Sun stewardship over Java. Viva the Java Republic and the Free World!

      For more background reading about "Operation Java Freedom" check out Viva! site @ http://viva.sourceforge.net and the Java Republic news blog @ http://viva.sourceforge.net/republic
  5. The Newsfactor article looks pretty silly to me. I work with software developers in IT shops all over the world and what I hear in general is IT shops are still heterogeneous (meaning they're not dumping J2EE for .NET, and not dumping .NET for J2EE, but instead using both) and that they want software development on both platforms to be easier.

    One thing I wish for J2EE and the JCP is that that Sun would accellerate their work on J2EE 1.5. We've had so much time to digest what's in 1.4 (mostly Web Service and XML handling stuff that I already had) that I'm wanting to dig into 1.5.

    -Frank Cohen
    TestNetwork 1.1 now shipping
  6. I don't agree with everything in the article but I agree that the JCP is waaay too slow. Take JSF for example its been a JSR for as long as I can remember! If you look at the ASP.NET framework it seems like Microsoft copied JSF (i.e. they are very similar... copying is OK to do anyway thats not really my point) however JSF has not even been released yet! Its quite unfortunate really. We are expecting JSF late this year (or next year ... probably even without a standard tree component!) and "project rave" mid next year several years after ASP.NET has been released/matured, etc. We definately need a faster JCP for Java/j2ee to be more competitive (i.e. be proactive not reactive ... management 101).

    <end rant/>

    Just my 2 pence ;-)


  7. The JCP is moving at the right speed.[ Go to top ]

    Just to play devil's advocate, I'd like to say that the JCP is moving at the right speed. Complex multivendor/multi-environment standards demand that you take your time.

    Users alway demand tons of features and want them completed and delivered yesterday. It's the craftsman's job to manage user's expectations and make them aware that all decisions are a tradeof of features versus resources versus quality versus time. You can't have it all.

    In the case of the the JCP process, the craftsmen are the JCP spec writers and the "users" are Java developers. The key problem with the JCP spec writers is that they haven't managed the expectations of Java developers. If the community wants the JCP process to go faster, it needs to do one or more of the following:

    1) increase resources (perhaps by increasing JCP membership prices -- something independent and small business JCP members wouldn't like)

    2) lower the quality of the JCP (get rid of a few draft versions or be more careless in the specification -- see the Microsoft MSDN documentation for Win32 as an example)

    3) reduce the features or scope of the JCP (don't try and standardize so much in each JCP or make each JCP simpler or say that JCPs don't have to be multivendor and that Oracle/IBM/... can "standardize" it's current implementation as being a JCP "standard")

    Personally, I think that reducing the scope of each JCP is the best way, but that's my minimalistic bias coming through.

    Either way, Java is doing just fine with the current process. The slow JCP process does not hinder Java innovation and standardization. Even though Struts, Ant, XDoclet, and JUnit are not JCP standards, they are supported by virtually every major appserver vendor and there's an ample number of books and training material on these non-JCP standards. Some of these non-JCP standards have become so popular that they're now going through JCP standardization (e.g. XDoclet->Java Metadata, Struts->JSF)