...
| Wiki Markup |
|---|
Joshua Bloch \[[Bloch 2008|AA. Bibliography#Bloch 08]\] suggests implementing a {{stop()}} method explicitly such that it leaves the class in an unusable state beyond its lifetime. A private field within the class can signal whether the class is unusable. All the class methods must check this field prior to operating on the class. This is akin to the "initialized flag" -- compliant solution discussed in rule [OBJ11-J. Be wary of letting constructors throw exceptions]. As always, a good place to call the termination logic is in the {{finally}} block. |
Exceptions
MET12-EX0: Finalizers may be used when working with native code because the garbage collector cannot reclaim memory used by code written in another language and because the lifetime of the object is often unknown. Again, the native process must not perform any critical jobs that require immediate resource deallocation.
...
The ordering problem can be dangerous when dealing with native code. For example, if object A references object B (either directly or reflectively) and the latter gets finalized first, A's finalizer may end up dereferencing dangling native pointers. To impose an explicit ordering on finalizers, make sure that B remains reachable until A's finalizer has concluded. This can be achieved by adding a reference to B in some global state variable and removing it when A's finalizer executes. An alternative is to use the java.lang.ref references.
MET12-EX1: A class may use an empty final finalizer to prevent a finalizer attack, as specified in rule OBJ11-J. Be wary of letting constructors throw exceptions.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e9ee93fe25c6dee4-3b1f1344-4b6c4907-b19ebe00-5f2521f71ccf2dbc749bb1e7"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | [ | http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#finalize()] | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="aac50b5700a679a6-3f9440d8-418c4d92-b2b88a51-2640b3e2ce651a0670494f52"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 7. Avoid finalizers | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="322649e694c887b8-4fa18433-49e84f10-9612b56d-e25287b72d043bf8173a7c7f"><ac:plain-text-body><![CDATA[ | [[Boehm 2005 | AA. Bibliography#Boehm 05]] |
| ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e365d47e66c8de51-ddf2a26b-4e5f42fb-8684ba49-416677fd6ca68d3c8582a5b7"><ac:plain-text-body><![CDATA[ | [[Coomes 2007 | AA. Bibliography#Coomes 07]] | "Sneaky" Memory Retention | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4fc444ed427abfaa-94bafc2f-44724f66-af7183c7-7891ac6321498dd379e1d2c3"><ac:plain-text-body><![CDATA[ | [[Darwin 2004 | AA. Bibliography#Darwin 04]] | Section 9.5, The Finalize Method | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="724963440ffc3531-4e282c2f-45d84f5f-bc8a939b-ba0a69a5e2dcde1a021e8db3"><ac:plain-text-body><![CDATA[ | [[Flanagan 2005 | AA. Bibliography#Flanagan 05]] | Section 3.3, Destroying and Finalizing Objects | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e0f356da9f1f1961-a10accff-4900434b-b4b39fa8-d84d7f057878106efe591b8d"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | §12.6, Finalization of Class Instances | ]]></ac:plain-text-body></ac:structured-macro> |
...