Sun's withdrawn JSR-189, Java 3D API 1.4 from the Java Community Process (JCP). I'm not sure exactly why.
Timesys has submitted JSR 289, SIP Servlet v1.1 to the Java Community Process. According to the JSR:
The SIP Servlet Specification (JSR116) is a container based approach (modelled on the HTTP servlet paradigm) to developing communication applications utilizing the Session Initiation Protocol (SIP) protocol. SIP is used to establish and manage multimedia IP sessions. This JSR requests the evolution of the SIP Servlet specification to address capabilities discovered by the industry as a result of using the specification. Some of the core requirements requiring the evolution of this specification are:
This list of requirements is not necessarily complete and this will be explored further in the expert group - for example, additional support could be defined for initial and subsequent request, inter-servlet loop detection, additional protocol support, complex SIP dialog management, explicit header manipulation, JMX management, 3GPP IMS support and inter-servlet communication. It is intended that the priority of each of these enhancements be defined by the expert group with the goal of defining the API in an incremental manner satisfying a bulk set of requirements in each release. This is done to ensure timely delivery of the API as well as in order to gain experience with some of the more advanced features prior to standardization.
Application Composition: The ability to map certain communication features to SIP Servlets and in-turn invokes those features in an independent manner is desirable. It is clear that a SIP Servlet environment should be able to support the composition on a call of multiple SIP servlets application written by unrelated parties and to have that composition produce good, predictable results. It is necessary to define when, if or how one SIP Servlet application is invoked to service a request with respect to another SIP Servlet application.
Application Invocation: When multiple applications are invoked the SIP servlet environment should define behaviour for the order in which applications or the triggering rules are considered. While SIP Servlet v1.0 does dictate an order for triggering rules within a servlet application it does not dictate anything about the order in which servlet applications themselves or their rules should be considered for invocation.
Application Convergence: The ability to move seamlessly between HTTP and SIP servlets within a convergence application.
Deployer support for Application Invocation and Composition: There is a need to define a mechanism that enables the deployer to have control, either real time or operational, over when and how SIP Servlet applications are invoked to handle communication requests. This needs to be a standard, non-proprietary mechanism whereby the deployer has a well understood role in determining the invocation of SIP Servlet applications.
Enhanced SIP Servlet control of Application Invocation: SIP servlets should be able to convey their intentions about how they wish subsequent service invocation to take place. For example, a B2BUA SIP Servlet application can be invoked and receive an initial request as a UAS. When it issues another request as a UAC, it has no way to indicate to the container or any deployer logic that how it wishes the new INVITE to be considered. Should the INVITE be routed as if it were received anew by the container or, should this request continue to be "routed" to subsequent applications as if it were a 'continuation' of the service invocation process that had already been started and resulted in the invocation of the B2BUA application.
Formal Distinction between Caller and Callee services: The SIP Servlet specification defines no formal distinction between callee and caller services, therefore SIP servlets cannot easily determine on whose behalf they are being invoked. Many telecommunications features involve application logic that acts on behalf of a particular subscriber where the functionality of the application needs to be present whether the subscriber places or receives calls.
Timesys has submitted JSR 282, RTSJ version 1.1 (Realtime Specification for Java, to the Java Community Process. According to the JSR:
This proposal addresses some of the simpler enhancements that have been requested in the RTSJ:
- Add waitForNextRelease() and release() to RealtimeThread so real-time threads will be better able to handle aperiodic processing.
- Investigate a class, similar to the weak reference classes, that supports references between memory areas that would normally be forbidden by the RTSJ assignment rules.
- Relax the ?bi-directional reference rule? for parameter objects.
- Add new methods in the Timed and Timer classes to more easily support both start relative to now and start relative to the original start time, for reset and reschedule.
- Add a form of Timed.reset() that resets the timeout for the current execution.
- Add new methods to query the state of Timers and real-time threads.
- Add a method to Schedulable and processing group parameters, that will return the elapsed CPU time for that schedulable (if the implementation supports CPU time)
- Add an option for AEH that will cause the AEH?s memory area to be entered each time the AEH invokes handleAsyncEvent()
- Consider a method that determines whether there is more than one reference to an object. (To better support ?recycling lists?)
- Add a blocking factor value to ReleaseParameters to support better feasibility analysis
- Review the current support for real-time garbage collectors, and expand it if necessary.
- Associate a scheduling eligibility value with async events.
- Permit all errors associated with exceeding RTSJ resource limits to fire async events (or alternatively, release async event handlers). Currently some of them can only throw exceptions.
- Add new methods as necessary to consistently provide both a method that creates a returned object and one that takes a destination wherever those forms are appropriate.
- Update the documentation for the physical memory classes to improve their clarity. Make the minimum modifications to the semantics and APIs required to fix any problems that justify such changes.
- Update the semantics for cost enforcement to permit support of the invariant that a schedulable's CPU use in each period is bounded by the cost.
- Consider compatible modifications to the RTSJ that would make it easier to limit the use of immortal memory.
- Modify the specification as required to clarify any interaction with Java™ 5.
- Consider hierarchical processing group parameters.
- Consider improvements to the wait-free queue classes, or possibly new classes with similar services.
- Consider enhancements to the async event system to let events carry data.