Having methods in a Java object that you will never invoke is a pretty obvious Design Smell. It's already hard to keep the complexity of your objects in check when you limit yourself to strict business logic, so why would you add these useless methods on top of it?
Well, it's actually quite common in Java programming. So common that you probably add such methods every day to your classes without even realizing it.
Some examples: HttlServlet.doPost(), JMSListener.onMessage(), EntityBean.passivate(), etc...
Dependency injection is also a big offender in this area: setter injection forces you to implement setters you will never invoke, and constructor injection makes you modify the signature of your constructors (which is even more intrusive in my opinion).
Alright, at this point you are probably rolling your eyes and dozens of objections are coming to your mind. Fair enough, I agree that most of these methods actually provide important connection points between the container and your object. When these methods are invoked, you are given a chance to execute some logic that can be very important to your application.
As a matter of fact, all the methods I have just mentioned enable this. All of them except... setter injection.
Setter injection is a way for the container to hand you some objects so you can store them and reuse them later. The problem is, it's not the setter you are interested in, but the getter. The typical implementations of an injected setter is to store the value in a field for later use. You don't get more boiler-plate than this.
There are three ways to look at this problem:
I wish there were one simple answer, but unfortunately, these three approaches all have pros and cons. The one-line method can be seen as needlessly polluting your POJO class. Field injection is a little less invasive but I'm not sure I like the idea that the container is messing with private parts of my object. Finally, solution 3 sounds like the ideal solution (no pollution, no messing with private fields) but it requires either abstract methods or objects whose bytecode has been tweaked by the container, both of which make testability harder.
James Strachan likes the idea of using AOP to introduce annotations in your code:
This will let us use our own conventions (naming conventions such as Java Beans default conventions) and let AOP weave in all the annotations
Well, it's not very often, but I strongly disagree with this.
Using pointcuts to specify where the annotations are going to be inserted is a huge step backward that brings us back to XML hell.
The reason why we are moving away from XML as a metadata description language is that it introduces redundancy: in order to define where the metadata is going to be introduced, you need to specify the Java element it applies to: class name or method name, parameter types, exceptions thrown, etc... This redundancy makes your code extremely fragile and even the most advanced IDE's of today don't cover the case of refactoring this kind of metadata. If you rename your method and forget to adjust your pointcut, you application will break. If you define your pointcut poorly, it might start introducing annotations in unexpected parts of your application with similar disastrous results.
JSR 175 annotations have two very strong points. They are:
These two points are already important separately, but taken together, they take Java programming to a whole new level of expressiveness.
Besides, what is exactly the problem, James? Are you afraid that the Java syntax is becoming encumbered? If so, then you need not worry: code folding and other IDE assistance will make it very easy for you to completely ignore the annotations if you so desire.
In a similar vein, Rickard posted the following comment:
Yeah, the way we solved this (the annotation nightmare) is to allow AOP pointcuts to introduce annotations. And then use those annotations in pointcuts for aspects. E.g. instead of setting an annotation "setter" on all set* methods and apply a "StoreToDb" aspect on those methods, I can create a pointcut that says "apply attribute 'setter' on all set* methods" and then have the "StoreToDb" trigger on the "setter" attribute. Just as you mention, with this approach I only have to mark the special cases with annotations; everything else is automatic. It works great, and is a big help.
I have to confess my skepticism about this approach as well. It seems to me that this method only adds a level of indirection for no obvious benefit. In effect, you are still defining a pointcut on "set*", calling it "StoreToDb" and invoking an aspect on it. Why the extra step?
All that being said, James original point is valid: are we going to see an abuse of annotations in the next couple of years? Most likely. But I think it's a little too early to worry about that right now. As the use of annotations percolates through our Java habits, good and bad practices will emerge and we can rely on book authors and fellow bloggers to spot those as they come. And on Hani to keep these people in check.
Aslak is not the first one wondering why the EJB3 Experts Group is not giving credit where credit is due. I have heard this quite a few times since last week, although to be honest, the complaints were only coming from the people who thought they should be credited, so they're probably not the most subjective people either anyway...
First of all, I'd like to dispel the conspiracy idea (very popular these days). There is absolutely no conscious intent from the group or from its members to avoid giving credit where credit is due.
Second, there is a difference between inventing a concept and popularizing it, but there is no question that both deserve credit.
When the first suggestions of dependency injections surfaced on the Experts Group, I didn't immediately make the connection with existing IoC containers because
Innovation happens all the time in software and except for a few very rare exceptions, it's usually very hard to tell who invented what, but we certainly know of a few names who are strongly associated to certain ideas (and Aslak is certainly on my list in the IoC category).
So apologies if a few feelings were hurt, but there is not much we can do about this and we certainly had no intention to offend anyone.
A very cool new site: javadocs.org. It contains all the Sun JavaDocs and also allows you to search directly from the URL.
I created the following bookmark with FireFox:
Location: http://javadocs.org/%s Keyword: jd
This way, I can type "jd url" in the FireFox address bar and I get the documentation for java.net.URL right away.
Even though I use an IDE, I still find myself browsing the HTML Javadocs with a browser fairly often, and even sometimes resorting to "javap|grep" to quickly find a method in a class. The good thing about the javadocs Web site is not that it provides javadocs online, obviously (I already have those in my toolbar) but the simple text search that it enables.
I only have two complaints:
Cool idea nevertheless.
I updated the TestNG distribution to contain the missing source files, let me know if I forgot any other.
I have just uploaded a new version of TestNG, the annotation-based test framework. A lot has gone into this new release:
Extensible API allowing you to generate your own reports or even your own testing methods (two are supported right now: annotations and JUnit).
The HTML reports are still fairly basic but they convey the results of the entire test run pretty well. You can see an example here or just go directly to the main documentation page.
I am getting tired of hearing "lightweight" tagged to the description of every piece of software that comes out. "Lightweight" has to be the most underrated buzzword of the year. Well, not any more. I hereby nominate "Lightweight" (and its evil sibling, "lightweight container") as a buzzword. Consequently, it should be reserved to PR releases and be banned from the vocabulary of anybody who claims to possess a minimum amount of technical knowledge.
Lightweight containers are all over the place these days, and you won't get the attention of the community if your framework weighs more than a certain number of pounds.
What cracks me up is that most of these frameworks have been in the making for quite a while and they stopped being lightweight a long time ago, but since the concept is totally undefined (hence its qualification as a buzzword), nobody will ever contradict you if you say your framework is lightweight.
I don't know about you, but I can't wait to be using an IDE that asks me if I want to create a "Lightweight / Mediumweight / Fatass project". Then it would monitor the number of classes/methods/keys that I type and if I pass a certain limit, it would show up a dialog box saying "Sorry, you selected a Lightweight project and the variable you just declared is turning your project into a Mediumweight one. Please delete all your files, close this project and create the right kind, this time. Moron."
Gavin just posted an interesting article summarizing his views on EJB3 and JDO.
There will be two EJB 3.0 events at TheServerSide Symposium this week:
Check out the full schedule and the BOF schedule for more details.
Hope to see you all there!
The EJBGen mailing-list just celebrated its 700th subscriber (702 actually)...
Who says EJB's are dead?