I am just starting to research into the world of Hibernate, so newbie warning for the following question. I do not have much knowledge yet, and will probably get answers to my questions sooner or later from some material that I study, but would like some feedback already at this phase.

As I understand, my objects need to be JavaBeans for Hibernate to be able to map them - right? Now, I could almost instantly think of a case where this is a problem. Let's say I have a User object. User has a password, which is stored hashed in database. My "pure" object would be like:

class User {
private hashedPassword;
public void setPassword(String pw) {
hashedPassword = hash(pw);
}

public String getHashedPassword() {
return hashedPassword;
}
}

I do not want to expose anything extra - no getter for unhashed password, no setter for hashed password. What I really want hibernate to do is to persist the object's private attributes. What would be a good way to accomplish this? This is just a simple example, but I think majority of cases will have some properties that should not be exposed through getters and setters. So should I a) mess up my business object's interface or b) use Hibernate to persist something else than my business object?

For b), one solution would be to have the internal state in a DTO and use hibernate to persist those objects. As in

class User {
UserDTO dto;

public String getHashedPassword() {
return dto.getHashedPassword();
}
}

class UserDAO {
public void store(UserDTO dto) {
//...do some Hibernate magick
}
}

This feels quite inflexible, though, and I am not sure how well it suits Hibernate's features such as automatically persisting / fetching object graphs etc.

Any wise advice?

Just use access=field and map a property with name="hashedPassword"

Wouldn't this throw a Security(or some other)Exception as the field is private?

No. Probably yes if you have a restrictive SecurityManager in effect. Just try it.

I will.

So my assumption "objects have to be JavaBeans to be persisted" was wrong....wonder where I picked that up. Thanks for clearing that up!

How does this actually work?

Accessing members of a class through the introspection API is allowed even though the members are defined with a visibility the caller would not be able to "see" without using introspection. This is true unless a security manager is set which explicitly disallows this; but the default security manager does allow it.