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