| 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:
- Convert to lambda or method references
- Static imports
- Unnecessary boxing
- Unnecessary unboxing
- Use JDK5 for-loop
- 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. |
