Spring Tools Suite requires throwing exceptions on older versions

Viewed 39

I'm not sure this question properly fits StackOverflow, so be free to flag it to be moved to the appropriate site.

Some people in my team use STS version 3.8 or 3.9. This has been since the start of our projects some years ago. A team member preferred Linux over Windows, so he installed STS on his own instead of using the pre-configured one because it threw random issues. He went to STS version 4. Fast-forward a couple years and new projects and members have decided to go with STS 4 and/or Vscode, while others stuck to STS 3, as "it worked just fine".

Recently though, handling JSONs, the STS 3 users NEED to throw some Runtime exceptions, but the code with those throws did not compile on the server and are detected by our Sonar analysis. The error is about unnecessary throws. Someone with STS 4 went and fixed the code by removing these throws (The IDE being totally ok with that), pushed to git and now the server compiled the code, but the coworkers with STS 3 couldn't run the app due "missing throws".

I investigated this by installing both version of the IDE, using the same JDK and the same projects in my git folder. Right away I found that while reading the same file at the same time, STS 3 required the throws but STS 4 didn't (Image related).

enter image description here

We are already updating people to STS 4 or Vscode , but I want to know why this is happening. I went as far as setting to 'Ignore' every option in Windows -> Preferences -> Java -> Compiler -> Errors/Warnings on STS 3, but it threw the same error, meaning that whatever it is, is not using the JDK we set as default.

The question is why this happens? What is Eclipse using to make the analysis? Can we change that behavior at all? I thought that this was handled by the JDK/JRE set as default, but this clearly show it isn't.

Other information: We use Oracle's JDK 1.8 on Windows and RedHat's OpenJdk 1.8 on Linux (There is a plea to use the same JDK going on. I'm advocating to move to Java 11 or even 17 if possible, but no resolutions yet). This issue is consistent in all Windows machines (We never really tried to get STS 3 running on Linux).

0 Answers
Related