The great rename: the old ‘website’ is now ‘website-old’, and ‘website2’ is now ‘website’.

1 files changed, 35 insertions, 0 deletions

diff --git a/website/templates/features/Cleanup.html b/website/templates/features/Cleanup.html
new file mode 100644
index 00000000..e868c40d
--- /dev/null
+++ b/website/templates/features/Cleanup.html
@@ -0,0 +1,35 @@
+<#import "_features.html" as f>
+
+<@f.scaffold title="@Cleanup" logline="Automatic resource management: Call your <code>close()</code> methods safely with no hassle.">
+	<@f.overview>
+		<p>
+			You can use <code>@Cleanup</code> to ensure a given resource is automatically cleaned up before the code execution path exits your current scope. You do this by annotating any local variable declaration with the <code>@Cleanup</code> annotation like so:<br />
+			<code>@Cleanup InputStream in = new FileInputStream("some/file");</code><br />
+			As a result, at the end of the scope you're in, <code>in.close()</code> is called. This call is guaranteed to run by way of a try/finally construct. Look at the example below to see how this works.
+		</p><p>
+			If the type of object you'd like to cleanup does not have a <code>close()</code> method, but some other no-argument method, you can specify the name of this method like so:<br />
+			<code>@Cleanup("dispose") org.eclipse.swt.widgets.CoolBar bar = new CoolBar(parent, 0);</code><br />
+			By default, the cleanup method is presumed to be <code>close()</code>. A cleanup method that takes 1 or more arguments cannot be called via <code>@Cleanup</code>.
+		</p>
+	</@f.overview>
+
+	<@f.snippets name="Cleanup" />
+
+	<@f.confKeys>
+		<dt>
+			<code>lombok.cleanup.flagUsage</code> = [<code>warning</code> | <code>error</code>] (default: not set)
+		</dt></dd>
+			Lombok will flag any usage of <code>@Cleanup</code> as a warning or error if configured.
+		</dd>
+	</@f.confKeys>
+
+	<@f.smallPrint>
+		<p>
+			In the finally block, the cleanup method is only called if the given resource is not <code>null</code>. However, if you use <code>delombok</code> on the code, a call to <code>lombok.Lombok.preventNullAnalysis(Object o)</code> is inserted to prevent warnings if static code analysis could determine that a null-check would not be needed. Compilation with <code>lombok.jar</code> on the classpath removes that method call, so there is no runtime dependency.
+		</p><p>
+			If your code throws an exception, and the cleanup method call that is then triggered also throws an exception, then the original exception is hidden by the exception thrown by the cleanup call. You should <em>not</em> rely on this 'feature'. Preferably, lombok would like to generate code so that, if the main body has thrown an exception, any exception thrown by the close call is silently swallowed (but if the main body exited in any other way, exceptions by the close call will not be swallowed). The authors of lombok do not currently know of a feasible way to implement this scheme, but if java updates allow it, or we find a way, we'll fix it.
+		</p><p>
+			You do still need to handle any exception that the cleanup method can generate!
+		</p>
+	</@f.smallPrint>
+</@f.scaffold>