Silent Lifeby Chris Adamson
ONJava Newsletter for 10/28/2004
I'm writing to you this week from the O'Reilly Mac OS X Convention in Santa Clara, California. Java is here, but it's not here. There are few sessions directly related to Java--and one even meant to show Java programmers how to make the jump to Objective-C--yet I'm constantly talking to fellow attendees about Java API's, tools, books, and more. I'll be showing off IBM's Java MPEG-4 authoring kit in a session later in the conference, and Daniel Steinberg's session on Rendezvous networking highlighted two different ways to use Rendezvous with Java. Perhaps the fact that it's not a big deal anymore for something to be made available in Java is, in itself, a pretty big deal.
PHP can be a good tool for whipping up web sites, but what happens when you need to connect that site to a J2EE backend? In How to Use JMS with PHP, Amir Shevat shows how open source tools can be used to make PHP code a participant in a Java Messaging Service system. He writes, "combining the strengths of PHP--easy and fast web development and compatibility with many types of databases--with those of JMS, which is the standard for communication with back-end enterprise applications, creates a powerful and easy-to-use tool for both Java and PHP developers."
Stephen Morris returns this week with another application of design patterns to the field of network management. In The Singleton as a Network Management Pattern, he considers the case of needing to have just a single point of entry for a block of functionality, such as a network provisioning server, in his example. He solves this by applying the Singleton pattern, making one instance of the service available on the network: "This solves the problem of avoiding multiple instances of the server code--by deploying just one. In other words, the provisioning server is a good candidate for implementation using the Singleton pattern"
In our second excerpt from Java Threads, 3rd Edition, Scott Oaks and Henry Wong look at the problems that can result when concurrent threads create impossible-to-resolve contention with one another: deadlock. In Advanced Synchronization in Java Threads, Part 2, they write, "Deadlock between threads competing for the same set of locks is the hardest problem to solve in any threaded program. It's a hard enough problem, in fact, that it cannot be solved in the general case. Instead, we try to offer a good understanding of deadlock and some guidelines on how to prevent it."
To subscribe to the ONJava.com newsletter (or any O'Reilly Network newsletters), visit https://epoch.oreilly.com/account/default.orm and select the newsletters you wish to receive in your user profile (you'll need to log in with your existing O'Reilly Network account -- if you don't yet have an account, you'll need to create one).
To change your newsletter subscription options, please visit https://epoch.oreilly.com/account/default.orm and click the"Manage My Newsletters" link. For assistance, send help to
In this week's feature article from java.net, Joshua Marinacci begins by pining for document-application association, simple embedding of the native web browser component, and other behaviors tightly coupled to the underlying platform and hard to achieve in Java. He writes, "I'll admit it: as great as Java is, there are times I long for the features and system access of native programming. Well, we don't have to wait any longer." In Introducing JDesktop Integration Components, Part 1 he looks at the JDIC project's major components, which address these and other issues of critical importance to those trying to deliver Java desktop applications that look, feel, and behave like their native counterparts.
Please join us again next week.
Chris Adamson, editor
Chris Adamson is an author, editor, and developer specializing in iPhone and Mac.
Return to ONJava.com.