I appreciate there are many reasons to encapsulate things with getters/setters. I’m just railing against the most common use case. Tools should make 80% of your job easy and the remaining 20% possible. Java seems to fail somewhat on simple things like this.

I completely agree on the benefit of first-class properties in Java for things like Hibernate (Wicket could also use this for PropertyModels and the like). I’d really, really like that and was saving a rant about it for another day. It would make usage of things like Hibernate and Wicket so much nicer.

That said I agree that writing setters and getters is moronic and that the language should provide ways to easily create them //when needed// without it being visible to calling code, so that we can change something like:

property long count;

to

property long count set { …. }

while all the time using the property itself in code like
c.count = c.count + 1;

This would at least fix the heaps of boilerplate crap present in most POJO classes.

But even more important than preventing the zillion of stupid “getters and setters” is having this in place to create //property references// from code.

Lots of frameworks need to refer to objects and properties of objects from within code. Take for instance Hibernate; when issuing a query you can easily create a class reference using something like “User.class”. But creating a criteria query on the user’s ‘name’ property must be done by coding the “name” field as a string:
c.add( Restrictions.eq(“name”, “Jalvingh”));

This makes most frameworks very fragile wrt refactoring and data changes, and it makes the reference invisible to most tools making change impact analysis hard.

Having properties as first-class elements in the language would make it possible to encode references to these properties which can then be checked at compile time by the compiler, and are visible to frameworks and IDE’s. For me this is the //real// value of properties syntax in Java.

As far as your comments on the Spring framework go: I mostly agree. Although I really like IOC when it is used to remove framework and factory references from beans, I am not impressed by the Spring way of configuring things. This is where I partly disagree with myth #4: having beans that do not contain references to the factories for the dao implementations are worth having; it really cleans up the code and removes dependencies not worth having.

Spring configuration is indeed a disaster. One gets a complete heap of “code” (in XML) that is invisible to any tooling. And this “code” forms a considerable amount of your application! I also dislike the many highly technical tricks needed to get stuff to work. If that much trickery is needed replacing Spring with something else might be very hard indeed.

Something that also bothers me is that although it is easy to keep simple code clean from Spring dependencies internally this is not doable when using many of the Spring “enhancements”. Take for instance the Hibernate DAO layer encoded with Spring – it enforces your DAO’s to be derived from a Spring base class to handle declarative transaction management… Gross.