Actually, this would be a breaking change... In 5.7.0.CR1, one can write this kind of code:
List<Foo> result = fullTextSession.createFullTextQuery( luceneQuery ).list();
Or this:
List<Foo> result = fullTextSession.createFullTextQuery( luceneQuery, Foo.class ).list();
Or even this:
FullTextQuery<Foo> query = fullTextSession.createFullTextQuery( luceneQuery, Foo.class );
All of which will work thanks to the FullTextQuery returned by fullTextSession being a raw type. Even if there will be compiler warning. With our change, the snippets of code above will give users a compilation error due to incompatible types. Users will have to adapt their code and add explicit casts... (even in our tests, this translates into more than 90 compilation errors) To sum up the problem, we can't fix the "mutable return type" issue without breaking the API: we'd need to remove the setProjection method. So we definitely cannot make createFullTextQuery return a typed (<T>) query. But adding <Object> or <?> to the returned FullTextQuery type will break existing user code, including code compatible with 5.7.0.CR1. So the two solutions I see are: 1. Leave createFullTextQuery() as is, returning a raw FullTextQuery. 2. Add <Object> or <?> to the returned FullTextQuery type, but release a CR2 or somehow warn users. Also, maybe we should introduce other methods, beside createFullTextQuery(), to support typed queries? E.g. createTypedFullTextQuery? Then it'd be up to the user to provide the correct type, and we could add some early runtime checks to ensure setProjection/setResultTransformer are used properly. It'd be a shame to introduce new API so late in the release cycle, though, particularly considering that these APIs will have to go in HSearch 6. By the way, the current situation in ORM isn't so bright as I understood from Steve's explanations: there is currently (in ORM 5.2) no replacement for the deprecated setResultTransformer method, so anyone wanting to transform results will have to use this non-typesafe API... Sanne Grinovero WDYT? |