Refactoring to update code to make use of Java 8 features (and other..)


Hi Yoann,
because of Java license changes I have to update a closed source product to java 11.
Trying to make myself familar with netbeans10 bulk update refactoring feature I tested some of the dependencies I use in this closed source project.
There are some really cool refactoring features added to netbeans10. I learned about that from a twitter comment of James Gosling

One of the dependencies I looked at is the latest production release of hibernate search.
At one point I decided that it could be interesting to share my experience or better some results with the maintainer and created the pull request

I wasn't aware that hibernate 5.11 is not any longer in focus. Sorry for that. I completely understand your arguments. Don't worry.
You suggested to create an issue about that before creating a pull request again.
I think it could be that for hibernate-search master (6.0) there are only few changes suggested by netbeans - at least that is the result of a short test. However it is up to you to decide what you want.
Some refactorings of course make the code incompatible with java 7 so that java 8 is required.
Instead of putting everything in one pull request for easier review it would be useful to use one pull request per refactoring even if you can get rid of unwanted commits using "git reset -p HEAD^" followed by "git commit --amend" anyway.
Of course it makes more sense that all this is done by someone of the hibernate-search development himself.

Btw. I tried to do similar changes on hibernate-orm but today it looks like developing on hibernate-orm seems to be a nightmare if you are not using idea.




Yoann Rodière
April 29, 2019, 7:07 AM

Hey Carsten,

Thank you for this ticket. To answer some of your implicit questions:

  • Java 7 compatibility is not a problem, we dropped it one or two years ago (since Hibernate Search 5.7).

  • Hibernate ORM is a huge codebase with a very long history, so I very much doubt it is a good idea to try and convert its code automatically on a large scale.

Regarding the migration itself, we've made some efforts to keep the code clean with respect to JDK8 standards in Hibernate Search 6, since we were rewriting a lot of the codebase. We've set up a Sonar instance in particular, which allows us to regularly inspect and fix the following problems:

  • @Override annotations

  • Diamond operator in generics

  • Unclosed resources

  • Duplicate catch sections in try/catch blocks

From what I can see, that leaves us with the following useful automatic refactorings:

  1. Convert to lambda or method references

  2. Static imports

  3. Unnecessary boxing

  4. Unnecessary unboxing

  5. Use JDK5 for-loop

  6. Use switch over strings if possible

1 is not a great idea because we've had reports that abusing lambdas may lead to a significant increase in memory usage due to JVM metadata, so we're trying to avoid it when we can.
2 consists in usign wildcard imports, if I understand correctly, and it conflicts with our style guide.

The other refactorings could be interesting indeed. We should try to have a look at some point.



Carsten Hammer


Carsten Hammer



Suitable for new contributors


Pull Request


Feedback Requested



Fix versions

Affects versions