An HTML tree in Groovy is defined like that

  html {
      head {
        title "hello groovy builder"
      }
  }

JavaFX uses a quite similar syntax but the syntax is built-in. The beauty of the groovy beast is that the builder syntax relies on closure.

Closure

The trick is the following:

1. An XML node is a method.
2. The content of a XML Node is a closure taken as argument of the method

Ok, so let's try to do the same in Java using the BGGA closure proposal. CICE is too verbose for that case and it should work seamlessly with FCM+ JCA

Proxiiiiiiiiii

But before, how to define all the allowed markups of an XML dialect ?
Ok, we need one method by markup, but because the code is identical for two different markups, instead of writing boilerplate code, I will use the class java.lang.reflect.Proxy.
To use the Proxy, we have to define an interface. The one below allow us to generate XHTML.

public interface XHTMLBuilder {
  public void html(Object textOrClosure);
  public void head(Object textOrClosure);
  public void title(String text);
  public void body(Object textOrClosure);
  public void h1(Object textOrClosure);
  public void br();
}

A Proxy acts as a multiplexer a call to any of its methods is redirected to a single generic method named invoke.

public class XMLBuilderFactory {
  final Appendable appendable;
  
  public XMLBuilderFactory(Appendable appendable) {
    this.appendable=appendable;
  }
  
  public void text(CharSequence seq) {
    try {
      appendable.append(seq);
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }
  
  public <T> T createBuilder(Class<T> generatorInterface) {
    return generatorInterface.cast(Proxy.newProxyInstance(
      generatorInterface.getClassLoader(),
      new Class<?>[]{generatorInterface},
      new InvocationHandler() {
        public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
          
          ...
          return null;
        }
      }));
  }
}

Here appendable acts as a writable stream of characters, something on which I can append characters.
The method createBuilder takes an interface as argument and returns a class that implements that interface. All methods of thi interface are routed to the method invoke of the InvocationHandler.

Java Builder

Now, suppose that the method invoke is written, we will see after how to write it.
To write an XHTML tree on the standard ouput, using the BGGA closure syntax, the code is:

public class Main {
  public static void main(String[] args) {
    XMLBuilderFactory factory=new XMLBuilderFactory(System.out);
    XHTMLBuilder b=factory.createBuilder(XHTMLBuilder.class);
    
    b.html({=>
      b.head({=>
        b.title("hello Java 7 builder");
      });
      
      b.body({=>
        b.h1("Hello");
        factory.text("Greetings from");
        b.br();
        factory.text("Java 7 builder");
      });
    });
  }
}

It's even more readable if we use the control invocation syntax.

    b.html() {
      b.head() {
        b.title("hello Java 7 builder");
      }
      
      b.body() {
        b.h1("Hello");
        factory.text("Greetings from");
        b.br();
        factory.text("Java 7 builder");
      }
    }

This construct has several advantages. I can't produce ill formed XML, markup are opened and closed by the same code. Because the builder uses an interface I can't create markup with the wrong name. Even better, refactoring the markup name will works !

How to write the method invoke ?

For each argument of the method, i have to determine if it's a closure or any other objects. If it's a closure, i have to invoke it. If it's another object, i can append it into the Appendable.
The question is how to dynamically test if an object is or not a closure.
I don't want any closure i just want a closure that takes no parameter and returns void, a {=>void}.

  if (arg instanceof {=>void}) {
    (({=>void})arg).invoke();
  }

There is two poblem with that code. First, there are two kinds of closure (function type), unrestricted and restricted one. A restricted closure is a closure that can't break the control flow using break, continue or return. I am not sure i want my closure be able to break the control flow but the control invocation syntax creates unrestricted closure, so i need unrestricted closure. So instead of using '=>' in the function type, i have to use '==>'
By the way, i think the spec should be revised to swap the two notations ('=>' and '==>'), '=>' should be used for unrestricted closure. If i want a restricted closure which is not the default case, i have to take care about that and use the '==>' syntax. Append a second '=' is equivalent to say don't worry compiler i know what i'am doing.
So currently, the code should be:

  if (arg instanceof {==>void}) {
    (({==>void})arg).invoke();
  }

But there is another problem, currently, {==>void} is a parameterized type and so it's illegal to use it in an instanceof. Here, i have ask Neal, he says he planed to make "types such as this one non-generic".
There is a workaround, currently the closure prototype works with 1.4/1.5 VM and thus generates interfaces corresponding to function types. The interface corresponding to the raw type of {==>void} is javax.lang.function.unrestricted.V.
Here is the code that works:

  String name=method.getName();
  if (args==null || args.length==0) {
    appendable.append('<'+name+"/>");
    return null;
  }
          
  appendable.append('<'+name+'>');
  try {
    for(Object arg:args) {
      if (arg instanceof javax.lang.function.unrestricted.V) {
        ((javax.lang.function.unrestricted.V)arg).invoke();
      } else {
        appendable.append(arg.toString());
      }
    }
  } finally {
    appendable.append("');
  }

A zip containing the wole codes is here: closure-builder.zip
You need the prototype of the BGGA closure too.

Cheers,
Rémi

One ugly thing of the draft v3 of the property spec, is a property object is implemented by a supplementary class generated by the compiler. This means the compiler must create one class by property and so bloat the application with lot of stupid code.
Ok, let's try to do better. No class at compile time means reflection or runtime time generation. In fact, it's not a real choice because reflection since 1.4.1 generates byte-code when a method is often called.

Da Vinci VM

The Da Vinci VM is the prototype implementation of JSR 292, a modified hotspot VM patched with new entry points that help to implement dynamic languages on top of the Java platform.
The first feature available, anonymous class (VM anonymous class not compiler one) allows you to create classes with some interesting features:

1. The class is not referenced by a classloader, so is GCed when there is no more instances of that class
2. Class is like an inner-class of an host class and therefore can access to members of the host class.
3. In order to create the class you can patch an existing class.

How property object works

If you are not familiar with properties, you can read an old blog entry.
A property object stands for a property and permit access to the value of the property of any instance of a Class that declare that property.
By example, the following code:

public class Bean {
  private int x;
  public int getX() {
    return x;
  }
  public void setX(int x) {
    this.x = x;
  }
  
  private String text;
  public String getText() {
    return text;
  }
  public void setText(String text) {
    this.text = text;
  }
    
  public static void main(String[] args) {
      Bean bean = new Bean();
      Property propertyX =
          Property.create(Bean.class, "x");
      bean.setX(0xCAFEBABE);
      System.out.printf(propertyX + " %x\n", propertyX.getValue(bean));
      
      Property propertyText = Property.create(Bean.class, "text");
      propertyText.setValue(bean, "hello property");
      System.out.println(bean.getText());
  }
}

prints:

  int Bean.x cafebabe
  hello property

How to test it ?

If your OS is Windows, Solaris or MacOs you have to compile the VM by yourself, sorry. On linux, you can download the binary of the jdk7 b24 if you haven't already it, download the following zip davinci.zip and unzip it in your JAVA_HOME/jre/lib/i386/
It adds a new server JVM lib named 'davinci' that can be launched using

  java -davinci ...
 

Now download the property runtime support property-runtime.jar, because it adds new classes and overrides some existing classes to the JDK you must prepend the jar to the bootclasspath.
To launch the example above:

  java -davinci -Xbootclasspath/p:property.jar Bean

The source of the property runtime support are available on the kijaro web site here: https://kijaro.dev.java.net/source/browse/kijaro/branches/properties/.

What's the next step, finish to write a new version of the property spec and provide a modified compiler according to that spec. I think i've solved most on the corner cases, so it's just a matter of time.
To be continued...
Rémi

The idea is simple. I want to create a calendar service, like the server part of Google Calendar. I want to create a server that is able to parse a specific protocol allowing to query calendars and send a response using by example the ical format.
This service can be queried by different languages so i've decided to use a text based protocol, like HTTP.
By example the request to get a calendar named mycalendar as user forax between November, the 6th and November, the 7th will be something like that.

GET mycalendar forax CAL/1.0
password: AjxHKRFkRwxx3j9lM2HMow==
from: Sun Nov  6 08:49:37 1994
to: Mon Nov  7 12:34:31 1994

More formally, requests can be described by the following grammar using the Tatoo EBNF form.
Tatoo EBNF form use sections:

• section tokens declares terminals and their regex.
• section blanks declares the regex whom the lexer will not send a terminal to the parser.
• section productions declares sequences of terminal and non terminal which will be reduced to a non terminal.

tokens:
  service='GET'
  uri= '([^ ])+'
  user= '([a-z][A-Z])+'
  protocol= 'CAL/1.0'
  colon= ':'
  header_key= '([^ :\r\n])+'
  header_value= '[^ \r\n]([^\r\n])+'
  eoln= '(\r)?\n'
 
blanks:
 space= "( |\t)+"

productions:
 start = request+
       ;
 request = firstline 'eoln' header* 'eoln'
         ;
 firstline = 'service' 'uri' 'user' 'protocol'
           ;
 header = 'header_key' 'colon' 'header_value' 'eoln'
        ;

Now Tatoo, a parser generator we have developed is able to create a non-blocking push lexer/parser for that grammar.
By non-blocking, i mean a parser that work on NIO buffers, and since christmas, Tatoo has a companion named banzai, a server using NIO that can embed a Tatoo parser generator.
Great, but how to specify the semantics, i.e how to specify that the password need to be checked, how the response is computed etc.

The semantics

The semantics is specified by creating a class that inherits from ProtocolHandler. A ProtocolHandler is an object called each time a terminal is recognized (shifted) or a production is reduced. Furthermore, it provides an object that own some methods like asyncWrite() to send back data to the client or endRequest() to end the request.

 public class CalendarProtocolHandler extends ProtocolHandler { 
  private String uri;
  private String username;
  private String header_key;
  private String header_value;
  private HashMap headerMap=...
  ...

  public void shift(RuleEnum rule,TerminalEnum terminal) {
    switch(terminal) {
      case uri:
        uri=decode();
        return;
      case user:
        user=decode();
        return;
      case header_key:
        header_key=decode();
        return;
      case header_value:
        header_value=decode();
        return;
    }
  }

  public void reduce(ProductionEnum production) {
    if (production==ProductionEnum.header) {
      headerMap.put(header_key,header_value);
      return;
    }
    if (production==ProductionEnum.request) {
      handle();
      return;
    }
  }
  
  private void handle() {
    try {
      String password=headerMap.get("password");
      boolean passwdOK=verifyPassword(username,password);
      if (!passwdOK) {
        putUnauthorizedResponse(outBuffer);
        analyzer.asyncWrite(outBuffer);
        return;
      }
      ...
      Calendar c=...
      putICalendar(outBuffer,c);
      analyzer.asyncWrite(outBuffer);
    
    } catch(IOException e) {
      analyzer.endRequest(e);
    }
  }
}

Short explanation of the code above: shift(), if a specific terminal is found, decode the buffer to find its value. reduce() if we reduce a header key/value pair, store it into a map, if we readuce a request, call handle(). handle() verify the password and write a response

Banzaï !

I know what you are thinking:
"Ok, it's interresting. But embeding a parser in a webserver will damage performance".
No, Tatoo parser is carefully designed to not hurt performance.
I know that you don't believe me. So let me try to convince you with a stupid benchmark(tm).
I have written a subset of the HTTP/1.1 grammar (a subset because the wole HTTP/1.1 grammar is huge and i'm lenient), generated the corresponding parser with Tatoo, written a ProtocolHandler corresponding to HTTP and beanchmark banzai (the server) with that protocol handler and comparing it with Grizzly and Jetty.

Benchmarks

So i've borrowed two DELLs (config) with ethernet Gigabit cards and a gigabit switch in my labs, plug them and play.
Servers are set up with a Gentoo (2.6.19-gentoo-r5) without major modifications. I have just raised the number of descriptors to 65535.
Because i want to do a stress test, i've used apache bench (ab) as client so this is not a real scenario, just a stupid benchmark(tm).
If you want to reproduce the test, checkout the code here svn checkout https://svnigm.univ-mlv.fr/svn/tatoo/trunk, compile Tatoo using ant.
Banzai is located in a sample directory named httpserver. use ant all compile to compile banzai, and to launch it using

 java -server -cp classes:../../lib/tatoo-runtime.jar fr.umlv.tatoo.samples.httpserver.banzai.Main

First test: how many requests can be handled by banzai

Serving files of 4k, 8k, 16k and 32k with different numbers of concurrent connections (8, 16, 32 etc.). The value is a mean over 25 runs of 50 000 requests.
First, when i have seen the result of the benchmark I was astonished. Wow, linux 2.6 and a Core Duo offers great perf, more than 25 000 requests by second for a 4k file.
Furthermore, it seems that banzai have a problem if there are lot of concurrent connections. Perhaps because banzai doesn't have a strategy like closing keepalive connections if there are lot of connections.
Now, a more interesting graphs.

Second test: comparing with the others

Serving a 4k with different concurrent connections
Yes, banzai performs slightly better than grizzly ...
at least if there are not lot of concurrent connections.
About Jetty, I think I screw up the conf because the slope of the curve is weird and I am not able to explain why.

What's next

I think it's possible to integrate non blocking parsers technology directly into grizzly.
Another idea is to wrap banzai to use RESTlet API.
To end, i have found small improvements to the OpenJDK and i will send patches that will benefit to anyone.

Cheers

By the way, i will be at FOSDEM'08, if you want to meet me, i will try to attend to all Free Java Meetings.

I have decided to finish this entry a la Chris Campbell.
In my ears: Morcheeba, "Dive Deep"
In my eyes: Some cryptic codes like always.

Unlike BGGA, CICE, or FCM (not entirely sure about FCM), i don't like the fact a closure is an instance of a class that implement a method. I prefer the John Rose's vision, closure are at runtime method handler on autonomous block of code.

There is another thing I don't like in the current BGGA proposal: its syntax of function type, {int,int=>int} is not enough Javaish for me. My proposal comes with a new way to declare a function type

I've separated my proposal in three parts:

1. function type declaration
2. how to use function type
3. closure syntax

Function types declaration

A function type is declared using the 'almost' keyword function.

// function types declaration
class Ops {

  // function are basically like typedef
  // top-level functions are illegal
  function <T> int comparator(T value1,T value2);

  // here function is not a real keyword, the compiler
  // recognize it as a keyword only in this construction
  function <E> void block(E element);

  // in the function below, E can be instantiated to any
  // object types or any primitive types,
  // it works because function are only declaration with no code. 

  // another function
  function <R> R task();
}

How to use function type

Function types are types so they can be used anywhere a type can be used except as bound of a type variable or type argument of a type variable.

// usage
import static Ops.*;

class Utils {
  // note: comparator<?> is illegal
  // (wildcard are prohibited for generics functions because
  // they are not needed).
  static <T> void sort(List<T> list,comparator<T> comparator) {
    ...
  }

  static <T> void forEach(Collection<T> c,block<T> block) {
    for(T t:c) {
      // invoke is a magic method that execute the block of code,
      // a special rule in the compiler is able to infer its
      // parameter type.
      block.invoke(t);
    }
  }
}

Closure syntax

Unlike function type syntax of BGGA, i like its closure syntax so basically my proposed closure syntax is identical. I have borrow method references from FCM even if we need to add a special lookup rule (because methods and fields are not in the same lookup space) for that in the compiler.
Like BGGA, my proposal include non local transfer and access to local variable (read and write) but only for closures and not for any anonymous classes, a closure is not an anonymous class. Like any proposal, my proposal allow interface conversion of function to interropt with legacy codes but only if closure use final local variable.
At last, return is not allowed in a closure to avoid stupid puzzlers but a replacement syntax exists.

// at calling site
class Main {
  static int f(Object o1,Object o2) {
    ...
  }

  void g(int value) {
    ...
  }

  public static void main(String[] args) {
    Ops.comparator<Object> c=Main.f;

    // using a primitive type here is legal,
    // it creates a block of code that call g()
    Ops.block<int> b=new Main().g; 

    List<String> l=Arrays.asList(args);
    Utils.sort(l,c); // ok contravariance

    // closure syntax, this syntax allow to specify the block of code
    Utils.sort(l,{Charsequence c1, CharSequence c2 =>
      c1.toString().compareTo(c1.toString());
    });

    // function to interface conversion
    java.util.Comparator<Object> javaUtilComparator=c;

    // it's roughly equivalent to
    final Ops.comparator<Object> tempc=c;
    java.util.Comparator<Object> javaUtilComparator=new java.util.Comparator<Object>() {
       public int compare(Object o1,Object o2) {
         return tempc.invoke(o1,o2);
       }
    };
    
    // closure to interface conversion
    java.util.Comparator<String> javaUtilComparator2={String s1, String s2 =>
      -s1.compareTo(s2);
    }); 
  }

Examples of non-local transfer and local variable mutation.

  // this is not allowed in contrast to BGGA.
  class NotAllowed implements Ops.block {
    ...
  }

  static int counter(Collection<Integer> c) {
    int count=0;
    // bloc of code (closure) can mutate local variable,
    // a function that returns an int is a subtype of a
    // function that returns void.
    Utils.forEach(c, {Integer i=>
      count+=i;
    });
    return count;
  }

  static boolean startsWith(Collection<String> c, String prefix) {
    // closure with non local tranfer,
    // moreover prefix doesn't need to be final
    // because this is not an interface conversion
    Utils.forEach(c, {String s=>
      if (s.startsWith(prefix) {
        return true; // doesn't compile ambiguous
        contains.return true; // ok
      } 
    });
  }
}

I wait your comments,
Rémi

Why i hate (yes hate) use-site extension ?

What i love (yes love) with Java is the fact that i can take a look to a screen over one of my student shoulder and be able to say is the snippet i see is correct or not.
With the use-site extension proposed by Neal, the behavior of a code depends on some static imports that are located in the beginning of the file. So you can't understand a code without browsing the entire file.

Demonstration. Do you understand this code ?

 ...
 String text=...
 for(int i=0;i<text.size();i++) {
   System.out.println(text.charAt(i));
 }

Hum, i have forget to say that the begining of the file contains that declaration: import static Strings. and that the class Strings is defined like that:

 public class Strings {
   public static int size(String s) {
     return s.trim().length();
   }
 }

I'am sure i will hate that.
It will remember me the the mess of C++ member functions: "where is the f***ing def of this method".

Furthermore, import static has already some limitations, the code below doesn't compile. This case is currently rare but with extension methods it will be more frequent.

  import static java.util.Arrays.*;

  public class StaticImport {
    public static void main(String[] args) {
      toString(args);
    }
  }

Why i prefer declaration-site extension methods ?

It's definitely a good property of a language to be able to understand a code that deals with some java.util.Lists, just by knowing the declaration of this type. If i don't know how to use it, i can just to browse its code. After that, because i have a good brain storage device, i will be able to understand ALL codes that deals with java.util.List.

Another proposed syntax

I think there is some problems with the syntax proposed by Peter.

  package java.util;
  public interface List<E> … {
  …
    void sort() import static java.util.Collections.sort;
  …
  }
 

1. A new syntax, again !
2. The syntax let a developer think that this method can be overriden but without a modified VM it's not possible.
3. The constraint on the elements of the list (must be comparable) are not visible.

Here is my proposed syntax, allow to declare static method in interfaces (in the same time, we close one the top 25 RFE Bug 4093687) and add some sugar in the compiler.

  package java.util;
  public interface List<E> … {
  …
    @ExtensionMethod
    static <T extends Comparable<? super T>> void sort(List<T> list) {
      java.util.Collections.sort(list);
    }
  …
  }

Like other proposed syntax, the compiler is modified to transform an instance call to a static call. The following code

  List<String> list=...
  list.sort();
 

  List<String> list=...
  List.sort(list);
 

@ExtensionMethod (borrowed from Stephen blog) like @Override is not mandatory and tells the compiler to verify that the first parameter of the static method is the same type that the declaring interface.

I wait your comments,
Rémi

My first thought was something like "you want to hack Tatoo but you are not able to configure your IDE, hoho"

Tatoo currently compiles with an Ant script or using Eclipse, why not try to compile it using Netbeans by myself, after all, reading some recent blogs, it seems that Netbeans is a good competitor of my "old buddy" Eclipse. And better, there is a netbeans plugin that can import an eclipse project in Netbeans. Cool, nothing to do.

The Ant script of Tatoo is a little bit complex, some parts are bootstraped, the Tatoo grammar compiler is created using Tatoo. So I was prepared to have to add classpath and other gory details by hands.

So I tried the import assistant, super, no problem, the import works. But after one or two seconds the Netbeans editor raises the weirdest error I have ever seen. I take a shoot.

If you don't see the problem, the compiler emits an error because it doesn't find a class that is in the same package, strange, is it ? Moreover, at the same location, it emits a warning saying that the class is in the same package so I don't need to import it. duh ??

So i've reverted my opinion about the contributor that use netbeans every day, he is able to hack Tatoo :)

cheers,
Rémi

PS: The last sentence is voluntarily provocative.

I am certainly a geek but i was shocked and, for me, this day will always be a day in gray. Afterall, SUN decide to kill dolphin.
I always think it's a little bit easier to try to explain to anyone that you have spent a whole night on ladybird than on jdk7 :)

I think it's time to resurrect the dolphin. Now, the openjdk is an opensource project, lead by a community not by some managers and lot of opensource softwares have a codename like Gran Paradiso, Etch, Moonshine, etc.

So i officialy request to be able to use dolphin as codename for openjdk7.

I wait your comment and hope your support.

Rémi

The idea is to create a bean (here MyBean) with a bound property (label) and to bind this property to two different textfields.

Defining a bean

Because i use the property support directly integrated in the language, defining such bean is easy. AbstractBean provides the basic support for managing property change listeners.

 public static class MyBean extends AbstractBean {
    property String label bound;
    
    private <B,T> void propertyChanged(java.lang.Property<B,T> property,Object oldValue,Object newValue) {
      firePropertyChange(property,oldValue,newValue);
    }
    
    @Override
    public String toString() {
      return "label "+label;
    }
  }

Wrap the property to someting understandable

By default bean bindings only supports two kinds of property bean property that uses bean introspector and EL property that uses EL script but the framework is easily extensible and let you create your own property implementation.

So i've created a new kind of property (here LangProperty) that exposes a java.lang.Property as a property understandable by the bindings framework.

And mix

And now mixing the language support and the API together is as simple as that:

    LangProperty<MyBean,String> labelProperty =
        LangProperty.create(MyBean#label);
    
    JLabel label = new JLabel("Label:");
    JTextField field = new JTextField(20);
    Bindings.createAutoBinding(READ_WRITE, 
        bean, labelProperty,
        field, BeanProperty.create("text")).bind();
    
    JLabel anotherLabel = new JLabel("Another label:");
    JTextField anotherField = new JTextField(20);
    Bindings.createAutoBinding(READ_WRITE, 
        bean, labelProperty,
        anotherField, BeanProperty.create("text")).bind();

The notation sharp ('#') is used to get an objet typed java.lang.Property that allow to get and set the value of the property.

Want to test it

You want to test it by yourself, ok, here a zip containing the code, the beanbindings jar and the javac.jar patched to understand properties.
Download properties-meets-bindings.zip

Use this line to compile

 java -Xbootclasspath/p:javac.jar com.sun.tools.javac.Main -XDallowProperty -cp beansbinding-1.0.jar *.java

And this one to execute

 java -Xbootclasspath/p:javac.jar -cp .:beansbinding-1.0.jar Sample

You must include javac.jar at runtime only because it contains the class java.lang.Property and i am too lazy to create two jars.

WARNING, i have re-written the bound property support in the patched compiler last night so i think it will not work on another example :)

Cheers,
Rémi

Cheers,
Rémi

What is a binding ?

A binding is a two-way connection between two properties (javabean property). When you change the value of one, automatically the value of the other one is changed.
The concept is not new, i have used JGoodies binding two years ago and the framework was mature at that time. And this concept is heavily used in web tier like Tapestry, JSF etc.

Why do we need bindings ?

Bindings are very elegant solution when you want to cleanly separate the presentation logic to the presentation view of a form.
The presentation view is a panel or a dialog with its components and the presentation logic is a bean. A binding allows you to connect a component (textfield, combo, etc) property to its corresponding bean's property.
So by example if you decide to change a textfield by a combo, you only update the presentation view, and doesn't change the presentation logic.

Furthermore bindings are great because:

1. it provides a unified concept that hide the complexity of dealing with different swing listeners, by example, the selected value of a list is not a bound property, a textfield can't be changed when it fire a modification event, etc.
2. if you set a validator to a binding, you can do validation (on the fly), and provide a feedback to the user by changing the component visual aspect. Futhermore if you have a way to group bindings you can easily find the list of all unvalidated bindings.
3. they can manage conversions (by example between text and primitive type, date etc) because a bean property exports its type.
4. dealing with swing listeners often leads to memory leaks, with a binding you can easily remove listeners by unbinding it or better by unbinding a group of bindings.

If you want more info, take a look to an introduction to jgoodies binding by R.J. Lorimer.

Simplifying the MVC

beansbinding spec/implementation allow not only to define bindings between simple components but to define bindings on MVC components like JList, JTable, JTree, i.e on components that display multiple objects. This provide a more simpler way to define component's model.

Let me take an example, i have a list of employees and i want to display their names in a JList. Moreover, if i modify the employee list or if i change the name of one employee, i want the JList to reflect that change.
A JList (like JTree or JTable) has 3 kinds of events, added, removed or changed. So my list need to be able to signal addition or removal and employee objet need to signal when its name changed.
Employee name modification is signaled using a classical binding

  List list=...
  new Binding(list, null, "${name}");
 

Why do we need the Expression Language ?

beansbinding let you specify the bound property using a enhanced version of the Expression Language (EL) script already use in JSP or JSF.
Suppose that now i want to display the list of street name of my employee. I can create this kind of binding

  List list=...
  new Binding(list, null, "${address.streetname}");
 

So if binding are is a great concept why don't you like beansbinding ?

I just don't like some parts of the current implementation of bean bindings:

1. javax.beans.binding.Binding is not an abstract class, so it's not a concept. I can't create a binding on a user defined component that have a specific listener.
2. beansbinding allows to define a tree of binding but i think it's not necessary, a path of bindings (or a collection/map of binding path) is sufficient.
3. you can define a binding and forget it, this will lead to memory leaks, All bindings need to appear in a group of bindings to be unbound easily.
4. name a binding (new in 0.6) is not a good solution(tm), an object is always more powerfull than a string, if you want a reference to a binding, store it in a field.
5. there is no simple way to get the list of bindings that have validation errors. Furthermore, pratically convertions and validations are often the same operation in Java, by example there is no method Integer.isAnInteger(), Integer.parseInt() do the convertion or throw an exception.
6. there is no way to set a collection of possible conversions for a group of bindings.
7. beanbindings use EL script so goodbye type safety. There is a real risk of creating a desktop applications that will work or not depending on inputs (by example, of data of a database) Java really needs something like C# expression trees, a part of (D)LINQ.
8. the way to define bindings for MVC component is clumsy, by example you can set the parameter of a tree to a binding that bind a table.
9. there is no support for dynamic bean. Roughtly, a dynamic bean is a hashmap of String/value with a property change listener mecanism. Swing's AbstractAction is that kind of bean, so there is currently no way to bind the name of an action to a text of a textfield.

Proposed new Design

Ok, i ve tried to summarize all my remarks in a new design:

  public abstract class Binding {
    Object getSource();
    Object getTarget();
    Binding setValidator(Validator validator);
    void bind();
    void unbind();
    //etc...
  }

  //BindingContext renamed
  public class BindingGroup {
    List bindingList() {...}
    void bindAll() {...}
    void unbindAll() {...}
    // list of all bindings that are not validated
    List unvalidatedBindingList() {..}
    void addValidationListener(ValidationListener l) {...}
    void removeValidationListener(ValidationListener l) {...}
    // the mapper find a converter by its source and target types
    void setConverterMapper(ConverterMapper mapper)
  }

  public interface ValidationListener extends java.util.EventListener {
     void validationFailed(Binding binding, ValidationResult result);
     // allows to remove visual effect on component
     void validationOk(Binding binding);
  }

  // i have tried to separate bindingroup concept from 
  // the binding factory, not sure that is a good idea
  public class BeanBinder {
    public BeanBinder(BindingGroup group) {...}
    public BeanBinder() { this(new BindingGroup()); }
    public BindingGroup getBindingGroup() {...}
    public Binding addBinding(Object source,String sourceExpr,Object target,Object targetPath) {...}
  }
  
  // add swing bindings for some specific components
  public class SwingBinder extends BeanBinder {
    public Binding addSelectedBinding(JTextCompmonent text, Object target,Object targetPath) {...}
    public Binding addSelectedBinding(AbstractButton button, Object target,Object targetPath) {...}
    public Binding addBinding(AbstractAction action String sourceExpr, Object target,Object targetPath) {...}
    public Binding addSelectedBinding(JList list, Object target,Object targetPath) {...}
    //etc.

    ListBinding addListBinding(JList list, ObservableList list) {...}
    ListBinding addListBinding(JList list, Object source, String sourceExpr) {...}

    TableBinding addTableBinding(JTable table, ObservableList list) {...}
    TableBinding addTableBinding(JTable table, Object source, String sourceExpr)
{...}    
    TreeBinding addTreeBinding(JTree tree, Object root) {...}
    //etc.  
  }
  
  // list specific binding
  abstract class ListBinding extends Binding {
    JList getSource() {...}
    ListModel getModel() {...}
    Binding addElementBinding(String elementPath) {...}
  }

  abstract class TableBinding extends Binding {
    JTable getSource() {...}
    TableModel getModel() {...}
    Binding addColumnBinding(int index,String elementPath) {...}
  }

  abstract class TreeBinding extends Binding {
    JTree getSource() {...}
    TreeModel getModel() {...}
    Binding addNodeBinding(Class nodeClass,String elementPath) {...}
  }
 

What do you think about that ? i wait your answers.

Cheers,
Rémi

During the last month, i've written a new prototype from scratch that follows the specification. The prototype is not available yet, mostly because i change the spec too frequently, but i hope to post a blog about its availability in one or two weeks.

If you are concerned by the implementation details of the prototype, i will soon post messages that describe its implementation to Kitchen Sink Language mailing list.

I wait your comment about the spec.

Cheers,
Rémi

Why allowing this is a good idea ?

There is real interest to allow annotation on Java types, it enables to write safer code by performing static source code analysis. Imagine annotations like:

1. JetBrain's IDEA @NonNull, @Nullable to avoid NullPointerException and helps database mapper
2. @Scoped to denote objects allocated in scoped memory of RTSJ
3. Java Concurrent In Practice @Immutable or @ThreadSafe that allows to write safer code in a multi-threaded environment.

There are two possible syntax, the first one is to allow annotation of type at the left of the type like any other Java annotations. But it introduce an ambiguity because a reader doesn't see clearly if an annotation belong to a variable, a method etc. or its type. In the following sample, @NonNull refers to String and @Column refers to name.

  @Local
  class MyBean {
      @NonNull @Column(name="_NAME") String name;
      @Deprecated @NonNull Dimension getSize() { ... }
  }

The second one is to allow annotation on type at the right of a type, in that case there is no ambiguity.

  @Local
  class MyBean {
      @Column(name="_NAME") String @NonNull name;
      @Deprecated Dimension @NonNull getSize() { ... }
  }

The JSR308 expert group seems to think that the first syntax is better, more Java-like even if it introduce an ambiguity.
I am not totally convinced.

What do you think ?

Cheers, Rémi

They propose another syntax for describing a closure which, in my opinion, is more a simpler way to declare an inner-class.
I am not a big fan of this proposal, i definitively prefer the closure syntax decribed by Neal Gafter.
But there is something that i like in their proposal, the fact that you can create invocable method references.

Invocable Method Reference

We need a way to easily create a reference to a method, an object that allow to call a method. Currently a method is not an Object and if you want something like that you have to use reflection (java.lang.reflect.Method) which is not type-safe, uses lot of checked exceptions and performs primitive boxing and array boxing.

So having a way to create a method reference is a good think. But unlike Stephen and Stefan, i don't think that a method reference is a java.lang.reflect.Method correctly typed by the compiler but instead a java.function object (a closure) of Neal.
In my opinion method reference is a kind of closure litteral, so this code snippet:

  public void init() {
    JButton button = ...;
    button.addActionListener(this#handleAction(ActionEvent));
  }
  public void handleAction(ActionEvent ev) {
    // handle event
  }

is a short syntax for:

  public void init() {
    JButton button = ...;
    button.addActionListener({ActionEvent e=>
      handleAction(e);
    });
  }
  public void handleAction(ActionEvent ev) {
    // handle event
  }

Because a method reference is a closure litteral, the type of a method reference is a function type.

 {ActionEvent=>void} handle = this#handleAction(ActionEvent);

I think that using # is a good idea. Perhaps because it's the syntax i choose to use to create property litteral (property reference) in my next property proposal that i will post in few days.

Cheers, Rémi

1. Why the JLS doesn't allow array of parametrized type.
2. Kitchen Sink Language.
3. Property syntax.
4. Why beers are so great in Belgium ?

I will be saturday and sunday at FOSDEM.

Rémi