Wednesday Dec 19, 2012

Adopt-a-JSR for Java EE 7 - Getting Started


Adopt-a-JSR is an initiative started by JUG leaders to encourage JUG members to get involved in a JSR, in order to increase grass roots participation. This allows JUG members to provide early feedback to specifications before they are finalized in the JCP. The standards in turn become more complete and developer-friendly after getting feedback from a wide variety of audience. adoptajsr.org provide more details about the logistics and benefits for you and your JUG. A similar activity was conducted for OpenJDK as well. Markus Eisele also provide a great introduction to the program (in German).

Java EE 7 (JSR 342) is scheduled to go final in Q2 2013. There are several new JSRs that are getting included in the platform (e.g. WebSocket, JSON, and Batch), a few existing ones are getting an overhaul (e.g. JAX-RS 2 and JMS 2), and several other getting minor updates (e.g. JPA 2.1 and Servlets 3.1). Each Java EE 7 JSR can leverage your expertise and would love your JUG to adopt a JSR.

What does it mean to adopt a JSR ?
  1. Your JUG is going to identify a particular JSR, or multiple JSRs, that is of interest to the JUG members. This is mostly done by polling/discussing on your local JUG members list.
  2. Your JUG will download and review the specification(s) and javadocs for clarity and completeness. The complete set of Java EE 7 specifications, their download links, and EG archives are listed here. glassfish.org/adoptajsr provide specific areas where different specification leads are looking for feedback.
  3. Your JUG can then think of a sample application that can be built using the chosen specification(s). An existing use case (from work or a personal hobby project) may be chosen to be implemented instead. This is where your creativity and uniqueness comes into play.
Most of the implementations are already integrated in GlassFish 4 and others will be integrated soon. You can also explore integration of multiple technologies and provide feedback on the simplicity and ease-of-use of the programming model. Especially look for integration with existing Java EE technologies and see if you find any discrepancies. Report any missing features that may be included in future release of the specification.

The most important part is to provide feedback by filing bugs on the corresponding spec or RI project. Any thing that is not clear either in the spec or implementation should be filed as a bug. This is what will ensure that specification and implementation leads are getting the required feedback and improving the quality of the final deliverable of the JSR.

How do I get started ?

A simple way to get started can be achieved by following S.M.A.R.T. as explained below.

Specific Identify who all will be involved ? What would you like to accomplish ? For example, even though building a sample app will provide real-world validity of the API but because of time constraints you may identify that reviewing the specification and javadocs only can be accomplished. Establish a time frame by which the activities need to be complete.
Measurable Define a success for metrics. For example, this could be the number of bugs filed. Remember, quality of bugs is more important that quantity of bugs. Define your end goal, for example, reviewing 4 chapters of the specification or completing the sample application. Create a dashboard that will highlight your JUG's contribution to this effort.
Attainable Make sure JUG members understand the time commitment required for providing feedback. This can vary based upon the level of involvement (any is good!) and the number of specifications picked. adoptajsr.org defines different categories of involvement. Once again, any level of involvement is good. Just reviewing a chapter, a section, or javadocs for your usecase is helpful.
Relevant Pick JSRs that JUG members are willing and able to work. If the JUG members are not interested then they might loose motivation half-way through. The "able" part is tricky as you can always stretch yourself and learn a new skill ;-)
Time-bound Define a time table of activities with clearly defined tasks. A tentative time table may look like:

Dec 25: Discuss and agree upon the specifications with JUG
Jan 1: Start Adopt-a-JSR for Java EE 7
Jan 15: Initial spec reading complete. Keep thinking through the application that will be implemented.
Jan 22: Early design of the sample application is ready
Jan 29: JUG members agree upon the application
Next 4 weeks: Implement the application

Of course, you'll need to alter this based upon your commitment. Maintaining an activity dashboard will help you monitor and track the progress.

Make sure to keep filing bugs through out the process!

12 JUGs from around the world (SouJava, Campinas JUG, Chennai JUG, London Java Community, BeJUG, Morocco JUG, Peru JUG, Indonesia JUG, Congo JUG, Silicon Valley JUG, Madrid JUG, and Houston JUG) have already adopted one of the Java EE 7 JSRs. I'm already helping some JUGs bootstrap and would love to help your JUG too.

What are you waiting for ?



Saturday Dec 03, 2011

Java EE 7: Key features, Specifications, Projects, Mailing List Archives, ...

An update and summary of the key features of different specifications in the Java EE 7 platform ...

Java EE 7 (JSR 342)
  • The main theme is to easily run applications on private or public clouds
  • The platform will define application metadata descriptor to describe PaaS execution environment such as multi-tenancy, resources sharing, quality-of-service, and dependencies between applications
  • Embrace latest standards like HTML5, WebSocket, JSON and have a standards-based API for each one of them
  • Remove inconsistencies between Managed Beans, EJB, Servlets, JSF, CDI, and JAX-RS
  • Possible inclusion of JAX-RS 2.0 in the Web Profile, revised JMS 2.0 API
  • Technology Refresh for several existing technologies (more on this below) and possible inclusion of Concurrency Utilities for Java EE (JSR 236) and JCache (JSR 107)
  • Status

JPA 2.1 (JSR 338)

  • Support for multi-tenancy
  • Support for stored procedures and vendor function
  • Update and Delete Critieria queries
  • Support for schema generation
  • Persistence Context synchronization
  • CDI injection into listeners
  • Status

JAX-RS 2.0 (JSR 339)

  • Client API - low level using builder pattern and possibly a higher level on top of that
  • Hypermedia - easily create and process links associated with resources
  • Form or Query parameter validation using Bean Validation
  • Closer integration with @Inject, etc
  • Server-side asynchronous request processing
  • Server-side content negotiation using "qs"
  • Status

Servlets 3.1 (JSR 340)

  • Optimize the PaaS model for Web applications
  • Multi tenancy for security, session, resources, etc.
  • Asynchronous IO based on NIO2
  • Simplfiied asynchronous Servlets
  • Utilize Java EE concurrency utilities
  • Enable support for WebSockets
  • Status:

Expression Language 3.0 (JSR 341)

  • Separate ELContext into parsing and evaluation contexts
  • Customizable EL coercion rules
  • Reference static methods and members directly in EL expressions
  • Adding operators like equality, string concatenation, and sizeof etc.
  • Integration with CDI such as generating events before/during/after the expressions are evaluated
  • Status

Java Message Server 2.0 (JSR 343)

  • Ease of development - changes to the JMS programming model to make the application development simpler and easier
  • Remove/Clarify ambiguities in the existing specification
  • Integration with CDI
  • Clarification of the relationship between JMS and other Java EE specs
  • A new mandatory API to allow any JMS provider to be integrated with any Java EE container
  • Multi-tenancy and other cloud-related features from the platform
  • Status

Java Server Faces 2.2 (JSR 344)

  • Ease of Development - making configuration options dynamic, make cc:interface in composite components optional, shorthand URLs for Facelet tag libraries, integration with CDI, OSGi support for JSF artifacts
  • Support implementation of Portlet Bridge 2.0 (JSR 329)
  • Support for HTML5 features like HTML5 Forms, Metadata, Heading and Section content model
  • Flow management, Listener for page navigation events, and new components like FileUpload and BackButton
  • Status

EJB 3.2 (JSR 345)

  • Enhancements to the EJB architecture to enable PaaS, such as multi-tenancy
  • Factorization of container-managed transactions to use outside EJB
  • Further use of annotations
  • Alilgnment and integration with other specifications in the platform
  • Status

CDI 1.1 (JSR 346, more details)

  • Global ordering of interceptors and decorators
  • API for managing built-in contexts
  • Embedded mode to allow startup outside Java EE container
  • Declarative control over which packages/beans are scanned in an archive
  • Injection for static members such as loggers
  • Send Servlet events as CDI event
  • Status

Bean Validation 1.1 (JSR 349)

  • Integration with other Java EE specs
    • JAX-RS: Validate parameters and return values on HTTP calls
    • JAXB: Convert constraints into XML schema descriptor
  • Method level validation
  • Apply constraints on group collection
  • Extend the model to support AND and OR style composition
  • Status
JCache (JSR 107)
  • API and semantics for temporary, in-memory caching of Java objects, including object creation, shared access, spooling, invalidation, and consistency across JVMs
  • Package: javax.cache
  • Status
    • Approved by the JCP
    • Spec lead: Yannis Cosmadopoulos, Cameron Purdy (Oracle) and Gregory Luck (Software AG)
    • Project page: jsr107spec
    • Mailing List Archive: jsr107@googlegroups.com

State Management (JSR 350)
  • API that can be used by applications and Java EE containers to offload the responsibility of statement management into third party providers with different QoS characteristics
  • Java SE-based callers can access the state data by querying the state providers
  • Providers with different QoS can be added and API callers can query to meet their criteria
  • Package: javax.state and javax.state.provider
  • Status
Batch Application for the Java Platform (JSR 352)
  • Programming model for batch applications and a runtime for scheduling and executing jobs
  • Defines Batch Job, Batch Job Step, Batch Application, Batch Executor, and Batch Job Manager for the standard programming model
  • Package: javax.batch
  • Status

Concurrency Utilities for Java EE (JSR 236)

  • Provides a clean, simple, independent API by building on JSR 166, making it appropriate for use within any Java EE contianer.
  • Package: javax.util.concurrent
  • Status
    • Approved by the JCP
    • Spec lead: Anthony Lai, Naresh Revanuru (Oracle)
    • Project page:
    • Mailing List Archive:

Java API for JSON Processing (JSR 353)



The Expert Groups for most of the JSRs have already been formed but you can still participate by joining the publicly visible aliases and reviewing the drafts. All the JSRs following JCP 2.8 are run more transparently and some of the highlights on that front are:

  • Names of the EG members are publicly visible
  • EG business reported on publicly readable alias
  • Schedule is public, current and updated regularly
  • Public can read/write to a wiki to discuss the status so far
  • Discussion board on jcp.org
  • Public read-only issue tracker

And you know all of this will be integrated in GlassFish - the Reference Implementation for Java EE 7!

Check out some early work at glassfish.org/javaone2011.

Tuesday Mar 08, 2011

TOTD #158: Java EE 7 JSRs: JPA 2.1, JAX-RS 2.0, Servlets 3.1, EL 3.0, JMS 2.0, JSF 2.2, CDI 1.1, Bean Validation 1.1

Java EE 6 specifications were approved on Dec 1st 2009 and the corresponding binaries and TCK were released on Dec 10th 2009. Oracle GlassFish Server 3.1 added Clustering and High Availability capabilities to Java EE 6 applications, and many other features, and was released on Feb 28th 2011. Now the wheels are chugging along and several Java EE 7 JSRs have been filed. This Tip Of The Day (TOTD) provides a summary of propopsed features in each of the JSR (make sure to read the proposed JSR for the complete list) ...

Java EE 7 (JSR 342)

  • The main theme is to easily run applications on private or public clouds
  • Application metadata descriptor to describe PaaS execution environment such as multi-tenancy, resources sharing, quality-of-service, and dependencies between applications
  • Embrace latest standards like WebSocket, HTML5, JSON and have a standards-based API for each one of them
  • Remove inconsistencies between Managed Beans, EJB, Servlets, JSF, CDI, and JAX-RS
  • Inclusion of JAX-RS 2.0 in Web Profile
  • Technology Refresh for several existing technologies (more on this below) and possible inclusion of Concurrency Utilities for Java EE (JSR 236) and JCache (JSR 107)
  • Spec leads: Roberto Chinnici, Bill Shannon (Oracle)

JPA 2.1 (JSR 338)

  • Multi-tenancy
  • Support for stored procedures and vendor function
  • Update and Delete Critieria queries, JPQL <-> Critieria mapping
  • Support for schema generation
  • Persistence Context synchronization
  • Dynamic definition of PU
  • Additional event listeners
  • Approved by the JCP EC, watch the progress at jpa-spec@java.net, spec lead: Linda DeMichiel (Oracle)

JAX-RS 2.0 (JSR 339)

  • Client API - low level using builder pattern and a higher level on top of that
  • Hypermedia
  • MVC Pattern - Resource controller and pluggable viewing technology
  • Form or Query parameter validation using Bean Validation
  • Closer integration with @Inject, etc
  • Server-side asynchronous request processing
  • Server-side content negotiation
  • Approved by the JCP EC, watch progress at jax-rs-spec@java.net, spec leads: Roberto Chinnici, Marek Potociar (Oracle)

Servlets 3.1 (JSR 340)

  • Multi tenancy for security, session, resources, etc.
  • Asynchronous IO based on NIO2
  • Simplfiied asynchronous Servlets
  • Utilize Java EE concurrency utilities
  • Enable support for WebSockets
  • Spec leads: Shing Wai Chan, Rajiv Mordani (Oracle)

Expression Language 3.0 (JSR 341)

  • Separate ELContext into parsing and evaluation contexts
  • Customizable EL coercion rules
  • Reference static methods and members directly in EL expressions
  • Adding operators like equality, string concatenation, and sizeof etc.
  • Integration with CDI such as generating events before/during/after the expressions are evaluated
  • Spec lead: Kin-man Chung (Oracle)

Java Message Server 2.0 (JSR 343)

  • Ease of development
  • Remove/Clarify ambiguities in the existing specification
  • Integration with CDI
  • Clarification of the relationship between JMS and other Java EE specs
  • A new mandatory API to allow any JMS provider to be integrated with any Java EE container
  • Spec lead: Nigel Deakin (Oracle)

Java Server Faces 2.2 (JSR 344)

  • Ease of Development - make cc:interface in composite components optional, shorthand URLs for Facelet tag libraries, integration with CDI
  • Support implementation of Portlet Bridge 2.0 (JSR 329)
  • Support for HTML5 features, Flow management, Listener for page navigation events, and new components like FileUpload and BackButton
  • Spec lead: Ed Burns (Oracle)

CDI 1.1 (details - JSR TBD)

  • Global ordering of interceptors and decorators
  • API for managing built-in contexts
  • Embedded mode to startup outside Java EE container
  • Injection for static members such as loggers
  • Send Servlet events as CDI event
  • Spec lead: Pete Muir (RedHat)

Bean Validation 1.1 (details - JSR TBD)

  • Integration with other specs
    • JAX-RS: Validate parameters on HTTP calls
    • JAXB: Convert into XML schema descriptor
    • JPA: DDL Generation
  • Method level validation
  • Apply constrains on group collection
  • Spec lead: Emmanuel Bernard (RedHat)

JPA 2.1 and JAX-RS 2.0 are already approved by the JCP Executive Committee and others are going through a review ballot. And then the EG needs to be formed, specifications and implementations delivered so its a long road ahead. But hey, this group has delivered every time in the past and we'll do it again :-) And this time all the JSRs are run more transparently and some of the highlights on that front are:

  • Names of the EG members are publicly visible
  • EG business reported on publicly readable alias
  • Schedule is public, current and updated regularly
  • Public can read/write to a wiki to discuss the status so far
  • Discussion board on jcp.org
  • Public read-only issue tracker

Here is a latest slide deck I delivered at OTN Developer Day Boston last week giving a good mix of Java EE 6 and providing an insight into the future:

I expect this slide deck to stay current and add more details as they become available, so stay tuned ...

Technorati: totd javaee6 javaee7 glassfish jcp jsr

Friday Aug 25, 2006

JSR 261 and JAX-WSA Future

JSR 261 (Java API for XML Web Services Addressing, JAX-WSA) has been operating under the assumption that it would layer on top of JAX-WS 2.0 (JSR 224). This enabled us to provide WS-Addressing functionality without delaying the JAX-WS 2.0 EG. The plan was to later make this JSR into a required component of a future version of the Java web services stack.

After looking at the current state of JSR 261 and listening to the feedback we received from community, this API seems to provide a rich and powerful API for WS-Addressing that is more targeted to stack implementers rather than to the end developer. In order to simplify the programming model for WS-Addressing for JAX-WS developers, we are revisiting those initial assumptions at the first available opportunity, namely the upcoming JAX-WS 2.1 Maintenance Release (MR).

We are converging the JSR 261 specification and API with the upcoming JAX-WS 2.1 MR. Here is a top-level summary of the proposed changes:

  1. Simpler abstraction of EndpointReference as a first-class citizen in JAX-WS.
  2. Standard way to enable WS-Addresing in JAX-WS using @BindingType.
  3. Various JAX-WS APIs expose/consume EPR.
  4. Action/FaultAction moved from JSR 261 to JAX-WS MR.

The proposals are being discussed with JSR 261 and JSR 224 EG. Since all the relevant functionality from JSR 261 will be incorporated in the JAX-WS MR, this would also mean that JSR 261 will be withdrawn from the JCP.

We believe this approach is the right thing to do for the specifications, the platform and the community. Leave a comment or send your feedback.

Technorati: JSR JCP JAXWS Web Services

About

profile image
Arun Gupta is a technology enthusiast, a passionate runner, author, and a community guy who works for Oracle Corp.


Java EE 7 Samples

Stay Connected

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today