Pith. sign in

REVIEW 4 major objections 4 minor 13 references

Adabot: Fault-Tolerant Java Decompiler

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

Pith's one-line read The paper argues that Java decompilation can be recast as statistical machine translation, with a Transformer model rebuilding source from bytecode and tolerating corrupted bytecode better than traditional rule-based AST decompilers.

desk verdict A genuinely new application of NMT to Java decompilation, but the central fault-tolerance claim is untested because no AST-based decompiler is ever run, and the evaluation rests on a two-template synthetic corpus. read the letter →

arxiv 1908.06748 v2 pith:K2QVGRWZ submitted 2019-08-14 cs.SE cs.CL

classification cs.SEcs.CL
keywords JavadecompilerneuralmachinetranslationTransformerfaulttolerancebytecodereverseengineeringBLEUworderrorrate
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 tries to establish that a neural machine translation model, in particular the Transformer architecture, can act as a full Java decompiler: given raw bytecode as input, it outputs readable Java source code, and it keeps working when the bytecode is corrupted by noise. The authors build a parallel corpus of bytecode and source by compiling 18,420 Java 11 API method snippets fitted into two fixed templates, and report BLEU-4 of 94.50% with a word error rate of 2.65% on the redundant test set, and 92.30% and 3.48% on the purified set. They claim this makes the neural decompiler more fault-tolerant than rule-based decompilers, whose strict syntax rules fail when nonconforming bytecode is encountered. The paper also argues that word error rate is a better evaluation metric than BLEU-4 for this task because it catches substitutions that change the meaning of a method call.

What carries the argument

The mechanism is a Transformer translation model trained on aligned (bytecode, source code) pairs. The bytecode is read as a token sequence and the source code is produced token by token, with self-attention letting the model weigh which bytecode units matter for each source token. The load-bearing design choice is the training corpus: every Java API method is fitted into one of two fixed source templates, static and non-static, compiled with javac to produce the corresponding bytecode, giving 18,420 pairs. This template structure keeps the translation problem simple enough for a pure attention model to learn both the structural skeleton of keywords, braces, and operators and the lexical content of class names, method names, and identifiers.

What would settle it

Compile a set of ordinary real-world Java programs that contain loops, conditionals, nested classes, and multiple statements per method, decompile their bytecode with the same trained Transformer, and measure BLEU-4, WER, and whether the output still compiles and runs identically; if the scores fall well below the reported 90% BLEU-4 range or the decompiled programs fail to compile, the claim of a general fault-tolerant decompiler is refuted.

Watch

Extended reading notes

Core claim

The central discovery is that Transformer-based sequence-to-sequence models can map bytecode to Java source directly, without an intermediate abstract syntax tree or hand-written grammar rules, and that this mapping degrades only slowly when the input bytecode is corrupted. Under salt-and-pepper noise with unit error probability from 1% to 20%, the Transformer loses only a few BLEU points on both the redundant and purified datasets, while an attention-based NMT baseline collapses. The authors attribute this to self-attention handling the unbalanced distribution of high-redundancy structural tokens and low-frequency identifier tokens better than recurrence, and to the absence of the vanishing gradient problem on bytecode sequences of average length around 400. They further observe that space-delimited tokens beat BPE subword tokens for this closed-vocabulary task, and that plain word error rate is more sensitive than BLEU-4 to erroneous substitutions of method names and identifiers.

Load-bearing premise

The paper's strongest assumption is that the synthetic corpus built from 18,420 Java API methods squeezed into two fixed templates represents the real Java decompilation problem; if real code has varied control flow, nested classes, and arbitrary expressions, the reported quality and noise-resistance numbers may not carry over.

Editorial extensions

If this is right

  • If the claim holds, bytecode-level reverse engineering can be done without hand-crafted grammar rules, so malformed or noisy bytecode that makes AST-based tools fail can still yield readable source.
  • Transformer decompilation degrades gracefully under bytecode corruption up to 20% unit error probability, making the approach a candidate for analyzing obfuscated or partially damaged binaries.
  • The comparison suggests software-language tokenization should use space delimiters, not subword models inherited from natural language processing, when building decompilation systems.
  • Word error rate, which counts substituted, missing, and extra tokens, gives a stricter and more meaningful quality signal than BLEU-4 when a single ground-truth decompilation exists.

Reading between the lines

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

  • Because the training corpus uses only two method templates, the reported numbers likely upper-bound performance on template-style snippets; whether the approach survives real control flow, nested classes, and arbitrary expressions is untested and would require a new corpus.
  • The corruption tested is random salt-and-pepper noise; the same architecture might also absorb deliberate obfuscation patterns such as junk bytecode insertions or renamed identifiers, but the paper does not test those cases.
  • The bytecode-to-source mapping could plausibly extend to other JVM languages or Android Dalvik bytecode, since the model ingests raw token streams rather than Java-specific grammar.
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.

Referee Report

4 major / 4 minor

Summary. The paper proposes Adabot, a Java decompiler built on attention-based NMT and Transformer models, treating decompilation as a statistical machine translation task from bytecode to source code. The authors construct a parallel corpus by crawling Java 11 API methods, fitting them into two fixed source templates, and compiling them with javac. They evaluate BLEU-4 and WER on 'redundant' and 'purified' datasets, introduce salt-and-pepper noise with unit error probabilities from 1% to 20%, compare space-delimiter versus BPE tokenization, and conclude that Transformer is more robust and fault-tolerant than traditional AST-based decompilers.

Significance. If the central claim were established, the paper would be a useful early step toward using neural models for decompilation under corrupted or obfuscated bytecode. The work has some constructive elements: it explicitly frames noise robustness as a first-class evaluation criterion, proposes WER as a more sensitive metric than BLEU-4 for this task, and compares tokenization schemes. However, the significance is severely limited by three gaps: there is no comparison with any actual AST-based or rule-based decompiler, the dataset is generated from only two fixed templates, and the evaluation does not check whether the output is valid, compilable Java. The strengths are real but the load-bearing claims go beyond what the experiments can support.

major comments (4)
  1. [Abstract; Results and Analysis (Table 3)] The abstract's central claim that the model is 'more robust and fault-tolerant compared to traditional Abstract Syntax Tree (AST) based decompilers' is not tested anywhere in the paper. Table 3 and Figure 8 compare only the authors' attention-based NMT and Transformer models on the authors' synthetic corpus; no AST-based or rule-based decompiler such as CFR, Procyon, or Fernflower is run on the same bytecode under the same noise conditions. The observed robustness of Transformer therefore cannot support the comparative claim in the title and abstract. This is a load-bearing omission because the paper's main selling point is precisely this comparison.
  2. [Data Preprocessing, Figure 7] The entire corpus is generated from exactly two fixed method templates: one static and one non-static wrapper. Every snippet has the same control-flow skeleton and differs only in class name, method name, and the constant-pool content. This makes the decompilation task largely one of copying identifiers into a fixed frame, and the BLEU-4 numbers in Table 3 are inflated by constant boilerplate. The NMT 'redundant' row is illustrative: BLEU-4 27.80 with WER 65.53, and Table 2 shows the model emitting nearly identical candidates for many different references. These results do not support the conclusion that the model performs 'high-quality decompilation' of real Java code, which contains control flow, nested classes, fields, and arbitrary expressions. The future-work sentence requesting 'longer, more randomized code snippets' explicitly concedes that the evaluated regime is far from practical decompilation.
  3. [Experiment Setup] The paper never specifies how the 18,420 snippets are split into training, validation, and test sets, nor does it report the number of examples per split, random seeds, error bars, confidence intervals, or significance tests. For example, the purified-set gap between NMT and Transformer (91.50 vs 92.30 BLEU-4) is 0.8 percentage points, which cannot be distinguished from random variation without repeated runs or a significance test. Since the paper ranks architectures on the basis of such differences, this is a load-bearing methodological gap.
  4. [Evaluation Metric of Reverse Engineering] The evaluation is limited to BLEU-4 and WER, both token-overlap metrics. Neither measures whether the predicted source is syntactically valid Java, whether it compiles, or whether it preserves the behavior of the original method. For a decompiler these properties are essential: a model emitting non-compiling or semantically wrong code could still score reasonably on BLEU because of shared boilerplate. No compilation-success rate, exact-match rate, or execution-based check is reported, so the central 'decompiler' claim is not established on the paper's own terms.
minor comments (4)
  1. [Introduction of Noise, Eq. (5)] Equation (5) defines UER ≈ puN, but this is dimensionally wrong: a rate cannot equal a probability multiplied by the number of units. The expression gives the expected number of corrupted units, not a unit error rate. The plots use UEP on the x-axis, so the error does not affect the reported results, but the formula should be corrected.
  2. [Throughout] There are numerous typos and grammatical errors that should be fixed: 'Tabel' in the Table 1 caption, 'distrbution' in the introduction, 'evalauton' in the contributions list, 'concluted' in Results and Analysis, 'stabalized' in the fault-tolerance discussion, and 'interrealtions' in the introduction, among others.
  3. [Experiment Setup (purified dataset)] The purification step is described only as removing 'a large proportion of units that represent the structural information'; the exact rule for deciding which tokens are structural, the proportion removed, and the resulting token counts are not specified. This makes the purified dataset difficult to reproduce and interpret.
  4. [Fault Tolerance, Figure 8] Figure 8 omits the attention-based NMT condition on the redundant dataset. The text explains that the model is already biased on the noise-free redundant set, but the figure and its caption should state this omission explicitly so that the reader does not infer a complete comparison.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the reported numbers come from the paper's own supervised training/evaluation loop, and the unsupported AST-decompiler comparison is an evaluation gap, not a circular reduction.

full rationale

The paper does not fit a parameter to a subset of data and then rename that fit as a prediction; it trains standard NMT and Transformer models on a parallel corpus it built and evaluates them on test sets with different noise levels. The bytecode-to-source mapping is not equivalent to the template input by construction: the model must still learn to order tokens, ignore structural bytecode, and recover the template, and the poor redundant-set result for NMT (BLEU-4 27.80) shows the mapping is not trivially forced. No load-bearing argument in the paper depends on a self-citation by the present authors; all cited architectures and metrics (Transformer, BLEU, WER, BPE) are external. The abstract's comparative claim against AST-based decompilers is unsupported because no AST-based decompiler is run in Table 3 or Figure 8, and the synthetic two-template corpus limits external validity; these are correctness and evaluation-design problems, not circularity. Therefore the circularity score is 0.

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

The empirical claims rest entirely on a self-built synthetic corpus and hand-designed preprocessing, with no external benchmark or formal derivation. The generality of the central claim depends on assumptions about templates, noise, and metrics that are not validated externally.

free parameters (3)
  • Method template design = two fixed templates
    All 18,420 source snippets are generated from two templates (Figure 7), constraining the output space and inflating BLEU-4 and WER scores.
  • Purification rule
    The purified dataset removes a large proportion of structural information, leaving only identifiers; the precise rule is not specified and directly affects the reported results.
  • Unit error probability range = 0.01 to 0.20
    Salt-and-pepper noise probabilities are chosen by hand to demonstrate fault tolerance, without justification for the range or its relation to real obfuscation.
assumptions (4)
  • domain assumption Two fixed method templates (static and non-static) represent the Java decompilation task
    All snippets are generated from these templates, so the model only learns to fill class and method names into fixed skeletons; real Java programs have far more varied structure.
  • domain assumption Random salt-and-pepper bytecode corruption at 1% to 20% unit error probability models real noise and obfuscation
    Real obfuscation is structured and semantic, not random bit flips; the fault-tolerance claim depends on this equivalence.
  • domain assumption BLEU-4 and WER on the template-based corpus measure decompilation quality
    These metrics reward matching the fixed template and identifier tokens; they do not verify compilability, semantic equivalence, or functional behavior of the recovered source.
  • domain assumption The crawled Java 11 API methods are representative of real-world Java code
    Only official API method signatures compiled into templates are used, with no real or obfuscated programs, so generalization to practical decompilation is assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Adabot: Fault-Tolerant Java Decompiler." pith.science (2026). https://pith.science/paper/K2QVGRWZ

@misc{pith2026190806748,
  author       = {Pith},
  title        = {Pith review of: Adabot: Fault-Tolerant Java Decompiler},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K2QVGRWZ}},
  note         = {Machine review of arXiv:1908.06748}
}
read the original abstract

Reverse Engineering(RE) has been a fundamental task in software engineering. However, most of the traditional Java reverse engineering tools are strictly rule defined, thus are not fault-tolerant, which pose serious problem when noise and interference were introduced into the system. In this paper, we view reverse engineering as a statistical machine translation task instead of rule-based task, and propose a fault-tolerant Java decompiler based on machine translation models. Our model is based on attention-based Neural Machine Translation (NMT) and Transformer architectures. First, we measure the translation quality on both the redundant and purified datasets. Next, we evaluate the fault-tolerance(anti-noise ability) of our framework on test sets with different unit error probability (UEP). In addition, we compare the suitability of different word segmentation algorithms for decompilation task. Experimental results demonstrate that our model is more robust and fault-tolerant compared to traditional Abstract Syntax Tree (AST) based decompilers. Specifically, in terms of BLEU-4 and Word Error Rate (WER), our performance has reached 94.50% and 2.65% on the redundant test set; 92.30% and 3.48% on the purified test set.

Figures

Figures reproduced from arXiv: 1908.06748 by the authors.

Figure 1
Figure 1. Instance of a parallel bytecode, mnemonic and source code triple. Literal, Field and Method indicate the lexicon ought [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Overall workflow of Adabot information. Concretely, to learn not only the structural in￾formation consists of keywords and operators that signifi￾cantly contributes to redundancy, but also the lexical infor￾mation of identifiers that are comparitively high in entropy. Intuitively, it’s not hard for the model to grasp the overall structural information since it’s high in redundancy and ap￾pears repetitively in all th… view at source ↗
Figure 3
Figure 3. An example of BPE based word segmentation [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: Attention mechanism in NMT In conclusion, being entirely based on self-attention mechanism allows Transformer to process all the bytecode units in parallel before deciding which of those deserve more attention. Thus makes it better in handling the unbalanced distributi…
Figure 4
Figure 4. Figure 4: Visualization of attention [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 6
Figure 6. Figure 6: An example of substitution in the predicted source [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
Figure 7. Figure 7: Method template able Java source code. We arbitrarily fit the static and non￾static methods into two different templates, which is illus￾trated in [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: Performance of attention-based NMT and Transformer models on purified and redundant dataset with salt-and-pepper [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

13 extracted references · 7 canonical work pages

  1. [1]

    David, Y.; Alon, U.; and Yahav, E. 2019. Neural reverse engineering of stripped binaries. arXiv preprint arXiv:1902.09122

  2. [2]

    Gage, P. 1994. A new algorithm for data compression. The C Users Journal 12(2):23--38

  3. [3]

    Gu, X.; Zhang, H.; Zhang, D.; and Kim, S. 2016. Deep api learning. In Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering , 631--642. ACM

  4. [4]

    He, J.; Ivanov, P.; Tsankov, P.; Raychev, V.; and Vechev, M. 2018. Debin: Predicting debug information in stripped binaries. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security , 1667--1680. ACM

  5. [5]

    J., and Devanbu, P

    Hellendoorn, V. J., and Devanbu, P. 2017. Are deep neural networks the best choice for modeling source code? In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering , 763--773. ACM

  6. [6]

    Hu, X.; Li, G.; Xia, X.; Lo, D.; and Jin, Z. 2018. Deep code comment generation. In Proceedings of the 26th Conference on Program Comprehension , 200--210. ACM

  7. [7]

    Jean, S.; Cho, K.; Memisevic, R.; and Bengio, Y. 2014. On using very large target vocabulary for neural machine translation. arXiv preprint arXiv:1412.2007

  8. [8]

    Luong, M.-T.; Pham, H.; and Manning, C. D. 2015. Effective approaches to attention-based neural machine translation. arXiv preprint arXiv:1508.04025

Show all 13 references
  1. [9]

    Papineni, K.; Roukos, S.; Ward, T.; and Zhu, W.-J. 2002. Bleu: a method for automatic evaluation of machine translation. In Proceedings of the 40th annual meeting on association for computational linguistics , 311--318. Association for Computational Linguistics

  2. [10]

    Sennrich, R.; Haddow, B.; and Birch, A. 2015. Neural machine translation of rare words with subword units. arXiv preprint arXiv:1508.07909

  3. [11]

    Shannon, C. E. 1951. Prediction and entropy of printed english. Bell system technical journal 30(1):50--64

  4. [12]

    N.; Kaiser, .; and Polosukhin, I

    Vaswani, A.; Shazeer, N.; Parmar, N.; Uszkoreit, J.; Jones, L.; Gomez, A. N.; Kaiser, .; and Polosukhin, I. 2017. Attention is all you need. In Advances in neural information processing systems , 5998--6008

  5. [13]

    Yin, P., and Neubig, G. 2018. Tranx: A transition-based neural abstract syntax parser for semantic parsing and code generation. arXiv preprint arXiv:1810.02720

Pith tools

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