new Retry(3,5000).run(new Retry.If(new Class[] {RemoteException.class} ) {
public void exec() throws Exception {
; // do something that throws RemoteException
}
});

I was kinda hoping to see this:

new Retry(3,5000).run(new Retry.If(…) {
; // do something that throws RemoteException
});

So, where is the trick ? I am bitterly disappointed. Make me smile!

It does simple closures in java and with IntelliJ “inject language” feature it works brilliantly!

Following things are now possible in java:
————————————————–

each(asList(”a”,”b”,”c”), “print ‘Element ‘+it+’\n’”)
will print to the System.out:

Element a
Element b
Element c

find(asList(”ab”, “abc”, “bc”, “bcd”), “it =~ /.*a.*/; “);
=> “ab”

findAll(asList(1,2,3,4,5,6,7), “it % 2 == 0″)
=> [2,4,6]

findAll(asList(”ab”, “abc”, “bc”, “bcd”), “it =~ /.*a.*/”)
=> ["ab", "abc"]

collect(asList(1,2,3), “it *it”)
=> [1,4,9]

any(asList(”ab”, “abc”, “bc”, “bcd”), “it =~ /bc/; “)
=> true

any(asList(”ab”, “abc”, “bc”, “bcd”), “it =~ /bcde/; “)
=>false

every(asList(”ab”, “abc”, “bc”, “bcd”), “it.length() > 0″)
=> true

every(asList(”ab”, “abc”, “bc”, “bcd”), “it =~ /.*a.*/; “)
=> false

addListener(…{…(MouseEvent e){
doStuff(e);
}});

I would avoid trying to fold anonymous classes into a closure syntax that resembles some other language, like ruby, or C#, or one of the proposals for java closures (which James Gosling reckons are off the cards now anyway). There just isn’t any one of those syntaxes that has a dominant support base. Use the folding syntax that you already use throughout IDEA, which all of your users are already familiar with.

As for closures, I don’t completely understand which glyphs you want to display. | meaning ‘as’ also seems strange for a Java person.

in long hand so it does not get garbled.

suggest that we can display different single glph chars for EQUAL vs DOUBLE EQUALS vs NOT EQUALS and you see the NOT EQUALS like a mathematical not-equal with a diagonal slash. the single EQUAL is drawn as a LEFT ARROW we use a RIGHT arrow in closure params separator and a graphic equals means equals = = .
you could have a really long graphical like 3 or 4 equals to swap in method .equals
so that you can see

mini = = = = me

rather than mini.equals(me)

the | reads AS meaning the {} closure created AS a new ActionListener

so that if you had many you could see

pretend that there are 2 of the ActionListener classes

addActionListener( {ActionEvent e –>(glpyh) onNodeChanged()} | (glyph) ActionListener );

addActionListener( {ActionEvent e –>(glpyh) onSuperNodeChanged()} | (glyph) ActionListenerSuper );

And you can use your “show me the Camel’s” flag to just render the camels, which is very concise.

addActionListener( {AE e –>(glpyh) onNodeChanged()} | (glyph) AL );

addActionListener( {AE e –>(glpyh) onSuperNodeChanged()} | (glyph) ALS );

I hope you guys take this and run with it. No need to wait on Sun/Oracle/JCP. You can add support for Closures, Type Inferencing, Operator Overloading, etc now. The editor can be taught to visualize these in a succinct way (e.g. BigDecimal.add() = ‘+’) while preserving source code compatibility on disk.

Then you’d write:

addActionListener({ActionEvent e => onNodeChanged()});

Better yet, since some people might prefer the CICE or FCM proposals, why not make it a preference or pluggable?

Actually the user can type inside these folded closures, so not displaying the parameters probably won’t be correct since they can be still referenced and completed inside the closure. As for generics, instead of hiding them I can shorten them to < ~> (if the corresponding folding is enabled). As I’ve already said, I’m strictly against hiding base class name, but this can be made an option if there are many proponents (probably a JIRA issue?).

I think if you display “ActionEvent” instead of “ActionEvent<T>” in the placeholder, that would be misleading. But I see what you mean. I think it makes sense to display type when needed and parameters when needed.

For example:

1. “ActionEvent e” is used, so we need to display it:

myNodeBox.addActionListener(ActionListener(ActionEvent e) { onNodeChanged(e); });

2. ActionEvent is not used, listener type is inferred:

myNodeBox.addActionListener({ onNodeChanged(); });

or at least (without type inference)

myNodeBox.addActionListener(ActionListener(…) { onNodeChanged(); });

3. Type cannot be inferred:

Object r = Runnable { doWork(); };