# HG changeset patch # User lana # Date 1442611200 25200 # Node ID ca8a1719588424f6e04e943790c7fcb7cb0b8c8f # Parent bf479079d11ffb6db569d44a3bf0cf7f70196543# Parent 3ef63dbde9659564e4c19d4cb67d5afeb24ffa3b Merge diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/com/sun/corba/se/impl/ior/ByteBuffer.java --- a/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ByteBuffer.java Fri Sep 18 10:46:34 2015 -0700 +++ b/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ByteBuffer.java Fri Sep 18 14:20:00 2015 -0700 @@ -37,9 +37,9 @@ protected byte elementData[]; /** - * The number of valid components in this ByteBuffer object. - * Components elementData[0] through - * elementData[elementCount-1] are the actual items. + * The number of valid components in this {@code ByteBuffer} object. + * Components {@code elementData[0]} through + * {@code elementData[elementCount-1]} are the actual items. * * @serial */ @@ -88,7 +88,7 @@ /** * Constructs an empty ByteBuffer so that its internal data array - * has size 10 and its standard capacity increment is + * has size {@code 10} and its standard capacity increment is * zero. */ public ByteBuffer() { @@ -99,7 +99,7 @@ * Trims the capacity of this ByteBuffer to be the ByteBuffer's current * size. If the capacity of this cector is larger than its current * size, then the capacity is changed to equal the size by replacing - * its internal data array, kept in the field elementData, + * its internal data array, kept in the field {@code elementData}, * with a smaller one. An application can use this operation to * minimize the storage of a ByteBuffer. */ @@ -138,7 +138,7 @@ * Returns the current capacity of this ByteBuffer. * * @return the current capacity (the length of its internal - * data arary, kept in the field elementData + * data arary, kept in the field {@code elementData} * of this ByteBuffer. */ public int capacity() { @@ -157,9 +157,9 @@ /** * Tests if this ByteBuffer has no components. * - * @return true if and only if this ByteBuffer has + * @return {@code true} if and only if this ByteBuffer has * no components, that is, its size is zero; - * false otherwise. + * {@code false} otherwise. */ public boolean isEmpty() { return elementCount == 0; diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java --- a/src/java.corba/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java Fri Sep 18 10:46:34 2015 -0700 +++ b/src/java.corba/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java Fri Sep 18 14:20:00 2015 -0700 @@ -438,11 +438,11 @@ } /** - * Writes a java.lang.Object as a CORBA Object. If obj is + * Writes a java.lang.Object as a CORBA Object. If {@code obj} is * an exported RMI-IIOP server object, the tie is found - * and wired to obj, then written to out.write_Object(org.omg.CORBA.Object). - * If obj is a CORBA Object, it is written to - * out.write_Object(org.omg.CORBA.Object). + * and wired to {@code obj}, then written to {@code out.write_Object(org.omg.CORBA.Object)}. + * If {@code obj} is a CORBA Object, it is written to + * {@code out.write_Object(org.omg.CORBA.Object)}. * @param out the stream in which to write the object. * @param obj the object to write. */ @@ -457,10 +457,10 @@ /** * Writes a java.lang.Object as either a value or a CORBA Object. - * If obj is a value object or a stub object, it is written to - * out.write_abstract_interface(java.lang.Object). If obj is an exported - * RMI-IIOP server object, the tie is found and wired to obj, - * then written to out.write_abstract_interface(java.lang.Object). + * If {@code obj} is a value object or a stub object, it is written to + * {@code out.write_abstract_interface(java.lang.Object)}. If {@code obj} is an exported + * RMI-IIOP server object, the tie is found and wired to {@code obj}, + * then written to {@code out.write_abstract_interface(java.lang.Object)}. * @param out the stream in which to write the object. * @param obj the object to write. */ @@ -595,7 +595,7 @@ * the class might be found. May be null. * @param loader a class whose ClassLoader may be used to * load the class if all other methods fail. - * @return the Class object representing the loaded class. + * @return the {@code Class} object representing the loaded class. * @exception ClassNotFoundException if class cannot be loaded. */ public Class loadClass( String className, String remoteCodebase, @@ -605,20 +605,20 @@ } /** - * The isLocal method has the same semantics as the + * The {@code isLocal} method has the same semantics as the * ObjectImpl._is_local method, except that it can throw a RemoteException. * (no it doesn't but the spec says it should.) * - * The _is_local() method is provided so that stubs may determine + * The {@code _is_local()} method is provided so that stubs may determine * if a particular object is implemented by a local servant and hence local * invocation APIs may be used. * * @param stub the stub to test. * - * @return The _is_local() method returns true if + * @return The {@code _is_local()} method returns true if * the servant incarnating the object is located in the same process as - * the stub and they both share the same ORB instance. The _is_local() - * method returns false otherwise. The default behavior of _is_local() is + * the stub and they both share the same ORB instance. The {@code _is_local()} + * method returns false otherwise. The default behavior of {@code _is_local()} is * to return false. * * @throws RemoteException The Java to IDL specification does to diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/JNDIStateFactoryImpl.java --- a/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/JNDIStateFactoryImpl.java Fri Sep 18 10:46:34 2015 -0700 +++ b/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/JNDIStateFactoryImpl.java Fri Sep 18 14:20:00 2015 -0700 @@ -93,7 +93,7 @@ * @param name Ignored * @param ctx The non-null CNCtx whose ORB to use. * @param env Ignored - * @return The CORBA object for orig or null. + * @return The CORBA object for {@code orig} or null. * @exception ConfigurationException If the CORBA object cannot be obtained * due to configuration problems * @exception NamingException If some other problem prevented a CORBA diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/com/sun/corba/se/spi/legacy/connection/ORBSocketFactory.java --- a/src/java.corba/share/classes/com/sun/corba/se/spi/legacy/connection/ORBSocketFactory.java Fri Sep 18 10:46:34 2015 -0700 +++ b/src/java.corba/share/classes/com/sun/corba/se/spi/legacy/connection/ORBSocketFactory.java Fri Sep 18 14:20:00 2015 -0700 @@ -165,7 +165,7 @@ * If number is 0 then use an emphemeral port for the listener of * the associated type.

* - * If number is greater then 0 use that port number.

+ * If number is greater than 0 use that port number.

* * An ORB creates a listener socket for each type * specified by the user by calling diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/javax/rmi/CORBA/Util.java --- a/src/java.corba/share/classes/javax/rmi/CORBA/Util.java Fri Sep 18 10:46:34 2015 -0700 +++ b/src/java.corba/share/classes/javax/rmi/CORBA/Util.java Fri Sep 18 14:20:00 2015 -0700 @@ -108,12 +108,12 @@ } /** - * Writes a java.lang.Object as a CORBA Object. If obj is + * Writes a java.lang.Object as a CORBA Object. If {@code obj} is * an exported RMI-IIOP server object, the tie is found - * and wired to obj, then written to -out.write_Object(org.omg.CORBA.Object). - * If obj is a CORBA Object, it is written to - * out.write_Object(org.omg.CORBA.Object). + * and wired to {@code obj}, then written to + * {@code out.write_Object(org.omg.CORBA.Object)}. + * If {@code obj} is a CORBA Object, it is written to + * {@code out.write_Object(org.omg.CORBA.Object)}. * @param out the stream in which to write the object. * @param obj the object to write. */ @@ -128,12 +128,11 @@ /** * Writes a java.lang.Object as either a value or a CORBA Object. - * If obj is a value object or a stub object, it is written to - * out.write_abstract_interface(java.lang.Object). If obj -is -an exported - * RMI-IIOP server object, the tie is found and wired to obj, - * then written to out.write_abstract_interface(java.lang.Object). + * If {@code obj} is a value object or a stub object, it is written to + * {@code out.write_abstract_interface(java.lang.Object)}. + * If {@code obj} is an exported + * RMI-IIOP server object, the tie is found and wired to {@code obj}, + * then written to {@code out.write_abstract_interface(java.lang.Object)}. * @param out the stream in which to write the object. * @param obj the object to write. */ @@ -161,8 +160,8 @@ } /** - * Removes the associated tie from an internal table and calls {@link -Tie#deactivate} + * Removes the associated tie from an internal table + * and calls {@link Tie#deactivate} * to deactivate the object. * @param target the object to unexport. */ @@ -219,27 +218,27 @@ *

The spec for this method is the "Java to IDL language * mapping", ptc/00-01-06. *

In Java SE Platform, this method works as follows: - *

Tools

diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html --- a/src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html Fri Sep 18 10:46:34 2015 -0700 +++ b/src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html Fri Sep 18 14:20:00 2015 -0700 @@ -9,7 +9,8 @@

IDL-to-Java Generated Files

The files that are generated by the IDL-to-Java compiler, in accordance with -the IDL-to-Java Language Mapping Specification, +the +IDL-to-Java Language Mapping Specification, which is implemented in JavaTM SE 6 according the compliance document. @@ -18,23 +19,25 @@ and identifiers with no change. Because of the nature of the Java language, a single IDL construct may be mapped to several (differently named) Java constructs. The additional names are constructed by appending a descriptive suffix. -For example, the IDL interface foo is mapped to the Java -interfaces foo and fooOperations, and additional -Java classes fooHelper, fooHolder, fooPOA, -and optionally fooPOATie. +For example, the IDL interface foo is mapped to the Java +interfaces foo and fooOperations, and additional +Java classes fooHelper, fooHolder, fooPOA, +and optionally fooPOATie.

The mapping in effect reserves the use of several names for its own purposes. These are:

@@ -42,50 +45,55 @@

Helper Files

Helper files supply several static methods needed to manipulate the type. -These include Any insert and extract operations for the type, +These include Any insert and extract operations for the type, getting the repository id, getting the typecode, and reading and writing the type from and to a stream.

The helper class for a mapped IDL interface or abstract interface also -include narrow operation(s). The static narrow method allows an org.omg.CORBA.Object +include narrow operation(s). The static narrow method allows an org.omg.CORBA.Object to be narrowed to the object reference of a more specific type. -The IDL exception CORBA::BAD_PARAM is thrown if the narrow fails because +The IDL exception CORBA::BAD_PARAM is thrown if the narrow fails because the object reference does not support the requested type. A different system exception -is raised to indicate other kinds of errors. Trying to narrow a null will always succeed with a return value of null. +is raised to indicate other kinds of errors. Trying to narrow +a null will always succeed with a return value of null.

Holder Files

Support for out and inout parameter passing modes requires the use of additional holder classes. -These classes are available for all of the basic IDL datatypes in the org.omg.CORBA package +These classes are available for all of the basic IDL datatypes in the org.omg.CORBA package and are generated for all named user defined IDL types except those defined by typedefs. (Note that in this context user defined includes types that are defined in OMG specifications such as those for the Interface Repository, and other OMG services.)

Each holder class has a constructor from an instance, a default constructor, and has -a public instance member, value which is the typed value. The default constructor +a public instance member, value which is the typed value. The default constructor sets the value field to the default value for the type as defined by the Java language: false for boolean, 0 for numeric and char types, null for strings, null for object references.

To support portable stubs and skeletons, holder classes also implement -the org.omg.CORBA.portable.Streamable interface. +the org.omg.CORBA.portable.Streamable interface.

Operations Files

A non abstract IDL interface is mapped to two public Java interfaces: a signature interface and an operations interface. -The signature interface, which extends IDLEntity, has the same -name as the IDL interface name and is used as the signature type in method declarations +The signature interface, which extends IDLEntity, has the same +name as the IDL interface name and is used +as the signature type in method declarations when interfaces of the specified type are used in other interfaces. -The operations interface has the same name as the IDL interface with the suffix Operations +The operations interface has the same name as the IDL interface +with the suffix Operations appended to the end and is used in the server-side mapping and as a mechanism for providing optimized calls for collocated client and servers.

The Java operations interface contains the mapped operation signatures. The Java signature interface extends the operations interface, -the (mapped) base org.omg.CORBA.Object, as well as org.omg.portable.IDLEntity. +the (mapped) base org.omg.CORBA.Object, +as well as org.omg.portable.IDLEntity. Methods can be invoked on the signature interface. Interface inheritance -expressed in IDL is reflected in both the Java signature interface and operations interface hierarchies. +expressed in IDL is reflected in both the Java signature +interface and operations interface hierarchies.

Stubs

@@ -96,11 +104,13 @@ for programmers to predict once they are familiar with OMG IDL and the language mapping for the particular programming language. The stubs make calls on the rest of the ORB using interfaces that are private to, and presumably optimized for, the particular ORB Core. -If more than one ORB is available, there may be different stubs corresponding to the different ORBs. -In this case, it is necessary for the ORB and language mapping to cooperate to associate +If more than one ORB is available, there may be different stubs +corresponding to the different ORBs. In this case, it is necessary for +the ORB and language mapping to cooperate to associate the correct stubs with the particular object reference. -

Object-oriented programming languages, such as Java, C++, and Smalltalk, do not require stub interfaces. +

Object-oriented programming languages, such as Java, +C++, and Smalltalk, do not require stub interfaces.

diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/org/omg/CORBA/package.html --- a/src/java.corba/share/classes/org/omg/CORBA/package.html Fri Sep 18 10:46:34 2015 -0700 +++ b/src/java.corba/share/classes/org/omg/CORBA/package.html Fri Sep 18 14:20:00 2015 -0700 @@ -34,27 +34,27 @@ Provides the mapping of the OMG CORBA APIs to the JavaTM -programming language, including the class ORB, which is implemented +programming language, including the class ORB, which is implemented so that a programmer can use it as a fully-functional Object Request Broker (ORB). -

For a precise list of supported sections of official CORBA specifications with which -the Java[TM] Platform, Standard Edition 6 complies, see Official Specifications for CORBA support in +

For a precise list of supported sections of official CORBA specifications with which +the Java[TM] Platform, Standard Edition 6 complies, see Official Specifications for CORBA support in Java[TM] SE 6.

General Information

-The information in this section is information relevant to someone who +The information in this section is information relevant to someone who compiles Interface Definition Language (IDL) files and uses the ORB to write clients and servers. -

The classes and interfaces described in this section can be put into -four groups: ORB classes, Exceptions, Helper classes, -and Holder classes. +

The classes and interfaces described in this section can be put into +four groups: ORB classes, Exceptions, Helper classes, +and Holder classes.

-The ORB Class

+The ORB Class

An ORB handles (or brokers) method invocations between a client and the method's implementation on a server. Because the client and server @@ -63,92 +63,91 @@ deal of work behind the scenes to accomplish this communication.

Most of what an ORB does is completely transparent to the user, and a major -portion of the CORBA package consists of classes used by the ORB +portion of the CORBA package consists of classes used by the ORB behind the scenes. The result is that most programmers will use only a small part of this package directly. In fact, most programmers will use -only a few methods from the ORB class, some exceptions, and +only a few methods from the ORB class, some exceptions, and occasionally, -a holder class. +a holder class.

-ORB Methods

+ORB Methods -

Before an application can enter the CORBA environment, it must first: +

Before an application can enter the CORBA environment, it must first:

The following operations are provided to initialize applications and obtain the appropriate object references:

-When an application requires a CORBA environment it needs a mechanism to -get an ORB object reference and possibly an OA object reference -(such as the root POA). This serves two purposes. First, it initializes -an application into the ORB and OA environments. Second, it returns the -ORB object reference and the OA object reference to the application -for use in future ORB and OA operations. +When an application requires a CORBA environment it needs a mechanism to +get an ORB object reference and possibly an OA object reference +(such as the root POA). This serves two purposes. First, it initializes +an application into the ORB and OA environments. Second, it returns the +ORB object reference and the OA object reference to the application +for use in future ORB and OA operations. -

In order to obtain an ORB object reference, applications call -the ORB.init operation. The parameters to the call can comprise an +

In order to obtain an ORB object reference, applications call +the ORB.init operation. The parameters to the call can comprise an identifier for the ORB for which the object reference is required, - and an arg_list, which is used to allow environment-specific data to be - passed into the call. + and an arg_list, which is used to allow environment-specific data to be + passed into the call. -

These are the ORB methods +

These are the ORB methods that provide access to the ORB:

-

Using the init() method without parameters initiates +

Using the init() method without parameters initiates a singleton ORB, which can only -give typecode creation anys needed in code generated -in Helper classes by idlj. +give typecode creation anys needed in code generated +in Helper classes by idlj. -

Applications require a portable means by which to obtain their -initial object references. References are required for the root -POA, POA Current, Interface Repository, and various Object Services +

Applications require a portable means by which to obtain their +initial object references. References are required for the root +POA, POA Current, Interface Repository, and various Object Services instances. The functionality required by the application is similar - to that provided by the Naming Service. However, the OMG does not - want to mandate that the Naming Service be made available to all - applications in order that they may be portably initialized. - Consequently, the operations shown in this section provide a - simplified, local version of the Naming Service that applications - can use to obtain a small, defined set of object references which - are essential to its operation. Because only a small well-defined + to that provided by the Naming Service. However, the OMG does not + want to mandate that the Naming Service be made available to all + applications in order that they may be portably initialized. + Consequently, the operations shown in this section provide a + simplified, local version of the Naming Service that applications + can use to obtain a small, defined set of object references which + are essential to its operation. Because only a small well-defined set of objects are expected with this mechanism, the naming context can be flattened to be a single-level name space. This simplification results in only two operations being defined to achieve the functionality required. -

Initial references are obtained via two operations provided in -the ORB object interface, providing facilities to list and +

Initial references are obtained via two operations provided in +the ORB object interface, providing facilities to list and resolve initial object references. These are:

-

An example that uses some of these methods is An example that uses some of these methods is Getting Started with Java IDL. @@ -156,7 +155,7 @@ Exceptions Exceptions in Java IDL are similar to those in any code written in the Java programming language. If a method is defined to throw an exception, -then any code using that method must have a try/catch +then any code using that method must have a try/catch block and handle that exception when it is thrown.

The documentation on The following is a list of the system exceptions (which are unchecked -exceptions inheriting through -org.omg.CORBA.SystemException from -java.lang.RuntimeException) that are defined in the package -org.omg.CORBA: +exceptions inheriting through +org.omg.CORBA.SystemException from +java.lang.RuntimeException) that are defined in the package +org.omg.CORBA: 


         BAD_CONTEXT
         BAD_INV_ORDER
@@ -203,7 +202,7 @@

The following is a list of user-defined exceptions defined in the package -org.omg.CORBA. +org.omg.CORBA. 


         Bounds
         UnknownUserException
@@ -212,37 +211,37 @@

Subpackages

-There are some packages inside the CORBA package with +There are some packages inside the CORBA package with "Package" as part of their names. These packages are generally quite small because all they do is provide exceptions or classes for use by interfaces -and classes in the CORBA package. +and classes in the CORBA package. -

For example, the package -org.omg.CORBA.TypeCodePackage contains -two exceptions thrown by methods in the class TypeCode. These +

For example, the package +org.omg.CORBA.TypeCodePackage contains +two exceptions thrown by methods in the class TypeCode. These exceptions are:

-The package -org.omg.CORBA.ORBPackage contains two exceptions: +The package +org.omg.CORBA.ORBPackage contains two exceptions: -

Another package that is a subpackage of CORBA is the -portable package. It -provides a set of ORB APIs that makes it +

Another package that is a subpackage of CORBA is the +portable +package. It provides a set of ORB APIs that makes it possible for code generated by one vendor's IDL compiler to run -on another vendor's ORB. +on another vendor's ORB. @@ -251,47 +250,49 @@ Holder classes -

Support for out and inout parameter passing modes requires the use of -additional holder -classes. Because the Java programming language does not support out or +

Support for out and inout parameter passing modes requires the use of +additional holder +classes. Because the Java programming language does not support out or inout parameters, holder classes are needed as a means of passing a parameter -that can be modified. To support portable stubs and skeletons, holder classes also implement - the org.omg.CORBA.portable.Streamable - interface. +that can be modified. To support portable stubs and skeletons, +holder classes also implement the +org.omg.CORBA.portable.Streamable +interface.

Holder classes are named by appending "Holder" to the name of the type. The name of the type refers to its name in the Java programming language. For - example, a holder class for the interface named Account in the Java programming - language would be named AccountHolder. + example, a holder class for the interface named Account + in the Java programming + language would be named AccountHolder.

Holder classes are available for all of the basic IDL - datatypes in the org.omg.CORBA package. So, for example, - there are already-defined classes for LongHolder, ShortHolder, - FloatHolder, and so on. Classes are also generated for - all named user-defined IDL types except those defined by typedefs. - (Note that in this context user defined includes types that are + datatypes in the org.omg.CORBA package. So, for example, + there are already-defined classes for LongHolder, ShortHolder, + FloatHolder, and so on. Classes are also generated for + all named user-defined IDL types except those defined by typedefs. + (Note that in this context user defined includes types that are defined in OMG specifications such as those for the Interface - Repository, and other OMG services.) + Repository, and other OMG services.)

Each holder class has:

-

The default constructor sets the value field to the default value for the -type as defined by the Java language: +

The default constructor sets the value field to the default value for the +type as defined by the Java language:

@@ -301,7 +302,7 @@ were mapped to the Java programming language, the following holder class would be generated: 
-public final class AccountHolder implements 
+public final class AccountHolder implements
     org.omg.CORBA.portable.Streamable
 {
   // field that holds an Account object
@@ -342,53 +343,52 @@
 
For more information on Holder classes, see Chapter 1.4, Mapping for
 Basic Types in the 
 OMG IDL to Java Language Mapping. The Holder classes defined 
-in the package org.omg.CORBA are:
-
-     AnyHolder
-     AnySeqHolder
-     BooleanHolder
-     BooleanSeqHolder
-     ByteHolder
-     CharHolder
-     CharSeqHolder
-     CurrentHolder
-     DoubleHolder
-     DoubleSeqHolder
-     FixedHolder
-     FloatHolder
-     FloatSeqHolder
-     IntHolder
-     LongHolder
-     LongLongSeqHolder
-     LongSeqHolder
-     ObjectHolder
-     OctetSeqHolder
-     ParameterModeHolder
-     PolicyErrorHolder
-     PolicyListHolder
-     PrincipalHolder
-     ServiceInformationHolder
-     ShortHolder
-     ShortSeqHolder
-     StringHolder
-     StringSeqHolder
-     TypeCodeHolder
-     ULongLongSeqHolder
-     ULongSeqHolder
-     UnknownUserExceptionHolder
-     UShortSeqHolder
-     ValueBaseHolder
-     WCharSeqHolder
-     WrongTransactionHolder
-     WStringSeqHolder
-
-

+in the package org.omg.CORBA are:
+

+     AnyHolder
+     AnySeqHolder
+     BooleanHolder
+     BooleanSeqHolder
+     ByteHolder
+     CharHolder
+     CharSeqHolder
+     CurrentHolder
+     DoubleHolder
+     DoubleSeqHolder
+     FixedHolder
+     FloatHolder
+     FloatSeqHolder
+     IntHolder
+     LongHolder
+     LongLongSeqHolder
+     LongSeqHolder
+     ObjectHolder
+     OctetSeqHolder
+     ParameterModeHolder
+     PolicyErrorHolder
+     PolicyListHolder
+     PrincipalHolder
+     ServiceInformationHolder
+     ShortHolder
+     ShortSeqHolder
+     StringHolder
+     StringSeqHolder
+     TypeCodeHolder
+     ULongLongSeqHolder
+     ULongSeqHolder
+     UnknownUserExceptionHolder
+     UShortSeqHolder
+     ValueBaseHolder
+     WCharSeqHolder
+     WrongTransactionHolder
+     WStringSeqHolder
+

 
 
Helper Classes 

 
Helper files supply several static methods needed to manipulate the type.
  These include:
  
 
 
 
The helper class for a mapped IDL interface or abstract interface
- also include narrow operation(s). The static narrow method allows 
- an org.omg.CORBA.Object to be narrowed to the object reference 
- of a more specific type. The IDL exception CORBA.BAD_PARAM 
- is thrown if the narrow fails because the object reference does not 
- support the requested type. A different system exception is raised 
- to indicate other kinds of errors. Trying to narrow a null will always
-  succeed with a return value of null. Generally, the only helper method an application programmer uses is
+also include narrow operation(s). The static narrow method allows
+an org.omg.CORBA.Object to be narrowed to the object reference
+of a more specific type. The IDL exception CORBA.BAD_PARAM
+is thrown if the narrow fails because the object reference does not
+support the requested type. A different system exception is raised
+to indicate other kinds of errors. Trying to narrow a null will always
+succeed with a return value of null.
+Generally, the only helper method an application programmer uses is
 the narrow method.  The other methods are normally used behind
 the scenes and are transparent to the programmer.
 
 
Helper classes
 fall into two broad categories, helpers for value types and
-helpers for non value types. Because all of the helper 
+helpers for non value types. Because all of the helper
 classes in one category
-provide the same methods, one generic explanation of each 
+provide the same methods, one generic explanation of each
 category of helper classes is presented here.
 
 

-When OMG IDL is mapped to the Java programming language, 
+When OMG IDL is mapped to the Java programming language,
 a "helper" class is generated for each user-defined type.
 This generated class will have the name of the user-defined type with
 the suffix Helper appended.  For example, if the
@@ -423,7 +424,7 @@
 idlj compiler will automatically generate a class named
 AccountHelper.  The AccountHelper class
 will contain the static methods needed for manipulating instances of the type,
-in this case, Account objects. 
+in this case, Account objects.
 
 
 
@@ -442,14 +443,12 @@
 not determines which narrow method its helper class will provide.
 The helper class for an interface
 that is not abstract will have a narrow method that takes a CORBA
-object, whereas the narrow method for an interface that is abstract 
-will
-take an object in the Java programming language.  The helper class for a
+object, whereas the narrow method for an interface that is abstract
+will take an object in the Java programming language.  The helper class for a
 non-abstract interface that has at least one abstract base interface will provide
 both versions of the narrow method.
-
The Hello World 
-tutorial uses a narrow method that looks 
-like this:
+
The Hello World
+tutorial uses a narrow method that looks like this:
 
         // create and initialize the ORB
         ORB orb = ORB.init(args, null);
@@ -469,7 +468,7 @@
 
 
Example of a Basic Helper Class

 A basic helper class, for purposes of this explanation, is one with
-the methods that are provided by every helper class, plus a narrow 
+the methods that are provided by every helper class, plus a narrow
 method if the type defined in OMG IDL maps to an interface in the Java
 programming language.  Types that are not value types will have a basic
 helper class generated for them.
@@ -626,57 +625,56 @@
 }
 

 
-
The Helper classes defined in the package org.omg.CORBA are:
+
The Helper classes defined in the package org.omg.CORBA are:
 

-     AnySeqHelper
-     BooleanSeqHelper
-     CharSeqHelper
-     CompletionStatusHelper
-     CurrentHelper
-     DefinitionKindHelper
-     DoubleSeqHelper
-     FieldNameHelper
-     FloatSeqHelper
-     IdentifierHelper
-     IDLTypeHelper
-     LongLongSeqHelper
-     LongSeqHelper
-     NameValuePairHelper
-     ObjectHelper
-     OctetSeqHelper
-     ParameterModeHelper
-     PolicyErrorCodeHelper
-     PolicyErrorHelper
-     PolicyHelper
-     PolicyListHelper
-     PolicyTypeHelper
-     RepositoryIdHelper
-     ServiceDetailHelper
-     ServiceInformationHelper
-     SetOverrideTypeHelper
-     ShortSeqHelper
-     StringSeqHelper
-     StringValueHelper
-     StructMemberHelper
-     ULongLongSeqHelper
-     ULongSeqHelper
-     UnionMemberHelper
-     UnknownUserExceptionHelper
-     UShortSeqHelper
-     ValueBaseHelper
-     ValueMemberHelper
-     VersionSpecHelper
-     VisibilityHelper
-     WCharSeqHelper
-     WrongTransactionHelper
-     WStringSeqHelper
-     WStringValueHelper
-
+     AnySeqHelper
+     BooleanSeqHelper
+     CharSeqHelper
+     CompletionStatusHelper
+     CurrentHelper
+     DefinitionKindHelper
+     DoubleSeqHelper
+     FieldNameHelper
+     FloatSeqHelper
+     IdentifierHelper
+     IDLTypeHelper
+     LongLongSeqHelper
+     LongSeqHelper
+     NameValuePairHelper
+     ObjectHelper
+     OctetSeqHelper
+     ParameterModeHelper
+     PolicyErrorCodeHelper
+     PolicyErrorHelper
+     PolicyHelper
+     PolicyListHelper
+     PolicyTypeHelper
+     RepositoryIdHelper
+     ServiceDetailHelper
+     ServiceInformationHelper
+     SetOverrideTypeHelper
+     ShortSeqHelper
+     StringSeqHelper
+     StringValueHelper
+     StructMemberHelper
+     ULongLongSeqHelper
+     ULongSeqHelper
+     UnionMemberHelper
+     UnknownUserExceptionHelper
+     UShortSeqHelper
+     ValueBaseHelper
+     ValueMemberHelper
+     VersionSpecHelper
+     VisibilityHelper
+     WCharSeqHelper
+     WrongTransactionHelper
+     WStringSeqHelper
+     WStringValueHelper
 

 
 

 Other Classes

-The other classes and interfaces in the CORBA package, which are
+The other classes and interfaces in the CORBA package, which are
 used behind the scenes, can be put into four groups. Three of the groups
 are used with requests in some capacity, and the fourth group, concerning
 the Interface Repository, is a category by itself.
@@ -686,38 +684,38 @@
 information used in request operations. 
 
 
@@ -726,23 +724,23 @@
 The second group of classes deals with requests:
 
 
@@ -750,82 +748,82 @@
 Interfaces That Serve as Constants
 The third group contains interfaces that serve as constants. The IDL-to-Java
 mapping mandates that IDL enums are mapped to a Java class with the enumerated
-values represented as public static final fields in that class (e.g. 
+values represented as public static final fields in that class (e.g.
 DefinitionKind).
 On the other hand IDL constants defined outside of an IDL interface are
 mapped to a Java interface for each constant.
 
-
This is why several interfaces in the org.omg.CORBA package
-consist of a single field, value, which is a short. This
+
This is why several interfaces in the org.omg.CORBA package
+consist of a single field, value, which is a short. This
 field is a constant used for such things as an error code or value modifier.
-For example, the value field of the interface BAD_POLICY
-is one of the possible reasons for the exception PolicyError to
-be thrown. To specify this error code, you would use BAD_POLICY.value.
+For example, the value field of the interface BAD_POLICY
+is one of the possible reasons for the exception PolicyError to
+be thrown. To specify this error code, you would use BAD_POLICY.value.
 
-
The exception PolicyError uses the value field of
+
The exception PolicyError uses the value field of
 the following interfaces as its possible error codes.
 

-The method TypeCode.type_modifier returns the value field
-of one of the following interfaces. The VM in the names of these
+The method TypeCode.type_modifier returns the value field
+of one of the following interfaces. The VM in the names of these
 interfaces stands for "value modifier."
 
 The following constants are returned by a ValueMember object's
 access method to denote the visibility of the ValueMember object.
 
-These flags, used in NamedValue objects or as parameters to methods,
+These flags, used in NamedValue objects or as parameters to methods,
 are defined in the following interfaces:
 
 
 

 Interface Repository Interfaces and Classes

 A fourth group contains the Interface Repository interfaces and classes,
-which are generated by the idlj compiler from the OMG IDL
-interface ir.idl. The purpose of the Interface Repository is to
+which are generated by the idlj compiler from the OMG IDL
+interface ir.idl. The purpose of the Interface Repository is to
 identify the interfaces stored in it so that they can be accessed by an
 ORB. Each module, type, interface, attribute, operation, parameter, exception,
 constant, and so on is described completely by the Interface Repository
@@ -874,7 +872,7 @@
 

 CORBA Features Not Implemented in Java IDL

 
-
Some of the API included in org.omg subpackages is provided for
+
Some of the API included in org.omg subpackages is provided for
 conformance with the current OMG CORBA specification but is not implemented
 in Sun's release of the JDKTM. This enables
 other JDK licensees to provide implementations of this API in standard
@@ -883,21 +881,21 @@
 

 
Features That Throw NO_IMPLEMENT

 
-
Some of the API included in org.omg subpackages throw 
-NO_IMPLEMENT exceptions for various reasons.  Among these reasons
+
Some of the API included in org.omg subpackages throw
+NO_IMPLEMENT exceptions for various reasons.  Among these reasons
 are:
     

 
 
@@ -912,65 +910,67 @@
 operation of Java IDL.
 
 
  • 
-Java IDL does not support long double.  
+Java IDL does not support long double.
 
 
 
  • 
-Policies (org.omg.CORBA.Policy) and methods for getting them are not implemented.
+Policies (org.omg.CORBA.Policy)
+and methods for getting them are not implemented.
 
 
  • 
-Domain managers (org.omg.CORBA.DomainManager) and methods for
+Domain managers (org.omg.CORBA.DomainManager) and methods for
 getting them are not implemented.
 
 
  • 
-Service Information org.omg.CORBA.ServiceInformation and ORB method public boolean get_service_information(short service_type, 
-ServiceInformationHolder
-service_info)  are not implemented.
+Service Information org.omg.CORBA.ServiceInformation
+and ORB method 
+public boolean get_service_information(short service_type, ServiceInformationHolder service_info)
+are not implemented.
 
-
  • ORB methods for supporting single-threading (perform_work, work_pending) are not implemented.
+
  • ORB methods for supporting single-threading
+(perform_work, work_pending) are not implemented.
 
 
  • IDL contexts.
 
 
 
    
 
    
-Specific List of Unimplemented Features in Package org.omg.CORBA
    
+Specific List of Unimplemented Features in Package org.omg.CORBA
 
 
 
    
-Unimplemented Methods in package org.omg.CORBA:
    
+Unimplemented Methods in package org.omg.CORBA:
 
 
      
 
    • 
-ORB
+ORB
 
 
        
 
      • 
-public org.omg.CORBA.Policy create_policy(int type, org.omg.CORBA.Any
-val)
+public org.omg.CORBA.Policy create_policy(int type, org.omg.CORBA.Any val)
 
 
 
 
      • 
-public void perform_work()
+public void perform_work()
 
 
      • 
-public boolean work_pending()
+public boolean work_pending()
 
 
      • 
-public org.omg.CORBA.Current get_current()
+public org.omg.CORBA.Current get_current()
 
 
      • 
-create_operation_list
+create_operation_list
 
 
      • 
-get_default_context
+get_default_context
 
 
      • 
-get_service_information
+get_service_information
 
 
      • 
-obsolete DynAnys (deprecated in favor of DynamicAny package)
+obsolete DynAnys (deprecated in favor of DynamicAny package)
 
 
 
      
diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/org/omg/CosNaming/NamingContextExtPackage/package.html
--- a/src/java.corba/share/classes/org/omg/CosNaming/NamingContextExtPackage/package.html	Fri Sep 18 10:46:34 2015 -0700
+++ b/src/java.corba/share/classes/org/omg/CosNaming/NamingContextExtPackage/package.html	Fri Sep 18 14:20:00 2015 -0700
@@ -30,20 +30,20 @@
 
 
 
-
      This package contains the following classes, which are used in 
-org.omg.CosNaming.NamingContextExt:
+
      This package contains the following classes, which are used in
+org.omg.CosNaming.NamingContextExt:
 
        
- 
      • AddressHelper
- 
      • StringNameHelper
- 
      • URLStringHelper
- 
      • InvalidAddress
+ 
      • AddressHelper
+ 
      • StringNameHelper
+ 
      • URLStringHelper
+ 
      • InvalidAddress
 
      
 
 
      Package Specification
      
 
-
      For a precise list of supported sections of official specifications with which 
-the Java[tm] Platform, Standard Edition 6 ORB complies, see Official Specifications for CORBA 
+
      For a precise list of supported sections of official specifications with which
+the Java[tm] Platform, Standard Edition 6 ORB complies, see Official Specifications for CORBA
 support in Java[tm] SE 6.
 
 @since 1.4
diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/org/omg/CosNaming/NamingContextPackage/package.html
--- a/src/java.corba/share/classes/org/omg/CosNaming/NamingContextPackage/package.html	Fri Sep 18 10:46:34 2015 -0700
+++ b/src/java.corba/share/classes/org/omg/CosNaming/NamingContextPackage/package.html	Fri Sep 18 14:20:00 2015 -0700
@@ -30,23 +30,23 @@
 
 
 
-
      This package contains Exception classes for the org.omg.CosNaming
+
      This package contains Exception classes for the org.omg.CosNaming
  package.  The list  of exception classes are:
  
        
-  
      • AlreadyBound
-  
      • CannotProceed
-  
      • InvalidName
-  
      • NotEmpty
-  
      • NotFound
-  
      • NotFoundReason
+  
      • AlreadyBound
+  
      • CannotProceed
+  
      • InvalidName
+  
      • NotEmpty
+  
      • NotFound
+  
      • NotFoundReason
  
      
 
 
 
      Package Specification
      
  
-
      For a precise list of supported sections of official specifications with which 
-the Java[tm] Platform, Standard Edition 6 ORB complies, see Official Specifications for CORBA 
+
      For a precise list of supported sections of official specifications with which
+the Java[tm] Platform, Standard Edition 6 ORB complies, see Official Specifications for CORBA
 support in Java SE 6.
 
 @since 1.4
diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/org/omg/CosNaming/nameservice.idl
--- a/src/java.corba/share/classes/org/omg/CosNaming/nameservice.idl	Fri Sep 18 10:46:34 2015 -0700
+++ b/src/java.corba/share/classes/org/omg/CosNaming/nameservice.idl	Fri Sep 18 14:20:00 2015 -0700
@@ -99,8 +99,8 @@
    * The BindingIterator interface allows a client to iterate through
    * the bindings using the next_one or next_n operations.
    * 
-   * The bindings iterator is obtained by using the list
-   * method on the NamingContext. 
+   * The bindings iterator is obtained by using the list
+   * method on the NamingContext.
    * @see org.omg.CosNaming.NamingContext#list
    */
   interface BindingIterator 
@@ -412,7 +412,7 @@
  * contains a set of name bindings in which each name is unique and is
  * part of Interoperable Naming Service.
  * Different names can be bound to an object in the same or different
- * contexts at the same time. Using NamingContextExt, you can use
+ * contexts at the same time. Using NamingContextExt, you can use
  * URL-based names to bind and resolve.
  * 
  * See 
diff -r bf479079d11f -r ca8a17195884 src/java.corba/share/classes/org/omg/CosNaming/package.html
--- a/src/java.corba/share/classes/org/omg/CosNaming/package.html	Fri Sep 18 10:46:34 2015 -0700
+++ b/src/java.corba/share/classes/org/omg/CosNaming/package.html	Fri Sep 18 14:20:00 2015 -0700
@@ -35,25 +35,25 @@
 
 
   
      
-  The package and all its classes and interfaces 
+  The package and all its classes and interfaces
   were generated by running the tool idlj on the file
   nameservice.idl, which is a module written in OMG IDL.
 
   
      Package Specification
      
 
-
      For a precise list of supported sections of official specifications with which 
-the Java[tm] Platform, Standard Edition 6, ORB complies, see Official Specifications for CORBA 
+
      For a precise list of supported sections of official specifications with which
+the Java[tm] Platform, Standard Edition 6, ORB complies, see Official Specifications for CORBA
 support in Java[tm] SE 6.
 
   
      Interfaces
      
-  The package org.omg.CosNaming contains two public interfaces
-  and several auxiliary classes. 
+  The package org.omg.CosNaming contains two public interfaces
+  and several auxiliary classes.
   
      
   The interfaces are:
   
        
-  
      • NamingContext 
-  
      • BindingIterator 
+  
      • NamingContext
+  
      • BindingIterator
   
      
   
      
   These two interfaces provide the means to bind/unbind names and object
@@ -68,7 +68,7 @@
   the idlj compiler creates Java classes that can be thought of
   as auxiliary classes.
   Comments for the generated auxiliary classes
-  used by the interfaces NamingContext and 
+  used by the interfaces NamingContext and
   BindingIterator are included here.
 
   
      Classes Used by NamingContext and
@@ -78,7 +78,7 @@
   generated for each of the classes listed here,  are discussed below.)
 
   
        
-    
      • public final class NameComponent -- 
+    
      • public final class NameComponent --
     a building block for names.  (Names are bound to object references
     in a naming context.)
     
        A name is an array of one or more NameComponent objects.
@@ -99,7 +99,7 @@
     rather than a file extension or some other syntactic convention.
     Examples of the value of the kind field include the strings
     "c_source", "object_code",
-    "executable", 
+    "executable",
     "postscript", and "".  It is not unusual
     for the kind field to be the empty string.
     
@@ -110,7 +110,7 @@
     This is similar to a path name, in which the last name is the
     file name, and all names before it are directory names.
 
-    
      • public final class Binding -- 
+    
      • public final class Binding --
     an object that associates a name with an object reference or a
     naming context.
     A Binding object has two fields:
@@ -142,9 +142,9 @@
     Binding or used as parameters or return values.  These
     BindingType objects are:
     
          
-    
        • public static final BindingType nobject -- 
+    
        • public static final BindingType nobject --
     to indicate that the binding is with an object reference
-    
        • public static final BindingType ncontext -- 
+    
        • public static final BindingType ncontext --
     to indicate that the binding is with a naming context
     
        
     
        
@@ -159,7 +159,7 @@
     If the method from_int is supplied with anything other
     than _nobject
     or _ncontext, it will throw
-    the exception org.omg.CORBA.BAD_PARAM. 
+    the exception org.omg.CORBA.BAD_PARAM.
     
        Usage is as follows:
     
                BindingType btObject = from_int(_nobject);
@@ -189,7 +189,7 @@
   An instance of a holder class can be passed to a
   Java method as a parameter, and
   a value can be assigned to its value field.  This allows
-  it to perform the function of an OUT or INOUT parameter.  
+  it to perform the function of an OUT or INOUT parameter.
   
        The following holder classes are generated for the package
   org.omg.CosNaming:
   
          
@@ -202,17 +202,17 @@
   
        • NameHolder
   
        
   
        
-  Note that in the org.omg.CORBA package, 
+  Note that in the org.omg.CORBA package,
   there is a holder class for each of the basic Java types:
-  IntHolder, ShortHolder, 
+  IntHolder, ShortHolder,
   StringHolder, and so on.
   
        
   Note also that there is a NameHolder class even though
   there is no Name class; similarly, there is a
   BindingListHolder class even though there is no
   BindingList class.  This is true because in the OMG IDL
-  interface, Name and BindingList are 
-  typedefs.  There is no mapping from an IDL 
+  interface, Name and BindingList are
+  typedefs.  There is no mapping from an IDL
   typedef to a Java construct, but holder classes
   are generated if the typedef is for a sequence or
   an array.  As mapped to the
@@ -245,7 +245,7 @@
   
        Helper Classes
        
   Helper classes, which are generated for all user-defined types
   in an OMG IDL interface, supply static methods needed to manipulate
-  those types.  
+  those types.
   
        
   There is only one method in a helper class that an
   application programmer uses:  the
@@ -282,7 +282,7 @@
 Sun's implementation of the CosNaming package complies
 with the OMG COSNaming specification.  In other words,
 the APIs in Sun's naming service are implemented according to the
-guidelines for a naming service provided by OMG.  Therefore, if a 
+guidelines for a naming service provided by OMG.  Therefore, if a
 third-party vendor has implemented a naming service that is OMG
 compliant, it is possible to switch between Sun's implementation of
 CosNaming and the third-party vendor's implementation.
@@ -292,18 +292,17 @@
 
 
        Instructions for Using a Third Party's Naming Service
        
 Although we encourage using an ORB and ORB services that are both
-from one vendor, it is possible to plug in a third party's 
+from one vendor, it is possible to plug in a third party's
 COSNaming implementation with Sun's RMI-IIOP ORB.
 Here are the steps to follow:
 
          
   
        1. Create a properties file for the Bootstrap server and give it
-      two entries.  For example, you could call this properties file 
+      two entries.  For example, you could call this properties file
       /tmp/services and put the following in it:
-      NameService, <Stringified IOR of the Root Naming 
-Context>.
+      NameService, <Stringified IOR of the Root Naming Context>.
       
          
       This associates NameService with the Root Naming
-      Context of the CosNaming implementation that you 
+      Context of the CosNaming implementation that you
       want to use.
   
        2. Start the standalone Bootstrap server using the following command:
   
          @@ -318,7 +317,7 @@
   specifying a port number is optional.
 
        
 
        
-Now when an application calls the method 
+Now when an application calls the method
 org.omg.CORBA.ORB.resolve_initial_references, CORBA
 processes will contact the Bootstrap Server to get the Root Naming
 Context.
@@ -326,13 +325,13 @@
 
        Package Specification
        
 
 
 
 
        Related Documentation
        
 
-For an overview and examples of how to use the 
+For an overview and examples of how to use the
 CosNaming API, please see: