Currying and the warning

Neal Gafter neal at gafter.com
Fri Nov 20 09:17:29 PST 2009


Its specification is just that one mention in the spec.  The API spec isn't
in the language spec part (perhaps it should be), but it will be something
like this:

*package java.lang
/** See JLS section n.m for the meaning of this annotation. */
@Target(LOCAL_VARIABLE)
@Retention(SOURCE)
@interface Shared {}
*

Cheers,
Neal

On Fri, Nov 20, 2009 at 9:09 AM, Osvaldo Doederlein <opinali at gmail.com>wrote:

> Thanks for the clarification, where is this @Shared annotation specified?
> It's not in the closures proposal and I admit to have just guessed its
> meaning, I'm not tracking all of JDK7 developments.
>
> A+
> Osvaldo
>
> 2009/11/20 Zdenek Tronicek <tronicek at fel.cvut.cz>
>
> Hi Osvaldo,
>>
>> the @Shared annotation says "I am aware that the variable may be accessed
>> from many threads". It warns you that you may need a synchronization. It is
>> not about hidden costs.
>>
>> Zdenek
>> --
>> Zdenek Tronicek
>> FIT CTU in Prague
>>
>>
>> Cituji Osvaldo Doederlein <opinali at gmail.com>:
>>
>>
>>  Hi Neal,
>>>
>>> I've just read the new proposal, seems to hit a quite good balance so I
>>> hope
>>> this will finally succeed. Some initial comments:
>>>
>>> The proposal doesn't mention support for any kind of transformation.
>>> You've
>>> already explained that MethodHandle doesn't serve as a good basis for
>>> closures, but I'd like both features to be as... close as possible; and
>>> for
>>> closures, it makes a lot of sense to support currying because this
>>> feature
>>> is highly useful and it wouldn't add any significant complexity (that I
>>> can
>>> see) to the language. The Method Reference facility would also allow to
>>> curry a common method, this is a simple combination of two steps
>>> (creating a
>>> closure that wraps the method and then currying that closure), but would
>>> be
>>> more efficient if defined/implemented as a single operation (so we can
>>> just
>>> create a single closure that performs the currying, i.e. passing some
>>> fixed
>>> parameters, when delegating to the method).
>>>
>>> The _mandatory_ warning for closures that capture non-final/shared vars
>>> seems too conservative. The motivation should be not freaking people who
>>> worry about hidden costs, but there's now plenty precedent for that, e.g.
>>> the silent allocations performed by enhanced-for or autoboxing, or much
>>> before, inner classes with their synthetic accessors to outer
>>> fields/methods
>>> including private ones. The language spec doesn't require mandatory
>>> warnings
>>> for those. I'm fully favorable to an _optional_ warning, that developers
>>> can
>>> activate when reviewing performance-critical code, such as the many extra
>>> warnings in the Eclipse compiler or tools like Checkstyle/FindBugs/PMD
>>> that
>>> include many detections of potential performance issues. But IMHO, making
>>> this warning of captures enabled by default will "taint" closures as
>>> something expensive, and make it more complex than necessary by requiring
>>> the @Shared or @SuppressWarnings("shared") annotations. (If the warning
>>> is
>>> optional, I guess we can omit at least @Shared from the spec.)
>>>
>>> In a secondary note, item 2 of that warning could be "The variable is not
>>> the target of any assignment after the closure is defined", which will
>>> avoid
>>> the warning for simple cases like "{ int x; if (a) x = 10 else x = 20;
>>> #()
>>> println(x) }" (not all developers would prefer using ?: here to enforce
>>> the
>>> initialization-in-declaration). Of course, the "after" in "after the
>>> closure
>>> is defined" is not that simple because if the closure is defined inside a
>>> loop, we can't have assignmaets to the variable before the closure
>>> definition but inside the loop; but I guess javac can already do the
>>> necessary flow analysis, should need it for definite assignment.
>>>
>>>
>>> A+
>>> Osvaldo
>>>
>>> --
>>> -----------------------------------------------------------------------
>>> Osvaldo Pinali Doederlein                        Visionnaire Virtus S/A
>>> osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
>>> Arquiteto de Tecnologia                         +55 (41) 3337-1000 #226
>>>
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091120/aa808c68/attachment.html 


More information about the closures-dev mailing list