I'm not sure if I understood that correctly, but I'm pretty sure that if what you're looking for is to have a persistent object that can be constructed either by a default (no-argument constructor) or by one or more non-default constructors (which initialize whatever they want), that that's not only legal, but quite proper. I'm pretty sure that I've done exactly that using JDO, in fact. The only stricture is that in addition to whatever other constructors you define, you must define the no-argument (default) constructor.
To be on the safe side, I'd recommend initializing the persisted fields using their setters and getter, rather than by taking advantage of their direct internal access, but other than that, I don't think you'll have any issues.
An IDE is no substitute for an Intelligent Developer.
The big key to an ORM is to make in unobtrusive. So in Hibernate your Java objects are just that Java Objects, built the way you would build a Java object. No extending or implementing classes/interfaces to make it a "persistable" object. So what works in POJOs (Plain Old Java Object) works with Hibernate.
Yes, I know. Returning a collection from a getter method other than the one we passed using the setter, Hibernate will issue unnecessary SQL statements. So my original question is : If I used one if my flavors, any unnecessary SQL statements will be used ?
I think you are trying to second-guess Hibernate too much. What SQL is issued will be controlled by the mapping of the association or any explict fetch strategy you are have using. Trying to control it by redesigning your POJO to be a not-so-POJO is not a fool proof way of controlling the SQL Hibernate may issue because its not the POJO itself that influences this aspect of the ORM.