Scream9371/hamnet-datasets

HAM-Net datasets

This repository provides the processed code datasets used in the HAM-Net experiments for cross-project software defect prediction.

Each JSONL record represents one source-code file or Java class containing multiple functions.

For datasets organized by file or class, HAM-Net treats the file/class as a bag and its functions as instances, following the multiple-instance learning (MIL) setting. Each record includes a binary defect label, a project identifier, and the extracted function-level code and AST information.

Record format

A simplified MIL record looks like:

{
  "id": "stable-sample-id",
  "project": "pandas",
  "file_path": "pandas/core/example.py",
  "label": 1,
  "functions": [
    {
      "name": "example_function",
      "code": "def example_function(...): ...",
      "func_label": 1,
      "ast_nodes": ["DECLARATION", "PARAMETER", "CONTROL", "RETURN"],
      "ast_edges": [[0, 1], [0, 2], [2, 3]]
    }
  ]
}

func_label is present only when it can be derived from patch or line-level annotations. It is not available for PROMISE.

Reproducibility release

The repository contains the dataset revision used by the HAM-Net paper's fixed CPDP experiments. The main branch and the immutable v1.0.0 tag contain the same four JSONL files and matching split files. To pin the paper revision:

hf download Scream9371/hamnet-datasets promise_java.jsonl --revision v1.0.0

Reproducibility contract

v1.0.0 is pinned to the four JSONL files at repository root and the fixed CPDP files under splits/cpdp/. The JSONL files preserve the bag identity and order used by the original local HAM-Net experiments, while each bag contains the complete parseable function list. Source text retains comments and AST graphs are not truncated at 800 nodes.

The paper experiments use the complete function bags. No deterministic training-time caps are provided or used by this release.

The BugsInPy CPDP split intentionally contains the 2,416 bags used by the original HAM-Net experiment repository.

Original data sources

The published JSONL files are derived from the following public datasets. Some original datasets provide labels for functions, classes, files, or code lines. During preprocessing, HAM-Net converts several of them into a common file/class-level MIL format. The table distinguishes the original annotation level from the released HAM-Net representation.

Dataset	Original source	Original annotations / content	HAM-Net representation
promise_java	PROMISE repository	Classic Java class-level defect metric datasets with a bug count/label	Each Java class forms one MIL bag. The bag is positive when bug > 0.
bigvul_c	MSR 2020 Big-Vul dataset	Large-scale C/C++ vulnerability records containing code changes and CVE-related metadata	Each C/C++ file forms one MIL bag. Functions overlapping buggy-side changed lines are marked as positive.
defactors_python	Defactors	Line-level defect annotations from multiple Python projects	Each Python file forms one MIL bag. Functions overlapping annotated defect lines receive func_label=1.
bugsinpy_python	BugsInPy	Reproducible defects, buggy/fixed commits, and patch information from Python projects	Each Python file forms one MIL bag. Bags are constructed from buggy files and same-project negative files.

PROMISE, Big-Vul, Defactors, and BugsInPy are converted into class-level or file-level bags for multiple-instance learning. The dataset sources provide the original labels or patch/line annotations; the exact sampling, parsing, AST normalization, and bag construction rules are described below.

Dataset summary

Percentages are computed from the final JSONL files. P50/P90/P99 are the numbers of functions per bag. mixed positive bags means positive bags containing both at least one func_label=1 function and at least one func_label=0 function. positive functions is computed only for datasets that retain function-level labels.

Dataset	Language / granularity	Bags or samples	Positive / negative	Functions per bag P50 / P90 / P99	Mixed positive bags	Positive functions
promise_java	Java class-level MIL bag	1,695 bags	647 / 1,048 (38.17% / 61.83%)	8 / 26 / 94.12	N/A: no function-level labels	N/A
defactors_python	Python file-level MIL bag	1,700 bags	873 / 827 (51.35% / 48.65%)	18 / 86 / 227.06	808 / 873 (92.55%)	3,190 / 58,028 (5.50%)
bugsinpy_python	Python file-level MIL bag	2,416 bags	525 / 1,891 (21.73% / 78.27%)	9 / 79 / 205	507 / 525 (96.57%)	1,080 / 63,937 (1.69%)
bigvul_c	C/C++ file-level MIL bag	1,700 bags	733 / 967 (43.12% / 56.88%)	16 / 64 / 279.01	733 / 733 (100.00%)	1,270 / 51,668 (2.46%)

promise_java uses bug > 0 as its class/bag label and therefore does not claim function-level defect localization ground truth.

How the MIL bags are constructed

The following rules define the published MIL samples.

PROMISE

• Unit of sampling: one target Java class is one bag; methods and constructors in that class are the bag instances.
• Source candidates: scan the available project/version CSV records and resolve each class name to its corresponding Java source file. Records without a source file, unparsable source, or fewer than three parseable methods/constructors are removed.
• Projects: ant, camel, ivy, jedit, log4j, lucene, poi, velocity, and xalan.
• Label: label=1 when the source bug value is greater than zero; otherwise label=0.
• Function sampling: retain all parseable methods and constructors in the selected class. No positive/negative function sampling is performed.

Defactors

• Unit of sampling: one Python source file is one bag and every parseable function in that file is an instance.
• Projects: pandas, scikit-learn, localstack, django, poetry, core, airflow, lightning, spaCy, ansible, ray, celery, sentry, cpython, and transformers.
• Function and bag labels: a function is positive when its span overlaps an annotated defect line; a bag is positive when it contains at least one positive function.
• Negative bags: sample files from the same project whose functions do not overlap the annotated defect lines; prefer the same commit and same module when available, then use other commits from the same project, with duplicate project/commit/file records removed.
• Function sampling: discard bags with fewer than three parseable functions during the original candidate construction.

BugsInPy

• Unit of sampling: one Python file at a buggy commit is one bag; each parseable function in the file is an instance.
• Projects: pandas, keras, youtube-dl, scrapy, luigi, thefuck, matplotlib, black, ansible, fastapi, tornado, tqdm, spacy, sanic, httpie, cookiecutter, and PySnooper.
• Positive candidates: use the buggy-side files touched by each BugsInPy patch. A function is positive when its span overlaps a buggy-side patch line, and the bag is positive when at least one such function exists.
• Negative candidates: for each bug, sample one same-project Python file from the same buggy snapshot that is not among the patched files. Half of the negative sampling quota targets files in the same directory or top-level module when such candidates exist; remaining candidates are sampled from the other files.
• Function sampling: use seed 42, discard files with no parseable function, and retain the complete parseable function list. This release also excludes bags that contain no function definition: older construction artifacts represented them as a single <file> placeholder, which is not a valid MIL instance.

Big-Vul

• Unit of sampling: one C/C++ file at the buggy snapshot is one bag; each parseable function is an instance.
• Projects: linux, ImageMagick, Android, tcpdump, FFmpeg, php-src, and radare2.
• Positive candidates: use the buggy-side files associated with the vulnerability patch. A function is positive when it overlaps a removed/changed buggy-side patch line; the file is a positive bag when at least one function is positive.
• Negative candidates: for each positive file, sample two unmodified same-project files from the same snapshot. Half of the negative quota targets the same directory or top-level module when possible; the remainder is sampled from other files. Sampling uses seed 42, with project and global sample limits applied before writing the final set.
• Function sampling: discard files with fewer than three parseable functions and retain all remaining functions in the full-function version.

AST normalization rules

• To make ASTs from Java, Python, C, and C++ comparable, language-specific node types are mapped to a shared set of structural roles, such as declarations, control-flow statements, calls, assignments, returns, and literals.
• This normalization preserves coarse syntactic structure while removing language-specific lexical details. Identifiers, punctuation, comments, and documentation text are not retained as structural AST nodes. The normalized graph contains parent-child structure, reverse edges, and self-loops.

Files

• promise_java.jsonl
• defactors_python.jsonl
• bugsinpy_python.jsonl
• bigvul_c.jsonl
• splits/cpdp/: fixed project-disjoint splits used by the paper