Imperative by day and functional by night

Pointer Syntax for Java Closures

If Java closures are pointers to methods then we should make them look like pointers to methods.

Closures for Java are a hot topic yet again. The BGGA proposal is currently leading in the polls. It seems that most people who want closures want full closure support. I like the BGGA proposal, but I think the syntax can be improved to look more familiar and less verbose.

I generally tend to think of Java closures in the same way that I think of C/C++ function pointers (or member function pointers). A lot of programmers like myself transitioned from C++ to Java back in 1999. Java borrows a lot of the syntax from C++ and it was a natural transition for C++ programmers to move to Java. Given this, I cant help but question whether or not we should adopt the familiar C++ function pointer syntax for Java closures. That way the syntax (at least) would not be too alien to us.

Borrowing the examples from Stephen Colebourne’s weblog entry on evaluating BGGA, we have the following syntax comparisons:

BGGA syntax:

int y = 6;
{int => boolean} a = {int x => x <= y};
{int => boolean} b = {int x => x >= y};
boolean c = a.invoke(3) && b.invoke(7);
public {T => U} converter({=> T} a, {=> U} b, {T => U} c) {
  return {T t => a.invoke().equals(t) ? b.invoke() : c.invoke(t)};

Java Method Pointer syntax (simplified C/C++ pointer syntax for Java):

int y = 6;
boolean* (int) a = (int x) {x <= y};
boolean* (int) b = (int x) {x >= y};
boolean c = a.invoke(3) && b.invoke(7);
public  U* (T) converter(T* a, U* b, U* (T) c) {
  return (T t) {a.invoke().equals(t) ? b.invoke() : c.invoke(t)};

In addition to this, we could also borrow the & syntax and reference existing static and instance methods like this:

boolean* (int) a = class&method(int);
boolean* (int) b = instance&method(int);
boolean* (int) c = this&method(int);

If we want closures in Java, why not borrow the C/C++ pointer syntax and think of them as pointers to methods if that’s what they are? Most of the Java syntax is borrowed from C++ after all. I understand that function pointers do not fit well in the OO paradigm but I’m not talking about pointers to functions here. I’m instead talking about pointers to methods in the OO world of Java.


Written by warpedjavaguy

February 21, 2008 at 9:51 pm

Posted in java, programming

Tagged with

17 Responses

Subscribe to comments with RSS.

  1. […] blogs it is evident that we all have our own opinions, preferences, and personal favourites (myself included). And as developers why shouldn’t we? We are the ones that will potentially have to write and […]

  2. Or to rephrase in other terms:

    If Java variables are pointers to objects then we should make them look like pointers to objects.

    Object *o=new Object();

    If you can’t tell, I disagree completely. We don’t have to relate every syntax feature to C. Java variables look like pointers to objects to anyone who knows that they are pointers to objects. There is no inherent ‘pointericity’ in the * symbol.

    Ricky Clarkson

    February 29, 2008 at 8:04 am

  3. Point taken Ricky. It is ironic though that the ‘=>’ symbol actually does have some ‘pointericity’ about it because it does look like an arrow. Maybe that’s because it was inspired by the same symbol used to denote function arrows in mathematics. Maybe not.

    The very similar ‘->’ symbol is also used in C/C++ to dereference pointers. So the BGGA proposal already looks kind of pointerish to me. I actually don’t mind it though and like it better than the FCM ‘#” symbol. But if we have to choose a symbol for closure declarations why not choose the familiar ‘*’ symbol already used in C to declare function pointers and keep the rest of the declaration more in line with Java method signatures?


    February 29, 2008 at 9:37 am

  4. In my proposal Clear, Consistent, Concise Syntax (C3S):


    You use the method keyword which I think is more Java like (unabbreviated keyword). Two examples in C3S are:

    // In examples below MethodX are generic predefined interfaces in java.lang, they have a call method
    // Keyword method, creates a MethodX
    // () when calling a method are optional if unambiguous
    // return is optional
    // type is optionally inferred in variable and field declarations
    // ; is optional before a }

    final plus2 = method( Integer x ) { x + 2 };

    public Method1 converter( Method0 a, Method0 b, Method1 c ) {
    __method( T t ) { a.call.equals( t ) ? b.call : c.call( t ) }

    Howard Lovatt

    February 29, 2008 at 12:14 pm

  5. From a development point of view my concern with closures is more about readability and usability. I’m not too concerned about implementation details and it looks like C3S is syntactically flexible enough to allow you to do the things that both the BGGA and FCM implementations do. I fear that it is too low level to be exposed to developers.

    Something that maps directly to Java method signatures is most ideal. The FCM proposal is good in that regard. But for a method or block of code that accepts an int and returns a boolean, a familiar pointer syntax like boolean* (int) or boolean(int)* would introduce almost minimal changes.


    February 29, 2008 at 3:38 pm

  6. Maybe it’s just a matter of taste, very personal, but one of the C features that I most hated was this cryptic pointer syntax (I used typedefs a lot to hide it). I think the proposed syntax is clearer, but I must admit it doesn’t look like so “Java-ish”.

    Anyway, if Java must have full closures I would prefer this non-pointer syntax (with ” =>”).




    February 29, 2008 at 5:50 pm

  7. Consider the following Java method signatures:

    boolean (int)
    void ()
    <T,U> T (U)

    Does this

    {int => boolean}
    {=> void}
    {U => T}

    look more Java-ish than this?

    boolean* (int)
    T* (U)


    March 3, 2008 at 11:02 am

  8. […] WarpedJavaGuy: Pointer Syntax for Java Closures […]

  9. Ick.

    A java variable declaration (if you ignore the c-style array notation) is always:


    I would prefer to retain the “I am declaring a variable of type TYPE called IDENTIFIER whose initial value is INITIALISER” structure. I’m even content to go down the FCM path to get it over what is being proposed here.

    To the “familiar ‘*’ symbol already used in C” statement I say… Go program in C. I always disliked the function pointer notation in C and no amount of “*” is going to fix that.

    And when you’re doing these examples please include one with exceptions and one that accepts and returns closures – as the notation needs to provide for both of these and combinations thereof.


    March 4, 2008 at 11:37 am

  10. @WarpedJavaGuy,

    I haven’t explained clear enough what I wanted to say (my comment is not very clear, I should have written it better). For me it is clearer the non-pointer syntax (with “=>”) _but_ it doesn’t look like Java-ish, perhaps because Java has shared a lot of syntax with C and C doesn’t have this “=>” syntax.

    The pointer syntax may be more Java-ish but, IMHO, it is cryptic and not so clear as the “=>” syntax. That’s why I prefer the “=>” syntax.

    For example, in the example you have written, I see much clearer the “{int => boolean}” syntax than the “boolean* (int)” one.




    March 4, 2008 at 5:58 pm

  11. => syntax is not java-like it breaks coherency with the rest of the lanquage.
    solution might be in looking at the past.
    java have modified the C syntax about arrays.
    int myarray[]; in C becames int[] myarray; in java
    also pointer becames implicit (-> became .)
    the rule mightbe
    -> the variable should be the last token before equal.
    C equivalent of int (*aFuncPtr)(int param) ; (forget throws)
    should became something like
    int*(int param) throws MathException aFuncPtr;

    for naive user the star symbol represent the wildcard symbol replacing the name of a function.
    aestically the star symbol seems a bit strange… but if you interpret it a a wildcard/replace-me-with-a-function-name, it is much better than other.
    aestically I’ve seen the “#” not so bad, but # is a comment mark.
    why not the ?, it is a wildcard like *, and is already used for templates, :
    int ?(int x) throws Exception funcPtr;

    another solution might be to use a reserved word, but I konw java have compatibility problems.
    int function (int param) thows XException;
    maybe magic anotation
    int @function (int param) thows XException;
    but break annotation logic. or just sugar word after star or #
    int *function (int param) thows XException funPtr;
    int #function (int param) thows XException funPtr;
    why not the ?

    also Template way seems interesting
    java.lang.Function pricer;
    but it is awful about return type (not clear it returns double), and cannot manage Exception throws (for me it is essential to support what is supported with Interface

    my summary :
    -syntax should enforce the principle that the variablename should be the last token before equal or semicolon.
    – should support throws, and parameter name as Interface Method
    – syntax should look like normal method declaration
    – should be simple to parse
    – Template does not support throws and parameter names. bad.

    these are cognitive equivalents :
    int *(int param) throws MathException myFunc= {return 100/param;};
    int #(int param) throws MathException myFunc= {return 100/param;};
    int ?(int param) throws MathException myFunc= {return 100/param;};
    considering ? is used already for template, my heart goes to ‘?’, the ‘*’ as a wildcard mark, then ‘#’ that despite beeing a comment mark in many language is beautiful.

    the invoke syntax is an orthogonal problem.
    compared to C/C++, java make pointer logic disapear
    Object *a=new A(); a->doIt();
    Object a=new A(); a.doIt()
    int (*funcPtr)(int param); int result=(*funcPtr)(3)
    shoudl bacame
    int ?(int param) funcPtr; int result=funcPtr(3);
    there is an ambiguity
    if a method funcPtr(int x) exist, and also a func Pointer funcPtr; as told here java had never any such ambiguity with homonymous.

    for me
    int result=funcPtr.invoke(3) is not so bad… it is really java spirit where we prefer to have method that operators.

    calling syntax funcPtr(3) might be acceptable as a syntax sugar when there is no ambiguity, but is it worth ? I love that in java many things stay a little verbose, showing that things are not so simple.

    so I vote for .invoke(…) as it explains that func pointer is used and it is not trivial.

    Alain Coetmeur

    March 4, 2008 at 7:49 pm

  12. I am just questioning why we should not consider a pointer syntax that is more in line with Java method signatures. If the general consensus is that this pointer syntax is too cryptic and does not belong in Java then so be it. It is interesting though that it does yield a less verbose syntax. That does not automatically mean that it is better though. A better syntax is one that is easier to read and easier to use. I personally find the BGGA syntax very easy to read and quite like it. But I am here wanting to explore whether or not a more familiar and less verbose variant form of the C/C++ style pointer syntax has any appeal.


    The TYPE part of the variable declaration using this pointer syntax can be defined as follows:

    ReturnType* ((p1, p2, …pN) throws e1, e2, …eN)

    Consider the following Java method signature that accepts two parameters of type File and int, returns a String, and throws an IOException

    String (File, int) throws IOException

    Closures for this method would be declared as follows:

    BGGA syntax:
    {File, int => String throws IOException}

    Pointer syntax:
    String* ((File, int) throws IOException)

    Stephen Colebourne’s generic BGGA converter example (used in this post) both accepts and returns closures. Lets add exceptions to that and compare:

    BGGA syntax:

    public {T => U throws E} converter({=> T} a, {=> U} b, {T => U throws E} c) {
      return {T t => a.invoke().equals(t) ? b.invoke() : c.invoke(t)};

    Pointer syntax:

    public U* ((T) throws E) converter(T* a, U* b, U* ((T) throws E) c) {
      return (T t) {a.invoke().equals(t) ? b.invoke() : c.invoke(t)};


    Thanks for your explanation. The BGGA syntax certainly does have a certain clarity about it. I think a lot of people would agree that as far as initial impressions go, both look rather cryptic.


    You are scaring me when you use names like funcPtr 😉
    I do agree with your summary in that the syntax should look very Java method like and should (unlike C/C++) enforce the principle that the variable name should be the last token.


    March 4, 2008 at 9:29 pm

  13. I should stress that closures really are more than just mere method pointers. They also capture all the bindings in the environment in which they are defined and therefore have access to the variables defined in the enclosing scope. This is true regardless of the syntax.


    March 5, 2008 at 10:18 am

  14. Naaahhhh, please. Don’t use the star.
    It is so plain ugly. More important: What people love about Java and hate about C are pointers. Remember your first C lessons?

    Psychologically it’d be a desaster to introduce the *pointer-style to java because everyone will think that their nemesis has finally arrived in java to make them roast on a hellish fire. Painful.


    March 11, 2008 at 2:04 am

  15. The star would be used to denote closures in Java and not pointers per se. Closures are like methods in that they can accept input values and return an output value. Take the signature of a method and add a star after the return type. The result is no more uglier than the method signature itself.

    Closures are pointers to methods or blocks of code that capture the environment in which they are defined. They are most likely coming to Java soon. Now which nemesis would you prefer?

    Java* or {=>Java}


    March 11, 2008 at 9:49 am

  16. very nice article.

    ankara nakliyat

    June 9, 2008 at 3:31 am

  17. Hello,

    well, I can understand why people like OOP but in the case I need function pointers -> Java is defenelty the wrong language….
    When ever I need to have functionpointers which cannot be avoided I write this stuff in C …. Java is OOP and pointer to functions or methods does not fit to OOP … function pointers makes sense in structural programming style …


    July 6, 2010 at 10:53 pm

Comments are closed.

%d bloggers like this: