The JDeveloper 11g Handbook: A Guide to Oracle Fusion Web Development is being released today! If you’re at Oracle OpenWorld, you can pick it up at the conference bookstore starting Monday. If not, you can buy it from Amazon.
You can access errata, database scripts you need for the hands-on practices, and hands-on practice solutions from the TUHRA2 home page on samplecode.oracle.com. Pretty soon you’ll be able to download code snippets from there, too.
Next week, I’ll be blogging from Oracle OpenWorld/Oracle Develop 2009. If you’re going to be there, maybe I’ll see you at one of the sessions, especially the sessions of the Oracle ADF Enterprise Methodology Group:
Sunday 10:30-11:30, Moscone West, Room 3014
Wednesday 1-3:30, Overlook I (the first hour of this is a reprise of the Sunday session)
In the spirit of the last post, I want to talk about another design pattern that’s useful in a wide range of Java development cases, and for which I think better tooling support (maybe in the form of a JDeveloper addin!) would be very useful: The bridge, also known as the driver. You’re probably familiar with the term “driver,” at least in the sense of device or JDBC drivers, and as we’ll see, there’s a reason why the driver pattern shares a name with them.
The stated purpose of this pattern is to “decouple an abstraction from its implementation so that the two can vary independently.” This may not make much sense at first, so we’ll start with a concrete example.
So, I’ve been doing some work on my Framework for Package API-Based ADF BC (locking doesn’t work as-is, and it turns out the framework needs some pretty significant re-architecture to get it to), and between that and my regular work, I’ve been a little ADF’ed out. So for a couple of weeks or so, I’m going to do something I haven’t done a lot of in this blog, and post a bit about pure Java. This will, hopefully, contain techniques of interest to ADF developers, and I’m probably going to use some ADF-based examples, but I’m mostly going to be talking about “Java techniques that they don’t teach you in a 5-day Java class.”
While working on the new version of the Framework, I’ve run into some significant annoyances, by which I mean the sort of coding work that a monkey–or better yet, a tool–could do but is long and fiddly to do by hand. This isn’t something that will primarily bug your average ADF developer, but it’s a sufficiently common Java technique that it would be a useful add-on for any Java IDE, JDeveloper included. It’d be a neat project for my Copious Free Time, but for now I’m just going to throw it out there in case anyone’s interested: The automatic generation of a decorator. Even if you’re not interested in that, you might want to read this article, just to get a feel for an important design pattern.
Continue reading Design Patterns and You: The Decorator
This is the last in a series of posts about tuning business components. The complete list:
The last post was about understanding application module pooling, so I’m going to assume you understand it now. And if you understand application module pooling, you can understand the pain points from a performance perspective, and you can gain some idea of how to balance out differing concerns. Here are the pain points, in decreasing order of importance.