HibernateTemplate's generic signatures break backwards compatibility at source level [SPR-11402]

[spring-projects-issues]

Bruce Jones opened SPR-11402 and commented

HibernateTemplate method signatures were changed in 4.0.0.Release to better support generics, however the developer involved changed them from List to List<Object>. They should have been changed to List<?> as was done for the methods that return Collection and Iterator.

Example method: org.springframework.orm.hibernate4.HibernateTemplate.findByNamedParam().
Spring 3.2.8 WAS:
public List findByNamedParam(String queryString, String paramName, Object value)
throws DataAccessException {

Spring 4.0.1 IS:
public List<Object> findByNamedParam(String queryString, String paramName, Object value)
throws DataAccessException {

This change will require all client code to be altered which is ironic considering HibernateTemplate itself is basically deprecated and really only exists to give people who use it access to all the bug fixes in 4.X (as per the javadoc). I see absolutely no reason for the new signature and if this change was intended it should have been mentioned in a migration guide?

Is it possible this can be changed before everybody switches their code to the new method signatures as most organisations normally wait 1-2 (n-1) releases until upgrading to a new version.

---

Affects: 4.0.1

Issue Links:

• Fix remaining compiler warnings and fail build if they return [SPR-11064] #15691 Fix remaining compiler warnings and fail build if they return

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

Good point - thanks for raising it. We'll try to remedy this arrangement for 4.0.2, scheduled for end of next week.

So you'd be happy for all of those signatures to declare List<?> instead? I suppose you're casting them to a specific element type then?

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Fixed all List return types to ? instead of Object, restoring backwards compatibility with existing Spring 3.2.x based code and allowing easier casts to other element types

Also declaring findByExample generically based on the given example object's type.

[spring-projects-issues]

Bruce Jones commented

Thank you, very much appreciated. Yes, the ? is so the existing approach of casting to a specific list can be maintained.

[spring-projects-issues]

Matt Raible commented

I'm still seeing a similar issue with Spring 4.0.3.

http://stackoverflow.com/questions/23210530/hibernatetemplate-has-incompatible-types-error-after-upgrading-from-spring-3-to

[spring-projects-issues]

Stéphane Nicoll commented

Matt, I just replied you on the SO thread.

[spring-projects-issues]

Bruce Jones commented

Hi Matt,

I raised the bug originally and yes there is still a small change required to code but I thought the projects I support could bear the cost of just adding the missing casts so I was satisfied with the change. Perhaps they should have been reverted to not use generics to be 100% backwards compatible.

I think the only reason I suggested the <?> as a fix was because other methods on this class had been changed to use that and I actually mistakenly thought that <?> return type would mean we wouldn't need to cast.