Towards a Knowledge Base of Common Sustainability Weaknesses in Green Software Development

Adam P. Burden; Priyavanshi Pathania; Rohit Mehra; Sanjay Podder; Vibhu Saujanya Sharma; Vikrant Kaulgud

REVIEW 4 major objections 4 minor 25 references

Towards a Knowledge Base of Common Sustainability Weaknesses in Green Software Development

T0 review · 4 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Existing software weakness catalogs cannot be re-tagged as sustainability weaknesses without per-case energy measurement, as shown by two CWE weaknesses with opposite energy impacts.

desk verdict A plausible position paper whose central empirical demonstration rests on two single-run microbenchmarks—talk about it, but don't treat the CWE-595 verdict as established. read the letter →

arxiv 2506.08812 v1 pith:YQHY46FC submitted 2025-06-10 cs.SE cs.CY

Priyavanshi Pathania , Rohit Mehra , Vibhu Saujanya Sharma , Vikrant Kaulgud , Sanjay Podder , Adam P. Burden This is my paper

classification cs.SEcs.CY

keywords sustainabilityweaknessesgreensoftwareenergyefficiencyCWEqualitystandardsknowledgebasecodeoptimizationJavameasurement

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the software industry lacks a standard knowledge base of sustainability weaknesses, and that this missing foundation blocks automated green-software tools. It proposes building such a knowledge base by examining existing weakness catalogs such as CWE, but only after empirical due diligence. To show why, it measures energy consumption for two CWE weaknesses in Java: fixing CWE-1046 (string concatenation in a loop) cut energy by 75.14%, while fixing CWE-595 (reference comparison instead of equals()) raised energy by 312.23%. The paper therefore concludes that existing weakness knowledge cannot be re-tagged as sustainability knowledge as-is, and calls for systematic, reproducible evaluation of each weakness.

What carries the argument

The central object is the sustainability weakness itself, defined as code that hurts energy consumption and can be remedied by an energy-efficient alternative. The argument runs on paired code variants: an unoptimized snippet containing the CWE weakness and an optimized snippet with the recommended fix, statically validated with SonarQube, executed a million times, with energy estimated through psutil and ESAVE. The energy impact percentage is the criterion that decides whether a weakness can be categorized as sustainability-related.

What would settle it

Run the CWE-595 paired snippets repeatedly on several AWS instance types and workloads and record energy each time; if the version using equals() does not consistently consume more energy than the version using ==, the paper's conclusion that this weakness is not sustainability-related would not hold.

Watch

Extended reading notes

Core claim

The central discovery is a caution: the sign and size of a weakness's energy impact cannot be inferred from its status in another quality dimension. Using paired unoptimized and optimized Java snippets run a million times on one AWS instance, the paper finds that the performance-oriented fix for CWE-1046 is also an energy win, with a 75.14% reduction, while the reliability-oriented fix for CWE-595 is an energy loss, with a 312.23% increase. On this basis the paper says it is safe to categorize CWE-1046 as a sustainability weakness and not safe to categorize CWE-595 that way, and uses the pair to argue that a sustainability weakness knowledge base must be built from per-weakness measurement rather than from re-tagging existing catalogs.

Load-bearing premise

The paper's classification depends on a single energy reading per code variant on one cloud instance, with no repeated runs or uncertainty estimate.

Editorial extensions

If this is right

Building a sustainability weakness knowledge base requires empirical energy evaluation of each candidate weakness rather than re-tagging entries from CWE or similar catalogs.
CWE-1046 (string concatenation in a loop) is safe to categorize as a sustainability weakness on the reported evidence, while CWE-595 (reference comparison instead of content comparison) is not.
The paired unoptimized and optimized snippet design gives a concrete template for future evaluations of other weaknesses.
Standard evaluation rules, a weakness repository with measured impacts, and ranking mechanisms are needed before automated green-software analysis tools can be built on such a knowledge base.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The measured results may not transfer across languages, virtual machines, or input sizes; a reliability fix that costs energy on this benchmark could save energy on another workload.
A certification scheme based only on energy impact could push developers away from reliability fixes, so a multi-criteria view is an open question the paper does not address.
The paired-snippet design could be scaled to the rest of the CWE catalog, but only with statistical repetition and hardware diversity to turn these demonstrations into a ranked knowledge base.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

You should know two things before reading. First, the paper is an honest, short position piece: it argues that existing weakness catalogs like CWE cannot be blindly re-tagged as sustainability weaknesses, and it illustrates the point with two microbenchmarks. Second, the entire empirical load rests on Table I, which has one execution time and one energy value per variant for each weakness. There are no repetitions, no error bars, no statistical test, and no code or data artifacts. So the central claim is plausible but not demonstrated.

What is actually new: the CWE-595 result. Using equals() instead of == on Java strings increased energy by 312% in their setup. If that holds up, it is exactly the kind of surprise that justifies the paper's main thesis. The framing of systematically building a sustainability weakness knowledge base on top of CWE is also sensible, and the authors are candid that this is early work. They list the right next steps: a reproducible evaluation framework, tagging rules, a weakness repository with measured impacts, and prioritization.

Where it goes soft. The conclusion that CWE-595 should not be a sustainability concern overreaches the data. One plausible reading is that the recommended fix has overhead in a microbenchmark, not that the weakness is irrelevant to sustainability. A correctness bug that causes extra computation downstream could still be energy-relevant in a real system. The single-run measurement could also be an artifact of JVM warm-up, string interning, or the loop structure; the paper gives no details on those. The generalization from two weaknesses to "cannot be re-tagged as is" is more rhetorical than logical—it is a cautionary example, not a demonstrated rule. The self-cited energy estimator with no independent calibration adds a small layer of uncertainty, though for a preliminary probe that is not disqualifying.

Who this is for: people working on green software, energy-aware static analysis, or refactoring tools. They will get a useful framing and a provocative data point to chase. It is not a definitive study, but it is a legitimate motivation for a systematic research program.

Recommendation: send it to peer review, but expect heavy revision or explicit "preliminary results" framing. Ask for repeated measurements, artifact release, and a more careful statement of what the CWE-595 result can and cannot support. I would not cite the empirical numbers as they stand, but I would cite the paper as related work in a green-software paper.

Would bring it to a reading group, but more to discuss methodology than to learn a result.

Referee Report

4 major / 4 minor

Summary. The paper argues that the software engineering community lacks a standardized knowledge base of sustainability weaknesses in code, and proposes that existing weakness catalogs such as CWE could serve as a starting point. To support this, the authors present two preliminary experiments, each comparing an unoptimized Java snippet containing a CWE weakness with an optimized variant. For CWE-1046 (string concatenation in a loop), the optimized code reduces energy consumption by about 75%, and the authors classify the weakness as sustainability-relevant. For CWE-595 (comparison of object references instead of contents), the optimized code using equals() consumes about 312% more energy than the unoptimized code using ==, leading the authors to classify CWE-595 as not a sustainability weakness. Based on these two cases, the paper concludes that existing weakness knowledge cannot be re-tagged as sustainability knowledge without significant due diligence, and calls for a community effort to build a sustainability weakness knowledge base.

Significance. If the central empirical claim were robust, the paper would make a useful and cautionary contribution: it would show that converting existing weakness catalogs into sustainability standards requires empirical validation, not mere relabeling. The vision of a community-driven sustainability weakness knowledge base is timely and aligns with current green-software research. The paper is also honest in calling the experiments 'early' and in listing future work such as a standard evaluation framework. However, the significance is currently limited by the thin empirical basis: two unreplicated measurements, no code artifacts, and no calibration for the energy estimator. The paper's main message is largely a position statement, and its demonstrative value depends entirely on the credibility of Table I, which the current manuscript does not establish. The claim that CWE-595 'should not be a concern' for sustainability is a specific falsifiable prediction that, if confirmed by repeated experiments, would be interesting; as presented, it is an overgeneralization from a single microbenchmark.

major comments (4)

[Section II, Table I] The classification of CWE-595 as not a sustainability weakness rests on a single unreplicated measurement of each variant. Table I reports one execution time and one energy value per variant, with no repetitions, no standard deviation or confidence interval, and no statistical test. Under these conditions, the reported 312.23% energy increase for the optimized variant could plausibly be an artifact of JVM warm-up, CPU frequency scaling, memory allocation state, or measurement order. This measurement is the only empirical support for the paper's central claim that existing weaknesses cannot be re-tagged as-is; as presented, the claim is not demonstrated. Please add repeated runs with variance reporting, a clear measurement protocol (warm-up, ordering, number of iterations), and ideally a cross-machine or cross-JVM check.
[Section II, CWE-595 paragraph] The conclusion that CWE-595 'should not be a concern while evaluating/certifying a software system for sustainability' overgeneralizes from one microbenchmark. The experiment tests one specific instantiation of the weakness (string comparison in a loop, with the particular data and loop structure chosen by the authors). It cannot establish that all instances of CWE-595 are energy-benign; the relative cost of equals() versus == depends on string contents, string length, interning, and the surrounding code. At most, the result suggests that CWE-595 requires case-by-case analysis. The sentence should be softened to match the evidence, e.g., 'this particular instance showed no energy benefit from the optimization.'
[Section II, experiment design] The manuscript does not provide enough detail to reproduce the experiments. The code snippets are not shown in the text, an appendix, or an external artifact, and the measurement setup only names psutil and ESA VE without describing how energy is attributed to the process or how the VM's baseline power is handled. The reader cannot assess whether the reported Joule values are meaningful. Please include the full source of both snippet pairs, the instrumentation code, and a description of the run environment (JDK version, JVM flags, isolation, number of iterations), or provide a link to a reproducibility artifact.
[Section II, measurement tooling] The energy estimator ESA VE is a self-cited tool (reference [19]) and the paper provides no independent calibration or validation of its accuracy on the m5.xlarge instance used here. Since the central argument depends on the relative energy values in Table I, a validation step—comparing ESA VE against a hardware power meter or a published benchmark—would substantially strengthen the evidence. Without this, the absolute and relative energy numbers are unvalidated.

minor comments (4)

[Introduction, references] References [8] and [9] are identical; the citation of CWE at [9] duplicates [8] and should be corrected.
[Introduction, grammar] There are small grammatical issues in the abstract and introduction, such as 'become' in 'engineering sustainable software systems become crucial' and the spacing in 'OW ASP'; these should be cleaned up.
[Table I] The column headers of Table I, especially 'Reference Execution Time (s)', are unclear; the header appears to mix the measured values with a label. Consider simplifying to separate 'Unoptimized' and 'Optimized' columns with clear units.
[Section II, paragraph 2] The phrase 'the weakness can appear to be reworded depending on the source' is imprecise; it should likely say 'renamed' or 'reinstantiated'. Clarify what 'reworded' means in the context of matching weaknesses across CWE, SonarQube, and ASCQM.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper's sustainability-weakness classifications are empirical measurements, not derivations from self-cited premises.

full rationale

The paper makes no first-principles derivation and introduces no fitted parameters. Its central claim — that existing weakness knowledge cannot be re-tagged as sustainability knowledge without due diligence — is supported by direct energy measurements on two CWE examples (Section II, Table I). The classification of CWE-1046 as 'True' and CWE-595 as 'False' follows from the paper's definition of a sustainability weakness as one with detrimental energy impact, applied to the measured direction and magnitude of energy difference. No equation is defined in terms of the conclusion, no fitted parameter is renamed as a prediction, and no uniqueness theorem is imported. The only self-citation is reference [19] (ESA VE), used as an energy-estimation tool; although no independent calibration is given, the measurement itself is external to the paper's definitions and is not equivalent by construction to the result. Any concern about unreplicated single-run measurements is a threat to validity, not circularity. Accordingly, no circular steps are identified.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no fitted parameters or invented entities. It rests on the reliability of its energy measurement setup, the representativeness of the two selected CWE weaknesses, and the correctness of the code snippet instantiations.

assumptions (4)

domain assumption Energy measurement via psutil and ESA VE accurately captures the energy difference between code variants at microbenchmark scale.
Section II uses these tools to estimate energy; no calibration, validation, or comparison against a physical power meter is reported.
ad hoc to paper The two selected CWE weaknesses are representative enough to support a general claim about re-tagging existing weakness catalogs.
The weaknesses were chosen from a list of frequently fixed warnings, not from a systematic or random sample of the 932 CWE entries.
domain assumption The unoptimized and optimized code snippets correctly instantiate the weaknesses and their canonical remediations.
Snippets were adapted from CWE and SonarQube and matched manually; SonarQube confirmed the weakness, but the energy comparison assumes the fix is the only meaningful change.
domain assumption A single execution batch of one million iterations yields stable and reproducible energy results.
No repetitions, no standard deviation, and no statistical test are reported in the experimental protocol in Section II.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Towards a Knowledge Base of Common Sustainability Weaknesses in Green Software Development." pith.science (2026). https://pith.science/paper/YQHY46FC

@misc{pith2026250608812,
  author       = {Pith},
  title        = {Pith review of: Towards a Knowledge Base of Common Sustainability Weaknesses in Green Software Development},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YQHY46FC}},
  note         = {Machine review of arXiv:2506.08812}
}

read the original abstract

With the climate crisis looming, engineering sustainable software systems become crucial to optimize resource utilization, minimize environmental impact, and foster a greener, more resilient digital ecosystem. For developers, getting access to automated tools that analyze code and suggest sustainabilityrelated optimizations becomes extremely important from a learning and implementation perspective. However, there is currently a dearth of such tools due to the lack of standardized knowledge, which serves as the foundation of these tools. In this paper, we motivate the need for the development of a standard knowledge base of commonly occurring sustainability weaknesses in code, and propose an initial way of doing that. Furthermore, through preliminary experiments, we demonstrate why existing knowledge regarding software weaknesses cannot be re-tagged "as is" to sustainability without significant due diligence, thereby urging further explorations in this ecologically significant domain.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

25 extracted references · 17 canonical work pages

[19]

Esave: Estimating server and virtual machine energy,

P. Pathania, R. Mehra, V . S. Sharma, V . Kaulgud, S. Podder, and A. P. Burden, “Esave: Estimating server and virtual machine energy,” inProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’22. New York, NY , USA: Association for Computing Machinery, 2023. [Online]. Available: https://doi.org/10.1145/35513...

arXiv 2023
[1]

Greenhouse gas emissions in the ict sector: trends and methodologies,

United-Nations-Environment-Programme-Copenhagen-Climate- Centre, “Greenhouse gas emissions in the ict sector: trends and methodologies,” https://c2e2.unepccc.org/wp-content/uploads/sites/3/ 2020/03/greenhouse-gas-emissions-in-the-ict-sector.pdf, Accessed - 10/05/2023

2020
[2]

The real climate and transformative impact of ict: A critique of estimates, trends, and regulations,

C. Freitag, M. Berners-Lee, K. Widdicks, B. Knowles, G. S. Blair, and A. Friday, “The real climate and transformative impact of ict: A critique of estimates, trends, and regulations,”Patterns, vol. 2, no. 9, p. 100340, 2021. [Online]. Available: https://www.sciencedirect.com/ science/article/pii/S2666389921001884

2021
[3]

Energy efficiency: A new concern for application software developers,

G. Pinto and F. Castor, “Energy efficiency: A new concern for application software developers,”Commun. ACM, vol. 60, no. 12, p. 68–75, nov 2017. [Online]. Available: https://doi.org/10.1145/3154384

doi:10.1145/3154384 2017
[4]

Towards a green quotient for software projects,

R. Mehra, V . S. Sharma, V . Kaulgud, S. Podder, and A. P. Burden, “Towards a green quotient for software projects,” in2022 IEEE/ACM 44th International Conference on Software Engineering: Software En- gineering in Practice (ICSE-SEIP), 2022, pp. 295–296

2022
[5]

Software industry awareness on green and sustainable software engineering: A state-of-the-practice survey,

L. Karita, B. C. Mour ˜ao, and I. Machado, “Software industry awareness on green and sustainable software engineering: A state-of-the-practice survey,” inProceedings of the XXXIII Brazilian Symposium on Software Engineering, ser. SBES ’19. New York, NY , USA: Association for Computing Machinery, 2019, p. 501–510. [Online]. Available: https://doi.org/10.11...

arXiv 2019
[6]

Challenges and opportunities for sustainable software,

P. Lago, “Challenges and opportunities for sustainable software,” in2015 IEEE/ACM 5th International Workshop on Product Line Approaches in Software Engineering, 2015, pp. 1–2

work page 2015
[7]

The software engineering initia- tive of dlr: Overcome the obstacles and develop sustainable software,

C. Haupt, M. Meinel, and T. Schlauch, “The software engineering initia- tive of dlr: Overcome the obstacles and develop sustainable software,” in 2018 IEEE/ACM 13th International Workshop on Software Engineering for Science (SE4Science), 2018, pp. 16–19

work page 2018

Show all 25 references

[9]

Common weakness enumeration (cwe) status update,

R. A. Martin and S. Barnum, “Common weakness enumeration (cwe) status update,”Ada Lett., vol. XXVIII, no. 1, p. 88–91, apr 2008. [Online]. Available: https://doi.org/10.1145/1387830.1387835

2008
[10]

Measuring the structural quality of software systems,

B. Curtis, R. A. Martin, and P.-E. Douziech, “Measuring the structural quality of software systems,”Computer, vol. 55, no. 3, pp. 87–90, 2022

2022
[11]

Ascqm - automated source code quality mea- sures,

O. S. D. Organization, “Ascqm - automated source code quality mea- sures,” https://www.omg.org/spec/ASCQM/, Accessed - 10/05/2023

2023
[12]

Owasp top-10 2013,

D. Wichers, “Owasp top-10 2013,”OWASP F oundation, February, vol. 12, 2013

2013
[13]

Investigating the energy impact of android smells,

A. Carette, M. A. A. Younes, G. Hecht, N. Moha, and R. Rouvoy, “Investigating the energy impact of android smells,” in2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), 2017, pp. 115–126

2017
[14]

A blessing in disguise? assessing the relationship between code smells and sustainability,

G. Catolino, “A blessing in disguise? assessing the relationship between code smells and sustainability,” in2020 IEEE International Conference on Software Maintenance and Evolution (ICSME), 2020, pp. 779–780

2020
[15]

Spongebugs: Automatically generating fix suggestions in response to static code analysis warnings,

D. Marcilio, C. A. Furia, R. Bonif ´acio, and G. Pinto, “Spongebugs: Automatically generating fix suggestions in response to static code analysis warnings,”Journal of Systems and Software, vol. 168, p. 110671, 2020. [Online]. Available: https://www.sciencedirect.com/ science/a...

2020
[16]

Sonarqube,

sonarsource.com, “Sonarqube,” https://www.sonarsource.com/products/ sonarqube/, Accessed - 17/05/2023

2023
[17]

Amazon ec2 m5 instances,

Amazon, “Amazon ec2 m5 instances,” https://aws.amazon.com/ec2/ instance-types/m5/, Accessed - 10/05/2023

2023
[18]

pypi.org, “psutil,” https://pypi.org/project/psutil/, Accessed - 10/05/2023

2023
[20]

Cwe-1046: Creation of immutable text using string con- catenation,

CWE, “Cwe-1046: Creation of immutable text using string con- catenation,” https://cwe.mitre.org/data/definitions/1046.html, Accessed - 10/05/2023

2023
[21]

Strings should not be concatenated using ’+’ in a loop,

sonarsource.com, “Strings should not be concatenated using ’+’ in a loop,” https://rules.sonarsource.com/java/type/Code%20Smell/ RSPEC-1643, Accessed - 10/05/2023

2023
[22]

Class stringbuilder,

Oracle, “Class stringbuilder,” https://docs.oracle.com/javase/8/docs/api/ java/lang/StringBuilder.html, Accessed - 10/05/2023

2023
[23]

Class stringbuffer,

Oracle, “Class stringbuffer,” https://docs.oracle.com/javase/8/docs/api/ java/lang/StringBuffer.html, Accessed - 10/05/2023

2023
[24]

Cwe-595: Comparison of object references instead of ob- ject contents,

CWE, “Cwe-595: Comparison of object references instead of ob- ject contents,” https://cwe.mitre.org/data/definitions/595.html, Accessed - 10/05/2023

2023
[25]

”==” and

sonarsource.com, “”==” and ”!=” should not be used when ”equals” is overridden,” https://rules.sonarsource.com/java/type/Bug/RSPEC-4973, Accessed - 10/05/2023

2023
[26]

Class string,

Oracle, “Class string,” https://docs.oracle.com/javase/8/docs/api/java/ lang/String.html#equals-java.lang.Object-, Accessed - 10/05/2023

2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [19]

Esave: Estimating server and virtual machine energy,

P. Pathania, R. Mehra, V . S. Sharma, V . Kaulgud, S. Podder, and A. P. Burden, “Esave: Estimating server and virtual machine energy,” inProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’22. New York, NY , USA: Association for Computing Machinery, 2023. [Online]. Available: https://doi.org/10.1145/35513...

arXiv 2023

[2] [1]

Greenhouse gas emissions in the ict sector: trends and methodologies,

United-Nations-Environment-Programme-Copenhagen-Climate- Centre, “Greenhouse gas emissions in the ict sector: trends and methodologies,” https://c2e2.unepccc.org/wp-content/uploads/sites/3/ 2020/03/greenhouse-gas-emissions-in-the-ict-sector.pdf, Accessed - 10/05/2023

2020

[3] [2]

The real climate and transformative impact of ict: A critique of estimates, trends, and regulations,

C. Freitag, M. Berners-Lee, K. Widdicks, B. Knowles, G. S. Blair, and A. Friday, “The real climate and transformative impact of ict: A critique of estimates, trends, and regulations,”Patterns, vol. 2, no. 9, p. 100340, 2021. [Online]. Available: https://www.sciencedirect.com/ science/article/pii/S2666389921001884

2021

[4] [3]

Energy efficiency: A new concern for application software developers,

G. Pinto and F. Castor, “Energy efficiency: A new concern for application software developers,”Commun. ACM, vol. 60, no. 12, p. 68–75, nov 2017. [Online]. Available: https://doi.org/10.1145/3154384

doi:10.1145/3154384 2017

[5] [4]

Towards a green quotient for software projects,

R. Mehra, V . S. Sharma, V . Kaulgud, S. Podder, and A. P. Burden, “Towards a green quotient for software projects,” in2022 IEEE/ACM 44th International Conference on Software Engineering: Software En- gineering in Practice (ICSE-SEIP), 2022, pp. 295–296

2022

[6] [5]

Software industry awareness on green and sustainable software engineering: A state-of-the-practice survey,

L. Karita, B. C. Mour ˜ao, and I. Machado, “Software industry awareness on green and sustainable software engineering: A state-of-the-practice survey,” inProceedings of the XXXIII Brazilian Symposium on Software Engineering, ser. SBES ’19. New York, NY , USA: Association for Computing Machinery, 2019, p. 501–510. [Online]. Available: https://doi.org/10.11...

arXiv 2019

[7] [6]

Challenges and opportunities for sustainable software,

P. Lago, “Challenges and opportunities for sustainable software,” in2015 IEEE/ACM 5th International Workshop on Product Line Approaches in Software Engineering, 2015, pp. 1–2

work page 2015

[8] [7]

The software engineering initia- tive of dlr: Overcome the obstacles and develop sustainable software,

C. Haupt, M. Meinel, and T. Schlauch, “The software engineering initia- tive of dlr: Overcome the obstacles and develop sustainable software,” in 2018 IEEE/ACM 13th International Workshop on Software Engineering for Science (SE4Science), 2018, pp. 16–19

work page 2018