Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Feb 6, 2014 · 6 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Feb 6, 2014

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:

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Feb 7, 2014

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
Copy link
Collaborator Author

spring-projects-issues commented Feb 7, 2014

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
Copy link
Collaborator Author

spring-projects-issues commented Feb 9, 2014

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
Copy link
Collaborator Author

spring-projects-issues commented Apr 22, 2014

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 22, 2014

Stéphane Nicoll commented

Matt, I just replied you on the SO thread.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 22, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants