Answer to 'Dude, where’s my class?'
After writing AADA, and starting some applications in some projects, I encountered this blog entry from Uri Boness Dev Thoughts » Blog Archive » Dude, where’s my class?
Here was my answer:
So I read a lot of your Dev Thougths and I'm surprisingly impressed. The subjects are right on today's Java critical issues and your analysis is open minded and fun to read.
But, after a lot of thoughts, I disagree about your bottom line on Annotations vs. XML and JBoss MC vs. Spring.
Spring
Spring is what I call an “Educational Framework”. People ask about Spring: “What does it do?”. Answer: Well, in fact, basically, heuh... instantiating Java classes from names written in an XML file...
WOW, that's a hell of a framework!
You can argue about the answer, but the point is: I like Spring not because of what it does, but because of what it makes me do.
I mean that Spring is educating Java developers to organized their classes and interfaces. It cleans my code from spaghetti plate dependencies, it enables me to play like Lego with my implementations, and gives high level of control of where a specific code should be.
From my experience, the first framework that had this effect was Struts. Before Struts, the amount of very ugly code in Web Application was amazing. But, when I arrive to customers using Struts I'm sure of 2 things:
They will have extended and overridden most of the basic classes of Struts (Action Servlet, Request Processor, Action, ...), reducing to a very thin amount what they actually used from Struts;
They will have some kind of MVC separation in their code.
For more than 3 years now, it proves to be faster and more efficient to write your own small MVC web framework than to use Struts. The main benefit of Struts was that it educated a lot of Java Web users on how to organized their code and architecture.
Today, Spring is on a lot better ground than Struts for one main reason: It was meant and build to be discreet: “Don't pollute my POJO”?
Now, having a good ground like the Spring framework, enables Spring to build additional framework pieces like WebFlow, Swing, Web, Transaction, Remoting, Validation and so on. But here, there is a danger:
I know the answers to the questions above but it's not clear anymore for a lot of people.
So, for me, some of these additions are not Spring Framework anymore.
Don't misunderstand me, I really like the Spring classes interfacing Hibernate, JTA, JDBC, the exception handling (Rod Johnson view of no more checked exception is brilliant), and they should be part of the basic Spring Framework.
But, for example:
Spring Web is great but should not be in Spring Framework,
Transaction declarations are perfect, but I saw too many high-end deployment relying solely on Tomcat + Spring Transaction crashing in production.
For me the basic Spring Framework should only be a good Micro Container with interfaces, and it should be clear that it doesn't replace real container services. Adding too much to Spring Framework will kill the motto of Spring: “Spring should not compete with good existing solutions”.
JBoss MC
The amount of code for a basic MC is relatively small (instantiating classes from names) and JBoss cannot build their platform on top of Spring! They need to offer full support on this.
So, they did it again. It's logical, it's good, and let's see other solutions. JBoss MC has completely different constraints and requirements than Spring. They will, can and should provide technical features that competes with other solutions.
JBoss led the POJO concept against the big guys (IBM, BEA, Oracle, ...), and it's not because they won (AS leaders) that the community should stop the support.
The bad guy is IBM WAS, not JBoss. I had the misfortune to look at some WAS Java code, and this is way more pathetic than JBoss MC. Those guys really completely missed the concept of MC and well organize Java code. I will jump with joy when Geronimo and JBoss will throw this ersatz of AS to history...
Annotations vs. XML
I'm thinking about this “Dude, where is my class?” issue for quite some time now (see AADA), and like you did, I went back and forth between XML and Annotations for managing metadata/configuration.
Today I'm sure of what I want: Annotations.
And this is for one simple reason: The XML way is at a dead end.
Everything was already done (and Spring the first) to maximize the capabilities of XML driven configuration/metadata, and it's still not good enough.
On the other hand, we just started with annotations and its teaming with ideas, feature requests, improvements and so on. “.NET” and then Java 5, just open a huge amount of opportunities on how to design and write applications and technical infrastructures.
In all projects using Java 5, it starts with puzzled developer faces but after a while, I'm always amazed by the ideas and implementations coming out of annotation usages. Once the developers gets it, amazing improvements goes on and on. This does not happens with XML.
We are just starting to play with this stuff. And, like you point out in “Java Annotations - We’re not quite there yet!”, Sun needs to add a lot more to Annotation in the language itself.
And here is my big disagreement with your view: Let's not throw Annotations away because of Sun short views. Let's push it forward. Let's keep asking for all the improvements we want, and may be, one day, Sun will give up under the pressure and make Java open source... (Wishful thinking isn't it?).
About the discussion around the “@injected” annotation (Bob vs. Spring). I don't understand the dilemma here. I'm an application developer and I need something that is not under my control (from the infrastructure or from another module/project/application). In Spring XML way, I need to declare injection in a shared XML file with configuration that I don't even understand.
Isn't it simpler just to write “@injected AnotherInterface myMember;” and expect the system to provide it, without going anywhere else than my class.
For me, “@injected” is the most understandable metadata information: This is “out-of-my-juris-dick-tion”, but I need it. Please give it to me.
In one project we refactored a huge J2SE application to be container enable. We used Spring to “Springify” the code so it will be “soft” enough to be inserted into JBoss. During this process we missed a lot the “@injected” annotation feature. The amount of repetitive XML and setter/getter was very tiring.
So, annotations are not polluting your code if you make them yours. And to link your personal annotations to infrastructure annotations is Spring (or other infrastructure) framework job.
About IDE, I'm using IntelliJ and the Spring navigation is amazing. It really gives what I need to write XML and Spring beans. But, I still prefer annotations navigation. Finding usage, controlling AOP injection, reviewing code and all other architect work is a lot easier with annotations then with any XML based system.
Lately, we refactored an application that used expression based AOP (declared in XML of course). The mental mapping (where are my pointcuts?) was giving us headache. We just wrote some well defined annotations, used them all over the code and redefined our expressions to point to them. It was an amazingly refreshing experience. We solved all the bugs related to AOP (mainly wrong cutting) and now the application developers can managed their Aspects without us.
Here also you can go on with “Is a pointcut position metadata?”. Well, I think I don't care about it. Annotations answered our need in a beautiful way, and I will stick to them.
After writing AADA, and starting some applications in some projects, I encountered this blog entry from Uri Boness Dev Thoughts » Blog Archive » Dude, where’s my class?
Here was my answer:
So I read a lot of your Dev Thougths and I'm surprisingly impressed. The subjects are right on today's Java critical issues and your analysis is open minded and fun to read.
But, after a lot of thoughts, I disagree about your bottom line on Annotations vs. XML and JBoss MC vs. Spring.
Spring
Spring is what I call an “Educational Framework”. People ask about Spring: “What does it do?”. Answer: Well, in fact, basically, heuh... instantiating Java classes from names written in an XML file...
WOW, that's a hell of a framework!
You can argue about the answer, but the point is: I like Spring not because of what it does, but because of what it makes me do.
I mean that Spring is educating Java developers to organized their classes and interfaces. It cleans my code from spaghetti plate dependencies, it enables me to play like Lego with my implementations, and gives high level of control of where a specific code should be.
From my experience, the first framework that had this effect was Struts. Before Struts, the amount of very ugly code in Web Application was amazing. But, when I arrive to customers using Struts I'm sure of 2 things:
They will have extended and overridden most of the basic classes of Struts (Action Servlet, Request Processor, Action, ...), reducing to a very thin amount what they actually used from Struts;
They will have some kind of MVC separation in their code.
For more than 3 years now, it proves to be faster and more efficient to write your own small MVC web framework than to use Struts. The main benefit of Struts was that it educated a lot of Java Web users on how to organized their code and architecture.
Today, Spring is on a lot better ground than Struts for one main reason: It was meant and build to be discreet: “Don't pollute my POJO”?
Now, having a good ground like the Spring framework, enables Spring to build additional framework pieces like WebFlow, Swing, Web, Transaction, Remoting, Validation and so on. But here, there is a danger:
- Should I start using Spring for what it does?
- And if I want WebWork?
- And if I want JBoss Remoting?
- And if I want Hibernate Validation?
- And so on...
I know the answers to the questions above but it's not clear anymore for a lot of people.
So, for me, some of these additions are not Spring Framework anymore.
Don't misunderstand me, I really like the Spring classes interfacing Hibernate, JTA, JDBC, the exception handling (Rod Johnson view of no more checked exception is brilliant), and they should be part of the basic Spring Framework.
But, for example:
Spring Web is great but should not be in Spring Framework,
Transaction declarations are perfect, but I saw too many high-end deployment relying solely on Tomcat + Spring Transaction crashing in production.
For me the basic Spring Framework should only be a good Micro Container with interfaces, and it should be clear that it doesn't replace real container services. Adding too much to Spring Framework will kill the motto of Spring: “Spring should not compete with good existing solutions”.
JBoss MC
The amount of code for a basic MC is relatively small (instantiating classes from names) and JBoss cannot build their platform on top of Spring! They need to offer full support on this.
So, they did it again. It's logical, it's good, and let's see other solutions. JBoss MC has completely different constraints and requirements than Spring. They will, can and should provide technical features that competes with other solutions.
JBoss led the POJO concept against the big guys (IBM, BEA, Oracle, ...), and it's not because they won (AS leaders) that the community should stop the support.
The bad guy is IBM WAS, not JBoss. I had the misfortune to look at some WAS Java code, and this is way more pathetic than JBoss MC. Those guys really completely missed the concept of MC and well organize Java code. I will jump with joy when Geronimo and JBoss will throw this ersatz of AS to history...
Annotations vs. XML
I'm thinking about this “Dude, where is my class?” issue for quite some time now (see AADA), and like you did, I went back and forth between XML and Annotations for managing metadata/configuration.
Today I'm sure of what I want: Annotations.
And this is for one simple reason: The XML way is at a dead end.
Everything was already done (and Spring the first) to maximize the capabilities of XML driven configuration/metadata, and it's still not good enough.
On the other hand, we just started with annotations and its teaming with ideas, feature requests, improvements and so on. “.NET” and then Java 5, just open a huge amount of opportunities on how to design and write applications and technical infrastructures.
In all projects using Java 5, it starts with puzzled developer faces but after a while, I'm always amazed by the ideas and implementations coming out of annotation usages. Once the developers gets it, amazing improvements goes on and on. This does not happens with XML.
We are just starting to play with this stuff. And, like you point out in “Java Annotations - We’re not quite there yet!”, Sun needs to add a lot more to Annotation in the language itself.
And here is my big disagreement with your view: Let's not throw Annotations away because of Sun short views. Let's push it forward. Let's keep asking for all the improvements we want, and may be, one day, Sun will give up under the pressure and make Java open source... (Wishful thinking isn't it?).
About the discussion around the “@injected” annotation (Bob vs. Spring). I don't understand the dilemma here. I'm an application developer and I need something that is not under my control (from the infrastructure or from another module/project/application). In Spring XML way, I need to declare injection in a shared XML file with configuration that I don't even understand.
Isn't it simpler just to write “@injected AnotherInterface myMember;” and expect the system to provide it, without going anywhere else than my class.
For me, “@injected” is the most understandable metadata information: This is “out-of-my-juris-dick-tion”, but I need it. Please give it to me.
In one project we refactored a huge J2SE application to be container enable. We used Spring to “Springify” the code so it will be “soft” enough to be inserted into JBoss. During this process we missed a lot the “@injected” annotation feature. The amount of repetitive XML and setter/getter was very tiring.
So, annotations are not polluting your code if you make them yours. And to link your personal annotations to infrastructure annotations is Spring (or other infrastructure) framework job.
About IDE, I'm using IntelliJ and the Spring navigation is amazing. It really gives what I need to write XML and Spring beans. But, I still prefer annotations navigation. Finding usage, controlling AOP injection, reviewing code and all other architect work is a lot easier with annotations then with any XML based system.
Lately, we refactored an application that used expression based AOP (declared in XML of course). The mental mapping (where are my pointcuts?) was giving us headache. We just wrote some well defined annotations, used them all over the code and redefined our expressions to point to them. It was an amazingly refreshing experience. We solved all the bugs related to AOP (mainly wrong cutting) and now the application developers can managed their Aspects without us.
Here also you can go on with “Is a pointcut position metadata?”. Well, I think I don't care about it. Annotations answered our need in a beautiful way, and I will stick to them.
No comments:
Post a Comment