Closures, too much or too little?

12 views
Skip to first unread message

mikaelgrev

unread,
Nov 18, 2009, 5:13:27 PM11/18/09
to The Java Posse
...or too late (but not really since pre Java 7 was never an option)?

I think the complexity of these proposed Closures are just right for
Java. Not so for Rock Start Programmers, but for 90% of us.

Syntax takes getting used to, but that's not biggie.

Less pitfalls than BGGA, that's what makes me happy. BGGA are perfect
for 10% of those 5 000 000 Java developers but really bad for, say,
30% since they'd had to re-learn more than they would've been able to
handle or want to.

Unless you haven't seen the spec: http://www.javac.info/closures-v06a.html

What you guys think?

Cheers,
Mikael

Alexey Zinger

unread,
Nov 18, 2009, 5:26:48 PM11/18/09
to java...@googlegroups.com
I like.
 
Alexey

From: mikaelgrev <mikae...@gmail.com>
To: The Java Posse <java...@googlegroups.com>
Sent: Wed, November 18, 2009 5:13:27 PM
Subject: [The Java Posse] Closures, too much or too little?
--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=.



Andreas Petersson

unread,
Nov 18, 2009, 5:59:02 PM11/18/09
to java...@googlegroups.com

>
> Unless you haven't seen the spec: http://www.javac.info/closures-v06a.html
>
is this the spec alex miller is referring to, described at
http://puredanger.com/tech/2009/11/18/closures-after-all/ ?
or is it more like http://docs.google.com/Doc?id=ddhp95vd_0f7mcns ?

Fabrizio Giudici

unread,
Nov 18, 2009, 6:28:04 PM11/18/09
to java...@googlegroups.com
mikaelgrev wrote:
> ...or too late (but not really since pre Java 7 was never an option)?
>

Too much for me - but above all I'd say that the decisional process is
in total confusion if first they say they'll add only project Coin
stuff, and then change their mind all of a sudden. Not a good sign, at all.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

Casper Bang

unread,
Nov 18, 2009, 7:09:30 PM11/18/09
to The Java Posse
Yeah it's confusing, what made them suddenly change their mind? And
doesn't this kinda portrait Coin as a joke (not wanting to touch the
type system, only small changes etc.). It feels like a last minute
180, perhaps an attempt to keep up and not be characterized as a
legacy language? (which the blogosphere has been saturated with the
last couple of years)

/Casper

On Nov 19, 12:28 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
> Fabrizio.Giud...@tidalwave.it

Fabrizio Giudici

unread,
Nov 18, 2009, 7:27:04 PM11/18/09
to java...@googlegroups.com
Casper Bang wrote:
> Yeah it's confusing, what made them suddenly change their mind? And
> doesn't this kinda portrait Coin as a joke (not wanting to touch the
> type system, only small changes etc.). It feels like a last minute
> 180, perhaps an attempt to keep up and not be characterized as a
> legacy language? (which the blogosphere has been saturated with the
> last couple of years)
>
RIght.

BTW, it took a while for me to realize that the closures they're talking
about are neither BGGA nor CICE, but rather a simpler version based on a
proposal of Stephen Couleborne and Stefan Schulz. I've just read it - I
appreciate the minimalistic approach and it makes me worry much less
than BGGA - but it's not a finished proposal: I understand that there
are still some issues *in the specifications* to be resolved. So, we're
switching from "only small changes" to "let's put in a thing that is not
yet finished". Perhaps they plan to postpone the release?

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

Serge Boulay

unread,
Nov 18, 2009, 7:34:42 PM11/18/09
to java...@googlegroups.com
What spec are you reading. It clearly says Neal Gafter in the top
right corner. From what I hear it's trimmed down version of bgga with
fcm syntax.
> --
>
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=.
>
>
>

--
Sent from my mobile device

Mark Derricutt

unread,
Nov 18, 2009, 7:40:01 PM11/18/09
to java...@googlegroups.com
My understanding is that the goal of "coin" was small changes that
don't affect the type system. That however doesn't preclude OTHER
projects which DO touch the type system (I'm sure modularity is
touching the type system for access levels at least).

Still - will be interesting to hear there reasoning behind the
decision changes to include it.

mark

--
Pull me down under...

Serge Boulay

unread,
Nov 18, 2009, 9:51:25 PM11/18/09
to java...@googlegroups.com
more good news .....Joe said "In terms of Project Coin, with the extended JDK 7 schedule the fate of multi-catch in the release may be reconsidered."

Casper Bang

unread,
Nov 19, 2009, 3:13:09 AM11/19/09
to The Java Posse
True, still confusing though. The release seems to have been
postponed, JDK7 features are not final just like Coin is not final
(http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/
002461.html). Does that mean the community has a new window for
contributing?

/Casper

Fabrizio Giudici

unread,
Nov 19, 2009, 3:26:05 AM11/19/09
to java...@googlegroups.com
Casper Bang wrote:
> True, still confusing though. The release seems to have been
> postponed, JDK7 features are not final just like Coin is not final
> (http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/
> 002461.html). Does that mean the community has a new window for
> contributing?
>
I'm not understanding anything - it sounds as everybody attending Devoxx
got it in a slightly changed way. An official blog post would be
welcome, at this point.

Yes, it seems that the releaseo of JDK7 has been postponed to the end of
2010. If it's the case, I understand it's a reasonable thing to re-think
the features. But, please, communicate in the proper way!

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

Reinier Zwitserloot

unread,
Nov 19, 2009, 5:16:17 AM11/19/09
to The Java Posse
Clarifications straight from Mark Reinhold at the later BOF here at
#devoxx.

1. His syntax is a strawman written up in de airplane. The point is:
Mark and friends have always loved closures, they just weren't sure
java should have them, as it has such a big impact on the feel of the
language. It is NOT AN ENDORSEMENT OF FCM. He was very specific about
that. He was also quite specific about keeping it simple (willing to
give up transparency et al). The point is, yes closures, no
complexity. Syntax is a teensy tiny detail of this, so don't get hung
up on that aspect.

2. For reasons unrelated to the new language features in java7, java7
will be delayed from feb to at least sept. There's time, so, the scope
of lang features for java7 has just expanded. Thus, this is NOT AN
INDICTMENT on Project Coin at all. On the contrary, Joe Darcy is here,
and he's planning on running more coins for the future. Mark Reinhold
*SPECIFICALLY* said he does not believe the JCP is a good source of
innovation, which seems like an *endorsement* of coin.

3. During the closure wars of 2007, Mark decided to let the dust
settle and play with the prototypes.

4. As java7 is delayed A LOT (due to the apache/sun tiff in the JCP),
and even the JDK7 has been delayed quite a bit (to at least sept),
java8 is of course also going to be around much later. So, Mark has
realized that now is probably the right time.

5. Of course there will be discussion with the community about how to
do it. He's also been privately talking to lots of key players in sun,
and they've all indicated they think it's time for closures, too.

6. Parallel Arrays are involved as a driving force behind the notion
that closures are needed.

7. Another feature that's back on the 'maybe' list is multicatch:
catch (IllegalAccessException | InvocationTargetException e) { ... do
stuff with e...}

Reporting from Devoxx,

--Reinier Zwitserloot

On Nov 19, 9:26 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
> Fabrizio.Giud...@tidalwave.it

Phil

unread,
Nov 19, 2009, 5:52:17 AM11/19/09
to The Java Posse
My main issue with all of this is not what is being done, but that the
RC has slipped from February to October/November timeframe. Thread
Hijack!

Jess Holle

unread,
Nov 19, 2009, 7:11:21 AM11/19/09
to java...@googlegroups.com
Reinier Zwitserloot wrote:
> 7. Another feature that's back on the 'maybe' list is multicatch:
> catch (IllegalAccessException | InvocationTargetException e) { ... do
> stuff with e...}
>
And the "catch ( final Throwable t ) { ... throw t; }" bit?

This would also be a big help.

--
Jess Holle

Tim

unread,
Nov 19, 2009, 10:10:41 AM11/19/09
to The Java Posse
Did Reinhold present something different from
http://www.javac.info/closures-v06a.html ?
That appears to be a new (simplified) version of BGGA
written by Neal Gafter.

It also refers to a separate spec for "control invocation syntax".
Has anyone seen that?

--
Tim

On Nov 19, 2:16 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Clarifications straight from Mark Reinhold at the later BOF here at
> #devoxx.
>
> 1. His syntax is a strawman written up in de airplane. The point is:
> Mark and friends have always loved closures, they just weren't sure
> java should have them, as it has such a big impact on the feel of the
> language. It is NOT AN ENDORSEMENT OF FCM. He was very specific about
> that. He was also quite specific about keeping it simple (willing to
> give up transparency et al). The point is, yes closures, no
> complexity. Syntax is a teensy tiny detail of this, so don't get hung
> up on that aspect.
> ...

Matias Berrueta

unread,
Nov 19, 2009, 10:21:15 AM11/19/09
to java...@googlegroups.com
this is simple, and powerfull


closures and lambda can be great

Matias Berrueta



Reinier Zwitserloot

unread,
Nov 19, 2009, 12:00:43 PM11/19/09
to The Java Posse
Jess: Yes, 'catch (final Throwable t) { throw t}', where the throw
statement only requires handling any checked exceptions thrown by
statements in the accompanying try block, is also on the table again.

Tim: No, as I said, the syntax is just a rough sketch. Neal wrote that
changed spec AFTER the presentation, and AFTER that BOF session. It's
basically BGGA with non-local control transfer taken out. It could
form a basis for further discussion, but that is about as far removed
from an official seal of approval as any other proposal.

Reinier Zwitserloot

unread,
Nov 19, 2009, 12:01:33 PM11/19/09
to The Java Posse
Phil: Heh, someone else created a new thread. I answered there before
I read your question here :)

NB: In case it wasn't obvious, I'm just reporting my impressions for
attending the java language-based sessions and BOFs at Devoxx.

gafter

unread,
Nov 20, 2009, 1:49:20 PM11/20/09
to The Java Posse, Neal Gafter
On Nov 19, 9:00 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Neal wrote that
> changed spec AFTER the presentation, and AFTER that BOF session. It's
> basically BGGA with non-local control transfer taken out. It could
> form a basis for further discussion, but that is about as far removed
> from an official seal of approval as any other proposal.

Correction: I wrote this spec about two weeks ago, before the
conference began, as part of a discussion with Gosling on a compromise
spec.

Fabrizio Giudici

unread,
Nov 20, 2009, 2:00:57 PM11/20/09
to java...@googlegroups.com, Neal Gafter
This thing is becoming a mess of rumors and urban myths... can please somebody who's well informed (possibly one of the key players) try to recap the *correct* situation in a blog post?

-- 
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Bill Robertson

unread,
Nov 20, 2009, 2:07:44 PM11/20/09
to The Java Posse
IIRC, I saw something about a silently generated interface as part of
the implementation the closure. Is this correct? Am I the only one
who remember some of the bad early days when oodles of tiny classes
killed your startup time?

Weren't method handles just approved for JDK 7? If so then why go
with the clunk of an interface?

Or am I completely off base?

Bill Robertson

unread,
Nov 20, 2009, 2:10:19 PM11/20/09
to The Java Posse
Sheesh, I can't type. I was referring to the early days of Swing.
When the all of the anonymous listener classes killed your GUI start-
up time due to all of the class loading.

Jess Holle

unread,
Nov 20, 2009, 2:11:22 PM11/20/09
to java...@googlegroups.com, Neal Gafter
Fabrizio Giudici wrote:
gafter wrote:
On Nov 19, 9:00 am, Reinier Zwitserloot <reini...@gmail.com> wrote:  
Neal wrote that
changed spec AFTER the presentation, and AFTER that BOF session. It's
basically BGGA with non-local control transfer taken out. It could
form a basis for further discussion, but that is about as far removed
from an official seal of approval as any other proposal.
      
Correction: I wrote this spec about two weeks ago, before the
conference began, as part of a discussion with Gosling on a compromise
spec.
    
This thing is becoming a mess of rumors and urban myths... can please somebody who's well informed (possibly one of the key players) try to recap the *correct* situation in a blog post?
Yes, please!

I am heartened to hear that the spec referenced is not too official yet.  I don't have any big issues with it -- but on a syntactic level I just really don't like the use of #.  It seems oddly out of place when compared to closures in other languages -- or in BGGA.

--
Jess Holle

Neal Gafter

unread,
Nov 20, 2009, 2:28:55 PM11/20/09
to Fabrizio Giudici, java...@googlegroups.com
On Fri, Nov 20, 2009 at 11:00 AM, Fabrizio Giudici <fabrizio...@tidalwave.it> wrote:
This thing is becoming a mess of rumors and urban myths... can please somebody who's well informed (possibly one of the key players) try to recap the *correct* situation in a blog post?

I'd like that too.  I have no idea if the spec I wrote had any influence on Reinhold's plans, or if he was even aware of it.

Andreas Petersson

unread,
Nov 20, 2009, 2:33:01 PM11/20/09
to java...@googlegroups.com
the same argument was brought forward against scala which generates more
classes than visible for the eye when looking at the source code.
I think that is only the case if you have individual .class files
hanging around on your disk. With a single .jar file an extra class file
or two won't hurt performance.
but this is only guesswork here.

Neal Gafter

unread,
Nov 20, 2009, 2:33:22 PM11/20/09
to Jess Holle, java...@googlegroups.com, closur...@openjdk.java.net
On Fri, Nov 20, 2009 at 11:11 AM, Jess Holle <je...@ptc.com> wrote:
I am heartened to hear that the spec referenced is not too official yet.  I don't have any big issues with it -- but on a syntactic level I just really don't like the use of #.  It seems oddly out of place when compared to closures in other languages -- or in BGGA.

This version is based on CLang, but with # instead of ^.  # is used for method references because that is the syntax in javadoc.  I would prefer ^ rather than # for function types and lambdas, but the current spec uses # for consistency with method references.

Cheers,
Neal
 

Fabrizio Giudici

unread,
Nov 20, 2009, 2:53:34 PM11/20/09
to java...@googlegroups.com
Andreas Petersson wrote:
> the same argument was brought forward against scala which generates more
> classes than visible for the eye when looking at the source code.
> I think that is only the case if you have individual .class files
> hanging around on your disk. With a single .jar file an extra class file
> or two won't hurt performance.
> but this is only guesswork here.
>
Also, the VM of several years ago is not the VM of today (or
tomorrow...). If I'm not wrong, as part of the Jigsaw work there is
stuff for improving packing and loading code in the JRE.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

Bill Robertson

unread,
Nov 20, 2009, 2:54:39 PM11/20/09
to The Java Posse
Certainly virtual machines (and real machines) are better now, but I
still don't think thats enough. One of the arguments in favor of
method handles though, is that they will let other languages perform
better because they don't have to generate classes for everything.
There's supposed to be higher overhead for classes, and the
trampolines and other tricks they need tend to defeat the optimizer.

Thanks all,
Bill

Mario Fusco

unread,
Nov 20, 2009, 6:10:56 PM11/20/09
to The Java Posse
> This version is based on
> CLang<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html>,
> but with # instead of ^.  # is used for method references because that is
> the syntax in javadoc.  I would prefer ^ rather than # for function types
> and lambdas, but the current spec uses # for consistency with method
> references.
>
> Cheers,
> Neal

Maybe I am a bit biased, but to be honest I don't see big differences
between what I developed in my project ( http://code.google.com/p/lambdaj
) and what this spec should make available in about a year (except a
nicer syntax of course). 2 years of discussions plus 1 year of delay
in the jdk7 release sounds a bit too much to have a so small set of
features.

@Gafter you wrote on the closure wiki page of lambdaj (
http://code.google.com/p/lambdaj/wiki/Closures ) that "it certainly
doesn't match any definition of "closure" that you are familiar with"
but you did not justify this sentence neither replied to my last
question. Could you clarify your thoughts about it?

Cheers
Mario

Reinier Zwitserloot

unread,
Nov 20, 2009, 8:35:54 PM11/20/09
to The Java Posse
Okay, I made a mistake and overstated the case on Neal's proposal. I
*knew* it wasn't anything official, and I guessed he wrote it in
response to the closure proposal. That was my mistake. Everything else
in there is true.

Bill: silently generated interfaces is a part of BGGA and the CFJ
variant of BGGA. Your argument is non-sensical; all closures are
implemented at the JVM level by inner classes (unless pretty massive
JVM changes are added. The JVM changes very rarely), so there are a
gazillion little classes regardless. Does scala code run slow? Because
scala compiles down to bucketloads of tiny classes. Seems like lots-of-
classes-kill-startup-time can be relegated to the same pile as
'instantiating objects is expensive', and 'you should reuse objects'.

Jars are also going away (jigsaw), with ahead-of-time compilation and
installation offering a lot of performance improvements. Whatever
insignificant problems are associated with tiny classes now, that will
definitely offer a way to reduce that to effectively nil.

On Nov 20, 8:00 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
> Fabrizio.Giud...@tidalwave.it

Reinier Zwitserloot

unread,
Nov 20, 2009, 8:39:30 PM11/20/09
to The Java Posse
I'm not trying to be a jackass, just giving honest advice:

Bill: Proof is in the pudding. Test it, write up a report, with pretty
charts. If you're right and there's a performance issue, take it to
the hill and start yelling. With proof, nobody can shut you up, and
discussion will commence about using method handles (I'm pretty sure I
remembed that Mark Reinhold said that would not be a good idea, but
can't remember the exact reasons he stated for this), or changing the
JVM spec, or changing sun's implementation of the JVM with more
optimizations for quickly loading AND unloading tiny one-shots like
closures, similar to generational garbage collecting. Without those
pretty charts, nobody is going to take this argument seriously, what
with scala and the like giving more than enough anecdotal evidence to
ignore you.

hlovatt

unread,
Nov 21, 2009, 9:53:15 AM11/21/09
to The Java Posse
LamdaJ is a really good example of what can be achieved with a few
changes. Hopefully examples like this will encourage Sun to choose
something more at the CISE end of the spectrum rather than the BGGA
end.

Mark Derricutt

unread,
Nov 21, 2009, 4:37:15 PM11/21/09
to java...@googlegroups.com
I look forward to being corrected, but all the examples I've seen of
lambaj show things like:

forEach(someCollection).setSomeMethod(withThis);

Giving to mind that forEach() returns some dynamic proxy to
someCollection that iterates over it, calling the provided method,
which is great for somethings, but in almost 99% of the times I've
wanted a nice closure based syntax for this, I've wanted to call
multiple statements on each item, or refer to the 'each' as part of
that statement, such like:

someCollection.forEach(each => each.value = each.value * 2);

Unless theres something akin to how Mockito handles parameters I don't
see how they're comparable, does lambaj allow for something like:

forEach(someCollection).setEach(each().getValue() * 2)

with each() return a ThreadLocal bound value from each iteration?


--
Pull me down under...

Mario Fusco

unread,
Nov 21, 2009, 4:53:59 PM11/21/09
to The Java Posse
> I look forward to being corrected, but all the examples I've seen of
> lambaj show things like:
>
> forEach(someCollection).setSomeMethod(withThis);
>
> Giving to mind that forEach() returns some dynamic proxy to
> someCollection that iterates over it, calling the provided method,
> which is great for somethings, but in almost 99% of the times I've
> wanted a nice closure based syntax for this, I've wanted to call
> multiple statements on each item, or refer to the 'each' as part of
> that statement, such like:
>
> someCollection.forEach(each => each.value = each.value * 2);
>
> Unless theres something akin to how Mockito handles parameters I don't
> see how they're comparable, does lambaj allow for something like:
>
> forEach(someCollection).setEach(each().getValue() * 2)
>
> with each() return a ThreadLocal bound value from each iteration?
>
> --
> Pull me down under...

Did you give a look at this?

http://code.google.com/p/lambdaj/wiki/Closures

Mark Derricutt

unread,
Nov 21, 2009, 5:19:13 PM11/21/09
to java...@googlegroups.com
I remember reading it awhile ago, and upon rereading it I'm still left
seeing the same problem, all of those closures just have a single
statement:

public int countFileLines(String fileName) {
lineCounter = 0;
Closure1<String> lineReader = closure(String.class); {
of(this).countNonEmptyLine(var(String.class)); }
readFileByLine(fileName, lineReader);
return lineCounter;
}


I'm not sure -how- you're pulling this off, and it sure looks like an
impressive as hell trick, but if I wanted this closure to do multiple
operations I don't see it, I assume if I had multiple of(this)
statements only the first would get associated with the closure()
definition?

I suspect if closure() was called something like "methodPointer()" it
would sit better with me, as (as far as I can tell), the intended
usage is more of that of an invokable pointer to a declared method,
and not short inline block of code (what I'd normally expect in a
closures system).

Would it be possible to just do:

public int countFileLines(String fileName) {
lineCounter = 0;
readFileByLine(fileName, of(this).countNonEmptyLine(var(String.class)));
return lineCounter;
}

and just use the of() declaration?


--
Pull me down under...

Mario Fusco

unread,
Nov 21, 2009, 5:41:57 PM11/21/09
to The Java Posse
> I'm not sure -how- you're pulling this off, and it sure looks like an
> impressive as hell trick, but if I wanted this closure to do multiple
> operations I don't see it, I assume if I had multiple of(this)
> statements only the first would get associated with the closure()
> definition?

Actually if you try to associate more than one of() statement to the
same closure you will get an Exception. The idea is that you put the
multiple statements you want to execute in the closure inside the
method bind through the of() operator. I admit it is a matter of
tastes, but to be honest it doesn't sound so limiting to me.

> I suspect if closure() was called something like "methodPointer()" it
> would sit better with me, as (as far as I can tell), the intended
> usage is more of that of an invokable pointer to a declared method,
> and not short inline block of code (what I'd normally expect in a
> closures system).

As demonstrated by this further example taken from the mentioned wiki
page, lambdaj provides real closure, not only method pointer

--- BEGIN of example provided in the wiki page ---

The variables in the lexical scope to be closed over are the ones
contained in the object passed to the of() method. A quick example
could clarify this point. Suppose you have the following class:

public class AdderOf {
private int first;

public AdderOf(int first) {
this.first = first;
}

public add(int second) {
return first + second;
}

public int getFirst() {
return first;
}

public void setFirst(int first) {
this.first = first;
}
}

and then you define a closure as this one:

AdderOf adderOf = new AdderOf(10);
Closure<Integer> closure = closure(Integer.class) {
of(adderOf).add(var(integer.class));
}

Now if you invoke this closure by passing 5 to it:

closure.apply(5);

you will obtain 15 as expected. But after changing the property of the
closed object

adderOf.setFirst(15);

and repeating the same closure invocation you will now obtain 20.

Please let me know if this is clear and if you think it matches the
closure definition.

--- END ---


> Would it be possible to just do:
>
> public int countFileLines(String fileName) {
>     lineCounter = 0;
>     readFileByLine(fileName, of(this).countNonEmptyLine(var(String.class)));
>     return lineCounter;
>
> }

The syntax provided by the delayed closure notation is not so
different:

public int countFileLines(String fileName) {
lineCounter = 0;
readFileByLine(fileName); { of(this).countNonEmptyLine(var
(String.class)); }
return lineCounter;
}

Don't you agree?

gafter

unread,
Nov 21, 2009, 9:15:12 PM11/21/09
to The Java Posse
On Nov 21, 2:41 pm, Mario Fusco <mario.fu...@gmail.com> wrote:
> Please let me know if this is clear and if you think it matches the
> closure definition.

As you are probably aware, a closure, by definition, captures
variables from the lexically enclosing scope. Lambdaj simply does
not. They are not, therefore, closures.

I don't mean to say lambdaj isn't useful - I'm willing to suspend
disbelief on that. They just aren't closures.

Cheers,
Neal

hlovatt

unread,
Nov 22, 2009, 2:36:18 AM11/22/09
to The Java Posse
The AdderOf example immediately above your post shows capturing a
variable, adderOf. Sure the syntax is different, but that doesn't mean
it isn't a closure. It is the Semantics that count.

Mario Fusco

unread,
Nov 22, 2009, 5:45:58 AM11/22/09
to The Java Posse
> As you are probably aware, a closure, by definition, captures
> variables from the lexically enclosing scope.  Lambdaj simply does
> not.  They are not, therefore, closures.
>
> I don't mean to say lambdaj isn't useful - I'm willing to suspend
> disbelief on that.  They just aren't closures.
>
> Cheers,
> Neal

Could you please better explain why the variable first of the AdderOf
class in my example cannot be considered a variable captured from the
lexically enclosing scope? I am sure that I am missing something but I
don't understand what.

Anyway I did not want to focus the discussion on my library. I was
just answering to the questions of Mark Derricutt. Sorry if I went OT.
As I stated somewhere else lambdaj is just an attempt to have in Java
a feature that I missed (and still miss) in the language. As a fan of
functional programming I would be very glad if we could have real
closures built in the language. And at that point I will be happy to
throw away lambdaj.

What I meant to underline is something different. Let me slightly
reframe the current situation in order to clarify my point of view.
Two years ago, you (of course not you Neal, it is just an hypothetical
example to illustrate my feeling) said to your employer that you were
going to add a new fantastic feature to your product. Then you spent
(wasted) the following 2 years discussing with your development team
about different proposals and evaluating their consequences. At the
end of this 2 endless years you went again to your employer saying
that you need another year to implement a "simplified" version of that
feature. I bet at this point of my hypothetical situation your boss
was running through the rooms of your office like an headless chicken
screaming loudly some non-repeatable words.

Being one of the about 5,000,000 of Java developers in the world I
suppose I am one of the employers (or customers, it is more or less
the same in this context) of people who work to define the next specs
of the language. And at the moment my only feeling is just that I
wanna scream.

gafter

unread,
Nov 22, 2009, 11:57:01 AM11/22/09
to The Java Posse
On Nov 22, 2:45 am, Mario Fusco <mario.fu...@gmail.com> wrote:
> Could you please better explain why the variable first of the AdderOf
> class in my example cannot be considered a variable captured from the
> lexically enclosing scope? I am sure that I am missing something but I
> don't understand what.

The hallmark of a closure is that it can contain an identifier that is
bound to a name in a lexically enclosing scope.

The name "first" does not appear in the "closure", and "first" is not
a variable that is defined in a scope that lexically encloses the
"closure".

Mario Fusco

unread,
Nov 22, 2009, 12:30:44 PM11/22/09
to The Java Posse
> The hallmark of a closure is that it can contain an identifier that is
> bound to a name in a lexically enclosing scope.
>
> The name "first" does not appear in the "closure", and "first" is not
> a variable that is defined in a scope that lexically encloses the
> "closure".

The closure is the method AdderOf.add(int second) and the name "first"
appears in its body and it is in its scope. The statements closre
() ... of(...) are just a way to build a reference to it.

gafter

unread,
Nov 23, 2009, 12:39:46 PM11/23/09
to The Java Posse
On Nov 22, 9:30 am, Mario Fusco <mario.fu...@gmail.com> wrote:
> The closure is the method AdderOf.add(int second) and the name "first"
> appears in its body and it is in its scope. The statements closre
> () ... of(...) are just a way to build a reference to it.

Let me be more precise. /Closure/ is an informal word to describe a /
lambda expression/, which is an expression defining a function value
that may have /free variables/ (i.e., names that are not defined in
the function), which are /bound/ to variables defined in the /lexical
scope/.

Lambdaj simply does not do this. "AdderOf" is an ordinary class,
"add" is an ordinary method, and "first" is an ordinary field of that
class. There is no expression in your example that defines a function
referencing a variable from the lexically enclosing scope.

Mario Fusco

unread,
Nov 23, 2009, 4:16:41 PM11/23/09
to The Java Posse
> Lambdaj simply does not do this.  "AdderOf" is an ordinary class,
> "add" is an ordinary method, and "first" is an ordinary field of that
> class.  There is no expression in your example that defines a function
> referencing a variable from the lexically enclosing scope.

The feature provided by lambdaj is exactly to "turn" the ordinary
method AdderOf.add() into a closure. If I am missing something please
show me a practical example where lambdaj cannot do the same of a
"real" closure with the same semantic (and probably just a slightly
uglier and more verbose syntax).

gafter

unread,
Nov 23, 2009, 10:27:56 PM11/23/09
to The Java Posse
On Nov 23, 1:16 pm, Mario Fusco <mario.fu...@gmail.com> wrote:
> The feature provided by lambdaj is exactly to "turn" the ordinary
> method AdderOf.add() into a closure. If I am missing something please
> show me a practical example where lambdaj cannot do the same of a
> "real" closure with the same semantic (and probably just a slightly
> uglier and more verbose syntax).

Closures do not increase the set of things that can be computed in the
language; Java is Turing-complete with or without closures, so no such
example exists. Rather, they expand the kinds of abstractions that
can be conveniently expressed. See Felleison's "On the Expressive
Power of Programming Languages" <http://reference.kfupm.edu.sa/content/
o/n/on_the_expressive_power_of_programming_l_293256.pdf> for the
meaning of "expressive power" in the sense that is relevant to adding
language features.

Mario Fusco

unread,
Nov 24, 2009, 3:20:54 AM11/24/09
to The Java Posse
> Closures do not increase the set of things that can be computed in the
> language; Java is Turing-complete with or without closures, so no such
> example exists.  Rather, they expand the kinds of abstractions that
> can be conveniently expressed.  See Felleison's "On the Expressive
> Power of Programming Languages" <http://reference.kfupm.edu.sa/content/
> o/n/on_the_expressive_power_of_programming_l_293256.pdf> for the
> meaning of "expressive power" in the sense that is relevant to adding
> language features.

When I wrote "with the same semantic" I meant that in my opinion
lambdaj's closures (or whatever you want to call them) provide exactly
the same "expressive power" of the closures defined by this last
proposal.

gafter

unread,
Nov 24, 2009, 12:25:58 PM11/24/09
to The Java Posse
On Nov 24, 12:20 am, Mario Fusco <mario.fu...@gmail.com> wrote:
> When I wrote "with the same semantic" I meant that in my opinion
> lambdaj's closures (or whatever you want to call them) provide exactly
> the same "expressive power" of the closures defined by this last
> proposal.

Can you please show how a lambdaj "closure" can capture a (mutable)
local variable? I don't mean show how to get the same effect - I mean
how to actually reference an actual (mutable) local variable from the
scope that encloses a lambda expression?

Mario Fusco

unread,
Nov 24, 2009, 3:37:54 PM11/24/09
to The Java Posse
> Can you please show how a lambdaj "closure" can capture a (mutable)
> local variable?  I don't mean show how to get the same effect - I mean
> how to actually reference an actual (mutable) local variable from the
> scope that encloses a lambda expression?

Sorry, but honestly I have not understood what you are asking. Can you
provide a practical example?

Anyway if you think that lambdaj's "closures" can provide the same
effect of the standard definition of a "real" closure, it means that
they can be considered closures under each practical point of view,
and then I reached my purpose.

gafter

unread,
Nov 24, 2009, 6:45:29 PM11/24/09
to The Java Posse
On Nov 24, 12:37 pm, Mario Fusco <mario.fu...@gmail.com> wrote:
> Anyway if you think that lambdaj's "closures" can provide the same
> effect of the standard definition of a "real" closure, it means that
> they can be considered closures under each practical point of view,
> and then I reached my purpose.

If by "effect" you mean computational effect, then you achieved your
purpose before you even started because Java was already Turing-
complete. But from the practical point of view of writing
abstractions over snippets of code, that purpose has not been
furthered by lambdaj.

Mikael Grev

unread,
Nov 25, 2009, 7:59:34 AM11/25/09
to The Java Posse
Neal, maybe a simple example of what you can't do with LambdaJ would
make things clearer?

I know about Turing completeness, but still, you can use that to say
we don't need any features at all as well.

So, what does current javac.info spec give that LambdaJ can give. I
think this is what Mario is asking.

Cheers,
Mikael

Joe Nuxoll (Java Posse)

unread,
Nov 25, 2009, 1:09:46 PM11/25/09
to The Java Posse
Gotta say it... This is not far off from the events part of this
proposal from 2004: http://blogs.sun.com/joe/resource/java-properties-events.pdf

I just had slightly little different syntax:

-------------------------------------------------------------------------8<
// using an event keyword – method declaration same
// as everywhere else in Java (nice – my favorite)
public event boolean onMouseClicked(JButton button, Point clickPoint,
int clickCount);

// maybe specify if its multicast?
// or should they all just be considered multicast?
public multicast event boolean onMouseClicked(JButton button, Point
clickPoint, int clickCount);

// or a new [] syntax to mean “method pointer”
// note that param names are included for IDE code-
// insight information – this is more like a field declaration
public [boolean: JButton button, Point clickPoint, int clickCount]
onMouseClicked;

// a no-arg, void return method pointer
// (syntax looks silly?)
public [void:] somethingHappened;

// looks a little better using an event keyword
public event void somethingHappened();
public [Object: int feet, int inches] onJump throws VaultException;

// read-only (final) 'mouseEvents' field
public final MouseEvents mouseEvents = new MouseEvents();

// read-only 'mouseEvents' property (same thing)
public MouseEvents mouseEvents get = new MouseEvents();
-------------------------------------------------------------------------8<

- Joe

On Nov 18, 2:13 pm, mikaelgrev <mikael.g...@gmail.com> wrote:
> ...or too late (but not really since pre Java 7 was never an option)?
>
> I think the complexity of these proposed Closures are just right for
> Java. Not so for Rock Start Programmers, but for 90% of us.
>
> Syntax takes getting used to, but that's not biggie.
>
> Less pitfalls than BGGA, that's what makes me happy. BGGA are perfect
> for 10% of those 5 000 000 Java developers but really bad for, say,
> 30% since they'd had to re-learn more than they would've been able to
> handle or want to.
>
> Unless you haven't seen the spec:http://www.javac.info/closures-v06a.html
>
> What you guys think?
>
> Cheers,
> Mikael

Josh McDonald

unread,
Nov 29, 2009, 8:44:14 PM11/29/09
to java...@googlegroups.com
Let me have a crack at it. Here's some Javascript code:

function showClosure()
{
    var localVar = 7;
    var f = function(x)
        {
            var result = x + localVar;
            localVar = 10;
            return result;
        }
    localVar = 9;
    return f;
}

var cl = showClosure();
print(cl(1)); // <-- 10
print(cl(2)); // <-- 12

Without real closures, you'll get something else other than 10 and 12, depending on where the limitations are in the bindings. You may get 8 and 9 (I /think/ this is what Obj-C blocks will do), or you may get 10 and 11.

With real closures, the local variables like localVar need to go on the heap for garbage collection instead of on the stack, which is a fairly signifigant change, which I beleive is why LambdaJ can't do it.

Disclaimer: Just because I (think I) understand it, doesn't mean I can necessarily explain it :-/

-Josh

2009/11/26 Joe Nuxoll (Java Posse) <jnu...@gmail.com>
--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.





--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

Josh 'G-Funk' McDonald
  -  jo...@joshmcdonald.info
  -  http://twitter.com/sophistifunk
  -  http://flex.joshmcdonald.info/

Alexey Zinger

unread,
Nov 29, 2009, 10:33:02 PM11/29/09
to java...@googlegroups.com
Josh,

Let's not forget that we can do these things in Java now, even without any kind of closure syntax sugar.  If syntax makes it easier, so much the better.

public interface Closure<P, R> { public R call(P param); }

// stuff happened...

public Closure<Integer, Integer> showClosure()
{
  final int[] localVar = new int[] { 9 };
  Closure<Integer, Integer> f = new Closure<Integer, Integer>()
  {
    public Integer call(int x)
    {
      int result = localVar[0] + x;
      localVar[0] = 10;
      return result;
  };
  return f;
}
localVar[0] = 9;

// more stuff happened...

Closure<Integer, Integer> cl = showClosure();
System.out.println(cl.call(1));
System.out.println(cl.call(2));
 
Alexey
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net



From: Josh McDonald <jo...@joshmcdonald.info>
To: java...@googlegroups.com
Sent: Sun, November 29, 2009 8:44:14 PM
Subject: Re: [The Java Posse] Re: Closures, too much or too little?

Josh McDonald

unread,
Nov 29, 2009, 11:23:17 PM11/29/09
to java...@googlegroups.com
Like Neal said, it's a Turing machine. Everything atop of LISP is sugar. The point is closing over the *binding* not the value. Otherwise it's simply an implied invocation parameter.

2009/11/30 Alexey Zinger <inlin...@yahoo.com>

Viktor Klang

unread,
Nov 30, 2009, 3:22:20 AM11/30/09
to java...@googlegroups.com
Honestly, that kind of mutable state juggling simply will make multithreading even more horrid.
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

Mario Fusco

unread,
Nov 30, 2009, 6:11:47 AM11/30/09
to The Java Posse
> Let me have a crack at it. Here's some Javascript code:
>
> function showClosure()
> {
>     var localVar = 7;
>     var f = function(x)
>         {
>             var result = x + localVar;
>             localVar = 10;
>             return result;
>         }
>     localVar = 9;
>     return f;
>
> }
>
> var cl = showClosure();
> print(cl(1)); // <-- 10
> print(cl(2)); // <-- 12
>
> Without real closures, you'll get something else other than 10 and 12,
> depending on where the limitations are in the bindings. You may get 8 and 9
> (I /think/ this is what Obj-C blocks will do), or you may get 10 and 11.
>
> With real closures, the local variables like localVar need to go on the heap
> for garbage collection instead of on the stack, which is a fairly
> signifigant change, which I beleive is why LambdaJ can't do it.

Said that I haven't well understood in which cases could be useful to
write a piece of code like that, I can do basically the same with
lambdaj.

public class AdderOf {
private int first = 9;

public add(int second) {
int result = first + second;
first = 10;
return result;
}
}

AdderOf adderOf = new AdderOf();
Closure<Integer> closure = closure(Integer.class) {
of(adderOf).add(var(integer.class));
}

closure.apply(1); // returns 10
closure.apply(2); // returns 12

Am I losing something?

Bye
Mario

Mario Fusco

unread,
Nov 30, 2009, 6:16:45 AM11/30/09
to The Java Posse
> Like Neal said, it's a Turing machine. Everything atop of LISP is sugar. The
> point is closing over the *binding* not the value. Otherwise it's simply an
> implied invocation parameter.

I am quite tired to read this nihilistic sentence. If everything that
matters is to have a Turing machine why do we bother ourselves with
Java or even C. Isn't assembler enough?

Casper Bang

unread,
Nov 30, 2009, 6:43:26 AM11/30/09
to The Java Posse
Because we are developers, we invent new layers of abstractions every
so often and considers this shift in complexity, progress. :)

/Casper

Josh McDonald

unread,
Nov 30, 2009, 8:21:14 AM11/30/09
to java...@googlegroups.com
Erm, that's kinda why I put it in there :-/

2009/11/30 Mario Fusco <mario...@gmail.com>
--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.


Mario Fusco

unread,
Nov 30, 2009, 9:21:16 AM11/30/09
to The Java Posse
> Erm, that's kinda why I put it in there :-/

Sorry, but I am afraid I am not understanding what you are saying. Do
you agree that your example and mine do exactly the same thing or not?
Of course just a "no" it is not enough as answer :)

Josh McDonald

unread,
Nov 30, 2009, 7:31:29 PM11/30/09
to java...@googlegroups.com
Yes I agree that your example appears to do the exact same thing, and I'm definitely willing to take your word for it. The point of the discussion isn't about using the existing ability to close over instance variables inside methods, but about adding syntax to close over method variables inside inner functions. Which Javac doesn't currently do, because it requires promoting said variables to the heap, and keeping the bindings alive when the parent method exits (in my understanding).

The reason I put in the statement about everything atop of LISP being sugar, is that the whole issue of closures is about sugar; We all know the same results can be achieved using more elaborate syntax. Showing how the same result can be computed using a more elaborate syntax doesn't really add much to the discussion of "what's a closure versus a function pointer," which is what I was weighing in on with my JS sample.

Basically, all I was trying to do was demonstrate the difference between a closure and a simple function-as-object, using some working JavaScript code and an example of what the output would be without closures. Like I said, just because I grok it (I believe), doesn't mean I can explain it well. Although I'd like to think it was a pretty decent example.

I guess you could say that a real closure promotes the *invocation* of Bar.methodFoo(10) into an "instance" of "new MethodFoo(10)", and the inner function acts as a method on the "instance of MethodFoo"

I understand that you're saying "the syntax we have is close enough, don't add a chapter to the Java spec", is that right? If so, that's a perfectly valid position to hold. Real closures are difficult to keep in your head, and I see AS3 / JavaScript people scratching their heads when the long-lived bindings make their code do things they didn't expect. When *most* Java programmers demand "closures," they mean "reified anonymous functions". I've interviewed enough "java programmers" to know that we *don't* want a lot of these people writing code full of closures. But none of them work for me ;-)

I like the idea of real closures and first-class functions in Java 7. But more important IMO is that the JVM gets a first-class "Function" interface and system, so that closures, simple function objects, and inner classes from various JVM languages can interoperate, and the standard class library gets support for said callables.

-Josh

2009/12/1 Mario Fusco <mario...@gmail.com>
--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.


Paul King

unread,
Dec 1, 2009, 12:50:31 AM12/1/09