Stock Thoughts: AMD

Advanced Micro Devices has come a long way from playing alongside Cyrix in the Intel clone market. As a chipmaker for PCs, they've gone from making cheap, discardable processors to exceeding Intel at its own game. The latest 64-bit chips for the desktop and the Opteron chips for the server have contributed to AMD outpacing Intel in the market. Additionally, Sun Microsystems jumped on the AMD bandwagon in a big way and has vaulted from nowhere to number 6 in the Intel-based server market.

So the big question is, why is the stock going down? Simple answer, it ran up too far and Intel warned recently. I'll be looking for a bounce off of obvious support levels before the end of the year.

Movie Review: Alfie (Spoilers)

Life has dealt me an unfortunate curse...the inability to quit watching a movie.

While Alfie offers some impressive actors with great performances (Jane Krakowski for one), I just didn't find it remotely entertaining. Sure there was a lot of attractive female flesh on the screen, but watching a story about a womanizing guy screwing over everyone including himself just isn't entertaining.

My wife fell asleep after about 15 minutes of the movie (a fitting review), but I just kept on watching.

Why I Hate Maven...Continued

In my previous post, I forgot the most glaringly ridiculous part of Maven's feature set...the dependency system. It's all well and good that I can, as a developer, list my application's dependencies somewhere. However, what's the point of a system that flattens the dependency hierarchy? It's a tree so implement it as a tree.

For instance, what happens if you specify Hibernate 3 as a dependency with nothing else listed in an application that does little more than create a session and run a query? You end up with millions of compile and/or runtime errors because Hibernate requires at least 20 libraries.

Why wouldn't specifying Hibernate 3 as a dependency in Maven cause it to generate dependencies automatically for all of the other required libraries?

Like FreeBSD Ports or Gentoo Portage, if you ask for an application or library, the system should automatically resolve everything you need. There's no reason to chase your tail trying to figure out what version of CGLIB is required by Hibernate or what version of ASM is required by CGLIB. Do I even know what those libraries are? No. Should I need to know? Probably helpful but not central to my job.

Attached to the issue of the dependency tree is that of the contents of the JAR files themselves. When you look around ibiblio.org in the Maven repository, you find several libraries with a variety of options. One option might include no dependencies, the other might include all dependencies, the library may be split into parts, or the library may have one massive, all-encompassing jar to simplify dependency craziness. Additionally, version numbering is like the wild west.

One word...STANDARDIZE.

I Hate Maven

Why do I hate Maven? For the exact reason that most people love it...the repository. With Ant and all dependencies checked into a source repository, my projects always build reliably. Having been forced to use Maven on a project, I've had to rig repositories with my own versions of libraries and never get a consistent build between different workstations. I guess I could set up my own personal repository on a server, but that takes time. Why mess with the repository? Is the storage saved by not storing libs in each project really that important? I certainly don't think so.

Hate may have been a bit extreme, but I'm the kind of developer who likes control. Maven takes it away and provides as your only reward some convenient goals and plugins like run and uberjar.

Unsubstantiated rant complete. My apologies to the Apache folks who tend to produce some amazing products and technologies. I'm especially looking forward to trying out Geronimo.

Java vs. OO Design

For two years, I debated with one of our programmers about her object oriented (OO) design choices. In essence, she reduced a relational database driven Java application to a set of procedures losing almost all of the benefits of good object design. At the time, I was not studying industry trends and did not realize she was merely following current trends and best practices.

Now after studying industry trends and best practices, it seems that true OO design is slowly disappearing. However, I have stumbled upon one voice of opposition. Martin Fowler of ThoughtWorks has written an article on the AnemicDomainModel. In it, he suggests that developers are robbing their Domain Model by putting all of the logic in a service layer.

Mr. Fowler makes many of the same points I have made over the years. In fact, I'm reminded of the definition of an object as it has always been given to me:

An object consists of data and operations performed on that data.

In the Java world, JavaBean methods are not operations on the data. In fact, one has to wonder what benefit there is in creating getter and setter methods instead of just making the data public. In fact for objects (i.e. not base types), getter and setter methods are little more than public variables due to the returned value being a reference. In other words, the following C++ and Java are equivalent:

class A {
public:
Shape& getShape() { return shape; }
private:
Shape shape;
};

public class A {
private Shape shape;
public Shape getShape() { return shape; }
};

The difference is that the reference operator (&) in C++ makes the mistake much more obvious. Programmers I have employed did not even realize unintended consequences. It is even worse for setter methods:

public class A {
private Shape shape;
public void setShape( Shape shape ) { this.shape = shape; }
};

What happens if we have calling code like this:

Shape shape = (Shape) new Circle();
shape.setDiameter( 5 );
A a = new A();
a.setShape( shape );
.
.
.
shape.setDiameter( 10 );

What most Java developers do not understand is that the Shape object contained in class A refers to the Shape object created by the calling code. Consequently, the second Shape setDiameter invocation changes the size of the Circle stored in class A.

Most Java programmers reading this will probably disagree, but I challenge you to run an example and see what happens. As a side note, keep in mind that Strings are treated like base types.

So, after that lengthy tangent, the point is that a JavaBean is little more than a C struct, and a DAO is little more than a C module where every method takes a common struct as an argument.

OOPs...pun intended.

Where's My Backwards Compatibility?

I've been around enough to know that the minute you question the open-source gods, you're likely to be cast into the burning fires of hell for an eternity of pain, suffering, and anguish. Nevertheless, they need to be raked over the coals for one very important thing...BACKWARDS COMPATIBILITY.

Let me tell you my current situation. I'm in the process of developing a small database system for a student organization where I'm using several new open-source technologies. Those include:

• SwiXAT: An XML authoring toolkit for Swing.


• Spring Framework: Best described as the swiss army knife of toolkits...a little something for every occasion.


• Hibernate: A popular Object Relational Mapping tool.

As grateful as I am for the availility of these tools, they've given me no end of headaches with version dependencies and backwards compatibility. SwiXAT actually uses Spring and is based on version 1.1.5. Spring, in turn, has database libraries that use Hibernate. In version 1.1.5 of Spring, you use Hibernate 2.x. In version 1.2, you can use the newer versions of Hibernate numbered 3.x.

So, here's the fun. Hibernate 3.x includes the database dialect for Apache Derby (formerly IBM's Cloudscape), but previous versions of Hibernate do not directly support it. While I could dig up the code and package it myself, life would be simpler if I could just use Hibernate 3.x with all of its new whiz-bang features and bug fixes, right?

Wrong...here are the two gotchas...

First and most importantly, Hibernate completely reworked its package naming from net.sf.hibernate to org.hibernate as part of its conversion to a JBoss project. I'm not aware of a way to overcome that change without rewriting the code, and I might as well just upgrade as rewrite it myself.

So if I want Hibernate 3.x with org.hibernate namespaces, Apache Derby dialect support, and who knows what else, I need to upgrade to Spring 1.2. Great...the only problem is that SwiXAT uses methods from Spring that no longer exist.

So, because of everyone's lack of interest in backwards compatibility, I now need to rewrite SwiXAT to comply with Spring 1.2 and possibly have to manage my own codebase until the SwiXAT authors are able/willing to upgrade.

If open source projects wish to thrive in commercial space, they must pay attention to issues like these. Nobody likes forced upgrades. Spring could have easily included a deprecated wrapper for the missing functions required by SwiXAT as they appear to be nothing more than OOP self gratification on the part of the developers. Hibernate should have continued with releases under both package namespaces to give developers time to make the change themselves.

Now, can I solve all of these problems? Yes. However, the goal of these projects is to save developers like me time. At this point, have they saved me time? Hard to know until I finish the project.

Ready to be burned at the stake...do your worst.