On 15/12/2015 10:48 AM, Mandy Chung wrote:
On Dec 14, 2015, at 2:38 PM, Roger Riggs <roger.ri...@oracle.com> wrote: Hi, The complexity of using Lambda for cleaning functions are too hard to explain in depth in the context of an example. A more conservative approach is to show using a static nested class. A lambda savvy developer can correctly determine how to avoid the pitfalls, and other should stick to the static nested class. [1]http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ [2]http://cr.openjdk.java.net/~rriggs/cleaner-doc/index.htmlLooks okay in general. When we convert existing use of finalizers in the JDK to Cleaner, that would give good feedback to this API. As the api note, it would be better if the CleaningExample shows the real cleaning work. It’s okay with me if you want to file a JBS issue and do that later if you want to build up some examples when converting existing use to Cleaner. Editorial comments. 186 * @exception IllegalThreadStateException if the thread from the thread 187 * factory was {@link Thread.State#NEW not a new thread}. s/@exception/@throws/ s/ {@link Thread.State#NEW not a new thread}/not a {@link Thread.State#NEW new thread}/ 205 * @param thunk a {@code Runnable} to invoke when the object becomes phantom reachable The spec refers this as a cleaning function and this is the only outliner and refer it as “thunk”. s/thunk/action - David suggested “action”. "function” vs “action” - It’s quite minor. I do think David has a good point that java.util.function.Function produces a result [1]. No new webrev is needed.
It also matches with j.u.c.RecursiveAction, which is a resultless ForkJoinTask. functions return values.
Cheers, David
Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037364.html
