Kiss My App

Wednesday, January 24, 2007

JavaOne 2007 - "In Case You Missed Last Year!"

I'm beginning to wonder if there's going to be anything exciting this year, or if it's going to be a series of repeat sessions from last year? JEE 5 was exciting, but many of the new innovations and JSRs are intelligently waiting on baited breath for what's coming in JSE 7-- closures and properties? Innovations like that can dramatically change the way APIs are presented, the same thing happened with JSE 5 and annotations. Unfortunately some of our favorite specs (*cough* JSF *cough*) never jumped on the annotation bandwagon with a pure maintenance release for JEE 5. I'd like to see some ramp up in the JCP before JavaOne-- maybe have JSE 7 'finalize' its feature set so the stagnant JCP can pick up in activity again.

Wednesday, January 10, 2007

Properties as Extensions of Member Variables

There's a great debate on where to go with properties in Java SE 7, largely impart to the fact that the original suggestion at Javaopolis was so-- blah. I, myself, went back and forth a bit on ideas, but found the C# syntax to be the most promising. The reason being is ease of refactoring. All Java programmers are familiar and seem to want only dot notation for property accessors:

public class Department {
public Company company;
}

Company mck = new Company();
Department hr = new Department();
hr.company = mck;

Department appDev = new Department();
appDev.company = hr.company;


Well, that's the way normal public field accessors work today. But, what about encapsulation, being able to decorate or protect field assignment and access?

public class Department {

private Company _company;

public Company company {
get { return this._company; }
set(Company c) { this._company = c; }
}
}


Ah, very C#-ish :-) But, notice that our original code doesn't change:

Company mck = new Company();
Department hr = new Department();
hr.company = mck;

Department appDev = new Department();
appDev.company = hr.company;


This allows for easy encapsulation, while making it okay to do simple 'property' declarations such as public Company company;. We already have seen lots of field level injections within EJB3, JPA, JAXB2, etc.

I think one of the struggles with the JavaBean spec is that the syntax changes dramatically when your object decides to encapsulate some behavior or make internal changes. This is why I wouldn't mind seeing the JavaBean spec kind of fall to the wayside. You should be able to refactor introvertantly instead of extrovertantly (I made those words up).

Now the Pie in the Sky Stuff



To be able to provide better refactoring without basically declaring two 'fields': a member variable, and public property, we can imply a super behavior of a member variable, such that we just have:

public class Department {

public Company company {
get { return super.get(); }
set(Company c) { super.set(c); }
}
}


The issue though is how to do a public, read-only property, if the set is implied as protected or what not. Interfaces over properties would be allowed just like C#:

public interface IDepartment {
public Company company {
get;
set;
}
}


If Sun did want to add a new accessor, then use it for accessing meta/type information:

Binding b = new Binding(uitext#value, myDept.company#name);


Which would be read as bind the uitext's value to my department's company's name. Possibly the return type of company#name has methods on it such that you could add a change listener or get the read/write methods:

Property p = company#name;
Method rm = p.getReadMethod();
Method wm = p.getWriteMethod();
Class type = p.getType();
p.addChangeListener(new PropertyChangeListener() {
public boolean onChange(PropertyChangeEvent ev) {
if ("foo".equals(ev.getNewValue()) {
// stop propagation
return true;
}
return false;
}
});