[hibernate-dev] ScrollableResults and 6.0

[Gunnar Morling]

> If only someone here was a expert of annotation processors maybe he
> could tell me if I'm dreaming :D

:) It's not something you could do with an AP officially as they don't see
the AST below method level.

You could do it by casting to internal implementation types of javac which
will give you the full AST down to actual leave nodes. But it's not
something I'd feel like doing as it ties you to com.sun.* APIs and won't be
portable across compilers.

The checker framework (
http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html)
helps a bit with it. But the issue remains that it cannot be used with
Eclipse's compiler.

Probably the best way to address this concern is to not use JP-QL but a
strongly typed query DSL altogether.

--Gunnar


2017-01-03 12:54 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 3 January 2017 at 11:39, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> It sounds great but I'm not sure it's possible?
> >
> >
> > WDYM specifically?
> >
> >> For example how would this handle projections? I guess it's a similar
> >> doubt as the one Gunnar shared, but while he suggests a semi-typesafe
> >> solution, I'm not sure how cool it is to give the feeling that types
> >> are being checked when they might actually blow at runtime, if the
> >> query string doesn't match expectations.
> >> Could an Annotation Processor verify the declared return types really
> >> match the HQL select?
> >
> >
> > I understand your point, but isn't it the same for createQuery( "from
> Foo",
> > Bar.class )? This also will only be detected at runtime. I.e. I don't see
> > how it's worse for the tuple approach?
>
> Yes it's the same problem: I wish we could fix that too.
>
> If only someone here was a expert of annotation processors maybe he
> could tell me if I'm dreaming :D
>