JCP Creates JSR 244: J2EE 1.5 Specification


News: JCP Creates JSR 244: J2EE 1.5 Specification

  1. JCP Creates JSR 244: J2EE 1.5 Specification (10 messages)

    This JSR is to develop J2EE 1.5, the next release of the Java 2 Platform, Enterprise Edition, targeted to ship in the second half of 2005.
    The major theme for the next version of J2EE is ease of development. The clear message we've heard from J2EE vendors and users is that the J2EE platform must evolve quickly to support a wider range of developers, including less sophisticated developers.

    JSR-175 (A Metadata Facility for the JavaTM Programming Language) is the enabling facility for a new declarative style of programming that significantly simplifies many programming tasks. J2EE must move quickly to take advantage of this capability and deliver significant improvements to ease of development for J2EE developers. In particular, this capability will be used to simplify the development of web service applications.

    J2EE 1.4 delivered basic web services support, including support for the WS-I Basic Profile, for the Java platform. Web service standards continue to evolve and it is critical that the Java platform support the latest web service standards.

    We propose that:

    • J2EE 1.5 will define the J2EE component model, deployment, packaging, and container requirements for J2EE components that use Java language annotations, as defined by J2EE component JSRs.
    • J2EE 1.5 will further define the J2EE component model, deployment, packaging, and container requirements for J2EE components that provide or use web services.
    Visit JSR 244: Java 2 Platform, Enterprise Edition 1.5 (J2EE 1.5) Specification

    Threaded Messages (10)

  2. J2EE 1.5[ Go to top ]

    this is a good news to here but JSF and other web technologies in its current form will not be able to compete with offering I belive more componenets needs to be added to JSF in order to compete with in terms of ease of use and richness this is very important in the web developmnt Arena I belive a second JSF spasfication can be drafted before the first realease of J2EE 1.5
    the reason behind this is that if we JSF to emerge a rich GUI componenets too if JSF can provide in the " spacificaions " rich controls such as :
    menues,trees,...etc that would be an excellent addetion and that way even 2-tier applications can more audiance .
  3. JSF[ Go to top ]

    this is a trailer to my first message where I have loooked up some implementations and componeents built using JSF actually what make wonders is that JSF is supposed to be a counterpart for and seems to provide much more functionality and componenets more that JSF wjat SUN really needs to do in J2EE 1.5 in to stuff more componeents for the developers to make the development and reuse much easier and folllowing the standars I belive since we have the foundation those components can be drafted in the next specification even before the realse of J2ee 1.5
    and please lets not forget that 70% or more of the web solutions dosen't need to use EJB .
  4. :-( Bad New
    I have seen nothing about JDO or other persistence interfaces ?
    :-) Good news
    JSF, i hope the jsr will give us a powerful tool on the Gui side !
  5. JSR 168[ Go to top ]

    Nothing about JSR 168 (Portlet API)! I hope it will be included in J2EE spec someday!

  6. The major theme for the next version of J2EE is ease of development. The clear message we've heard from J2EE vendors and users is that the J2EE platform must evolve quickly to support a wider range of developers, including less sophisticated developers.
    I'm pleased to see the announcement of JSR-244. J2SE 1.5 does indeed promise a number of development aids which should be promoted into the Enterprise Edition to improve ease of use.

    JSR-220 is explicitly listed as a candidate JSR. This is the EJB 3.0 spec which aims to make EJB development easier. However, in the absence of much concrete information as to how this might be manifest, I suggest that the Java community needs an official advocacy of alternative solutions particularly for persistence.

    JSR-243 is not explicitly listed. This is the JDO 2.0 JSR. Adding JDO 2.0 into the mix of technologies which make up the J2EE platform would be widely welcomed by the broader community. Developers looking for a standards-based persistence platform already have a choice between CMP and JDO, since JDO is a Standard Extension of the Java platform. However, it would help the community for JDO to be promoted into the "Enterprise" stable. There are already plenty of examples of JDO's usage in such contexts, whether fronted by Web components, EJB components or both. Indeed, there distinct lack of a persistence solution in J2EE itself for use by web components without requiring the services of a full-blown EJB container.

    Thanks, Robin.
  7. Don´t forget J2SDK[ Go to top ]

    Another thing to have in mind: J2SE 1.5 compatibility (generics, annotation,...)
  8. I think EJB should fully support the inheritance !!!
  9. I think EJB should fully support the inheritance !!!
    There are lots of things that the Java community urgently needs from EJB 3.0.

    1. Testability. EJBs are not easily tested; in particular they do not work well outside the container due to their heavy reliance (and compile-time dependency) on EJB interfaces.

    2. Ease of development. There's still too much infrastructure code in a Session/MessageDriven Bean. They should be POJOs with descriptors.

    3. Session bean naming. Can we rename "Stateless Session" Beans to "Service" Beans please?

    4. Lack of inheritance for Entity Beans.

    5. Lack of polymorphism (particularly regarding Entity queries).

    6. Lack of a dynamic query capability.

    7. Performance/scalability problems due to the multi-row finder architecture.

    8. Lack of encapsulation of data in Entity Beans, violating OO best practices.

    9. Due largely to point 8 above, the inability to write "behaviourally complete" entities (as per the Pawson/Matthews definition in "Naked Objects" [Wiley]).

    10. Linked to point 1, the inability to run entity beans outside the container, the inability easily to test entity bean logic, and the inability to use "transient" (non-persistent) versions of entity beans. They should behave the same, with “persistent” instances merely living longer than their in-memory incarnation.

    Naturally I'm cherry-picking the particular Entity Bean gripes which I know JDO 1.0 already solves and which JDO 2.0 strengthens; I'm sure many other people have additional problems with the Entity bean architecture (and the EJB architecture in general).

    JDO (and Hibernate) have shown us the power of transparent persistence. Design methodologies such as Domain Driven Design and Streamlined Object Modelling have shown us the benefits of "behavioural completeness" in our persistent domain object models.

    Now it is the turn of the J2EE team to recognize the underlying shift in application architecture and design which these philosophies (e.g. behavioural completeness), methodologies (e.g. DDD, SOM) and technologies (e.g. JDO, Hibernate) are bringing to the Java platforms. The user base is asking for transparent persistence, and within the JCP that means JDO. It is time for JDO to become part of J2EE.

    It has always been my belief that Entity Beans should be a well-specified but "optional feature" of EJB 3.0, allowing for the evolution of low-cost and low-footprint containers which choose not to implement that part of the spec. I doubt that the J2EE folks will go quite that far (although I think they should – we might even get extensions to Spring and Pico which render them J2EE-compliant!), but it certainly is time for JDO to be explicitly and deliberately included in the Enterprise platform.

    Kind regards, Robin.

    The English language PDF Edition of my book, “Java Data Objects” by Roos (Addison-Wesley), is available for download through

    The Chinese language Printed Edition of my book, “Java Data Objects” by Roos (Posts & Telecom Press), is also available. See
  10. Backing JDO for a place in J2EE 1.5[ Go to top ]

    Before the JCP will promote a J2SE API (e.g. JDO) into the J2EE platform there needs to be a critical mass behind the technology. Many facttors contribute to such critical mass, but not the least of these is the "noise" made by the wider Java community.

    If you agree with what I wrote don't be silent - this merely comes across as apathy. Instead, post a sentance stating that you'd like to see JDO in the J2EE 1.5 platform and another sentance saying why.

    If you disagree, then likewise post a message indicating why you think JDO should not be part of J2EE 1.5.

    I know that these informal community discussions are closely watched by many influential people.

    Thanks, Robin.
  11. JDO should definitely be part of J2EE. (Maybe we should have it in J2SE asap, then it will automatically make its way into J2EE. I can think of some reasons to have a light-weight persistency framework in J2SE.)

    I find this article rather worrying.