JSR-282 SI3.2
------------------------------------------------
 
Summary
---------------------
Relax the "bi-directional reference rule" for parameter objects.
 
Specification References
---------------------
This SI proposes changes to most of the constructors for SOs, and for
most of the setter methods in the Schedulable interface. In each case it
removes the words that say an IllegalAssignmentError should be thrown if
a parameter object cannot hold a reference to an SO.
 
Specifically:
   *         The IllegalAssignmentError clause in 
     o        three of the RealtimeThread constructors 
     o        all of the NoHeapRealtimeThread constructors 
     o        and three AsyncEventHandler constructors 
   *         The IllegalAssignmentError clause in all the setIfFeasible and
set methods in the Schedulable interface except setScheduler(Scheduler
scheduler) and setIfFeasible(Scheduler scheduler) 
   *         The IllegalAssignmentError clause in the three setIfFeasible methods in the abstract Scheduler class and the concrete PriorityScheduler class.
 
Problem being Addressed
---------------------
 
The current specification does not permit an SO to use a parameter
object unless that parameter object can hold a reference to the SO. For
SOs in scoped memory, that effectively requires the parameter object to
be in the same scope as the SO which reduces the opportunities for
sharing or recycling parameter objects.
 
This restriction was imposed because SOs need to respond to changes made
to the parameter objects. This implied a link from the parameter object
to the SO. It turns out that this can probably be implemented without
requiring that link.
 
Proposed Solution Summary
---------------------
 
In each IllegalAssignmentError clause remove words similar to, "or the
parameter object cannot hold a reference to this."
 
Semantics
---------------------
 
This change makes many methods and constructors more permissive about
the memory areas from which parameter objects can be drawn.  Otherwise,
it does not change the external behavior of any RTSJ classes.
 
Discussion Points
---------------------
 
This is a bit painful to implement, but the improvement for developers
may be worth the pain.
 
It might be too difficult to implement on the RI, or it may be too
costly in some way.  The best way to be certain is to try it and find
out.
 
Compatibility Issues
---------------------
The only incompatibility would be with programs that intentionally get
IllegalAssignmentErrors.