Java News from Monday, January 16, 2006

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.

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:

  1. Add waitForNextRelease() and release() to RealtimeThread so real-time threads will be better able to handle aperiodic processing.
  2. 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.
  3. Relax the ?bi-directional reference rule? for parameter objects.
  4. 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.
  5. Add a form of Timed.reset() that resets the timeout for the current execution.
  6. Add new methods to query the state of Timers and real-time threads.
  7. 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)
  8. Add an option for AEH that will cause the AEH?s memory area to be entered each time the AEH invokes handleAsyncEvent()
  9. Consider a method that determines whether there is more than one reference to an object. (To better support ?recycling lists?)
  10. Add a blocking factor value to ReleaseParameters to support better feasibility analysis
  11. Review the current support for real-time garbage collectors, and expand it if necessary.
  12. Associate a scheduling eligibility value with async events.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. Consider compatible modifications to the RTSJ that would make it easier to limit the use of immortal memory.
  18. Modify the specification as required to clarify any interaction with Java™ 5.
  19. Consider hierarchical processing group parameters.
  20. Consider improvements to the wait-free queue classes, or possibly new classes with similar services.
  21. Consider enhancements to the async event system to let events carry data.