Memory management fixes and comment corrections

git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@5656 626c5289-ae23-0410-ae9c-e8d60b6d4f22

Examples/java/extend/main.java

@@ -10,6 +10,10 @@ class CEO extends Manager {
   public String getPosition() {
     return "CEO";
     }
+  // Public method to stop the SWIG proxy base class from thinking it owns the underlying C++ memory.
+  public void disownMemory() {
+    swigCMemOwn = false; 
+  } 
 }
 
 
@@ -26,9 +30,9 @@ public class main {
   public static void main(String argv[]) 
   {
 
-    // Create an instance of our employee extension class, CEO. The calls to
-    // getName() and getPosition() are standard, the call to getTitle() uses
-    // the director wrappers to call CEO.getPosition. e = CEO("Alice")
+    // Create an instance of CEO, a class derived from the Java proxy of the 
+    // underlying C++ class. The calls to getName() and getPosition() are standard,
+    // the call to getTitle() uses the director wrappers to call CEO.getPosition().
 
     CEO e = new CEO("Alice");
     System.out.println( e.getName() + " is a " + e.getPosition() );
@@ -41,29 +45,23 @@ public class main {
 
     EmployeeList list = new EmployeeList();
 
-    // EmployeeList owns its items, so we must surrender ownership of objects
-    // we add. This involves first calling the __disown__ method to tell the
-    // C++ director to start reference counting. We reassign the resulting
-    // weakref.proxy to e so that no hard references remain. This can also be
-    // done when the object is constructed, as in: e =
-    // CEO("Alice").__disown__()
-
-//    e = e.__disown__();
+    // EmployeeList owns its items, so we must surrender ownership of objects we add.
+    e.disownMemory();
     list.addEmployee(e);
     System.out.println( "----------------------" );
 
     // Now we access the first four items in list (three are C++ objects that
     // EmployeeList's constructor adds, the last is our CEO). The virtual
     // methods of all these instances are treated the same. For items 0, 1, and
-    // 2, both all methods resolve in C++. For item 3, our CEO, getTitle calls
+    // 2, all methods resolve in C++. For item 3, our CEO, getTitle calls
     // getPosition which resolves in Java. The call to getPosition is
-    // slightly different, however, from the e.getPosition() call above, since
+    // slightly different, however, because of the overidden getPosition() call, since
     // now the object reference has been "laundered" by passing through
     // EmployeeList as an Employee*. Previously, Java resolved the call
     // immediately in CEO, but now Java thinks the object is an instance of
-    // class Employee (actually EmployeePtr). So the call passes through the
+    // class Employee. So the call passes through the
     // Employee proxy class and on to the C wrappers and C++ director,
-    // eventually ending up back at the CEO implementation of getPosition().
+    // eventually ending up back at the Java CEO implementation of getPosition().
     // The call to getTitle() for item 3 runs the C++ Employee::getTitle()
     // method, which in turn calls getPosition(). This virtual method call
     // passes down through the C++ director class to the Java implementation
@@ -78,12 +76,7 @@ public class main {
     System.out.println( "----------------------" );
 
     // Time to delete the EmployeeList, which will delete all the Employee*
-    // items it contains. The last item is our CEO, which gets destroyed as its
-    // reference count goes to zero. The Java destructor runs, and is still
-    // able to call self.getName() since the underlying C++ object still
-    // exists. After this destructor runs the remaining C++ destructors run as
-    // usual to destroy the object.
-
+    // items it contains. The last item is our CEO, which gets destroyed as well.
     list.delete();
     System.out.println( "----------------------" );