Proposal: Direct Bean support

[Bosmon]

Many, many beans I write have no logic associated with their access methods, never will, and could do with this being made architecturally clear. In addition I would like to avoid the unnecessary verbiage of writing out dozens of identical access methods (yes, I know Eclipse makes this easier, but they still need to be read).

I propose that the Spring introspector be extended to allow properties to be resolved onto publically visible fields of the same name where they exist.

Why write this

public class Bean {
private String property;
public void setProperty(String property) {
this.property = property;
}
public String getProperty() {
return property;
}
}

When you really mean this?

public class Bean {
public String property;
}

The latter expresses intent far more clearly in many instances.
IMO this should have been in the bean spec from the start, and shows the continuing unhealthy impact of "OO" "thought" knocking on from the 90s. People have become so carried away with the architectural possibilities offered by overriding and interception of requests that it would seem they often ignore the possibility that in many instances this kind of affordance is unnecessary and extraneous.

This would require only a small change to Spring code and would offer a considerable convenience to users.

[steven.warren]

What Spring introspector are you talking about? AFAIK Spring only uses the standard java.beans.Introspector

Cheers

[rrsIPOV]

While this might be a little simplier for some people; on the whole the more I think about it, the more I don't like the idea. While Spring can be used as a general purpose configuration library, it is mainly targeted as an IoC/DI framework, and as such most of the properties being set should be service dependencies and making them JavaBean properties makes a lot of sense (both to help document the service dependencies, and to keep them seperate from more mundate object state). Finally, I don't think user's need yet another way to choose from when learning Spring.

[jbetancourt]

From pure OO of course public fields are a no-no. But, I have wondered why there is no 'struct' in Java.

If a field is public, I would expect the compiler to optimize away an accessor, or even if not public, it probably writes the same JVM bytecodes. ???

If so, then the question is just syntax. Perhaps the fix is that the IDE or editor just hides accessors by default. Or they don't appear in code at all but thru annotations that cause their insertion into compiled code (if there is a need for them that I don't see just yet).

[davison]

The OP may want to look at something like Groovy which allows you to write code like that and have it compiled to the same bytecode as Java code that uses accessors/mutators.

Regards,