Original Whatever

I've been using Maven 2.0.4 for the last month or two and am discovering that I spend so much time dealing with Maven that I am wondering if I should give it up completely and go back to Ant. I used Maven archetypes to set up my project modules, and that worked pretty well. But almost immediately, I found myself on the Maven treadmill. One of the improvements that Maven 2 has over Maven 1 (which I have never used) is support for transitive dependencies. That means that Maven will download not only the artifacts (usually jars) that your project needs, but also any artifacts that those artifacts need, and so forth, to any depth. It sounds cool, but it's not so simple in practice. For one thing, in order to figure out the transitive dependencies, Maven has to download the POM (project object model) files for all the dependencies, but many artifacts in the Maven 2 repository do not have POM files. In that case, I have to work out the dependencies myself and add them to my proje

I was reading about C in Wikipedia (under C programming language ). The article first presented the ubiquitous "hello, world" program written in K&R C: main() { printf("hello, world\n"); } and then the same program in ANSI C: #include <stdio.h> int main(void) { printf("hello, world\n"); return 0; } Now I know that ANSI C is an improvement over K&R C. But in this case, the "improvement" has produced a program that needs two additional lines to accomplish the same thing. Wouldn't it be better if technologists spent time making technologies simpler rather than more complicated? It's true that simpler technologies are always arriving. But unfortunately the tendency for any single technology is to get more complicated rather than less. I think that the only real reason why C hasn't gotten significantly more complicated since ANSI C is that all the extra features got tacked on to C++ instead, making it an insa

I find java.util.Date to be most of the most annoying class in the entire Java class library. It is essentially a wart left over from Java 1.0, but the fact that it is used in many APIs makes it difficult to remove. The most insidious aspect of Date is that despite being nothing more than a wrapper around a long, Date is mutable. Anyone can call the setTime method and change the internal long. That causes problems with methods changing Date instances that are passed to them and code accidentally changing Date instances that are members of collections. What benefit comes from Date being mutable? Java understands the benefits of immutable objects. String is immutable. Long is immutable. Why not Date? What's worse is that the SQL date types specified by JDBC inherit from java.util.Date, making them mutable too! That's in addition to the general inconvenience imposed by having them in the first place. The inconvenience of Date might be acceptable if it actually did somethi

I wrote in my last post that I preferred to let the database just store data and and implement all the business logic in my Java code but that I usually let the database handle primary key generation. After thinking about it for a few days, I decided to experiment with using UUIDs as primary keys. Java 5 has a convenient java.util.UUID class that I used to replace the integer identifiers in my entity classes. I found a bunch of blog entries about using UUID versus integer primary keys. UUIDs do have some disadvantages: UUIDs are larger than integer IDs. A UUID, when stored in its most compact form, consumes 128 bits, or 16 bytes. That's four times larger than a regular 32-bit integer. UUIDs are binary. While they fit in a 16-byte binary column, when expanded into a string, they typically consume 32 or 36 characters, depending on whether the string is the human-friendly 00112233-4455-6677-8899-aabbccddeeff format. UUIDs are computationally harder to generate than integers. The disad

How much time I spend, writing crap like this: class Something { private int id; private String name; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getName() { return name; } public setName(String name) { this.name = name; } } Any decent IDE will generate the property methods for you, but why is this necessary? Way back in ancient history, Visual Basic knew how to do the right thing: If you defined a setter for some property, then VB would call it when the application set the property. Set it how? With the equals operator, of course. (The equals operator was how software developers assigned values to variables prior to the release of the JavaBeans specification.) And if you defined a getter, then VB would call the getter when the app used the property in some non-lvalue context. If you didn't provide a getter or setter, then no problem, VB just treated the property as a regular old field. In an anemic domain model , whole classes ma