Re: lifetime of UNO objects, writing Java exception-safe code

On Fri, Sep 13, 2013 at 02:28:35PM +0200, Stephan Bergmann wrote:
> On 09/13/2013 11:07 AM, Lionel Elie Mamane wrote:
> > On Wed, Sep 11, 2013 at 12:35:15PM +0200, Stephan Bergmann wrote:

> > > First, note that we don't have reference-counting garbage collection
> > > in general in UNO.  For example, Java-UNO doesn't use
> > > reference-counting.

> > > Second, note that there needs to be code (the "owner" in the jargon
> > > of the udkapi/com/sun/star/lang/XComponent.idl documentation) that
> > > explicitly calls dispose on a UNO object.  It is not magically
> > > called when a UNO object becomes unreachable.

> > So let's take the concrete example of
> >   reportbuilder/java/org/libreoffice/report/SDBCReportDataFactory.java
> >   around line 233:
> >   private String getOrderStatement(final int commandType, final String command, final List 
> > sortExpressions)

> > Concretely, the Java code does:

> >    final XComponent[] hold = new XComponent[1];
> >    final XNameAccess columns = getFieldsByCommandDescriptor(commandType, command, hold);

> > I assume this whole rigmarole with "hold" is to ensure that
> > "dispose()" is called on "columns", providing an owner for it.
> > (I assume it uses this round-about way instead of just declaring the
> >   caller the owner of columns because in some conditions columns will be
> >   a temporary and in other conditions, it will not; with this setup,
> >   this is testable with (hold[0] == null)).

> (At least the documentation you cite above does not make it look
> like keepFieldsAlive could return a null reference.)

In my quote of the documentation, I simplified this point away. It
depends. Sometimes it returns a temporary object (owned by
another temporary that is put in keepFieldsAlive) and sometimes it
returns a long-lived "shared" object that the caller should *not*
dispose.

> > So I need to do something like:

> >   final XComponent[] hold = new XComponent[1];
> >   try
> >   {
> >     (...)
> >     final XNameAccess columns = getFieldsByCommandDescriptor(commandType, command, hold);
> >     (...)
> >     if(hold[0] != null)
> >        hold[0].dispose();
> >   }
> >   catch (SQLException ex)
> >   {
> >      if(hold[0] != null)
> >        hold[0].dispose();
> >      LOGGER.error("ReportProcessing failed", ex);
> >   }
> >   catch(java.lang.Exception e)
> >   {
> >     if(hold[0] != null)
> >       hold.dispose();
> >     throw e;
> >   }

> Why not use a finally block?

Because my knowledge of Java is limited to what I had to
learn. finally blocks seem to be *exactly* what is needed
indeed. Thanks for the pointer.

> > Did I understand what you were saying correctly? This function (and
> > _any_ code getting a fresh/temporary UNO object) needs to clean up
> > after itself manually in this pedestrian, error-prone way? Do we get a
> > cop-out in C++ because of the use of com::sun::star::uno::Reference
> > which calls _pInterface->release()? Do we get a cop-out in any other
> > UNO language? (Python? Basic?)

> This specific Java code obtaining ownership of an XComponent is
> supposed to follow the protocol of XComponent and ensure that
> dispose is called, yes.  But not every UNO object implements the
> XComponent protocol, so there is lots of code obtaining references
> to UNO objects that does not need to do this sort of clean-up.

So basically, the documentation of the API call should tell you
whether you have to do that or not. OK.

-- 
Lionel