From: Douglas Wells [d.wells@opengroup.org]
Sent: Wednesday, March 24, 2004 7:03 AM
To: SC Java Spec Development
Subject: My Notes/Minutes on the SC Java spec meeting at the San Diego
Conference

Folks,

I apologize for the delay in getting these notes out. I kept promising myself that I would do a more complete job of expanding the rationale. At this point, I have a set of additional notes from Kelvin that I still need to factor in.  I will do that and release these notes for Joe Bergmann to post after I give the participants a week or so to correct errors.

 - dmw

-----------------------------------------------------------------------

Several members of the Safety Critical Java Working group met on Friday morning, February 6, 2004 at The Open Group's San Diego conference.  Attendees included:
	Joe Bergmann		(The Open Group)
	Bill Bush		(Sun Microsystems)
	Alessandro Coglio	(Kestrel Technology LLC)
	James Hunt		(Forschungszentrum Infomatik)
	Edwin Lee		(Raytheon)
	Doug Locke		(TimeSys)
	Kelvin Nilsen		(Aonix)
	Sumit Ray		(BAE Systems Control)
	Doug Wells		(The Open Group)

The resulting action items were:
	All: Look at CDC and see what needs to be removed (in terms
		of libraries). Exchange lists  of what needs to
		be done.
	Bush: Determine the state and reasoning of CLDC with respect
		to floating point and class loading.
	Kelvin Nilsen: Elaborate justification for eliminating
		scheduler interface in SC Java.
	Kelvin Nilsen: Propose new memory construct, something
		beyond immortal memory, similar to scoped memory,
		but without run-time hazards.
	Doug Locke: Entice Peter Dibble to contribute to new memory
		proposal.
	Doug Locke: Expand on proposed concept of a filter for Raw
		memory access and RTSJ investigation/discussions.

There were several general issues upon which we seemed to have reached consensus at the conceptual level.  Some of the ramifications of these issues caused prolonged discussions, but the results were generally consistent with the general concepts:

	- We need to specify a subset of "Java," not just RTSJ.
	  (Thus, we need to provide an enumeration of both the
	  language and the libraries that would be guaranteed to
	  be available in the minimum implementation of SC Java.)

	- SC Java will be the minimally capability version of a
	  series of real-time platforms.  There should be a smooth
	  growth path from the SC Java as the minimum implementation
	  up through full Java. It is expected that RTSJ, or an
	  updated RTSJ, would be included on the path. The general
	  intent is that an application that operates on one
	  platform would also operate on a more capable platform
	  with minimum changes. An example of a possible required
	  change would be converting the type of the initial thread
	  on a particular platform.

	- Each platform will have a set of features, facilities,
	  and libraries that are required. Features and facilities
	  that are not included in less capable platforms are not
	  generally precluded for that platform, that is, a vendor
	  can optionally include these capabilities -- though this
	  will, of course, impact certification evaluation.

	- We want to eliminate or simplify as many run-time errors
	  as possible.  We need to enable the use of design-time
	  and compile-time tools to support the certification
	  activities. The primary problems in this area are the
	  Java exception mechanism and the RTSJ dynamic scoped
	  memory hierarchy.

	- In order to support the intent of certifiabilty of resulting
	  compliant platforms, we need to be developing the rationale
	  for the specification along with the specification
	  itself.

There were a number of more detailed issues that were discussed relative to the minimum SC Java. These are presented here mostly in the order that they were discussed, which was generally  based on the RTSJ specification.

	- User class loading is not required (but not precluded)
	- We probably want to use the full JVM as a base, not the
	  one from CLDC
	- We may want to use KVM for the JVM (but no one volunteered
	  to investigate this issue).
	- We assume that we will use many of the concepts from the
	  Ravenscar Java proposal:
		- SC Java will only require no-heap RT threads
		  (but other thread types are not precluded)
		- JVM Initialization will need to change to not
		  use a normal Java thread.

    Scheduling:
	- Scheduling feasibility is not included (but not precluded)
	- We want to include periodic scheduling (but interface
	  not yet determined)
	- The problems associated with deadline overrun detection
	  will require investigation of the interaction with other
	  areas, such as timer management.
	- We can probably discard the Processing Group concept
	  from the scheduler.
	- We do want a sleep capability.
	- The scheduled We will require a priority scheduler.
	- The JVM must support FIFO scheduling and must include
	  FIFO, but applications must not depend upon FIFO behavior.

-----------------------------------------------------------------------

-- 
.   Douglas M. Wells      .   Internet:  d.wells@opengroup.org   .
.   The Open Group        .   Voice:     +1 781 564 9206         .
.   Burlington, MA   USA  .   WWW:  http://www.opengroup.org     .