Random Thoughts on Software

I just read that Universal Music is suing MySpace.com over copyright violation, saying that MySpace encourages its users to illegally distribute copyrighted materials. Universal is arguing that:

“Our music and videos play a key role in building the communities that have created hundreds of millions of dollars of value for the owners of MySpace,” the company said in a statement. “Our goal is not to inhibit the creation of these communities, but to ensure that our rights and those of our artists are recognized.”

Yes, and MySpace, through its “copyright violation” has played a key role in creating hundreds of millions of dollars of value for the owners of Universal. Call me crazy, but how does Universal not realize that MySpace is a massive marketing engine that is promoting their music.

People post songs on their profiles and their friends can listen to those songs when they visit. This is called “sampling” and it promotes Universal’s music. Sampling of this sort is going to be one of the most significant ways that digital content will become popular in the next 5-10 years. People share music and music becomes popular because of it. When music becomes popular, musicians sell more music, concert tickets, t-shirts, etc.

The record companies have got to take off their blinders and realize that they need to help promote this, not fight it. These types of lawsuits and lobbying hurt technological innovation and damage our culture.

Since Java adopted annotations, I’ve heard a lot of discussion around whether to prefer annotations over external configuration files (often XML) and vice versa.

I think the decision boils down to two criteria:

1) Can annotations simplify the metadata?
2) Can changes to the metadata break behavior in your application?

If annotations do not reduce the amount of metadata that you have to provide (in most cases they do), then you shouldn’t use annotation.

I think the more important thing to considered is whether a configuration change could break behavior or not. If not, then you can feel comfortable applying the change while the system is running in production. External config files are the best place for the metadata in this case because you don’t want to have to recompile your code to make the change.

However, if a metadata change could break behavior then you’ll want to test the change by going through a full release cycle (change code, build, test, deploy). If you’re going to go through a full release cycle there is practically no benefit to not recompiling besides the 5-10 seconds you save in compile time. The more important thing to consider is which method of metadata definition is simpler.

For example, Hibernate mappings are often in XML, but annotations often provide the ability to specify the same mappings with significantly less metadata. Any changes you make to your mappings (whether in XML or annotations) could potentially be behavior breaking. You’re not going to change your mappings dynamically at runtime, are you? So, annotations seem like a much better choice.

[Note: I might consider using XML metadata for Hibernate when mapping to a legacy database because the annotations can often become bulky. Also, you are forced to use XML if you want to map the classes against two different databases with different schemas. I haven’t heard of a way to specify two mutually exclusive sets of Hibernate annotations on my classes. Even if this did exist it would be complex, which violates my first criterion for selecting annotations over XML.]