lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (SOLR-924) Solr: Making finalizers call super.finalize() wrapped in try..finally block
Date Thu, 18 Dec 2008 07:40:46 GMT


Hoss Man commented on SOLR-924:

What Kay is suggesting is a pretty well established "best practice" .. even if you *know*
the super class has an empty finalize method it's still a good idea to call super.finalize()
in a finally block because you have no garuntee someone else won't modify the implementation
of the super class in a future version.  even when you subclass Object, super.finalize() is
a good idea to protect yourself against yourself: future refactoring could inject a new super
class (which could then gain a non-trivial finalize method)

i really see no downside to the patch

> Solr: Making finalizers call super.finalize() wrapped in try..finally block 
> ----------------------------------------------------------------------------
>                 Key: SOLR-924
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: contrib - DataImportHandler, replication (java)
>         Environment: Tomcat 6, JRE 6
>            Reporter: Kay Kay
>            Priority: Minor
>             Fix For: 1.4
>         Attachments: SOLR-924.patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
> There are some occurences of finalizers in the code base. While the presence of them
is debatable and discussed in a separate JIRA - the ones that are retained are better off
wrapped around a try .. finally block to recursively call the finalizer of the super class
for proper resource usage unwinding , (in case finalizers get invoked ). 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message