A keep-it-simple approach to managing transactions
The basics of the transaction problem -- the need for the steps of a transaction to either all succeed or to fail and make no changes -- are pretty well understood. What can be tricky is deciding now how to solve the problem, but where. One option is the bulky application server, which manages and coordinates transactions, as long as you code your applicaiton the way the appserver wants you to. Another is to use the Java Transcation API, but as authors Binildas C. A. and Sowmya Hubert point out, "if [...] you go for direct JTA API integration at the application code level, you don't need to pay for the additional server infrastructure, but you may end up with business logic mixed with infrastructure-level code."
In today's Feature Article, they offer a third way, combining the darlings of the "lightweight" enterprise Java world, Hibernate and Spring, with JOTM, the Java Open Transaction Manager. In JOTM Transactions In Spring And Hibernate, they consider the case of travel reservations involving separate systems for flights, hotels, and cars, and show a strategy that not only provides a lightweight approach to transactional integrity, but also is sufficiently component-based to allow each of the pieces to be used separately, e.g., to just make a car reservation.
Today's Forums, offer some significant contrarian views to two of the hottest recent topics: open sourcing Java and bringing closures to Java. In Re: Closures and Swing, Shai Almog argues for inner classes over closures: "Anonymous inner classes are a shorthand for class declarations, so they have very low impact... They have no ripple effect of complexity through the language since you don't have to add methods to support them or additional declarations. Closure usage is arguably simple but it introduces brand new constructs and concepts into the language that people have to understand... Closures hide some syntax from the user of the method while creating a unique syntax for the method implementer, it would require an overhaul of every API in Java to support this for advantages that are really trivial and unnecessary in most cases."
weberjn asks if an open-source Java isn't just asking for a rival to fork the language, writing in Microsoft and a WFC killer app: "If Java were opensourced, Microsoft [would be] free to create a non-compatible Java (e.g. resurrect Windows Foundation Classes). None of the currently discussed licenses, not even the GPL, prohibits this. (And if Sun were to create a special license that would prohibit forking and creating non compatible versions, this wouldn't be a real open source license.) So, what if Microsoft put a swing-less, WFC-resurrected JVM into all Windows installations _and_ included some real killer apps written against this JVM? Then everybody would use the non-Sun-compatible MS JVM and nobody would bother to download the Sun JVM. With time even Eclipse would be written against this JVM. Imagine enough users complaining that Eclipse wouldn't run with the JVM on their machines."