I2JAV11 — Local stubs

Summary: - There is no example given in the mapping. I forget the exact problem,
but some guesswork was required to work out exactly what code should be
generated.

• Why should the class name be specified? Surely it is up to the Helper
  to generate instances and thus decide which to create? (I note that
  recent changes have altered this somewhat, with ORBs apparently now free
  to bypass the Helper altogether and instantiate stubs directly. This
  seems like a bad idea.)

• Why are local stubs disctinct? Given that a local stub has to deal
  with the possibility of an object ceasing to be local, and that it would
  be desirable for a non-local stub to discover that an object has become
  local and make use of that knowledge, surely it is up to ORB
  implementors to have their Helpers make whatever choices are appropriate
  to instantiate appropriate stubs. The way that the mapping currently
  stands, it does not seem to be possible to implement a stub that will
  cope with objects moving into and out of the current JVM and still
  remain compliant.

• _is_local is redundant. The success/failure of preinvoke is the acid
  test. This also avoids races: if preinvoke suceeds then you know that
  the object is available for a single local invocation. If _is_local
  suceeds, then you know nothing of the sort, you have to invoke preinvoke
  anyway, and if it fails, invoke remotely anyway.

closed issue