Slashdot Mirror
Object-Relation Mapping without the Container
Justin Powell writes "If you follow the latest developer buzz then you've likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming). Like many developers, however, you may not see where these technologies fit into your development efforts. Learn where they can fit with a hands-on introduction to using Hibernate and Spring to build a transactional persistence tier for your enterprise applications."
It is proof that no one paradigm can solve all problems easily. AOP solves some problems easier than OOP, but some prblems it does not.
AOP has the small problem that it is patented. It was, at the time of creation, genuinly new, so it is only right the the creators should be able to patent it. But doing so has limited the ability of OSS tools to support AOP properly.
After all, Java development environments are well known for thier conciseness and simple nature. Let's throw another couple of tools into the works....
Your comment seems to sum up J2EE fairly well. This is why Spring was created. A container should provide a framework for containing things. period. If you want persistence, add a persistence framework. If you want transactions, add a transaction framework. If you think you need all the extra complexity, feel free to add it.
J2EE, however is complex by default. Spring tries to get away from that. Whether Spring itself can replace J2EE has yet to be shown, but it's philosophy will (at least in those companies flexible enough to change).
J2EE was a good first step, I suppose. They combined all the complex middleware software of the early to mid 90's into one giant all-inclusive spec. Anyone with a couple million man hours could implement the spec and join the market. I guess it made sense at the time.
Now we have a handful of application servers each costing tens of thousands of dollars (not including two very nice open source implementations). Most companies opt to spend $20k on WSAD just for transaction support, or just so they can use the app server's security. They never stop and ask if they need all the power their buying. Spring (and the light weight containers that are sure to follow) will give people an alternative.
Java the language has been drawn into the hatred here by its association with other things:
The billions of dollars of advertising that got managers and HR people to take Java classes because it was the way of the future.
All the things that don't live up to their billing: AWT, Swing, keep trying.
Anyone else feel like the "write once run anywhere" philosophy just reduced java to the lowest common denominator of functionality?
Sun has spent a lot of money promising Java will do a lot of things it hasn't done.
Then there are all the fanboys of java that drive some of us nuts on a daily basis. Just trying to explain to them that even though Java is compiled, it is still interpreted (in the same fashion as Perl or Python) falls on deaf ears.
Other languages popular here are popular because they bend to the programmers will. With Java it is the programmer who must bend.
Java is and has been all about marketing. Marketing isn't well liked here.
To me, java is like ms-windows. It is usable, but only after you go out and get someone else's add-ons that should have been included in the first place.
Oh, and I hate java because it isn't LISP.
t
"Whatever happened to plain Java?"
We got tired of reinventing the wheel. These API's exist because the solve problems. By not having to deal with these problems, you can focus on your specific business needs.
Have fun writing everything in C++ (no STL mind you) and no linking to external libraries. Let me know how it goes talking to the database, or parsing that XML file some vendor just sent you.
I can't tell you how many times someone has said to me "Gee if we just had our own implementation of platform and vendor neutral database connectivity API it would solve a critical business need!".