Issue 1897: Evolving the org.omg.* APIs (java-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: Now that the org.omg.* APIs are built into the JDK core (from JDK 1.2 onwards), there is an issue with how these could be evolved to support changes to the OMG spec that happen between JDK major releases. The following is a proposal for how this could be handled. Resolution: resolved, see revised text Revised Text: 1. Change the IDL/Java mapping of enums so that a. the generated Java classes are not final b. the from_int method is not final, and c. the constructor is protected instead of private. Rationale: This change has previously been discussed by this RTF. It is needed in this context because of the need to include some Java classes mapped from IDL enums (e.g., TCKind) in the core JDK. If new members are added to such an enum later, there needs to be a way to subclass the generated Java class to produce a subclass that corresponds to the new IDL (or PIDL) enum. 2. Change the Object, ObjectImpl, and Delegate classes to a. add new methods org.omg.CORBA.Object _get_interface_def() to Object and ObjectImpl and org.omg.CORBA.Object get_interface_def(org.omg.CORBA.Object self) to Delegate. b. deprecate the existing methods org.omg.CORBA.InterfaceDef _get_interface() on Object and ObjectImpl and org.omg.CORBA.InterfaceDef get_interface(org.omg.CORBA.Object self) on Delegate. Rationale: The new methods do not refer to Interface Repository types in their signatures. However, at runtime they still return the same IR objects as the deprecated methods. Since this signature change is a binary incompatible change, and since Java methods cannot be overloaded on their return types, the new methods have different names than the deprecated methods. This allows an easier path for user migration than if the method signatures had been updated "in place". Removing IR types from the signatures allows the new methods to be included in the core JDK without also having to include all the IR classes in the core JDK. With likely changes in this area in the near future because of the Components RFP, it is felt to be unwise to put the IR into core in JDK 1.2. 3. Change the ORB class to a. add a new method public NVList create_operation_list(org.omg.CORBA.Object oper) b. deprecate the existing method public NVList create_operation_list(org.omg.CORBA.OperationDef oper) Rationale: The reason for this change is as for item 2 above. Since Java supports overloading on argument types, there is no need to change the method name in this case. 4. Move some methods needed by Objects By Value from the ORB, InputStream and OutputStream classes to new subclasses (that will not be part of the core JDK 1.2). The names of these new classes are: org.omg.CORBA_2_3.ORB org.omg.CORBA_2_3.portable.InputStream org.omg.CORBA_2_3.portable.OutputStream and the methods affected are: ORB.get_value_def ORB.register_value_factory ORB.unregister_value_factory ORB.lookup_value_factory InputStream.read_Value InputStream.read_Abstract OutputStream.write_Value OutputStream.write_Abstract OutputStream.start_block OutputStream.end_block Actions taken: August 28, 1998: received issue June 4, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 28 Aug 1998 18:01:16 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: java-rtf@omg.org Subject: Evolving the org.omg.* APIs Now that the org.omg.* APIs are built into the JDK core (from JDK 1.2 onwards), there is an issue with how these could be evolved to support changes to the OMG spec that happen between JDK major releases. The following is a proposal for how this could be handled. When a JDK release is frozen, the org.omg.* APIs will match the latest approved OMG specs. These API methods will be methods of abstract classes such as org.omg.CORBA.ORB, and will be delivered with dummy implementations that just throw NO_IMPLEMENT. ORB products will subclass these APIs and provide real implementations for the API set each product chooses to implement. The only problem is if some new APIs are standardized by OMG after the JDK freeze, and an ORB vendor wishes to implement these APIs. If these APIs are in a new class, there is no problem, as the ORB vendor can just include the class with the ORB product. Even if the class is in an org.omg.* package, there is no problem with this class being loaded from outside the core Java runtime. If these new APIs are in an existing class, there is a problem, because the original org.omg.* API class that shipped with the core Java runtime cannot be replaced by an ORB product without using nonstandard options. However, the ORB product can do the following: 1. Create a subclass of the org.omg.CORBA.ORB class, let's say org.omg.CORBA.extended.ORB, and deliver it as a standard extension. 2. Add the new APIs to org.omg.CORBA.extended.ORB. 3. Make the product ORB class that needs the new APIs subclass org.omg.CORBA.extended.ORB. 4. People that want to call the new APIs should import org.omg.CORBA.extended.ORB instead of org.omg.CORBA.ORB. 5. In the next JDK, the methods from org.omg.CORBA.extended.ORB are moved up into org.omg.CORBA.ORB. org.omg.CORBA.extended.ORB becomes empty but is still shipped as a standard extension. 6. If people want, they can change their imports to org.omg.CORBA.ORB instead of org.omg.CORBA.extended.ORB, but they don't need to do this. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: X-NS-Transport-ID: 0800200D19BA39490D20 Date: Fri, 28 Aug 1998 10:45:57 PDT Sender: Christian_P_Jacobi.PARC@xerox.com From: jacobi.PARC@xerox.com Subject: Re: Evolving the org.omg.* APIs To: nash@hursley.ibm.COM cc: Christian_P_Jacobi.PARC@xerox.com, java-rtf@omg.org >Now that the org.omg.* APIs are built into the JDK core (from JDK 1.2 I find this to be a big problem. You may have found a partial solution, but it is too complex and forces omg actions and java releases to be performed in lockstep. In particular this makes org.omg.* part of the boot classes and also part of the rt.jar file. The java licensing terms do not allow anybody to make changes to the rt.jar file. This means it is not possible for an orb vendor to legally run on a different version of the org.omg classes. A much simple solution would be to put the org.omg classes in a separate jar file. When working with a newer corba version, we'd use a newer version of the corba jar file. Chris Return-Path: Date: Fri, 28 Aug 1998 19:17:08 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: jacobi.PARC@xerox.com Cc: java-rtf@omg.org Subject: Re: Evolving the org.omg.* APIs References: <98Aug28.104623pdt."52144(2)"@alpha.xerox.com> Chris, Please read my message again. The solution I proposed does not require any ORB vendor to change the org.omg.* classes that are part of the rt.jar file. Their changes would be in other files that they can ship legally as standard extensions. This is because there is no issue with anyone shipping additional classes whose names start with org.omg.*, unlike classes whose names start with java.*. Simon jacobi.PARC@xerox.com wrote: > > >Now that the org.omg.* APIs are built into the JDK core (from JDK > 1.2 > I find this to be a big problem. You may have found a partial > solution, but it is too complex and forces omg actions and java > releases > to be performed in lockstep. > > In particular this makes org.omg.* part of the boot classes and > also part of the rt.jar file. The java licensing terms do not allow > anybody to make changes to the rt.jar file. This means it is > not possible for an orb vendor to legally run on a different version > of the org.omg classes. > > A much simple solution would be to put the org.omg classes in a > separate > jar file. When working with a newer corba version, we'd use a newer > version of the corba jar file. > > Chris > -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: X-NS-Transport-ID: 0800200D19BA39490D25 Date: Fri, 28 Aug 1998 11:56:19 PDT Sender: Christian_P_Jacobi.PARC@xerox.com From: jacobi.PARC@xerox.com Subject: Re: Evolving the org.omg.* APIs To: nash@hursley.ibm.COM cc: jacobi.PARC@xerox.com, java-rtf@omg.org You are correct when you say >The solution I proposed does not require any ORB vendor to >change the org.omg.*classes that are part of the rt.jar file. but this is not the problem. The problem is: how CAN we support changes to the org.omg.*classes WHEN such changes are required in the future. I think your solution puts too many constraints on what kind of changes we might desire in the future. It has nice dynamic for the kind of extensions which fit the scheme, but it restricts other extensions. I repeat: making a separate jar file which could be replaced entirely allows further changes, experimental changes which could be more light weight, and, wouldn't require the timing to be synchronized that strongly. It would also not even preclude doing gentle changes according to your scheme. Chris Return-Path: Sender: raz@arrakis.com.au Date: Fri, 28 Aug 1998 22:17:07 +0000 From: Roland Turner Organization: - To: java-rtf@omg.org Subject: Re: Evolving the org.omg.* APIs References: <35E6E25C.6B2DF2E4@mailserver.hursley.ibm.com> Simon Nash wrote: > When a JDK release is frozen, the org.omg.* APIs will match the > latest approved OMG specs. These API methods will be methods of > abstract classes such as org.omg.CORBA.ORB, and will be delivered > with dummy implementations that just throw NO_IMPLEMENT. Why throw NO_IMPLEMENT in the standard classes? The correct language feature to use here is to define abstract methods. If a vendor CHOOSES to throw NO_IMPLEMENT, fine, but having it as standard behaviour makes it extrememly difficult to work out whether or not there are unimplemented methods left in a product. The use of abstract methods give us back the support of the compiler, runtime and type-system in discovering oversights and, for administrators managing deployment environments, allows for rapid identification of products which don't implement the interface that is being offerd through the org.omg.* hierachy. Can anyone state a reason FOR having these methods be non-abstract and throw NO_IMPLEMENT instead of just being abstract? > 1. Create a subclass of the org.omg.CORBA.ORB class, let's > say org.omg.CORBA.extended.ORB, and deliver it as a standard > extension. Vendors should not, under any circumstances, be placing code outside of the CORBA spec into the org.omg.* hierachy. The moment they do, the hierachy becomes polluted and the ability of different implementations to exist inside the same JVM is extinguished. > 4. People that want to call the new APIs should import > org.omg.CORBA.extended.ORB instead of org.omg.CORBA.ORB. > 5. In the next JDK, the methods from org.omg.CORBA.extended.ORB > are moved up into org.omg.CORBA.ORB. org.omg.CORBA.extended.ORB > becomes empty but is still shipped as a standard extension. So implementations are to use the org.omg.CORBA.extended.* classes instead of the org.omg.* classes? For this to work, Sun would need to undertake not to provide org.omg.CORBA.extended.* classes (that observation, incidentally, points the way to a solution), but this would mean that Sun's bundled ORB could no longer be bundled, or no longer be depended upon, or simply no longer work. For your proposal to work, Sun would have to cease bundling a working ORB with the JRE. The solution to the problem is, IMHO, a great deal simpler, and it is this: Have Sun NOT obligate its licensees to leave the org.omg.* package alone. This is sensible, Sun does not define that package, the OMG does. It is therefore inappropriate for Sun to be locking in a particular version of someone else's standard. Clearly this course of action requires Sun's aquiesence, but as should be clear, the entire exercise of the IDL/Java mappings is about getting Sun's product into the CORBA space, something which Sun seems reasonably happy to help happen. Sun's lawyers may be tempted to try to put some other constraint in (e.g. require that changes to that hierachy be CORBA compliant), but let us hope not. CORBA is too poorly defined and too fast moving to be used for that purpose. For this to work in all cases would require that there be some identifiable ordered sequence of "versions" of the Java mapping (there almost is, but the lack of definition of what classes actually go into the org.omg.* module complicate this) for vendors to implement. The administrator handling the deployment environment then needs merely to ensure that the org.omg.* package from the product compliant with the most recent version of the mapping is the one that is used, the rest will simply fall into place. Granted, where differnt vendors take on different extensions that are newer that the published RTF output, this won't always work, but where this has happened, no other approach will work either (short of requiring administrators in the deployment environment calculate the union of the involved products' requirements), so it's as good as we'll get. Having the mapping support the presence of multiple ORB implementations is challenging, it does require some measures that have not been undertaken previously in the OMG, but I believe (and I think that others believe) that it is worth the effort. Chris Jacobi wrote: > A much simple solution would be to put the org.omg classes in a > separate > jar file. When working with a newer corba version, we'd use a newer > version of the corba jar file. This doesn't really help. Depending upon being able to replace jar files in the execution environment (which are conceivably not controlled by whoever "deploys" an implementation, e.g. onto a web server) is not a complete solution. Having Sun permit the replacement of the org.omg.* classes (and arranging for runtimes to accept replacements for non-core classes at runtime) does solve the problem however. - Raz Return-Path: Sender: "George Scott" Date: Mon, 31 Aug 1998 14:38:34 -0700 From: "George M. Scott" Organization: Inprise Corporation To: Roland Turner CC: java-rtf@omg.org Subject: Re: Evolving the org.omg.* APIs References: <35E6E25C.6B2DF2E4@mailserver.hursley.ibm.com> <35E72C63.DBB52FDC@arrakis.com.au> Roland Turner wrote: > > > Why throw NO_IMPLEMENT in the standard classes? The correct language > feature to use here is to define abstract methods. If a vendor > CHOOSES > to throw NO_IMPLEMENT, fine, but having it as standard behaviour > makes > it extrememly difficult to work out whether or not there are > unimplemented methods left in a product. The use of abstract methods > give us back the support of the compiler, runtime and type-system in > discovering oversights and, for administrators managing deployment > environments, allows for rapid identification of products which > don't > implement the interface that is being offerd through the org.omg.* > hierachy. > > Can anyone state a reason FOR having these methods be non-abstract > and > throw NO_IMPLEMENT instead of just being abstract? Yes. Any new methods added to org.omg.CORBA.ORB are declared to throw NO_IMPLEMENT so that older orb implementations can continue to run with a newer version of the org.omg.* packages. For example, let's say a browser vendor such as Netscape decides to place the CORBA 2.3 org.omg.* package in Netscape 5.0. If all the methods were defined as abstract, then an "older" ORB such as VisiBroker 3.x or OrbixWeb 3.x wouldn't be able to run inside of the new browser without the vendors defining an implementation for those methods. This mechanism allows the spec to evolve, but allows older ORBs to continue to run. George Return-Path: Date: Tue, 01 Sep 1998 15:09:39 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: jacobi.PARC@xerox.com Cc: java-rtf@omg.org Subject: Re: Evolving the org.omg.* APIs References: <98Aug28.115657pdt."52060(3)"@alpha.xerox.com> Chris, You are right that allowing the API classes to be replaced completely would give even more flexibility than my proposal. If Sun were to enable this replacement, I would welcome it. However, the purpose of my proposal was to show that a certain amount of flexibility is possible even in the absence of the "complete replacement" capability. I would like to know what other kinds of extensions you think might be made that are upward compatible with the JDK 1.2 base functionality but would not be amenable to the type of solution I have proposed. CORBA APIs could not be removed or changed during the life of a JDK major release without damaging the base functionality, which would go against the "write once run anywhere" nature of the Java platform. Also, if additional org.omg.* classes or interfaces are needed, they could be added by any ORB vendor simply by placing them on the classpath. Simon jacobi.PARC@xerox.com wrote: > > You are correct when you say > > >The solution I proposed does not require any ORB vendor to > >change the org.omg.*classes that are part of the rt.jar file. > > but this is not the problem. The problem is: how CAN we > support changes to the org.omg.*classes WHEN such changes > are required in the future. > > I think your solution puts too many constraints on what > kind of changes we might desire in the future. It has nice > dynamic for the kind of extensions which fit the scheme, > but it restricts other extensions. > > I repeat: making a separate jar file which could be replaced > entirely allows further changes, experimental changes > which could be more light weight, and, wouldn't require > the timing to be synchronized that strongly. It would > also not even preclude doing gentle changes according to > your scheme. > > Chris -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Date: Tue, 01 Sep 1998 15:31:12 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: Roland Turner Cc: java-rtf@omg.org Subject: Re: Evolving the org.omg.* APIs References: <35E6E25C.6B2DF2E4@mailserver.hursley.ibm.com> <35E72C63.DBB52FDC@arrakis.com.au> Roland, Roland Turner wrote: > > Simon Nash wrote: > > > When a JDK release is frozen, the org.omg.* APIs will match the > > latest approved OMG specs. These API methods will be methods of > > abstract classes such as org.omg.CORBA.ORB, and will be delivered > > with dummy implementations that just throw NO_IMPLEMENT. > > Why throw NO_IMPLEMENT in the standard classes? The correct language > feature to use here is to define abstract methods. If a vendor > CHOOSES > to throw NO_IMPLEMENT, fine, but having it as standard behaviour > makes > it extrememly difficult to work out whether or not there are > unimplemented methods left in a product. The use of abstract methods > give us back the support of the compiler, runtime and type-system in > discovering oversights and, for administrators managing deployment > environments, allows for rapid identification of products which > don't > implement the interface that is being offerd through the org.omg.* > hierachy. > > Can anyone state a reason FOR having these methods be non-abstract > and > throw NO_IMPLEMENT instead of just being abstract? > George has responded to this. > > 1. Create a subclass of the org.omg.CORBA.ORB class, let's > > say org.omg.CORBA.extended.ORB, and deliver it as a standard > > extension. > > Vendors should not, under any circumstances, be placing code outside > of > the CORBA spec into the org.omg.* hierachy. The moment they do, the > hierachy becomes polluted and the ability of different > implementations > to exist inside the same JVM is extinguished. > This would not be code that is outside the CORBA spec. This would be code that has become part of the CORBA spec since 1.2 was frozen. > > 4. People that want to call the new APIs should import > > org.omg.CORBA.extended.ORB instead of org.omg.CORBA.ORB. > > 5. In the next JDK, the methods from org.omg.CORBA.extended.ORB > > are moved up into org.omg.CORBA.ORB. > org.omg.CORBA.extended.ORB > > becomes empty but is still shipped as a standard extension. > > So implementations are to use the org.omg.CORBA.extended.* classes > instead of the org.omg.* classes? For this to work, Sun would need > to > undertake not to provide org.omg.CORBA.extended.* classes (that > observation, incidentally, points the way to a solution), but this > would > mean that Sun's bundled ORB could no longer be bundled, or no longer > be > depended upon, or simply no longer work. > Sun would not place org.omg.CORBA.extended.* classes in the core. Since Sun's core ORB (which is frozen in functionality at the point of 1.2 FCS) does not need any org.omg.CORBA.extended.* classes, this ORB would always work correctly. > For your proposal to work, Sun would have to cease bundling a working > ORB with the JRE. > I don't understand why this would be the case. See my comment above. > The solution to the problem is, IMHO, a great deal simpler, and it is > this: Have Sun NOT obligate its licensees to leave the org.omg.* package > alone. > > This is sensible, Sun does not define that package, the OMG does. It is > therefore inappropriate for Sun to be locking in a particular version of > someone else's standard. Clearly this course of action requires Sun's > aquiesence, but as should be clear, the entire exercise of the IDL/Java > mappings is about getting Sun's product into the CORBA space, something > which Sun seems reasonably happy to help happen. Sun's lawyers may be > tempted to try to put some other constraint in (e.g. require that > changes to that hierachy be CORBA compliant), but let us hope not. CORBA > is too poorly defined and too fast moving to be used for that purpose. > There would need to be some constraint on what the licensees do with the org.omg.* APIs. They would need to be an upward compatible evolution of the version that was shipped in the 1.2 JDK. If not, users with CORBA applications written to those 1.2 base APIs would not be able to run their applications on all JDKs that the licensees ship, which would negate the "write once run anywhere" benefit of the Java platform. > For this to work in all cases would require that there be some > identifiable ordered sequence of "versions" of the Java mapping > (there > almost is, but the lack of definition of what classes actually go > into > the org.omg.* module complicate this) for vendors to implement. The > administrator handling the deployment environment then needs merely > to > ensure that the org.omg.* package from the product compliant with > the > most recent version of the mapping is the one that is used, the rest > will simply fall into place. Granted, where differnt vendors take on > different extensions that are newer that the published RTF output, > this > won't always work, but where this has happened, no other approach > will > work either (short of requiring administrators in the deployment > environment calculate the union of the involved products' > requirements), > so it's as good as we'll get. > > Having the mapping support the presence of multiple ORB > implementations > is challenging, it does require some measures that have not been > undertaken previously in the OMG, but I believe (and I think that > others > believe) that it is worth the effort. > Yes, it would take something like a reference implementation of the org.omg.* classes that is maintained by OMG and tested for compliance with the last major release of the JDK, initially 1.2. Any ORB vendor could replace the org.omg.* APIs shipped with JDK 1.2 with the OMG reference version and be assured that the base JDK functionality would still work. > Chris Jacobi wrote: > > > A much simple solution would be to put the org.omg classes in a > > separate > > jar file. When working with a newer corba version, we'd use a > newer > > version of the corba jar file. > > This doesn't really help. Depending upon being able to replace jar > files > in the execution environment (which are conceivably not controlled > by > whoever "deploys" an implementation, e.g. onto a web server) is not > a > complete solution. > > Having Sun permit the replacement of the org.omg.* classes (and > arranging for runtimes to accept replacements for non-core classes > at > runtime) does solve the problem however. > I agree that it would be good if Sun could make the org.omg.* classes replaceable. I don't agree with making them non-core, though. It's important that some baseline CORBA functionality be part of every JDK from every licensee, and having the org.omg.* classes be core is the best way to accomplish that. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Date: Thu, 05 Nov 1998 04:35:31 +0000 From: Simon Nash Organization: IBM To: java-rtf@omg.org Subject: Issue 1897: Evolving the org.omg.* APIs Here is a proposal for changes to the IDL/Java mapping which will permit base CORBA functionality to become part of the core JDK 1.2 and also allow OMG to evolve the CORBA standard and ensure that ORB vendors can ship products that are compliant with this evolving standard. I would like to discuss and hopefully vote on this at the Java RTF meeting in Burlingame on Monday. This proposal is intended to satisfy the following requirements: a. Enable Sun to ship a base level of CORBA support in the core JDK so that this level of CORBA capability becomes part of the Java "write once run anywhere" platform. b. Avoid "baking in" parts of the CORBA specs that may be unstable or subject to near-term evolution. c. Allow ORB vendors to ship compliant products that implement both the current APIs and future evolutions of them. d. Allow migration of new CORBA APIs into the core JDK in due course, by agreement between OMG and Sun. The proposed changes are to the IDL/Java mapping and do not affect the CORBA core or other language mappings. The changes are: 1. Change the IDL/Java mapping of enums so that a. the generated Java classes are not final b. the from_int method is not final, and c. the constructor is protected instead of private. Rationale: This change has previously been discussed by this RTF. It is needed in this context because of the need to include some Java classes mapped from IDL enums (e.g., TCKind) in the core JDK. If new members are added to such an enum later, there needs to be a way to subclass the generated Java class to produce a subclass that corresponds to the new IDL (or PIDL) enum. 2. Change the Object, ObjectImpl, and Delegate classes to a. add new methods org.omg.CORBA.Object _get_interface_def() to Object and ObjectImpl and org.omg.CORBA.Object get_interface_def(org.omg.CORBA.Object self) to Delegate. b. deprecate the existing methods org.omg.CORBA.InterfaceDef _get_interface() on Object and ObjectImpl and org.omg.CORBA.InterfaceDef get_interface(org.omg.CORBA.Object self) on Delegate. Rationale: The new methods do not refer to Interface Repository types in their signatures. However, at runtime they still return the same IR objects as the deprecated methods. Since this signature change is a binary incompatible change, and since Java methods cannot be overloaded on their return types, the new methods have different names than the deprecated methods. This allows an easier path for user migration than if the method signatures had been updated "in place". Removing IR types from the signatures allows the new methods to be included in the core JDK without also having to include all the IR classes in the core JDK. With likely changes in this area in the near future because of the Components RFP, it is felt to be unwise to put the IR into core in JDK 1.2. 3. Change the ORB class to a. add a new method public NVList create_operation_list(org.omg.CORBA.Object oper) b. deprecate the existing method public NVList create_operation_list(org.omg.CORBA.OperationDef oper) Rationale: The reason for this change is as for item 2 above. Since Java supports overloading on argument types, there is no need to change the method name in this case. 4. Move some methods needed by Objects By Value from the ORB, InputStream and OutputStream classes to new subclasses that will not be part of the core JDK 1.2. The names of these new classes are: org.omg.CORBA.ext.ORB org.omg.CORBA.portable.ext.InputStream org.omg.CORBA.portable.ext.OutputStream and the methods affected are: ORB.get_value_def ORB.register_value_factory ORB.unregister_value_factory ORB.lookup_value_factory InputStream.read_Value InputStream.read_Abstract OutputStream.write_Value OutputStream.write_Abstract OutputStream.start_block OutputStream.end_block Rationale: Excluding these methods from the core JDK 1.2 allows these methods to be revised by the IDL/Java 2.4 RTF (e.g., to solve the known issues with OBV) without the current state of the spec being "locked in" as part of the core JDK 1.2. The number of extension subclasses is expected to remain small. Initially it is only 3 classes, of which only 1 (ORB) contains user application APIs. It's important to emphasize that there is only one version of CORBA. The core JDK will contain a carefully selected subset of CORBA based on the functionality that is felt to be important for the "write once run anywhere" Java platform. Over time, this set of functionality will be extended as CORBA is extended. Some users will program to the "write once run anywhere" CORBA support provided by the core JDK, and others will exploit additional CORBA functionality that will be available as part of third-party ORB products. In either case, their programs should continue to run unchanged when non-core APIs move into core, and when new non-core APIs are added. It is expected that non-core APIs will move into the core JDK over time. For example, OBV support should be included in the next JDK release. In order to ensure consistent evolution of the CORBA APIs in the core JDK and the CORBA standard as defined by OMG, it will be necessary to define new procedures that OMG and Sun will follow. A precise definition of how this will work will be added to this proposal. It has been suggested that OMG would recommend which fully approved OMG specifications/APIs should become part of the core JDK and Sun would not add OMG specifications/APIs to the core that have not been so recommended. Details of exactly how this process will work in OMG and its timing, granularity, etc. still need to be defined. A word on naming. Choosing names for things often seems to raise strong opinions. The names I have proposed for the new non-core subclasses of core classes in point 4 above represent one of a number of possible choices which are listed below. For each of these, example names for the non-core subclasses of the core classes org.omg.CORBA.ORB and org.omg.CORBA.portable.InputStream are shown. 1. Change the class name but leave the package unchanged. For example, add the suffix "2" (or something else) to all affected class names, resulting in names such as: org.omg.CORBA.ORB2 org.omg.CORBA.portable.InputStream2 2. Put an additional qualifier into the package name underneath its low-order component. The additional qualifier could be anything, for example: org.omg.CORBA.ext.ORB org.omg.CORBA.portable.ext.InputStream 3. Change the low-order component of the package name. For example, these new APIs could go in classes called: org.omg.CORBA3.ORB org.omg.CORBA3.portable.InputStream 4. Put an additional qualifier into the package name between its high-order component and the org.omg prefix. The additional qualifier could be anything, for example: org.omg.ext.CORBA.ORB org.omg.ext.CORBA.portable.InputStream 5. Change the "reverse DNS" prefix from org.omg to something else such as com.omg or org.corba, for example: com.omg.CORBA.ORB com.omg.CORBA.portable.InputStream My view of these is that 5 would be a particularly bad choice because it creates a whole new namespace, which is out of all proportion to the significance of the small number of extension classes that add methods to the base versions in the core JDK. We need to promote a single coherent CORBA standard (some subset of which is in the core JDK), and avoid the appearance that there are two alternative versions of CORBA called org.omg.* and com.omg.*. As far as the others are concerned, there are pros and cons to each of them, but most people seem to prefer 2 and 4 to 1 and 3. Comments? Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: From: "Martin Chapman" To: "Simon Nash" , Subject: RE: Issue 1897: Evolving the org.omg.* APIs Date: Thu, 5 Nov 1998 11:21:10 -0000 X-MSMail-Priority: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Simon, Could you clarify teh intention of what will happen when something moves into the core (through this yet undefibed process): will it move from NEW.omg.org (or whatever it is called) to omg.org, will it be copied, or will it remain just in NEW.omg.org? Martin. > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: 05 November 1998 04:36 > To: java-rtf@omg.org > Subject: Issue 1897: Evolving the org.omg.* APIs > > > Here is a proposal for changes to the IDL/Java mapping which will > permit base CORBA functionality to become part of the core JDK 1.2 > and also allow OMG to evolve the CORBA standard and ensure that > ORB vendors can ship products that are compliant with this evolving > standard. I would like to discuss and hopefully vote on this at > the Java RTF meeting in Burlingame on Monday. > > This proposal is intended to satisfy the following requirements: > > a. Enable Sun to ship a base level of CORBA support in the core JDK > so that this level of CORBA capability becomes part of the Java > "write once run anywhere" platform. > b. Avoid "baking in" parts of the CORBA specs that may be unstable > or subject to near-term evolution. > c. Allow ORB vendors to ship compliant products that implement > both the current APIs and future evolutions of them. > d. Allow migration of new CORBA APIs into the core JDK in due > course, > by agreement between OMG and Sun. > > The proposed changes are to the IDL/Java mapping and do not affect > the CORBA core or other language mappings. The changes are: > > 1. Change the IDL/Java mapping of enums so that > a. the generated Java classes are not final > b. the from_int method is not final, and > c. the constructor is protected instead of private. > > Rationale: > > This change has previously been discussed by this RTF. It is > needed in this context because of the need to include some Java > classes mapped from IDL enums (e.g., TCKind) in the core JDK. > If new members are added to such an enum later, there needs to be > a way to subclass the generated Java class to produce a subclass > that corresponds to the new IDL (or PIDL) enum. > > 2. Change the Object, ObjectImpl, and Delegate classes to > a. add new methods > org.omg.CORBA.Object _get_interface_def() > to Object and ObjectImpl and > org.omg.CORBA.Object get_interface_def(org.omg.CORBA.Object > self) > to Delegate. > > b. deprecate the existing methods > org.omg.CORBA.InterfaceDef _get_interface() > on Object and ObjectImpl and > org.omg.CORBA.InterfaceDef > get_interface(org.omg.CORBA.Object self) > on Delegate. > > Rationale: > > The new methods do not refer to Interface Repository types in > their > signatures. However, at runtime they still return the same IR > objects > as the deprecated methods. Since this signature change is a > binary > incompatible change, and since Java methods cannot be overloaded > on > their return types, the new methods have different names than the > deprecated methods. This allows an easier path for user > migration > than if the method signatures had been updated "in place". > > Removing IR types from the signatures allows the new methods to > be > included in the core JDK without also having to include all the > IR > classes in the core JDK. With likely changes in this area in the > near > future because of the Components RFP, it is felt to be unwise to > put > the IR into core in JDK 1.2. > > 3. Change the ORB class to > a. add a new method > public NVList create_operation_list(org.omg.CORBA.Object > oper) > > b. deprecate the existing method > public NVList > create_operation_list(org.omg.CORBA.OperationDef oper) > > Rationale: > > The reason for this change is as for item 2 above. Since Java > supports > overloading on argument types, there is no need to change the > method > name in this case. > > 4. Move some methods needed by Objects By Value from the ORB, > InputStream and > OutputStream classes to new subclasses that will not be part > of the core > JDK 1.2. The names of these new classes are: > org.omg.CORBA.ext.ORB > org.omg.CORBA.portable.ext.InputStream > org.omg.CORBA.portable.ext.OutputStream > and the methods affected are: > ORB.get_value_def > ORB.register_value_factory > ORB.unregister_value_factory > ORB.lookup_value_factory > InputStream.read_Value > InputStream.read_Abstract > OutputStream.write_Value > OutputStream.write_Abstract > OutputStream.start_block > OutputStream.end_block > > Rationale: > > Excluding these methods from the core JDK 1.2 allows these > methods to be > revised by the IDL/Java 2.4 RTF (e.g., to solve the known issues > with > OBV) without the current state of the spec being "locked in" as > part of > the core JDK 1.2. > > The number of extension subclasses is expected to remain small. > Initially it is only 3 classes, of which only 1 (ORB) contains > user > application APIs. > > It's important to emphasize that there is only one version of CORBA. > The core JDK will contain a carefully selected subset of CORBA based > on the functionality that is felt to be important for the "write > once > run anywhere" Java platform. Over time, this set of functionality > will be extended as CORBA is extended. Some users will program to > the > "write once run anywhere" CORBA support provided by the core JDK, > and > others will exploit additional CORBA functionality that will be > available as part of third-party ORB products. In either case, > their > programs should continue to run unchanged when non-core APIs move > into > core, and when new non-core APIs are added. > > It is expected that non-core APIs will move into the core JDK over > time. > For example, OBV support should be included in the next JDK release. > In order to ensure consistent evolution of the CORBA APIs in the > core > JDK and the CORBA standard as defined by OMG, it will be necessary > to > define new procedures that OMG and Sun will follow. A precise > definition > of how this will work will be added to this proposal. It has been > suggested that OMG would recommend which fully approved OMG > specifications/APIs should become part of the core JDK and Sun would > not > add OMG specifications/APIs to the core that have not been so > recommended. > Details of exactly how this process will work in OMG and its timing, > granularity, etc. still need to be defined. > > A word on naming. Choosing names for things often seems to raise > strong > opinions. The names I have proposed for the new non-core subclasses > of > core classes in point 4 above represent one of a number of > possible choices > which are listed below. For each of these, example names for the > non-core > subclasses of the core classes org.omg.CORBA.ORB and > org.omg.CORBA.portable.InputStream are shown. > > 1. Change the class name but leave the package unchanged. For > example, > add the suffix "2" (or something else) to all affected class > names, > resulting in names such as: > org.omg.CORBA.ORB2 > org.omg.CORBA.portable.InputStream2 > > 2. Put an additional qualifier into the package name underneath its > low-order component. The additional qualifier could be anything, > for example: > org.omg.CORBA.ext.ORB > org.omg.CORBA.portable.ext.InputStream > > 3. Change the low-order component of the package name. For example, > these new APIs could go in classes called: > org.omg.CORBA3.ORB > org.omg.CORBA3.portable.InputStream > > 4. Put an additional qualifier into the package name between its > high-order component and the org.omg prefix. The additional > qualifier could be anything, for example: > org.omg.ext.CORBA.ORB > org.omg.ext.CORBA.portable.InputStream > > 5. Change the "reverse DNS" prefix from org.omg to something else > such as com.omg or org.corba, for example: > com.omg.CORBA.ORB > com.omg.CORBA.portable.InputStream > > My view of these is that 5 would be a particularly bad choice > because it > creates a whole new namespace, which is out of all proportion to the > significance of the small number of extension classes that add > methods > to the base versions in the core JDK. We need to promote a single > coherent CORBA standard (some subset of which is in the core JDK), > and > avoid the appearance that there are two alternative versions of > CORBA > called org.omg.* and com.omg.*. As far as the others are concerned, > there are pros and cons to each of them, but most people seem to > prefer 2 and 4 to 1 and 3. Comments? > > Simon > -- > Simon C Nash, IBM Java Technology Centre, Hursley, UK > MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 > Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb > Return-Path: Date: Thu, 05 Nov 1998 18:25:45 +0000 From: Simon Nash Organization: IBM To: Martin Chapman CC: java-rtf@omg.org Subject: Re: Issue 1897: Evolving the org.omg.* APIs References: <002401be08ae$6402f640$e205a8c0@chaplin.dublin.iona.ie> Martin, It will be copied. If it were to remain just in org.omg.NEW, Sun would have to put org.omg.NEW into the core JDK and OMG would have to start a org.omg.NEW2 for the next round of new stuff. This seems clumsy. If it were to be moved from org.omg.NEW to org.omg, that would be fine for users of the new JDK release X.Y, but users of older JDKs would have a problem. So the APIs need to stay in org.omg.NEW until OMG decides that the specification no longer needs to support JDKs older than X.Y. For example, the Java RTF recently decided to change the IDL/Java mapppings so that they don't support JDKs older than 1.1. At that time, the APIs that were added to core JDK X.Y will be deleted from org.omg.NEW. This process only applies to new APIs that affect classes currently in the core JDK. Any entirely new classes start life as org.omg, not org.omg.NEW, and no renaming, moving, or copying is needed when these become part of core. Simon Martin Chapman wrote: > > Simon, > Could you clarify teh intention of what will happen when something > moves > into the core (through this yet undefibed process): will it move > from > NEW.omg.org (or whatever it is called) to omg.org, will it be > copied, or > will it remain just in NEW.omg.org? > > Martin. > > > -----Original Message----- > > From: Simon Nash [mailto:nash@hursley.ibm.com] > > Sent: 05 November 1998 04:36 > > To: java-rtf@omg.org > > Subject: Issue 1897: Evolving the org.omg.* APIs > > > > > > Here is a proposal for changes to the IDL/Java mapping which will > > permit base CORBA functionality to become part of the core JDK 1.2 > > and also allow OMG to evolve the CORBA standard and ensure that > > ORB vendors can ship products that are compliant with this > evolving > > standard. I would like to discuss and hopefully vote on this at > > the Java RTF meeting in Burlingame on Monday. > > > > This proposal is intended to satisfy the following requirements: > > > > a. Enable Sun to ship a base level of CORBA support in the core > JDK > > so that this level of CORBA capability becomes part of the Java > > "write once run anywhere" platform. > > b. Avoid "baking in" parts of the CORBA specs that may be unstable > > or subject to near-term evolution. > > c. Allow ORB vendors to ship compliant products that implement > > both the current APIs and future evolutions of them. > > d. Allow migration of new CORBA APIs into the core JDK in due > course, > > by agreement between OMG and Sun. > > > > The proposed changes are to the IDL/Java mapping and do not affect > > the CORBA core or other language mappings. The changes are: > > > > 1. Change the IDL/Java mapping of enums so that > > a. the generated Java classes are not final > > b. the from_int method is not final, and > > c. the constructor is protected instead of private. > > > > Rationale: > > > > This change has previously been discussed by this RTF. It is > > needed in this context because of the need to include some Java > > classes mapped from IDL enums (e.g., TCKind) in the core JDK. > > If new members are added to such an enum later, there needs to > be > > a way to subclass the generated Java class to produce a > subclass > > that corresponds to the new IDL (or PIDL) enum. > > > > 2. Change the Object, ObjectImpl, and Delegate classes to > > a. add new methods > > org.omg.CORBA.Object _get_interface_def() > > to Object and ObjectImpl and > > org.omg.CORBA.Object > get_interface_def(org.omg.CORBA.Object self) > > to Delegate. > > > > b. deprecate the existing methods > > org.omg.CORBA.InterfaceDef _get_interface() > > on Object and ObjectImpl and > > org.omg.CORBA.InterfaceDef > > get_interface(org.omg.CORBA.Object self) > > on Delegate. > > > > Rationale: > > > > The new methods do not refer to Interface Repository types in > their > > signatures. However, at runtime they still return the same IR > objects > > as the deprecated methods. Since this signature change is a > binary > > incompatible change, and since Java methods cannot be > overloaded on > > their return types, the new methods have different names than > the > > deprecated methods. This allows an easier path for user > migration > > than if the method signatures had been updated "in place". > > > > Removing IR types from the signatures allows the new methods to > be > > included in the core JDK without also having to include all the > IR > > classes in the core JDK. With likely changes in this area in > the near > > future because of the Components RFP, it is felt to be unwise > to put > > the IR into core in JDK 1.2. > > > > 3. Change the ORB class to > > a. add a new method > > public NVList create_operation_list(org.omg.CORBA.Object > oper) > > > > b. deprecate the existing method > > public NVList > > create_operation_list(org.omg.CORBA.OperationDef oper) > > > > Rationale: > > > > The reason for this change is as for item 2 above. Since Java > supports > > overloading on argument types, there is no need to change the > method > > name in this case. > > > > 4. Move some methods needed by Objects By Value from the ORB, > > InputStream and > > OutputStream classes to new subclasses that will not be part > > of the core > > JDK 1.2. The names of these new classes are: > > org.omg.CORBA.ext.ORB > > org.omg.CORBA.portable.ext.InputStream > > org.omg.CORBA.portable.ext.OutputStream > > and the methods affected are: > > ORB.get_value_def > > ORB.register_value_factory > > ORB.unregister_value_factory > > ORB.lookup_value_factory > > InputStream.read_Value > > InputStream.read_Abstract > > OutputStream.write_Value > > OutputStream.write_Abstract > > OutputStream.start_block > > OutputStream.end_block > > > > Rationale: > > > > Excluding these methods from the core JDK 1.2 allows these > > methods to be > > revised by the IDL/Java 2.4 RTF (e.g., to solve the known > issues with > > OBV) without the current state of the spec being "locked in" as > part of > > the core JDK 1.2. > > > > The number of extension subclasses is expected to remain small. > > Initially it is only 3 classes, of which only 1 (ORB) contains > user > > application APIs. > > > > It's important to emphasize that there is only one version of > CORBA. > > The core JDK will contain a carefully selected subset of CORBA > based > > on the functionality that is felt to be important for the "write > once > > run anywhere" Java platform. Over time, this set of functionality > > will be extended as CORBA is extended. Some users will program to > the > > "write once run anywhere" CORBA support provided by the core JDK, > and > > others will exploit additional CORBA functionality that will be > > available as part of third-party ORB products. In either case, > their > > programs should continue to run unchanged when non-core APIs move > into > > core, and when new non-core APIs are added. > > > > It is expected that non-core APIs will move into the core JDK over > time. > > For example, OBV support should be included in the next JDK > release. > > In order to ensure consistent evolution of the CORBA APIs in the > core > > JDK and the CORBA standard as defined by OMG, it will be necessary > to > > define new procedures that OMG and Sun will follow. A precise > definition > > of how this will work will be added to this proposal. It has been > > suggested that OMG would recommend which fully approved OMG > > specifications/APIs should become part of the core JDK and Sun > would not > > add OMG specifications/APIs to the core that have not been so > recommended. > > Details of exactly how this process will work in OMG and its > timing, > > granularity, etc. still need to be defined. > > > > A word on naming. Choosing names for things often seems to raise > strong > > opinions. The names I have proposed for the new non-core > subclasses of > > core classes in point 4 above represent one of a number of > > possible choices > > which are listed below. For each of these, example names for the > > non-core > > subclasses of the core classes org.omg.CORBA.ORB and > > org.omg.CORBA.portable.InputStream are shown. > > > > 1. Change the class name but leave the package unchanged. For > example, > > add the suffix "2" (or something else) to all affected class > names, > > resulting in names such as: > > org.omg.CORBA.ORB2 > > org.omg.CORBA.portable.InputStream2 > > > > 2. Put an additional qualifier into the package name underneath > its > > low-order component. The additional qualifier could be > anything, > > for example: > > org.omg.CORBA.ext.ORB > > org.omg.CORBA.portable.ext.InputStream > > > > 3. Change the low-order component of the package name. For > example, > > these new APIs could go in classes called: > > org.omg.CORBA3.ORB > > org.omg.CORBA3.portable.InputStream > > > > 4. Put an additional qualifier into the package name between its > > high-order component and the org.omg prefix. The additional > > qualifier could be anything, for example: > > org.omg.ext.CORBA.ORB > > org.omg.ext.CORBA.portable.InputStream > > > > 5. Change the "reverse DNS" prefix from org.omg to something else > > such as com.omg or org.corba, for example: > > com.omg.CORBA.ORB > > com.omg.CORBA.portable.InputStream > > > > My view of these is that 5 would be a particularly bad choice > because it > > creates a whole new namespace, which is out of all proportion to > the > > significance of the small number of extension classes that add > methods > > to the base versions in the core JDK. We need to promote a single > > coherent CORBA standard (some subset of which is in the core JDK), > and > > avoid the appearance that there are two alternative versions of > CORBA > > called org.omg.* and com.omg.*. As far as the others are > concerned, > > there are pros and cons to each of them, but most people seem to > > prefer 2 and 4 to 1 and 3. Comments? > > > > Simon > > -- > > Simon C Nash, IBM Java Technology Centre, Hursley, UK > > MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 > > Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb > > -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Date: Sat, 07 Nov 1998 02:07:37 +0000 From: Simon Nash Organization: IBM To: java-rtf@omg.org Subject: Issue 1897: update to proposal In my recent proposal for issue 1897, I said I would add more detail later on the proposed new process for API evolution. Here are the words for this, to be added after point 4 of the proposed changes. 5. The Java RTF recommends these changes to the PTC for incorporation into CORBA 2.3. The Java RTF also recommends that the PTC adopt the following procedure for approving future changes to the org.omg.* APIs in the core JDK: When necessary, an appropriate TF sponsored by the PTC shall consider and report on recommended changes to the org.omg.* APIs in the core JDK. Such changes are to be approved by the PTC. For each approved change, Sun will determine whether and when to implement it in a JDK release. Sun will not make changes to the org.omg.* APIs in the core JDK that have not been approved by the PTC. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb Return-Path: Date: Fri, 08 Jan 1999 09:06:14 +0000 From: Simon Nash Organization: IBM To: java-rtf@omg.org Subject: (Issue 1897) Names for non-core packages At the last face-to-face meeting of the RTF in Burlingame, we agreed to leave open the names of the new packages for OMG-defined non-core subclasses of core JDK classes pending discussion by the Core RTF. I discussed this again with Jishnu a couple of weeks ago, and it seems there is nothing to be gained by delaying this decision any further. I would therefore like to formally propose that the names of these Java packages shall be org.omg.CORBA_2_3 (for subclasses of core classes in org.omg.CORBA) and org.omg.CORBA_2_3.portable (for subclasses of core classes in org.omg.CORBA.portable). At this time, this naming convention is used only for the following OMG-defined classes: org.omg.CORBA_2_3.ORB org.omg.CORBA_2_3.portable.InputStream org.omg.CORBA_2_3.portable.OutputStream Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb