I'm just curious about the usage of the term "Bean" across the framework, mainly because any kind of object may be managed, not only JavaBean compatible ones. It seems to me that the term "Bean" comes from previous versions, when only setter-based dependency injection was supported and the managed objects must be JavaBean compatible.
Are you planning to refactor the code to support a more generic term like "Object"? In this case, the BeanFactory would become ObjectFactory.
Btw, when porting to other environments like .NET, Java related terms like "Bean" may become meaningless, since they are not part of a generic programing language vocabulary.
Any thoughts about this?
Regards, LB.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, the term "bean" is well known not only from "JavaBean", i.e. a Java object with properties setters/getters, but also from "Enterprise JavaBeans", i.e. an enterprise component model that has nothing to do with properties setters/getters.
IMO, "object" is a too general term: While it's technically correct, it leaves the impression of setting up any sort of object in that style. It doesn't imply any notion of a lightweight application component, which is what you typically set up in a Spring context.
There'd be a further option: the term "component" (as chosen by the Pico team). I'm not too fond of that either, though, as it implies coarse-grained facade components rather than fine-grained application objects. It's arguably still preferable to "object", due to its less general meaning.
So in total, I think that "bean" gets an appropriate message across: While you can use setter-based dependency injection in a Java"Bean" fashion, it also reminds of the power of an Enterprise Java"Bean" component. And it's just one syllable, two less than "component" :-)
Of course, this is largely a matter of taste. In any case, you do have a point regarding the .NET port: AFAIK, the spring.net team plans to use the term "object" instead of "bean" there. On the other hand, doesn't the popularity of the property setter/getter concept originate from Java?
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, this question is really a matter of taste. I agree with you, the term "component" refers to coarse-grained facade objects, I don't like it in this context. Regarding "object", it's generic, but aren't we talking about object orientation at all? Spring is a great piece of work about applying good OO principles and patterns, so the term "object" would not be so misused here :-)
Anyway, I think it would be nice to have both Java and .NET versions as synchronized as possible, and if the term "object" is used in one version, if possible it should also be used in the other. I know that would be a great deprecation, but with the actual tools supporting advanced refactoring it would not be a great problem at all.
Regarding getters and setters, their popularity can really be associated to Java, like OO programming itself (how many Smalltalk or OO C++ developers are out there?). But remember that their usage is very polemic, since some advocate that setters (and in some cases getters too) break encapsulation. Please note I'm not trying to start an endless debate here :-)
Regards, LB.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, thanks for your kind words on Spring regarding OO principles and patterns :-) I appreciate your thoughts; I'm by no means against discussing such fundamental naming strategies.
One of the major differences between EJBs and Spring beans is that EJB is all about coarse-grained components while Spring is all about fine-grained application objects. This won't change any time soon, even if EJB 3.0 allows for easier component development than EJB 2.x. That's why quite a few people use fine-grained Spring beans to implement coarse-grained EJB services.
Spring certainly is about POJOs, after all. But there are a lot of "objects" in a typical application, and only a minority of them are Spring-managed beans defined in an application context. That's why I think "object" is too generic: There are parameter objects, persistent objects, model objects, etc - none of them getting set up in a Spring context.
Frankly, I don't think that we will ever replace the term "bean" with "object": Despite "bean" being more specific (and more memorable) in terms of specifying a Spring-managed application object, its use goes throughout the entire framework: BeanFactory, BeanNameAware, getBean, org.springframework.beans.factory, etc.
Of course, an IDE like Eclipse or IDEA allows to apply such renamings without too much effort. But we would break such a lot of the API, even renaming whole packages, that's it certainly not manageable within Spring 1.x in terms of backward compatibility. That would be even worse than the deprecation mess that is Struts 1.1 (dragging along so many deprecated 1.0 methods).
There are absolutely no plans for Spring 2.0 yet, which would be the first chance to introduce such a major change. But even for a 2.0 release, I'm not sure that it would be worth the hassle: All we'd achieve is different *naming*, without any sort of new functionality or other signifcant benefit (for the Java framework) reaped from it. I strongly believe that this would be a bad tradeoff.
Regarding the Java and .NET version staying as synchronized as possible: This is certainly a goal, but we'll have to accept different naming conventions and different API strategies on both platforms. I certainly don't want to see major changes in the Java version just because of different naming conventions in the .NET world.
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Current thinking is for the .NET version to pretty much global replace Bean with Object, e.g. ObjectFactory.
As Juergen says, we wouldn't want to drive the Java terminology from other languages. However, we do want the mapping to be obvious, so developers switching between Java and .NET can easily orientate themselves.
"Component" brings in a whole host of meanings, that shouldn't necessarily be implied by IoC IMHO, although Spring IoC is great for managing components.
Rgds,
Rod
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm just curious about the usage of the term "Bean" across the framework, mainly because any kind of object may be managed, not only JavaBean compatible ones. It seems to me that the term "Bean" comes from previous versions, when only setter-based dependency injection was supported and the managed objects must be JavaBean compatible.
Are you planning to refactor the code to support a more generic term like "Object"? In this case, the BeanFactory would become ObjectFactory.
Btw, when porting to other environments like .NET, Java related terms like "Bean" may become meaningless, since they are not part of a generic programing language vocabulary.
Any thoughts about this?
Regards, LB.
Luis,
Actually, the term "bean" is well known not only from "JavaBean", i.e. a Java object with properties setters/getters, but also from "Enterprise JavaBeans", i.e. an enterprise component model that has nothing to do with properties setters/getters.
IMO, "object" is a too general term: While it's technically correct, it leaves the impression of setting up any sort of object in that style. It doesn't imply any notion of a lightweight application component, which is what you typically set up in a Spring context.
There'd be a further option: the term "component" (as chosen by the Pico team). I'm not too fond of that either, though, as it implies coarse-grained facade components rather than fine-grained application objects. It's arguably still preferable to "object", due to its less general meaning.
So in total, I think that "bean" gets an appropriate message across: While you can use setter-based dependency injection in a Java"Bean" fashion, it also reminds of the power of an Enterprise Java"Bean" component. And it's just one syllable, two less than "component" :-)
Of course, this is largely a matter of taste. In any case, you do have a point regarding the .NET port: AFAIK, the spring.net team plans to use the term "object" instead of "bean" there. On the other hand, doesn't the popularity of the property setter/getter concept originate from Java?
Juergen
Juergen,
Ok, this question is really a matter of taste. I agree with you, the term "component" refers to coarse-grained facade objects, I don't like it in this context. Regarding "object", it's generic, but aren't we talking about object orientation at all? Spring is a great piece of work about applying good OO principles and patterns, so the term "object" would not be so misused here :-)
Anyway, I think it would be nice to have both Java and .NET versions as synchronized as possible, and if the term "object" is used in one version, if possible it should also be used in the other. I know that would be a great deprecation, but with the actual tools supporting advanced refactoring it would not be a great problem at all.
Regarding getters and setters, their popularity can really be associated to Java, like OO programming itself (how many Smalltalk or OO C++ developers are out there?). But remember that their usage is very polemic, since some advocate that setters (and in some cases getters too) break encapsulation. Please note I'm not trying to start an endless debate here :-)
Regards, LB.
LB,
First of all, thanks for your kind words on Spring regarding OO principles and patterns :-) I appreciate your thoughts; I'm by no means against discussing such fundamental naming strategies.
One of the major differences between EJBs and Spring beans is that EJB is all about coarse-grained components while Spring is all about fine-grained application objects. This won't change any time soon, even if EJB 3.0 allows for easier component development than EJB 2.x. That's why quite a few people use fine-grained Spring beans to implement coarse-grained EJB services.
Spring certainly is about POJOs, after all. But there are a lot of "objects" in a typical application, and only a minority of them are Spring-managed beans defined in an application context. That's why I think "object" is too generic: There are parameter objects, persistent objects, model objects, etc - none of them getting set up in a Spring context.
Frankly, I don't think that we will ever replace the term "bean" with "object": Despite "bean" being more specific (and more memorable) in terms of specifying a Spring-managed application object, its use goes throughout the entire framework: BeanFactory, BeanNameAware, getBean, org.springframework.beans.factory, etc.
Of course, an IDE like Eclipse or IDEA allows to apply such renamings without too much effort. But we would break such a lot of the API, even renaming whole packages, that's it certainly not manageable within Spring 1.x in terms of backward compatibility. That would be even worse than the deprecation mess that is Struts 1.1 (dragging along so many deprecated 1.0 methods).
There are absolutely no plans for Spring 2.0 yet, which would be the first chance to introduce such a major change. But even for a 2.0 release, I'm not sure that it would be worth the hassle: All we'd achieve is different *naming*, without any sort of new functionality or other signifcant benefit (for the Java framework) reaped from it. I strongly believe that this would be a bad tradeoff.
Regarding the Java and .NET version staying as synchronized as possible: This is certainly a goal, but we'll have to accept different naming conventions and different API strategies on both platforms. I certainly don't want to see major changes in the Java version just because of different naming conventions in the .NET world.
Juergen
Current thinking is for the .NET version to pretty much global replace Bean with Object, e.g. ObjectFactory.
As Juergen says, we wouldn't want to drive the Java terminology from other languages. However, we do want the mapping to be obvious, so developers switching between Java and .NET can easily orientate themselves.
"Component" brings in a whole host of meanings, that shouldn't necessarily be implied by IoC IMHO, although Spring IoC is great for managing components.
Rgds,
Rod