java-gnome-hackers

[java-gnome-hackers] Potential issues with new closures in JDK 7

[Jacek F. <ja...@gm...>]

As you've probably heard by now, looks like JDK 7 will be giving us
closures/lambdas after all (as announced yesterday at Devoxx):

So, instead of a verbose listener like this in Swing:

button.addActionListener(
   new ActionListener() {
      public void actionPerformed(ActionEvent e) {
         System.out.println("Hi!"); } } );

we could have a much more concise:

button.addActionListener(#(ActionEvent e) System.out.println("Hi!));

As you can see, the new closures are designed to be backwards compatible,
i.e. able to be used in method that expect an interface with just one
method,
which makes them usable with existing APIs.

I am not sure however if this would work so well with the standard event
APIs in Java-GNOME. Let's look at these two examples:

* **connect(new Widget.KeyPressEvent() {*
* **public boolean onKeyPressEvent(Widget source, EventKey event) {*
* **return false;*
* **}*
* **});*
*        *
*        connect(new Widget.KeyReleaseEvent() {*
* **public boolean onKeyReleaseEvent(Widget source, EventKey event) {*
* **return false;*
* **}*
* **});*

With the new closure syntax both calls would look the same:

*connect(#(Widget source, EventKey event) return false);*

I would guess there would be no way for the compiler to figure out in this
case whether it is a KeyPressEvent or KeyReleaseEvent, making JDK 7 closures
potentially unusable with Java-GNOME. Maybe there will be a need for actual
event-specific connect methods?

Example:

*connectKeyPressEvent(#(Widget source, EventKey event) return false);*
*connectKeyReleaseEvent(#(Widget source, EventKey event) return false);*
*
*
Jacek

Re: [java-gnome-hackers] Potential issues with new closures in JDK 7

[Andrew C. <an...@op...>]

On Thu, 2009-11-19 at 10:15 -0500, Jacek Furmankiewicz wrote:
> As you've probably heard by now, looks like JDK 7 will be giving us
> closures/lambdas after all (as announced yesterday at Devoxx):

To be honest, I don't follow the politics of Java 1.7 development that
closely; but that's interesting to hear.

Speaking personally, I've never really missed closures as a language
concept in Java; proper function/method pointers would have been wizard
cool for us {10,4} years ago when we engineered java-gnome, but we don't
have them in Java, so {shrug} we don't.

And meanwhile the technique of implementing an interface and using that
in a callback (especially doing so via an anonymous inner class) has
been good enough. Modern IDE support means that the code appears click
swish bang! which makes it even more of a non-issue :)

...

> I would guess there would be no way for the compiler to figure out in
> this case whether it is a KeyPressEvent or KeyReleaseEvent, making JDK
> 7 closures
> potentially unusable with Java-GNOME.

Perhaps!

> Example:

> 
I've never written a callback that short, so I'm not sure I'd miss being
able to use closures.

That said, surely they've got some casting mechanism? ie, taking your
example and having done zero research about it, surely you can put a
cast in to tell the closure which overload of a method you are actually
trying to call?


> Maybe there will be a need for actual event-specific connect methods?

Perhaps. I rather like overloaded methods. I think they look good in
Java, our implementation has beautiful completion and type safety
properties, and it ties somewhat nicely with the underlying
g_signal_connect() API [though that is voodoo at the best of times]

++

Anyway, very interesting design question you've raised. We had similar
conversations when generics first came long, and enums too. Both turned
out to be not that interesting/helpful to us, but it still took
investigation to work that out.

It will be good to think about closures it over the coming years as Java
1.7 gets closer to being actually available out in the wild.

AfC
Sydney



> like this in Swing:
> 
P.S. "the way that Swing does it" doesn't count for all that much. Most
of us have a well-earned and now reflexive hatred for their API. Making
java-gnome appropriate Java is important. Solving design questions
specifically in order to end up with the same thing that {AWT, Swing,
SWT, etc} did is not.