|
The Politics of Persistence
BB: What do you mean by the "politics of persistence?"
BT: The fundamental concept behind the politics of persistence is that the best technology doesn't always win. Technologies can fail for political reasons. To give you an example, bytecode enhancement in JDO was at first a huge marketing stumbling block for the JDO platform. Recently, bytecode enhancement has become much more broadly accepted because we've got things like AspectJ and obfuscation frameworks.
Another example is TopLink. Once it was acquired by Oracle, TopLink lost a lot of traction. Customers understood that Oracle may someday bind TopLink to the Oracle application server or the database. So even though Oracle hasn't built any proprietary hooks into TopLink, people are less likely to choose TopLink.
BB: What's in the future for persistence frameworks?
BT: I think that EJB3 (the combined persistence API) will add additional credibility to many of the JDO products. The JDO vendors will have a seat at the table with all the big container vendors. They are able to offer EJB persistence and JDO side-by-side and when those things are installed side-by-side, the best API can win. The best API may turn out to be JDO.
BB: On a separate note, what you think of the general direction in which Sun is taking the Java platform?
BT: You have to give Sun, which is essentially a hardware company, very high marks for presiding over the most dominant language of our time, maybe the most dominant language ever.
That said, a lot of influence and energy is being invested in making Java the best possible tool for the hardest possible problem. I think Java needs to be focusing more on the most basic problems like: "How do you baby-sit a big fat relational database with a Web-based user interface?" Java doesn't solve that particular problem right now. Simplification efforts are helping but they're not going far enough.
We need to think about the role for AOP in the language. I'd like a stronger roll for dependency injection in the language. Perhaps EJB3 will move us in that direction.
We need a lot more energy around the area of defaults and conventions. We need to be a little bit more aggressive as Java gets closer to the end of its leadership life, which could be today. We should be willing to embrace ideas like closures, continuations, and more dynamic typing—even if it means that Java 3 breaks backward compatibility.
I'm putting the finishing touches on a book called Beyond Java. In Beyond Java, I make the point that conditions are ripe for an alternative to emerge. I don't pick what the alternative will be. I just show some of the productivity problems with Java and I show the types of projects in other languages that are interesting. Frameworks like Ruby-on-Rails, Seaside and continuations servers in Lisp and SmallTalk could well become catalysts for another language.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
