Crjvm205

[AntoineMeheut]

CRJVM205 - Force the use of FetchType LAZY on collections in Entity JPA

• Team: 17%
• Analyzed language: java
• Implemented rule: search in the java code for FetchTypes for which the developer has not set LAZY in order to avoid unnecessarily loading data clusters into memory.
• Result of this rule: reduce the amount of useless data loaded into memory, to reduce the consumption of RAM and therefore of electricity.
• Unit tests: passed
• Definition of done : test in sonarqube passed with ecoCode-java-test-project and we did a merge request of the tests in ecoCode-java-test-project

Pitch : Consider using LAZY mode on your FetchType for collections in JPA type entities. This will reduce the amount of data loaded into memory. And having less data loaded into memory reduces power consumption. Any electricity not produced is good for our planet.

[AntoineMeheut]

Sorry, but we didn't see in the rules that we had to increment the number of rules in this control, it's done

[MP-Aubay]

Just for information, 3 PR on the same rule : https://github.com/green-code-initiative/ecoCode/pull/125 https://github.com/green-code-initiative/ecoCode/pull/155

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

96.4% Coverage
0.0% Duplication

[dedece35]

Hi @dirdr, please take into account remaining review notes and correct the code small raised by sonarcloud.io thank you.

[dirdr]

code review fix ok

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

93.4% Coverage
0.0% Duplication

[github-actions[bot]]

This PR has been automatically marked as stale because it has no activity for 30 days. Please add a comment if you want to keep the issue open. Thank you for your contributions!

[dirdr]

Any news ?

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

93.4% Coverage
0.0% Duplication

[dedece35]

Hi @dirdr, no, I didn't work on this PR, sorry. Once current task is over, this is my next priority ... with two others CRJVM205 JIRAs :p

[github-actions[bot]]

This PR has been automatically marked as stale because it has no activity for 30 days. Please add a comment if you want to keep the issue open. Thank you for your contributions!

[dedece35]

Hi @dirdr, sorry there is another conflict to resolve, please. and then, check DoD list here : https://github.com/green-code-initiative/ecoCode-common/blob/main/doc/starter-pack.md#definition-of-done-of-a-pr

[github-actions[bot]]

This PR has been automatically marked as stale because it has no activity for 30 days. Please add a comment if you want to keep the issue open. Thank you for your contributions!

[dedece35]

PR on java-test-project : https://github.com/green-code-initiative/ecoCode-java-test-project/pull/5

[dedece35]

to discuss in core-team :

• good argument to prove it's a "green" rule
• no native Sonarqube rule found

but I think we can't force developers not to use EAGER key word if they really need it.

do we refuse this rule or not ?

[jhertout]

Hello,

we do not force the user to not use "EAGER", it is just a code smell. He can always ignore it. The true question is, when we use JPA entities, is the "EAGER" keyword a classic use? If in 90% of the case its use is justified may be we should not raise the code smell to avoid to pollute the analysis. However, I think this rule is specific enough to not raise too much (not like a problem we had with a rule on Exceptions) and I think it is not a bad thing to throw the code smell because as I understand the rule, the usage of "EAGER" must be done in specific justified cases.

[github-actions[bot]]

This PR has been automatically marked as stale because it has no activity for 60 days. Please add a comment if you want to keep the issue open. Thank you for your contributions!