Sorry for the late response.
I agree with you. It's always better to have a compile time error than a
runtime one. However, there are still projects out there which are
prohibited to use the native Hibernate API "just because" some architect
says it is not a good thing to do.
This is rather just an idea from me because personally I worked on this
kind of project in the past and I could've really make use of such a
I'd be interested in other opinions as well.
On Fri, Aug 18, 2017 at 5:53 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
On Fri, Aug 18, 2017 at 10:21 AM Arnold Gálovics
> Hey Steve,
> Thanks for the answer.
> I was aware of these two solutions but there are definitely projects
> which want to use DTO projections and cannot (don't) want to utilize
> neither the annotation nor the native Hibernate API.
> I think using the approach I mentioned would be beneficial, at least I
> see the potential.
> Do you think if we implement this it would violate some contract or do
> you see anything which prevents us from supporting this?
It's not a question of whether we *can* do this. Its programming...
essentially anything is possible. Its a question of whether it makes
sense. And I personally am not sure this does conceptually, although I
will for sure listen to other opinions.
At the very least however I am not even going to consider this in 5.x
And btw... you say you do not want to use the native Hibernate APIs yet
you want to use some Hibernate-specific feature beyond the spec. Assuming
the desire to not use the Hibernate APIs is to allow for that completely
pie-in-the-sky idea of provider portability adding this feature actually
introduces a unequivocally worse situation. At least when you use the
Hibernate-specific APIs you will get a compile-time error when you switch
vendors; but using this proposed feature you'd only get such a error at
runtime - and you'd still have the problem of how to solve this in the new