Issue 1739: Local stubs (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: closed issue Revised Text: Actions taken: July 27, 1998: received issue June 4, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Sender: raz@arrakis.com.au Date: Mon, 27 Jul 1998 09:42:37 -0300 From: Roland Turner Organization: - To: java-rtf@omg.org Subject: IDL-Java issues I'm a little embarrassed to be posting these so late. I've been meaning to clean these up and check their status first for some time, but the opportunity doesn't appear to have presented itself. Now it's probably too late to make use of them this time around, but here they are for future consideration. However, the first item should be considered this time around if at all possible. Thanks. Use of NO_IMPLEMENT where abstract should be used. A "throw new NO_IMPLEMENT" should be a conscious choice by an ORB implementor indicating non-compliance of the product at that point. It should never be a default action, this is what abstract methods are for. As a special case, it might be a worthwhile default action for deprecated methods. If I've understood correctly, the response to the mixed application of these two approaches has been to turn them all to NO_IMPLEMENT. This subverts the type-safety of both the Java language and the JVM. Worse still, we lose the ability to machine check the completeness of an implementation with respect to some version of the org.omg.* package. Not only do ORB implementors lose this ability, users do as well. The possibility of an incomplete ORB successfully loading and only falling over mid-application, perhaps intermittently (rather than reliably failing to load - which will be seen to indicate an incomplete ORB immediately) is raised substantially by the NO_IMPLEMENT approach, which in turn will raise the appearance of CORBA as an unreliable technology for use in a Java environment. Perhaps some other point of view is considered more important, perhaps this should be spelt out in the mapping. Return-Path: Sender: mleland@fpk.hp.com Date: Tue, 22 Sep 1998 11:51:52 -0400 From: Mary Leland Organization: Hewlett-Packard To: java-rtf@omg.org Cc: mleland@fpk.hp.com Subject: NO_IMPLEMENT explanation My action item from last week's meeting was to come up with some words to explain the two different uses of throwing NO_IMPLEMENT in the Java code in the specification. Here's an attempt, but please note that I'm not sure I really understand the second reason, so suggestions for modifications are very welcome. Add a new paragraph to the end of current section .0.1 (org.omg.* Packages): "There are two cases in which methods in the org.omg.* packages are specified as throwing the exception org.omg.CORBA.NO_IMPLEMENT: 1. For deprecated methods. These are clearly marked with a javadoc comment. 2. For methods for which an implementation is not mandatory. However, conforming implementations may override any of these methods to provide the specified semantics."