I am a little bit worried about these annotations. I am worried about two things:
Annotation Hell
This has nothing to do with the technology, rather how it will be abused. I was looking at some code that came from BEA’s WebLogic Workshop. The source code was using Controls and such…. and the ration of code to annotations was about 1:10. This doesn’t seem right.
We have been seeing this for awhile via XDoclet, and the .NET community is definitely seeing it. I dunno, maybe it is just me, but it scares me. We need to get out some practices for what should be in annotations, and really hope specs will not do crazy things which have you nesting them 5 times.
Coupling of information to source code
Why do we suddenly have to put everything in source code? Does it really make sense to hard code a table name there? If the schema changes we have to recompile code?
Deployment descriptors themselves are NOT intrinsically evil. Angle brackets are also not evil. It was how we were using them that was bad.
This scares me:
@ManyToMany(cascade=CREATE)
@AssociationTable(
table=@Table(name=”EMP_PROJ”),
joinColumns=
@JoinColumn(name=”EMP_ID”, referencedColumnName=”ID”),
inverseJoinColumns=
@JoinColumn(name=”PROJ_ID”, referencedColumnName=”ID”)
)
public CollectiongetProjects() { return projects; }
public void setProjects(Collectionprojects) {
this.projects = projects;
}
We need to think about what really is deployment time information, and what makes sense to be in the source code. The things that I want in annotations are items that make me understand the code better.
July 2nd, 2004 at 5:03 pm
I disagree with the first user about the stability of d.b. schemas. Sounds good in theory, but in practice we use views in Oracle, which allow a great deal of flexibility above the schema. Most of our app code queries views because it allow DBAs to write views that enable simpler queries than querying the underlying tables. As for the underlying schema, it too evolves in response to requirements, and we have upgrade procedures for rolling out schema changes to clients.
I agree with Dion’s point that annotations, like aspects, will inevitably require standards, patterns, conventions and idioms. And developers will need to be disciplined in their use of this stuff so as not to write unmaintainable, unintelligible code.
Speaking of fashionable technology, I have personally been lukewarm to bringing in aspects to one of our (workscape.com) larger projects because of the total lack of attention the strongest advocates have paid to the impact that aspects will have on all our developers’ IDEs, source code organization, build scripts, coding standards, etc. Not doubt I will probably be one of the first to use aspects on my job, in part because I happen to be partly or mostly responsible for a bunch of those concerns, so I will have to resolve them as part of the decision.
Another thing I’ve noticed is that the most eager, zealous advocates of using aspects or annotations bring them up as ad hoc solutions to minor problems and don’t have them in mind as solutions for architectural or systematic problems. You need discipline and you need to see the bigger picture. Again, I would say code and project maintenance and intelligibility are the two biggest areas where business users of these technologies need to be careful (of course, if you’re just hacking away on Sourceforge or something, go nuts!). Some folks believe IDEs will solve these problems for us, and they will some, but not all (particularly not the source code and build management parts).
July 4th, 2004 at 10:30 pm
I agree…
http://radio.weblogs.com/0112098/2004/05/15.html#a481
its time for lightweight annotations :)