Actually, the property is just a value of a type having a name. The property has the responsibility to hold and provide access to its value. It's definitely not the properties responsibility to know how it is being stored in a database, this is a so called 'mapping'. If you'd change the table name, you should not have to change the property, but the mapping. Another important aspect is readability.

Just to take the join definition, here it is :

    @JoinTable(
    name = "customer_order",
    joinColumns = {
        @JoinColumn(name = "customer_id", referencedColumnName = "id")
    },
    inverseJoinColumns = {
        @JoinColumn(name = "order_id", referencedColumnName = "id")
    }
    )

In rails, this would be:

    belongs_to :customer

and maybe has_many or belongs_to on customer for the inverse.

and the xml translation is pretty transparent too, under the hood it's not very different, but it's a lot simpler to write/read. It is possible to get rid of a lot of this sort of boilerplate by adopting conventions about naming etc and then specifying the exceptions where necessary. I do think these would be better moved to methods rather than being object attributes like this (which read like a translation of XML into text annotations on the object, rather than convention + code when convention isn't enough).