Skip to main content

Da Vinci runtime properties

Posted by forax on March 23, 2008 at 2:07 PM PDT

After a week without any internet access point surfing the
snow of the Alp, monday, my fingers was eager to touch the keyboard again.
Why not finishing my prototype of runtime properties that use
the Da Vinci VM (i really love that name).

One ugly thing of the
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.

So i can create property object by patching a
template code, the resulting class will be able to call getter and setter
of the bean class.

Great !

I've implemented a small library that allows to create
property object at runtime. It detects if the current VM
is the Da Vinci VM and uses VM anonymous class or
uses reflection otherwise.

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");
      System.out.printf(propertyX + " %x\n", propertyX.getValue(bean));
      Property propertyText = Property.create(Bean.class, "text");
      propertyText.setValue(bean, "hello property");


  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
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
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:

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...


Related Topics >>


good questions:
performance: Da Vinci properties get/setValue() are at least four times faster than using reflection. You can test by yourself using:
part of Java 7: hum, i've to finish the prototype first :)
use VM anonymous classes to implement closure at runtime: I think it's possible, but you will need invokedynamic.


very nice. is there any performance implications of this? Also, please make it part of Java 7 :).

Rémi, Also at one point you were concerned about the number of compiler generated classes the various closure proposals were going to create. Is this technique a viable implementation alternative?