Java ORM Data Mapping Eclipse Plug-in Due
A new Eclipse plug-in will be released in August that looks to speed up how Java/J2EE devs can map their applications code to underlying SQL databases. See why the JSR220-ORM Project lead says that object-relational mapping technologies are the "last missing piece" for getting rid of the pain Java/J2EE devs face when building complex apps.
The latest Eclipse plug-in is a standards-based object-relational mapping design time tool, built to comply with the latest Java ORM standards (JSR 220), Robert Greene, the Eclipse JSR220-ORM Project lead told Integration Developer News. Greene is also vice president of product strategy at Versant, a commercial provider of ORM tools.
The first milestone release for JSR-220 ORM toolkit, due in early August, delivers "forward" and "meet-in-the-middle" mapping for JSR220 runtimes, Greene said. But don't think about downloading the JSR22-ORM Project plug-in on its own. To work in Eclipse, devs will also need the Eclipse Modeling Framework (EMF) and the Eclipse Data Tools Project Schema Model (DTP), Greene said. More information, and a free download of Eclipse's JSR220-ORM Project toolkit (issued under an Open Source license), go to http://www.eclipse.org/proposals/eclipse-jsr220-orm/main.html.
Feeling, Easing the Pain of Building to the DB
"If you look at the pain a developer experiences when writing an application, it's changed over the years," Greene said. "It used to be [developer] pain involved the systems infrastructure and connectivity in between different systems and business rules. But, there has been a lot of work done in these areas - look at server technology enhancements, messaging infrastructure and other areas," he said.
"The one big [pain] area that's left, which has never really been addressed, is the area of dealing with the database. Building to a database is the hardest part, and we're still [using] JDBC, something that originated in the earliest days of Java. This [ORM tooling project] is the first major shift where that part of [developer] pain is being addressed.
This 'building to a database" element of Java/J2EE appdev is so painful, in fact, Green said that he expects "ORM will become part of core Java platform over time. So, the tooling we're bringing now to Eclipse is a natural requirement to support the Java language. "
Giving Devs, DB Architects
So, just how will Eclipse's JSR-200 ORM Project plug-in help ease pain for devs and database architects? Greene explained it this way:
"We will solve a wide variety of issues that developers face when mapping complex Java models to relational tables," Greene told IDN. "For instance, when you have a project with hundreds of classes and need to figure out how they map to as many as 100 tables in a database, it's a non-trivial issue. To try to do that by hand with editing an XML file is next to impossible."
In short, JSR220-ORM Project tooling brings automation and metadata techniques to the problem of mapping Java classes to database tables. "ORM on it's own may not be thought of as an attractive technology, but by adding tooling on top, which is what we're doing [in the JSR-220 ORM Project], the process of mapping Java objects to tables literally becomes a click of the mouse. Just drag of a column onto an attribute and it's mapped."
So, do Java devs need to know XML to use these tools? Greene says not at all: "XML is just something that gets generates, and eliminates the need for developers to think about XML," Greene said. "Instead they just click on different areas of their source code and little config boxes come up and tell them to do the right thing. Behind the scenes all the XML stuff gets done for them."
The JSR-220 ORM Project tooling provides more than simply abstract mappings through XML. It brings both a dev and architect approach to the problem, because depending on the size (or culture) of a company's IT shop, these issues can fall in the lap of either the developer - or the database expert. Greene explained how the JSR-220 Project tool can accommodate both user audiences.
"A developer could be writing annotations in source code and relevant mapping options will come up in wizards. And, for the database architect, we have live 'Entity Relationships' diagrams where the architect is looking at tables in a visual form and doing that mapping using ER diagrams," which is the approach database architects are more comfortable with, Greene said.
At a high-level, JSR220-ORM Project tooling will provide visual development tools to ease round-trip engineering when using the JSR 220 (EJB 3.0 persistence) and JSR 243 (Java Data Objects) approaches to persistence. [The JSR-220 ORM Project is also extensible, to enable devs to support other persistence standards, and it can also be extended to generate artifacts for alternative ORM runtimes.]
Notably, the JSR220 ORM Project tooling could also be flexible enough to support Hibernate, Greene added. "In fact, if Hibernate supports EJB 3.0 as a standard, [JSR-220 ORM tooling] will support Hibernate out-of-the-box because it is generating metadata that will work with any EJB 3.0 runtime," Greene said. However, J2EE devs will have to make sure they don't get too customized. "But, if they have special hooks that aren't exactly in line with the spec, and want to expose those through the tooling, there are extension points. We wouldn't support that [custom work] out-of-the-box, but somebody could come along to customize and handle the extras."
And what about the JSR220-ORM Project tooling's ability to support devs who need help with both relational (SQL) and non-relational data, such as native XML? Well, noâ€¦not yet, anyway, Greene told IDN.
"Today, the tool will not support XML out of the box," Greene said. "However we are building the JSR-200 tooling in an open way, so it could be a framework. So, longer term, we believe [the JSR-220 ORM Project] can be an effective data mapping tool that would let someone in the future support input from XML, instead of a relational database. So, in a similar way, over time somebody could also easily extend [JSR-220 ORM Project] to support SDO (Service Data Objects), or even conceivably be used to customize a JAX-B binding."