Why natural selection did not kill the scientists?

A new post on Nothing is Infinite seems good for software techies too :)
Why natural selection did not kill the scientists?

Obama from a 9 year old!

Being a French man living in Israel, we have 3 languages at home: English, French and Hebrew.
And many of my friends around here have this trilingual environment.
Last week the 9 year old son of one of them told him:
- Dad, Obama is talking Hebrew?
- No, Why do you ask?
- Because he keep saying: Yes Oui Ken!

Note: "Yes We Can" sounds like Yes, Oui (yes in French), Ken (yes in Hebrew).

Amazing no?
I found out that it was already used in Obama's campaign.

Anyway, international triple yes from an Israeli 9 year old kid...

Lists and Contextual Menus, MMI nightmare!

I'm more of a "server side" kind of developer.
When I see too much HTML, CSS and Javascript, I need pills!
Still, I like to challenge the MVC architecture of UI frameworks. I even wrote my own web framework for fun (but some poor developers, in India I think, are now suffering from it), and played with Swing developing Stellarium4Java.

So, UI is not my cup of Tea. Now, for the latest release of Artifactory, I needed to managed the communication between the UI Designer and the Web developers. I learned a lot from this interesting experience.
During this process I encountered a really basic UI design issue. It was so basic I got worried I missed something!
The point is: The way we are used to manage lists, selections, actions and contextual menus is totally incoherent.

In real UI applications (fat client and Ajax), you get a list of elements and then you can act on them. Usually, you select a line, then some Action (Buttons, Menus) become enabled and you can activate them. But to minimize the amount of clicks and mouse gestures there are also contextual menus. This is where it gets weird...
You select one line, and then can actually "right click" on another one. That way, the list of Actions on the contextual menus does not match the one in buttons and menus.
You can force select the line where you right click, but few Applications are doing it!

The other issue is that contextual menus are really not that great (i.e. I hate them!):

• They are not Web Browser friendly.
• They don't actually save much in terms of clicks and gestures (right click, move, left click).
• They get in the middle of reading the lists of elements.
• They never disappear when you want them to, and always disappear before you find the menu item you want to click on.
• To remove them go away you need to click elsewhere, crossing your finger you did not actually click on "buy in one click" button.

One solution on the Web (and on the iPhone/iPod, where there is no right click :), is to add action buttons directly in the list itself as columns. That works and can be nice looking (with good icons) but this technique get very heavy (bunch of garbage icons all over). Anyway, it is not scalable: 5 icons it's already too much.

So, the UI designer came with the really cool idea: A hovering toolbox appearing on the side of the list when rollover the line element.
At first, I thought:

• It may work but we'd be going against a big UI muscle memory about how to use a list.
• People will hate it!
• The toolbox is too far from where my mouse is, and going there will be very annoying.
• We are not here to reinvent UI and Men Machine Interaction!

But, anyway I took the chance and we implemented it. To see it, you can go to Artifactory live demo, do a quick search on "log" for example, and hover above the list. It's still a beta version and the previous select/link actions are not removed, so it may be confusing. As anonymous user your action list is limited, but you can still get the feel of it.

I'm using this feature for 2 weeks now and frankly: I love it!
I hover on the list in the left side of it, I can read the line I'm on, and then activate the action with one click. Just natural moves and ONLY ONE click.

May be I'm under the influence (it's our application at the end :), and that's why I'm anxiously waiting for the feedback!
What do you think?

IT opportunities in the current financial crisis?

I'm not optimistic, but here is a fact: For more than 20 years (since the 1987 crash) or in some cases since the usage of computers in companies, the IT budgets of financial institutions (banks, insurance companies, stock markets etc.) ALWAYS go up.
In the meantime, technologies went from Mainframe, to Client/Server, to Web 1.0, to Web 2.0, to SOA, to Virtualization and now Cloud Computing. But in spite of all the technological advances, IT budgets ALWAYS go up. I've given consulting services to many banks and insurance companies, and one thing got increasingly clear: If you're trying to sell a software that will reduce their IT budget... Forget it!

Of course, the financial institutions' needs from IT increased in the last 20 years. They want to setup new services and products (online banking, new policies, new mortgages :) faster than their competitors. But the increase in end user demands is an order of magnitude lower than the technological advances in hardware and software. IT budgets should have gone down, and insurance premiums and bank fees also. But no - IT budgets ALWAYS go up.

I think the main reason is Wall Street. If you are Bank of America, and someone finds out you're reducing your IT budget... Your stock will go down immediately!

A month ago after 20 years of IT budget increases all the CIO and IT department in financial companies have a huge amount of cash fat.
Where the fat goes?

• Buying hard to install and unmaintainable software (you need to keep all these engineers) from BIG vendors.
• Buying low performance hardware for incredible amounts of money.
• Of course, a big team of developers and system engineers to oil down the cranky machines.

And now, for the first time all the CIOs have only one goal: Reduce your IT budget!
IT department in financial companies will never be the same!

From my knowledge, and experience with theses companies their IT budget is about 3 to 5 times bigger than it should be. I don't think they will go all the way and slash 80% of the IT department, but what's for sure, they'll slash the vendors, and contractors.

I think one big software/hardware company will suffer big time from this change because it's living and breathing of this fat. The saying was that a CIO choosing IBM will never get fired for his choice (even he wasted time and money on a failed project). Today that thinking changed.

So, where are the opportunities?
Well, now you can really sell and prove the advantages of modern technological advances to financial CIO. They will be sensitive to TCO, developer productivity, software quality and maintenance.

The issue is that no CIO will start a costly migration project now! So the current state of IT will be frozen for some time. But, some companies will really analyze what's going on and make a decision to go with open source, agile and distributed all the way.

Things will change in banks and insurance companies IT departments, let's hope WebsFear does not blackmail their customers again...

Originally posted on dzone

All new?

The amount of new Web adventures going on around me starts to make a big pile. So, instead of twittering them with 144 characters, here they are:

1. A very good content Podcast about Java on server side from AlphaCSP consultants: The Alpha Pub. I really enjoyed the show, and the latest interview with Alef Arendsen has very good content. Thanks, Ophir for setting up this!
2. The JavaEdge 2008 is on the way, and it's going to be even better than last year!
3. JFrog.org just released the version 1.3.0-beta-3 of Artifactory with the integration of Jersey, which was a lot of fun to do.
4. I sarted a new blog to release in the wild my toughts around Space, Physics and the bad taste left by the failure of Super String Theory!

That's a lot of good stuff coming, and I'm really missing Stellarium4Java and OpenJDK, but that's life... Need to set priorities, and be happy about what you did not do!

Using Jersey for exposing REST services

I just started integrating Jersey in Artifactory and I have to say: I'm impressed!
Like the XFire (still crying on its death :( ) I really like the process of: Write a simple annotated POJO, compile and run, that's it.

Anyway, since I encountered a couple of issues, and implemented some nice extra (XStream adapter and Spring beans injection) here are my findings.
First thanks to getting started entry and getting started with jersey that convinced me Jersey is the way to go.

Getting started

I'm using Maven and Jetty and so running the HelloWorld example got this bug 70. Setting up the Annotation scanner per Java packages solves the problem, and anyway sounds a lot more manageable to me. So here is my web.xml (for 0.8):

<servlet>
    <servlet-name>Jersey Web Application</servlet-name>
    <servlet-class>org.artifactory.rest.servlet.ArtifactoryRestServlet</servlet-class>
    <init-param>
        <param-name>com.sun.jersey.config.property.resourceConfigClass</param-name>
        <param-value>com.sun.jersey.api.core.PackagesResourceConfig</param-value>
    </init-param>
    <init-param>
        <param-name>com.sun.jersey.config.property.packages</param-name>
        <param-value>org.artifactory.rest</param-value>
    </init-param>
    <!-- Usable only in 0.9 version of Jersey
    <init-param>
        <param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
        <param-value>org.artifactory.rest.common.AuthorizationContainerRequestFilter</param-value>
    </init-param>
    -->
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Jersey Web Application</servlet-name>
    <url-pattern>/api/*</url-pattern>
</servlet-mapping>

So now the annotations scanner reads correctly my classes, and I needed only 2 dependencies in my pom.xml:

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>2.5</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey</artifactId>
    <version>${jersey.version}</version>
</dependency>

XStream Message Reader and Writer

Most of my object model classes are using XStream, so I wanted Jersey to marshall/unmarshall automatically any XStream class. It was amazingly easy, here is my XStream message reader provider class:

@ProduceMime({"application/xml", "text/xml", "*/*"})
@ConsumeMime({"application/xml", "text/xml", "*/*"})
@Provider
public class XStreamAliasProvider extends AbstractMessageReaderWriterProvider<Object> {
    private static final Set<Class> processed = new HashSet<Class>();
    private static final XStream xstream = new XStream();
    private static final String DEFAULT_ENCODING = "utf-8";

    public boolean isReadable(Class<?> type, Type genericType, Annotation annotations[]) {
        return type.getAnnotation(XStreamAlias.class) != null;
    }

    public boolean isWriteable(Class<?> type, Type genericType, Annotation annotations[]) {
        return type.getAnnotation(XStreamAlias.class) != null;
    }

    protected static String getCharsetAsString(MediaType m) {
        if (m == null) {
            return DEFAULT_ENCODING;
        }
        String result = m.getParameters().get("charset");
        return (result == null) ? DEFAULT_ENCODING : result;
    }

    protected XStream getXStream(Class type) {
        synchronized (processed) {
            if (!processed.contains(type)) {
                xstream.processAnnotations(type);
                processed.add(type);
            }
        }
        return xstream;
    }

    public Object readFrom(Class<Object> aClass, Type genericType, Annotation[] annotations,
            MediaType mediaType, MultivaluedMap<String, String> map, InputStream stream)
            throws IOException, WebApplicationException {
        String encoding = getCharsetAsString(mediaType);
        XStream xStream = getXStream(aClass);
        return xStream.fromXML(new InputStreamReader(stream, encoding));
    }

    public void writeTo(Object o, Class<?> aClass, Type type, Annotation[] annotations,
            MediaType mediaType, MultivaluedMap<String, Object> map, OutputStream stream)
            throws IOException, WebApplicationException {
        String encoding = getCharsetAsString(mediaType);
        XStream xStream = getXStream(o.getClass());
        xStream.toXML(o, new OutputStreamWriter(stream, encoding));
    }
}

Spring integration

All my backend objects are Spring service bean, so I wanted autowired injection of Spring beans. Here again it was really nice. I defined my own annotation @SpringAutowired, and created a SpringBeanInjector for it that was fetching my context for a bean of the type of the injected field. Here I'm adding manually the list of "injectable" interfaces, because: I don't have an annotation to identify them :) With EJB3 it should be a lot cleaner to use @Stateless.
Here is my annotation:

@Target({ElementType.PARAMETER, ElementType.METHOD, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface SpringAutowired {
}

And here the bean injector class as inner class of my Servlet:

public class ArtifactoryRestServlet extends ServletContainer {
    @Override
    protected void configure(ServletConfig config, ResourceConfig rc,
            WebApplication application) {
        super.configure(config, rc, application);

        Set<Object> pi = rc.getProviderInstances();
        pi.add(getSpringBeanInjector(AuthorizationService.class));
        pi.add(getSpringBeanInjector(CentralConfigService.class));
        pi.add(getSpringBeanInjector(UserGroupService.class));
        pi.add(getSpringBeanInjector(AclService.class));
        pi.add(getSpringBeanInjector(RepositoryService.class));
        pi.add(getSpringBeanInjector(ArtifactoryContext.class));
        pi.add(getSpringBeanInjector(SecurityService.class));
    }

    public static <T> SpringBeanInjector<T> getSpringBeanInjector(Class<T> beanInterface) {
        return new SpringBeanInjector<T>(beanInterface);
    }

    public static class SpringBeanInjector<T>
            implements InjectableProvider<SpringAutowired, Type>, Injectable<T> {
        private Class<T> type;

        public SpringBeanInjector(Class<T> t) {
            this.type = t;
        }

        public ComponentProvider.Scope getScope() {
            return ComponentProvider.Scope.PerRequest;
        }

        public Injectable getInjectable(ComponentContext ic,
                SpringAutowired autowired, Type type) {
            if (type.equals(this.type)) {
                return this;
            } else {
                return null;
            }
        }

        public T getValue(HttpContext context) {
            /*
            (ArtifactoryContext) context
                    .getAttribute("org.springframework.web.context.ROOT");
            */
            ArtifactoryContext springContext = ContextHelper.get();
            if (springContext == null) {
                return null;
            }
            return springContext.beanForType(type);
        }
    }
}

Conclusion

I really liked the WebBeans consept and the Guice injection, but actually working with these nice modern Framework architecture on a real case proved that's the way to go.
Morale: "Chapeau bas for Paul Sandoz at Sun"

Stellarium For Java Alpha release!

After a lot of ups and downs, we (Jerome Beau and myself) are really happy to release an alpha version of Stellarium For Java (S4J in short).
This project is a migration of the very successful C++ project Stellarium created by Fabien Chereau.
For the record, I really like this C++ version but I am missing a lot of features:

1. Ability to add stars catalogs like in Celestia
2. Loading data on demand from the web instead of the resources in the installation
3. Resizable window (I have a Widescreen and need to play with config file)

So, as a open source minded guy, I looked inside the code... And I got flashbacks! I found myself, back in time, when I was doing C++ for Video servers, and MFC applications.
I laughed, and then tried to find a Java version of any Astronomy software. I found Stellarium4Java.
The project had started a year before with Jerome and Arnaud Barre. At the time, it was in the middle of the pure code migration from Stellarium C++ to Java.
It looked like a small decision at the time, so I joined the project! Today I can say: It took time and energy to get were we are today.
But, thanks to the great work of the JOGL team in Sun, and all the Java open source projects, here or here is the alpha version loading with Web Start. I'm still working on the web distribution of resources, so for the moment you will have to wait for 13Mo of download :(
There is a Wiki page on jfrog with the jnlp links (they are still a moving target ;-) and the bug report access (be nice it's still alpha:-).
The most interesting part is that we got selected for a presentation at JavaOne this year to present this application. We will show how Java and the open source projects really helped us doing this, and what features we got for free from Java!

Side note: This project makes me love Java, every time I'm freeing myself for it.

Closure Campaign 2008

After many discussion, it is election time (year) for closure.
I voted for the readable, easy to grasp, and "almost" complete implementation of closure: FCM.
The posts of Stephen on the differences are very instructive:

1. Closures - Comparing the core of BGGA, CICE and FCM


2. Closures - Comparing control structures of BGGA, ARM and JCA


3. Closures - Comparing closure type inference

I hope this vote will have an influence on the JCP...

Wild Java Properties, The Wild Part

Following my previous blog entry, I tried to use Remi's property implementation for JPA or WebBeans. These 2 recent (WebBeans being still in diapers) frameworks really represent what I need from the property proposal. Generally I'd like to be able to do things like:

JPA (Hibernate)

@Id
public property long id get;

@Column("FIRST_NAME")
public property String firstName;

new Criteria(Person#firstName, value);

Validations

protected <B,T> void propertyChanged(
java.lang.Property<B,T> property,
Object oldValue,Object newValue) {
    // Activate validation rules and so stop setting the value
} 

WebBeans (JSR-299) or Guice

@Log
private static property Logger log;

Wicket or Swing

new TextField(Person#firstName);
new DynamicPanel().addAll(Person.properties());

I'd like to say that Remi's work is truly amazing and is a good first draft. It is open source for us to analyze and contribute to. The benefits of properties in the cases above are:

1. No issue of annotations on either a field and/or getter/setter methods. All is centralized on one property declaration.
2. No reflection. All method calls from and to the framework are compiled and wired without using reflection. This is a great boost for UI and Dependency Injection framework.
3. Introspection without reflection.

Trying to write the properties for the logger example (in fact any DI/IoC framework) and validations framework, I found that this implementation is not helping, and even worse - It's stopping me from doing what I need. Here are the limitations:

1. The first problem I encountered is that writing get and set blocks inline looks really good but breaks Object Orientation. I cannot do inheritance or use polymorphisms in these blocks. I ended up having more boilerplate code than without the usage of properties.
2. The second is that the private field exists only if there is no get/set block. So, if you wish to write getter/setter that uses a field, you need to declare this field. Suddenly, a lot of the generated syntactic sugar disappears and you find yourself writing almost as much as before.
3. The third issue is that encapsulation is asymmetric. What I mean by that is System.out.println(firstName) will use directly the field, but this.firstName = "toto" will become this.setFirstName("toto");

So, I tried to see how I can solve these limitations. Since modularity is the most important feature for me, a clean solution for the DI framework property issue is critical. This can really turn Java into a true Component based platform at its root. So as for the Logger issue I actually want to write:

private static property Logger log
init {log = Logger.getLogger(Person.class.getName());};

I added here some init block in the same line as the get/set block, since this is really what I want - to declare how the field is initialized. But, I'd like to write this once and reuse it. Furthermore, I want the init to be executed when the field (either static or instance) is declared, or on demand (lazy init). The only good way to do it is to have a class wrapping the Type2 property. It would look something like:

public class Person {
    public final static Property<Logger> log = new LazyInitProperty() {
        protected void init() {
            value = Logger.getLogger(Person.class.getName());
        }
    };
    public final Property<String> lastName = new Property<String>();
}

public class Property<T> implements BaseProperty<T> {
    private T value;
    public T get() {return value;}
    public void set(T value) {this.value = value;}
}

public abstract class LazyInitProperty<T> implements ReadOnlyProperty<T> {
    protected T value;
    public T get() {
        if (value == null)
            init();
        return value;
    }
    protected abstract void init();
}

Of course it is missing a lot of good (or not) synchronized, but the idea is here. Basically I ended up with the Joda Beans or java.net bean properties concept, and also Yardena's idea.
This is an old idea about the notion that properties don't need to be a language feature. Take a look at What Makes Bean-Properties Special, and 2 discussions on The Java Posse Google group: Wonder what Joe thinks of this properties solution, Still hope for first-class properties.

Conclusion

The solution to all of my problems: Properties should not be a language feature!
When I got there for the first time I thought: WTF! But that's a logical step, isn't it? Properties are field level encapsulation with accessors and events. You can do this in any OO language with a class wrapping your field. So why are we suffering?

The main problem with open source properties projects is that all the classes and interfaces of PropertyType2<T> and PropertyType1<B,T> belong in the JDK. They need to be made a standard so that all framework and component will use them. To be useful, the bean-properties project needs to be in a JSR and included in Java 7. Why didn't any open source property project became a de-facto standard? It's amazing how many Property classes already exists out there!

1. Joda does binding with no boilerplate but changes the getter/setter style.
2. Bean-properties does the binding boilerplate code (and even setter/getter) with bytecode generation. Personally I prefer good syntactic sugar.
3. Annotations on these specific "Property" fields are not understood by 3rd party framework like JPA.
4. You need to declare public final fields.
5. Even if the amount of code is quite low, you still repeat yourself in the field declaration.
6. Bean introspection and Property object access are done using Strings and reflection.
7. The amount of features (Read, Write, initialized, Lazy, bind), types (Simple, Array, Set, Map,...), Modifiers (private, public, synchronized, volatile, for field/getter/setter), are generating a combinator which is impossible to implement with a Property<T> class hierarchy.

Personally, I don't find items 1 and 4 to be a problem. The getter/setter style is related to encapsulation. It's the OO convention for dealing with properties. For me, automatically transforming person.firstName="toto"; to person.setFirstName("toto"); in Java today is very confusing. With Joda style, the type of person.firstName is Property<String>, so when "toto" is assigned to it, something needs to box the value! Transforming person.firstName="toto"; to person.firstName.set("toto"); looks very close to the boxing/unboxing feature, doesn't it? Basically I feel comfortable with the idea that if you want to encapsulate a field in a Property, you should use a class for the encapsulation, not getXXX() and setXXX() methods. And if it's a class, make it clear, don't hide it. So, as for point 4 - a property may be visible or not. Here, I have a strong issue with visibility control around the field, getter, setter trio. Today, I do use different modifiers for each of them. Is it really useful?

So what!

Well, my final wild idea is:

• I want a unique Type1 interface in the JDK (like Remi's Property<B,T>) called PropertyAdaptor<B,T> to be separated from bean-properties class. This can (and will in my kijaro branch) be implemented with an abstract enum.
• I want Person#firstName to return the above Type1 enum instance, and then use it to remove the need to change the class format (similar to what needs to be done in Remi's implementation today).
• I want a nice, small and simple Type2 property interfaces and classes hierarchy, that are making a heavy usage of Annotations and the above unique Type1 enum entry for initialization. Basically this means making some "kind of" bean-properties project part of the Kijaro JDK (KDK ;-).
• The Type1 methods "T get(B)" and "void set(B,T)" should delegate (by the javac phase) to "T get()" and "set(T)" of the Type2 instance. This would remove the need for reflection.
• There should be no restrictions on extending classes or interfaces in the JDK based Property<T> (Type2) hierarchy and on using them. This way, WebBeans and JPA can provide state-of-the-art properties implementations tuned for their needs. This would provide the loose coupling and transparent state management at a language level without reflection.
• The property keyword should be replaced by the above annotation. This Annotation will activate all the syntactic sugar that would remove the standard properties boilerplate code. But, most of the actual Type2 implementation will come from the super class and extra annotations.

Each time I apply the concept of Type2 property class provided and implemented by frameworks, I find a new way to clean and optimize my code:

• Dependency Injection (OSGi), dynamic object allocation and redirection - can be done by calling set on the required properties, by having a smart get or by setting a dirty flag. Whatever the solution be, it is totally transparent to the business code declaring the property field.
• Persistence framework providing validations (from DB type, data and annotations) and listening to property changes.
• Swing bindings of course, but used by higher level framework that can manage full business objects and all their properties.

What I'm gonna' do!

Independently of the wild crazy idea of properties by annotation as a language feature, the property list introspection will be done using a unique abstract enum java.property.PropertyDefinition<B,T>:

public abstract enum PropertyDefinition<B, T>
implements PropertyAdaptor<B, T> {
    public abstract T get(B bean);
    public abstract void set(B bean, T newValue);
    public abstract Property<T> getProperty(B bean);
    public String propertyName() {
        return name();
    }
    public Class<B> getBeanClass() {...}
    public Class<T> getPropertyType() {...}
    public Annotation[] getAnnotations() {...}
    public boolean isReadable() {...}
    public boolean isWritable() {...}
    public int getFieldModifiers() {...}
    public int getGetterModifiers() {...}
    public int getSetterModifiers() {...}
}

And the javac generated code will look like:

public class Person {
[...]
    public static enum properties<T> extends PropertyDefinition<Person,T> {
        <String> firstName,
        <String> lastName,
        <Integer> age
    }
} 

The above work is a simple merge of Remi's implementation and the abstract enum. On top of that, I'll implement the generic Type2 thing. First an annotation needs to be associated with a Property<T> (Type2) abstract class. I'll use a meta-annotation PropertyClass, so anyone can declare a future @Property annotation.

The meta annotation:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface PropertyClass {
    Class value();
}

The specific annotation for a basic property:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
@PropertyClass(BasePropertyImpl.class)
public @interface BasicProperty {
    PropertyAccess value();
}

The specific annotation for a property that can be bound:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
@PropertyClass(ObservablePropertyImpl.class)
public @interface ObservableProperty {
    // Using FCM
    #void(PropertyStateEvent) onSet default null;
}

Then, the bean class:

public class Person {
    @BasicProperty(PropertyAccess.READ_WRITE)
    private String firstName;
    @ObservableProperty(Person#firstNameChanged)
    private String lastName;
    @BasicProperty(PropertyAccess.READ_ONLY)
    private int age;

    private void firstNameChanged(PropertyStateEvent se) {
        System.out.println("property changed "+se);
    }
}

And so the boilerplate code generated by javac will look like:

public class Person {
    @BasicProperty(PropertyAccess.READ_WRITE)
    private final BasePropertyImpl<String> firstName =
            new BasePropertyImpl<String>(properties.firstName);
    @ObservableProperty(Person#firstNameChanged)
    private final ObservablePropertyImpl<String> lastName =
            new ObservablePropertyImpl<String>(properties.lastName);
    @BasicProperty(PropertyAccess.READ_ONLY)
    private final BasePropertyImpl<Integer> age =
            new BasePropertyImpl<Integer>(properties.age);

    private void firstNameChanged(PropertyStateEvent se) {
        System.out.println("property changed "+se);
    }

    public static enum properties<T> extends PropertyDefinition<Person,T> {
        <String> firstName,
        <String> lastName,
        <Integer> age
    }
}

And all accessors to person.firstName will be wrapped in javac with person.firstName.set() and person.firstName.get().

This proposition respects Object Orientation, it is very flexible and open for future extension. It removes a lot of boilerplate code and makes Java ready for easy-to-use components. For example, by applying this solution IoC frameworks can really be "inverted". What I mean by that is that instead of trying to invoke setXXX() on the components at the right time (object life cycle and/or component state), they can simply provide a state-of-the-art getter in the property type2 class that will fetch the right object at the right time, all the time. This is transparent decoupling, keeping type safety and without using reflection.

So it solves some (but not all) of the issues like:

• Yardena's need for flexible property behavior and generics issue with properties,
• Eric Burke's ability to have more flexible binding
• My need for using FCM pointer in properties declaration. Which methods init, bind, listen, and so on.

The only thing that property as a language feature will have a hard time providing is dynamic creation of properties, but that's another story.

A few more white nights are ahead of me so I can put all this in kijaro, I guess ;-) Unless someone finds a good reason to stop me in my wild Java experience!