Are mapping xml and jpa the only ways to map java classes? I wondering if there are other methods for mapping that might be faster write from scratch and maintain. The xml file isn't bad by any means, but I'm curious if there is even something slimmer. Or perhaps more convention-based configuration options to slim down the code it takes to get hibernate up and running.

As I look at my java classes and don't see anything out of the ordinary, I always ponder the question: "Can't hibernate just map this without me saying anything?" Like perhaps telling it things that it couldn't figure out on its own, or exceptions to the rule... but basically hibernate takes a stab at everything else?

The other thing I was thinking was a slimmer dsl with more convention-based options.

I just have this idea in my head where it should be almost no lines of configuration these days to get it up and running. I think it's possible. Not for all applications mind you... but ones created in a modern-pojo way that don't have to interact with legacy databases.

Anything new recently that fits the bill?

well then lets build some auto-persistent specification ourself...

amit

Well, even JPA mappings are fairly new, and we're just getting used to them right now. But I'd throw my chips all in if you wanted to put together a little framework that does what you're saying!

Maybe I might.

I know with JPA, there were many things that annoyed me. I don't think it was worth it.

For example, class A contains a List of class B... and we actually have to say that the B's are mapped by A in the annotation... even though we know this from the code itself.

Common things like billingAddress and shippingAddress have very, very messy annotations to adjust the column names. It wasn't enough to put @Embedded/@Embaddable on them... we have to add attribute overrides for every column name. To me, this is very bloated since all I really wanted to tell JPA was, "put billing_ and shipping_ in front of all of these."

Imagine if the address had 100 columns in it? Man, that would be 200 attribute overrides.

And maybe I just don't know what the heck I'm doing ;)

I also though the mapped superclass didn't work as expected. When I put an "id" property in a DomainObject base class, I had to override the column name in every sub class. YUCK.

There is a philosophy with JPA though that stresses specifying "what needs to happen" as opposed to "what doesn't need to happen". To me, the later would have been less configuration heavy. Saying, "Don't map this" would have happened far less frequently than saying "map this" - whether that's a property, a super class, or a component class.

To me, that's JPA's failing. I realize it wasn't made with these intentions in mind... so that's why I think it can be improved.

I'd love to write a new set of annotations and have a pre-processor framework act on them to establish the mappings. I know it wouldn't work for ALL applications. It would definitely "expect" a lot of convention for it to work. Still, as long as the conventions were natural and sensible, I think people would like it.