API Misuse Correction: A Statistical Approach

Phong Minh Vu; Tam The Nguyen; Tung Thanh Nguyen

REVIEW 3 major objections 5 minor 23 references

API Misuse Correction: A Statistical Approach

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read Statistical rarity in API usage is treated as misuse and repaired automatically.

desk verdict A plausible but entirely unevaluated proposal: the five-factor misuse taxonomy is reasonable, yet without implementation or evaluation the rarity-to-misuse mapping and the 'optimal repair' claims are unsupported. read the letter →

arxiv 1908.06492 v1 pith:5JQI7DIE submitted 2019-08-18 cs.SE

Tam The Nguyen , Phong Minh Vu , Tung Thanh Nguyen This is my paper · ORCID

classification cs.SE

keywords APImisusedetectionrepairstatisticalprogramanalysistemporalorderofmethodcallsexceptionhandlingpreconditionsandpostconditionsargumentvaluescorpus-trainedcodemodels

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

This paper argues that API misuse can be detected and repaired automatically by treating correct usage as a statistical tendency in a large body of production code. It defines five usage factors for any method call—the temporal order of surrounding calls, exception handling, preconditions, postconditions, and argument values—and trains a probability model for each by counting occurrences in the corpus. A call with any factor below a low-probability threshold is labeled an API misuse, and correction becomes an optimal search for editing operations that removes all low-probability factors. If the approach holds, developers would get a single detector that both locates API errors and suggests concrete fixes, an ability the paper says existing detectors lack.

What carries the argument

The working machinery is a set of five statistical usage-factor models attached to each API method call, trained purely by occurrence counting over a large corpus of production code. Each factor has a probability: temporal order $P_\alpha$, precondition $P_\beta$, postcondition $P_\gamma$, argument value $P_\delta$, and exception handling $P_\epsilon$. The central identity is the smoothed bigram estimate $P(m_i|m)\approx(N(m_i m)+1)/(N(m)+1)$, which converts raw co-occurrence counts into a usable probability for the order factor; the other factors are assigned analogous count-based distributions. Correction is driven by a recursive optimal-search procedure that detects the low-probability factors, generates repair actions for each, applies each action, and recurses until no factor is low or a maximum edit length is reached.

What would settle it

Run the detection rule on a clean corpus of known-correct code and count how many calls have at least one usage factor below the proposed threshold; a substantial false-positive rate would show that rarity is not equivalent to misuse.

Watch

Extended reading notes

Core claim

SAM's central claim is that API misuse is a measurable deviation from statistically normal usage, not a property that must be specified by hand. For each method call $m$, the paper models five usage factors: the probability $P(m_i|m)$ that another method call $m_i$ appears immediately before $m$ in the temporal order, the probability that a parameter is null-checked before the call (precondition), the probability that the return value or object state is checked after the call (postcondition), the probability distribution of argument values, and the probability of the exception-handling context. The temporal-order estimate is $P(m_i|m)\approx(N(m_i m)+1)/(N(m)+1)$, a smoothed count ratio, and analogous count-based estimates are proposed for the other factors. Once trained, the detector flags any call with at least one factor below threshold; the repair phase searches over editing operations, up to a maximum edit length, until no factor remains below threshold. The intended result is a unified, corpus-trained approach that covers five different misuse categories in one pipeline.

Load-bearing premise

The load-bearing premise is that statistically rare usage of an API is usually a mistake: a call with a low-probability factor is treated as a misuse, so if rare usages are actually correct but unusual coding styles, or if the training corpus itself contains misuses, the detector will flag the wrong code.

Editorial extensions

If this is right

A tool built on this design could take a failing code snippet and return both a warning and an automatically edited version with the low-probability factors removed.
Because training is counting, the models can be retrained on larger or more specialized corpora, and the paper claims accuracy would improve with more production code.
The five-factor decomposition means one pipeline can address wrong call order, missing preconditions, missing postconditions, bad argument values, and exception-handling mistakes that earlier tools targeted separately.
The same counting-and-search recipe transfers, in principle, to any API or programming language where a sufficiently large corpus of high-quality code is available.

Reading between the lines

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

A natural next step the paper does not take is to condition the probability estimates on the specific API or application domain, so that rare-but-correct idioms in a niche library are not flagged as misuses.
The optimal search could be made practical by ranking repair actions according to how much they raise the lowest probability factor, rather than exploring all edits up to a fixed maximum edit length.
The five-factor claim is directly testable against a public benchmark of documented misuses: if most documented misuses do not have a low-probability factor, the rarity assumption would need revision.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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

Short version: this is a four-page proposal, not a demonstrated result. The authors propose SAM, which uses five statistical usage factors to detect API misuses and then repairs them via search. The idea is coherent and the taxonomy is well grounded in their 144-misuse analysis, but the paper provides no implementation, no evaluation, no threshold, and no proof of the search claims. The right venue for this is a workshop or a position statement, not a peer-reviewed venue.

What is good: the five factors (temporal order, preconditions, postconditions, argument values, exceptions) map naturally to the root causes in the MuBench data, and framing correction as a search over edits is a sensible direction that goes beyond detection alone. The bigram probability estimate P(mi|m) ≈ (N(mim)+1)/(N(m)+1) is standard smoothed counting, and the claim that this is easy to train is fair.

Where it falls down: the central mapping from low probability to misuse is asserted, not validated. The paper cites MuBench and a prior study of 144 real misuses, but offers no precision/recall on that benchmark or any ground-truth set. Rarity could just as easily be a domain-specific idiom. The training corpus is only described as 'high-quality production code,' so the counts themselves may contain misuses. No probability threshold is specified, which makes the detector parameter-dependent. The repair algorithm in Figure 2 is a sketch: there is no termination proof, no bound on the search space, no argument that MaxLength is enough, and no proof that GENERATE-REPAIR-ACTIONS covers the relevant edits. 'Optimal' is never defined. On novelty, the five factors overlap with JADET, Alattin, ExAssist, and the authors' own HMM work, so the only new piece is the repair search, and that is the thinnest part.

The citation pattern is fine; the self-citations are to closely related prior work and are not being used to hide a flaw. The paper reads as an honest research proposal, just a very early one.

Who is this for? Someone curating a reading list on API misuse tools might skim it for the taxonomy, but I wouldn't cite it as a result. If it came to me for peer review, I would desk reject it in its current form and invite the authors to resubmit once they have an implementation, a threshold policy, and an evaluation on MuBench. The idea is not bad; the evidence is absent.

Referee Report

3 major / 5 minor

Summary. The paper proposes SAM, a statistical approach for automatically detecting and repairing API misuses. SAM trains statistical models on a large corpus of high-quality production code for five usage factors of an API method call: temporal order, preconditions, postconditions, argument values, and exception handling. At detection time, any factor with a "sufficiently low probability" is treated as an API misuse, and the repair step is framed as an optimal search over editing operations that remove these low-probability factors. The manuscript motivates the five factors using a dataset of 144 real API misuses from MuBench and defines a bigram-style probability estimate for the temporal-order factor, but it does not describe an implementation, report experiments, or provide formal guarantees about the search procedure.

Significance. If the central assumptions were validated, this work could meaningfully address a known limitation of API-misuse detectors, namely their low accuracy and their inability to repair detected misuses. The paper appropriately draws on the public MuBench benchmark and a 144-case study to motivate the five-factor taxonomy, which is a reasonable step toward organizing the problem. However, as submitted, the manuscript is essentially a research proposal: it contains no implementation, no evaluation, no parameter settings, and no formal analysis of the search procedure. The main scientific claim that statistical rarity equates to API misuse is plausible but entirely unvalidated, and the repair claim is unsupported by any termination, completeness, or optimality argument. The paper's significance cannot be assessed on the evidence presented.

major comments (3)

[Section II (Detection)] The load-bearing claim that a usage factor with a "sufficiently low probability" constitutes an API misuse is never validated. The paper neither specifies the threshold nor reports any precision/recall evaluation against MuBench [8] or any other ground-truth dataset, despite citing a study of 144 real API misuses in Section I that could have been used to set or test the threshold. Because the trained models are the only detection criterion, the entire approach fails if the training corpus contains misuses or if rare usage is mostly domain-specific idiom rather than error; the manuscript provides no evidence against those failure modes. At minimum, the authors should report detection precision/recall on MuBench and compare with existing detectors.
[Figure 2 / Section II (Repair algorithm)] The repair procedure is described as an "optimal search", but no optimality criterion, cost function, or completeness argument is provided. The paper does not prove that the search space is finite, that GENERATE-REPAIR-ACTIONS enumerates all relevant edits, or that MaxLength is chosen appropriately; moreover, the recursion shown in line 10 discards the returned candidates without selecting the best one, so the algorithm as written cannot be expected to return an optimal corrected program. These gaps are load-bearing because automatic repair is one of the paper's two central contributions.
[Section II (Probability model)] The statistical model is underspecified. The equation P(mi|m) ≈ (N(mim)+1)/(N(m)+1) is not a standard smoothed conditional-probability estimate as written (no vocabulary-size term appears), and the paper does not explain how the probabilities of the five usage factors are combined into a single detection decision, how preconditions and postconditions are represented in the count-based models, or what concretely constitutes "high-quality production code" for training. These details are necessary for reproducibility and for assessing whether low probability can be equated with misuse.

minor comments (5)

[Section II (Temporal order definition)] In the definition of temporal order, the sentence "The method mi appears right before mi" should read "The method mi appears right before m".
[Figure 1 caption] The caption mentions FileOutputStream while the code snippet creates a FileInputStream; the caption and code should be consistent.
[Figure 2 line 10] The recursive call CORRECT-API-MISUSES(C', L+1) has no mechanism to collect or compare the returned candidates, which makes the labeling of the search as "optimal" misleading; a selection step should be shown or described.
[Section II (Training)] The paper gives no high-level description of how precondition, postcondition, argument-value, and exception factors are extracted and counted from source code, so a reader cannot tell whether the approach is implementable as described.
[References] The bibliography contains formatting inconsistencies, such as reference [10] lacking volume and page details and references [9] and [21] having identical author lists despite different titles; the reference list should be cleaned up.

Circularity Check

1 steps flagged · score 6.0 of 10

SAM's central claim is self-definitional: "API misuse" is defined as a sufficiently low-probability usage factor, so detection and repair reduce by construction to thresholding the trained statistical models.

self definitional [Section II (API misuse detection criterion; abstract states the same rule)]
"An API method call is considered a misuse if there is at least one usage factor of a method m has a sufficiently low probability (e.g. less than a threshold). Thus, the API misuse detector simply checks all probabilities of usage factors to detect API misuses."

The paper's target concept, "API misuse," is not independently defined or validated against ground truth; it is operationally defined as "a usage factor with sufficiently low probability." Therefore the claimed result "SAM can detect API misuses automatically" is equivalent by construction to "SAM can flag low-probability usage factors," which is exactly what the trained statistical models output. No external benchmark is used to break the loop: MuBench [8] is cited and a 144-misuse dataset is described, but no precision/recall or any other comparison is reported.

full rationale

The statistical n-gram estimation itself is not circular: P(mi|m) is computed from corpus counts, and the five-factor decomposition is a reasonable modeling choice. However, the central claim of the paper reduces by construction because "API misuse" is defined as a low-probability usage factor. Section II explicitly says a call is a misuse if a factor has "a sufficiently low probability" and that the detector "simply checks all probabilities." Thus the detection result is the same as the model's own threshold, making the headline contribution tautological as stated. The correction algorithm is built on this detector, so its success criterion is also defined by the model rather than by independent labels. The self-citations in the related work and references are background and not load-bearing uniqueness claims; they do not add circularity. Score 6 is appropriate because the underlying probability computation has independent content and could in principle be validated against MuBench or another ground-truth set, but the paper as written does not do so and instead defines the target outcome in terms of its own model output.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The central claim rests on three untested domain assumptions and two unspecified algorithm parameters. No independent ground-truth benchmark is used, so the paper contributes a categorization and a system sketch rather than a validated result.

free parameters (2)

probability threshold for misuse detection
The paper says a factor with a sufficiently low probability is a misuse (Section II), but no threshold value or fitting procedure is given; detection results depend on it.
maximum edit length (MaxLength)
The correction search in Figure 2 stops at MaxLength, which determines whether a repair can be found; the paper does not say how it is chosen.

assumptions (3)

domain assumption Statistical rarity in a large code corpus is a reliable signal of API misuse.
Section II: 'If a factor has a sufficiently low probability, the corresponding call is considered as an API misuse.' No ground-truth validation is provided.
domain assumption The five factors (temporal order, preconditions, postconditions, argument values, exceptions) fully characterize API misuse.
Table I classifies only 144 misuses from one dataset; the paper gives no evidence this taxonomy is exhaustive across libraries.
domain assumption The training corpus of high-quality production code is representative and free of misuses.
The abstract says models are 'trained from a large repository of high-quality production code,' but no corpus is described or checked for correctness.

how reviews work

0 comments

Cite this review

Pith. "Pith review of API Misuse Correction: A Statistical Approach." pith.science (2026). https://pith.science/paper/5JQI7DIE

@misc{pith2026190806492,
  author       = {Pith},
  title        = {Pith review of: API Misuse Correction: A Statistical Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5JQI7DIE}},
  note         = {Machine review of arXiv:1908.06492}
}

read the original abstract

Modern software development relies heavily on Application Programming Interface (API) libraries. However, there are often certain constraints on using API elements in such libraries. Failing to follow such constraints (API misuse) could lead to serious programming errors. Many approaches have been proposed to detect API misuses, but they still have low accuracy and cannot repair the detected misuses. In this paper, we propose SAM, a novel approach to detect and repair API misuses automatically. SAM uses statistical models to describe five factors involving in any API method call: related method calls, exceptions, pre-conditions, post-conditions, and values of arguments. These statistical models are trained from a large repository of high-quality production code. Then, given a piece of code, SAM verifies each of its method calls with the trained statistical models. If a factor has a sufficiently low probability, the corresponding call is considered as an API misuse. SAM performs an optimal search for editing operations to apply on the code until it has no API issue.

Figures

Figures reproduced from arXiv: 1908.06492 by the authors.

**Figure 2.** The API misuse correction algorithm Training SAM requires calculating the probability distribution of each usage factor of every API method call m. For example, the probability distribution of the temporal order factor of the method call m requires computing all probabilities P(mi |m), where the method m appears right before m. We have, P(mi |m) = P(mim) P(m) ≈ N(mim) + 1 N(m) + 1 where N(mim) is number of occurren… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 11 canonical work pages

[8]

Mubench: A benchmark for api-misuse detectors,

S. Amann, S. Nadi, H. A. Nguyen, T. N. Nguyen, and M. Mezini, “Mubench: A benchmark for api-misuse detectors,” in 2016 IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR) , May 2016, pp. 464–467

work page 2016
[1]

Revisiting prior empirical ﬁndings for mobile apps: An empirical case study on the 15 most popular open-source android apps,

M. D. Syer, M. Nagappan, A. E. Hassan, and B. Adams, “Revisiting prior empirical ﬁndings for mobile apps: An empirical case study on the 15 most popular open-source android apps,” in Proceedings of the 2013 Conference of the Center for Advanced Studies on Collaborative Research , ser. CASCON ’13. Riverton, NJ, USA: IBM Corp., 2013, pp. 283–297. [Online]. ...

work page arXiv 2013
[3]

Detecting missing method calls as violations of the majority rule,

M. Monperrus and M. Mezini, “Detecting missing method calls as violations of the majority rule,” ACM Trans. Softw. Eng. Methodol. , vol. 22, no. 1, pp. 7:1–7:25, Mar. 2013. [Online]. Available: http://doi.acm.org/10.1145/2430536.2430541

arXiv 2013
[4]

Searching the state space: A qualitative study of api protocol usability,

J. Sushine, J. D. Herbsleb, and J. Aldrich, “Searching the state space: A qualitative study of api protocol usability,” in Proceedings of the 2015 IEEE 23rd International Conference on Program Comprehension , ser. ICPC ’15. Piscataway, NJ, USA: IEEE Press, 2015, pp. 82–93. [Online]. Available: http://dl.acm.org/citation.cfm?id=2820282.2820295

work page arXiv 2015
[5]

An empirical study of cryptographic misuse in android applications,

M. Egele, D. Brumley, Y . Fratantonio, and C. Kruegel, “An empirical study of cryptographic misuse in android applications,” in Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security , ser. CCS ’13. New York, NY , USA: ACM, 2013, pp. 73–84. [Online]. Available: http://doi.acm.org/10.1145/ 2508859.2516693

arXiv 2013
[6]

”jumping through hoops

S. Nadi, S. Krger, M. Mezini, and E. Bodden, “”jumping through hoops”: Why do java developers struggle with cryptography apis?” in 2016 IEEE/ACM 38th International Conference on Software Engineer- ing (ICSE), May 2016, pp. 935–946

work page 2016
[7]

The most dangerous code in the world: Validating ssl certiﬁcates in non-browser software,

M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V . Shmatikov, “The most dangerous code in the world: Validating ssl certiﬁcates in non-browser software,” in Proceedings of the 2012 ACM Conference on Computer and Communications Security , ser. CCS ’12. New York, NY , USA: ACM, 2012, pp. 38–49. [Online]. Available: http://doi.acm.org/10.1145/23...

arXiv 2012
[9]

An empirical study of exception handling bugs and ﬁxes,

T. T. Nguyen, P. M. Vu, and T. T. Nguyen, “An empirical study of exception handling bugs and ﬁxes,” in Proceedings of the 2019 ACM Southeast Conference , ser. ACM SE ’19. New York, NY , USA: ACM, 2019, pp. 257–260. [Online]. Available: http://doi.acm.org/10.1145/3299815.3314472

arXiv 2019

Show all 23 references

[10]

A systematic evaluation of static api-misuse detectors,

S. Amann, H. A. Nguyen, S. Nadi, T. N. Nguyen, and M. Mezini, “A systematic evaluation of static api-misuse detectors,” IEEE Transactions on Software Engineering , pp. 1–1, 2018

2018
[11]

Detecting object usage anomalies,

A. Wasylkowski, A. Zeller, and C. Lindig, “Detecting object usage anomalies,” in Proceedings of the the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of Software Engineering , ser. ESEC-FSE ’07. New York, NY ...

2007
[12]

Graph-based mining of multiple object usage patterns,

T. T. Nguyen, H. A. Nguyen, N. H. Pham, J. M. Al-Kofahi, and T. N. Nguyen, “Graph-based mining of multiple object usage patterns,” in Proceedings of the the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of So...

2009
[13]

Detecting missing method calls in object-oriented software,

M. Monperrus, M. Bruch, and M. Mezini, “Detecting missing method calls in object-oriented software,” in ECOOP 2010 – Object-Oriented Programming, T. D’Hondt, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, pp. 2–25

2010
[14]

Mining temporal speciﬁcations from object usage,

A. Wasylkowski and A. Zeller, “Mining temporal speciﬁcations from object usage,” in Proceedings of the 2009 IEEE/ACM International Conference on Automated Software Engineering , ser. ASE ’09. Washington, DC, USA: IEEE Computer Society, 2009, pp. 295–306. [Online]. Available: h...

2009 doi
[15]

Pr-miner: Automatically extracting implicit programming rules and detecting violations in large software code,

Z. Li and Y . Zhou, “Pr-miner: Automatically extracting implicit programming rules and detecting violations in large software code,” in Proceedings of the 10th European Software Engineering Conference Held Jointly with 13th ACM SIGSOFT International Symposium on Foundations of...

2005
[16]

Static speciﬁcation inference using predicate mining,

M. K. Ramanathan, A. Grama, and S. Jagannathan, “Static speciﬁcation inference using predicate mining,” in Proceedings of the 28th ACM SIGPLAN Conference on Programming Language Design and Implementation, ser. PLDI ’07. New York, NY , USA: ACM, 2007, pp. 123–134. [Online]. Ava...

2007 doi
[17]

Path-sensitive infer- ence of function precedence protocols,

M. K. Ramanathan, A. Grama, and S. Jagannathan, “Path-sensitive infer- ence of function precedence protocols,” in29th International Conference on Software Engineering (ICSE’07), May 2007, pp. 240–250

2007
[18]

Mining api error-handling speciﬁcations from source code,

M. Acharya and T. Xie, “Mining api error-handling speciﬁcations from source code,” in Proceedings of the 12th International Conference on Fundamental Approaches to Software Engineering: Held As Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 20...

2009 doi
[19]

Investigating next steps in static api-misuse detection,

S. Amann, H. A. Nguyen, S. Nadi, T. N. Nguyen, and M. Mezini, “Investigating next steps in static api-misuse detection,” in Proceedings of the 16th International Conference on Mining Software Repositories , ser. MSR ’19. Piscataway, NJ, USA: IEEE Press, 2019, pp. 265–275. [Onl...

2019
[20]

Mining exception-handling rules as sequence association rules,

S. Thummalapenta and T. Xie, “Mining exception-handling rules as sequence association rules,” in Proceedings of the 31st International Conference on Software Engineering , ser. ICSE ’09. Washington, DC, USA: IEEE Computer Society, 2009, pp. 496–506. [Online]. Available: http:/...

2009
[21]

Recommending exception handling code,

T. T. Nguyen, P. M. Vu, and T. T. Nguyen, “Recommending exception handling code,” in ICSME, 2019

2019
[22]

Alattin: Mining alternative patterns for detecting neglected conditions,

S. Thummalapenta and T. Xie, “Alattin: Mining alternative patterns for detecting neglected conditions,” in 2009 IEEE/ACM International Conference on Automated Software Engineering , Nov 2009, pp. 283– 294

2009
[23]

Recommending api usages for mobile apps with hidden markov model,

T. T. Nguyen, H. V . Pham, P. M. Vu, and T. T. Nguyen, “Recommending api usages for mobile apps with hidden markov model,” in 2015 30th IEEE/ACM International Conference on Automated Software Engineer- ing (ASE), Nov 2015, pp. 795–800

2015
[24]

Mad-api: Detection, correction and explanation of api misuses in distributed android applications,

T. Luo, J. Wu, M. Yang, S. Zhao, Y . Wu, and Y . Wang, “Mad-api: Detection, correction and explanation of api misuses in distributed android applications,” in Artiﬁcial Intelligence and Mobile Services – AIMS 2018, M. Aiello, Y . Yang, Y . Zou, and L.-J. Zhang, Eds. Cham: Spri...

2018

Pith tools

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

[1] [8]

Mubench: A benchmark for api-misuse detectors,

S. Amann, S. Nadi, H. A. Nguyen, T. N. Nguyen, and M. Mezini, “Mubench: A benchmark for api-misuse detectors,” in 2016 IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR) , May 2016, pp. 464–467

work page 2016

[2] [1]

Revisiting prior empirical ﬁndings for mobile apps: An empirical case study on the 15 most popular open-source android apps,

M. D. Syer, M. Nagappan, A. E. Hassan, and B. Adams, “Revisiting prior empirical ﬁndings for mobile apps: An empirical case study on the 15 most popular open-source android apps,” in Proceedings of the 2013 Conference of the Center for Advanced Studies on Collaborative Research , ser. CASCON ’13. Riverton, NJ, USA: IBM Corp., 2013, pp. 283–297. [Online]. ...

work page arXiv 2013

[3] [3]

Detecting missing method calls as violations of the majority rule,

M. Monperrus and M. Mezini, “Detecting missing method calls as violations of the majority rule,” ACM Trans. Softw. Eng. Methodol. , vol. 22, no. 1, pp. 7:1–7:25, Mar. 2013. [Online]. Available: http://doi.acm.org/10.1145/2430536.2430541

arXiv 2013

[4] [4]

Searching the state space: A qualitative study of api protocol usability,

J. Sushine, J. D. Herbsleb, and J. Aldrich, “Searching the state space: A qualitative study of api protocol usability,” in Proceedings of the 2015 IEEE 23rd International Conference on Program Comprehension , ser. ICPC ’15. Piscataway, NJ, USA: IEEE Press, 2015, pp. 82–93. [Online]. Available: http://dl.acm.org/citation.cfm?id=2820282.2820295

work page arXiv 2015

[5] [5]

An empirical study of cryptographic misuse in android applications,

M. Egele, D. Brumley, Y . Fratantonio, and C. Kruegel, “An empirical study of cryptographic misuse in android applications,” in Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security , ser. CCS ’13. New York, NY , USA: ACM, 2013, pp. 73–84. [Online]. Available: http://doi.acm.org/10.1145/ 2508859.2516693

arXiv 2013

[6] [6]

”jumping through hoops

S. Nadi, S. Krger, M. Mezini, and E. Bodden, “”jumping through hoops”: Why do java developers struggle with cryptography apis?” in 2016 IEEE/ACM 38th International Conference on Software Engineer- ing (ICSE), May 2016, pp. 935–946

work page 2016

[7] [7]

The most dangerous code in the world: Validating ssl certiﬁcates in non-browser software,

M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V . Shmatikov, “The most dangerous code in the world: Validating ssl certiﬁcates in non-browser software,” in Proceedings of the 2012 ACM Conference on Computer and Communications Security , ser. CCS ’12. New York, NY , USA: ACM, 2012, pp. 38–49. [Online]. Available: http://doi.acm.org/10.1145/23...

arXiv 2012

[8] [9]

An empirical study of exception handling bugs and ﬁxes,

T. T. Nguyen, P. M. Vu, and T. T. Nguyen, “An empirical study of exception handling bugs and ﬁxes,” in Proceedings of the 2019 ACM Southeast Conference , ser. ACM SE ’19. New York, NY , USA: ACM, 2019, pp. 257–260. [Online]. Available: http://doi.acm.org/10.1145/3299815.3314472

arXiv 2019