Prior to a few days ago, when I thought about JDBC, I thought I was thinking about a problem that has been solved. Our latest java.net article, Has JDBC Kept up with Enterprise Requirements? by Jesse Davis, has eliminated that kind of thinking for me.
It shouldn't be a surprise that, as technology advances, problems that were "solved" may eventually become new unsolved problems. But... with JDBC, I just thought the solution that had evolved into JDBC Type 4 was a kind of permanent, at least a rather enduring, solution for the problem of abstracting applications from the details of underlying databases.
Well, yes, it's true that JDBC Type 4 performs that abstraction. The problem, however, is performance and frameworks. Today, we as developers often don't directly access JDBC settings, because we often work with frameworks that apply their own implementations of JDBC. So, when it comes to performance, we face a dilemma: live with the framework's implementation of JDBC (which may not be ideally tuned for the application we're developing), or make our own custom version of the framework (and have to copy in our changes every time a new version of the framework is released). Umm.. no good choice there!
Here's how Jesse describes it:
While superior to other JDBC driver architecture types, most Type 4 drivers come with glaring limitations that make them impractical for today's Java-based enterprise application environments. Most, for instance, require changes in an application's JDBC code in order to be tuned for performance. Doing this for each unique application deployment scenario is unmanageable and impractical. When you throw an ORM (object-relational mapping) on top, if you must have a vendor-specific statement method, you'll be unable to do that casting without modifying the code of the ORM. So unless you want to be modifying, let's say, a Hibernate implementation, you need to make sure that those JDBC drivers are clean--that is, that they adhere to the standard while yet executing things in a flexible manner.
So, is there any way out of this dilemma? Well, yes. But, for it to happen, further evolution of JDBC drivers is required. Jesse Davis is a member of the JDBC Expert Group. He's been thinking about the problems with Type 4 JDBC drivers for quite a while. In Has JDBC Kept up with Enterprise Requirements? Jesse concludes by outlining the requirements that a "Type 5" JDBC driver should offer:
Unrestricted performance: Data throughput is maximized regardless of the runtime environment or data access model.
Codeless enhancement: Features and functionality can be added, configured, or tuned for any application without changing application code, regardless of runtime or data access model.
Resource efficiency: Use of application runtime CPU and memory resources is minimized and can be tuned as needed to fit specific runtime environment parameters or limits.
All-in-one deployment: A single driver JAR file that maximizes the data access simplicity for any Java environment or application.
Streamlined standard: No proprietary extensions to the JDBC specification are required for any supported data source--a "clean" spec implementation.
It's not a tiny task, this evolution of JDBC that Jesse suggests. However, as he concludes:
Such "Type 5" JDBC drivers would truly enable modern data-driven Java applications to take advantage of years of innovation in database features, data access models, and virtualization technologies--in many cases without requiring code changes.
I've been working on Joda-Money as a side project and have been investigating serialization, with a hope of improving JSR-310Small serialization: Joda-Money has two key classes - BigMoney, capable of storing information to any scale and Money, limited to the correct number of decimal places for the currency. public class BigMoney ...
Forking or splitting the workload into multiple tasks for parallel processing and joining the results together is a technique used in countless scientific, number crunching applications. Many other applications could benefit from fork-join processing but using the scientific approach may not be in their best interest. This article presents an "embarrassingly parallel" fork-join approach that works well for everyday, multi-core applications in Java SE....
Next week will be all about Java EE 6. At the ejug conference in Vienna I will start (23.02) with a "fight" against Juergen Hoeller and discuss the Spring vs. Java EE thing. We did it already last year - but now Java EE 6 is out with an API designed by SpringSource. I will also give a dedicated Java EE 6 / EJB 3.1 / CDI / REST / JPA session about Xtreme Lightweight Architectures (you could also call that "weightless" :-)). The next day (24.02), at the Jax London conference (The Perfect Storm session), I will use more the IDE and "hack" a Java EE 6 application live on stage. I will try to kill some Java patterns with Java FX as well...
Originally, I wanted to write about Magnolia-Twitter integration, but at some point I've realized such integration is so simple that there's no point writing about it. So instead, let's look how you can write custom commands for Magnolia. Anybody who seriously developed on Magnolia for while had to write a Command sooner or later. They are incredibly simple, yet very powerful. Part of it is that you can use commands just anywhere - call them from the context Menu in AdminCentral, invoke them from Groovy or BSH console, call them inside of the workflow, kick start them based on Observation and changes in repository or call them periodically via scheduler...
There are many things, mostly implementation-related, that can be blamed on Maven, but I think most people agree on the fact that the POM concept (a declarative model of your project) is a good thing. Among other things, it allows to run a new plugin often with a minimum of configuration, or no configuration at all. For instance, a few days ago I was pointed to the Clirr plugin, a tool that allows to verify whether the API of a module has changed (and eventually breaking back-compatibility). If you have a working mavenized project, it's just the matter of running...
In the Forums, larrytek asks about module versions Binary versus Trunk in the Wonderland forum: I notice there are several differences in the included modules for binary builds versus the trunk and preview3 source. My information comes from the administrators page at http://server:8080 - There are some 53 modules in the binary build vs 45 modules in the source...
In the SwingLabs forum, kleopatra posted Calendar renderers need localizable StringValues - best option?: not only calendar renderers, but right now it's hitting me in the realm of the calendar because the ui-delegate needs to update itself and any helpers working for it So it...
In the GlassFish forum, ossaert needs to Call Webservice from other WS: Hi, I cannot call another Webservice from a Webservice in GFv3. I get the following error. I cannot and will not change the code in this JAR file, since it is the SDK from Paypal. This is a major showstopper for GFv3. The tester doesn't work...
Our current Spotlight is the Mobile Desktop Grid (MDG) project: Mobile Desktop Grid (MDG) is a one-stop solution for obtaining worldwide grid resources for computational use. With the MDG solution, world wide physicists, biologists, chemists, laboratory assistants, and computer scientists are able to complete exhaustive computational jobs in a shorter period. The MDG solution aids researchers addressing global issues. Even users who do not have a lot of knowledge about grid and clustered computing can utilize cluster resources with the MDG solution. For more information about the MDG project, download the Mobile Desktop Grid User and Developer Guide.
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
