# codelibrary: algorithm and data structure implementations in five languages with public-domain code

> codelibrary collects competitive-programming algorithms and data structures across C++, Java, Kotlin, Python and Rust. The README explicitly marks several graph and string algorithms as absent, and CI badge coverage does not extend to Python or Kotlin.

**indy256/codelibrary** — :gem:Collection of algorithms and data structures

- Repository: https://github.com/indy256/codelibrary
- Stars: 2,025 · Forks: 520
- Language: Java
- License: Unlicense
- Published: 2026-10-11 · Updated: 2026-10-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/indy256-codelibrary

## Five language directories in one repository and what the project covers

codelibrary collects algorithm and data structure implementations in C++, Java, Kotlin, Python and Rust. All code is under the Unlicense, which places it in the public domain with no attribution required. The last push was on 2026-09-21, and the repository has no GitHub releases.

The repository root separates the five languages into their own directories: cpp/, java/, kotlin/, python/ and rust/. A .clang-format file at the root covers C++ style. The .github/ directory holds CI workflow definitions.

The project suits competitive programmers who need algorithms that language standard libraries do not include. For common operations like sorting and priority queues, a language's built-in collections are simpler to depend on than cloning a repository. codelibrary's value comes from advanced structures that standard libraries leave out: link/cut trees, wavelet trees, treaps with indexed keys, suffix automata and spatial indexes. The topics listed for the repository confirm the target audience: algorithm, cpp, data-structures, java and kotlin.

## Checked boxes and open contribution issues mark the project's scope

The README uses a checkbox notation to distinguish completed and missing work. Checked entries ([x]) are available; unchecked entries ([]) are not yet implemented and link to open GitHub issues inviting contributions. In graph algorithms alone, five items are unchecked: planarity testing (issue #28), dynamic graph connectivity (issue #29), Chu-Liu/Edmonds' algorithm (issue #30), minimum augmentation to strong connectivity (issue #32) and minimum augmentation to biconnectivity (issue #33). String algorithms carry two open gaps: palindrome tree (issue #34) and sorting strings in linear time (issue #31).

Each unchecked item is not an algorithm outside the project's scope. Each one links to a GitHub issue asking for a contribution, which means the maintainer considers it within scope but has not yet received or written an implementation. If you need Chu-Liu/Edmonds' algorithm or dynamic graph connectivity, issue #30 and #29 are where the maintainer would expect an implementation to land.

Verifying which boxes are checked in your required language is the right first step before deciding the library covers your needs. A data structure listed in the README may exist only in Java or only in C++, and an algorithm marked as available may have no Kotlin or Rust counterpart.

## Data structure coverage from segment trees to spatial indexes

Segment trees appear in two forms: the standard recursive variant and a version without recursion. Both are in C++ and Java; the recursive form also has a Kotlin implementation. Fenwick trees come in a standard form in C++, Java, Kotlin and Rust, and in an extended version with interval operations in C++ and Java only.

Three link/cut tree variants appear together. The general link/cut tree has C++ and Java implementations (link_cut_tree.cpp and LinkCutTree.java). Both the connectivity-query variant (LinkCutTreeConnectivity.java) and the LCA-query variant (LinkCutTreeLca.java) are Java-only, with no C++ counterpart for either. That means two of the three link/cut variants are Java-exclusive, which is easy to miss when scanning the checklist. Centroid decomposition and heavy/light decomposition both follow the standard two-language pattern.

Spatial indexes cover k-d trees for point queries in C++ and Java, k-d trees for rectangular queries in Java only, R-tree in Java, metric tree in Java and quadtree in Java. C++ has no persistent tree; the three language files are java/structures/PersistentTree.java, kotlin/PersistentTree.kt and rust/structures/persistent_tree.rs. Mo's algorithm appears as a standard Java implementation and as a version with point updates in C++ only. The sorting section includes sorting algorithms in C++ and Java alongside an N-th element implementation in Java.

Treaps come in two forms: a standard treap in C++, Java, Kotlin and Rust, and a treap with an indexed key in C++ and Java. Disjoint sets cover C++, Java and Rust. A mergeable heap exists in Java and Rust.

## Graph algorithms in six categories with five entries marked as absent

Graph algorithms cover shortest paths, maximum flow, maximum matching, spanning trees, connectivity and biconnectivity, and LCA. For shortest paths and maximum flow, the README points to subdirectories in cpp/ and java/ rather than individual files, so those categories hold multiple implementations. The LCA section contains the Schieber-Vishkin algorithm in C++ and Java as a named entry, alongside a general LCA directory in Java.

Biconnectivity appears in Java only under java/graphs/dfs/Biconnectivity.java, with no C++ counterpart listed. Spanning tree and connectivity each follow the more common pattern of having both cpp/ and java/ subdirectories.

The five unchecked entries mark genuine gaps in competitive graph coverage. Chu-Liu/Edmonds' algorithm, which finds minimum-cost arborescences in directed graphs, is absent. Dynamic graph connectivity is also missing from the library. Planarity testing determines whether a graph can be embedded in a plane without crossing edges; that too has no implementation. Minimum augmentation to strong connectivity (#32) and minimum augmentation to biconnectivity (#33) bring the count to five. All five are tracked in the project's GitHub issue list.

## Three suffix array implementations at different time complexity bounds

String algorithms are where the library provides the most variation on a single data structure. Suffix arrays appear three times. A radix sort construction, labelled O(n*log(n)) in the README, covers C++ and Java. DC3, labelled O(n), also covers both. SA-IS, the third variant and also O(n), appears in C++ only.

DC3 and SA-IS share a complexity class but differ in algorithm design and language support. A Java user looking for an O(n) suffix array construction has only DC3 as an option within this library. The README does not explain the practical differences between the two O(n) algorithms, so anyone choosing between them for a specific use case needs to consult external sources.

The rest of the string section includes Knuth-Morris-Pratt in C++ and Java, Aho-Corasick in C++ and Java, two suffix tree variants (Ukkonen's algorithm in C++ and Java, and the Breslauer-Italiano algorithm in C++ only), suffix automaton in C++ and Java, trie in Java, Z-function in C++ and Java, hashing in C++ and Java, and parsing directories in C++ and Java. Breslauer-Italiano being C++ only matches the pattern of SA-IS: more specialised algorithms with narrower language support.

The two unchecked string items are palindrome tree (issue #34) and sorting strings in linear time (issue #31), both linking to open GitHub issues.

## Cloning and copying is the only documented adoption path

The README gives no install command and no package manager entry. The top-level repository entries include gradlew, build.gradle, settings.gradle and a gradle/ folder, pointing to a Gradle project for the Java code. The README references none of those files and gives no task name to run. For C++, the .clang-format file at the root sets up formatting, but no build file or Makefile appears in the README.

Anyone who needs one algorithm clones the repository and copies that source file directly. No package exists in Maven, Gradle, Cargo or pip, so build manifests cannot reference codelibrary as a versioned dependency. Engineers who expect that level of version management will find nothing.

For running the tests, the CI workflows in .github/ are the closest the project comes to documented build steps. The Java CI, C++ CI and Rust CI workflows are all visible through the badge links in the README, so the commands they run can be found there.

## Java, C++ and Rust have CI badges; Python and Kotlin have none in the README

The README shows three CI badges: Java CI, C++ CI and Rust CI. Each links to a GitHub Actions workflow in .github/. Python and Kotlin each have their own source directories (python/ and kotlin/) in the repository and appear among the five repository topics, but neither has a CI badge in the README.

That gap in the badge set has a practical consequence: the CI safety net that is visible for Java, C++ and Rust simply does not appear for Python or Kotlin. The three language paths with badges in the README have workflows that confirm tests are run. No badge in the README confirms that for Python or Kotlin. That gap does not mean the Python or Kotlin code is incorrect, but anyone relying on those implementations cannot point to a CI badge as evidence that tests are run automatically.

Checking the .github/ workflow files is the way to find out whether tests exist for those two languages. The repository topics include kotlin alongside java, cpp and algorithm, so the maintainer treats Kotlin as a first-class target despite the missing badge.

## Conclusion

codelibrary suits engineers and students who need reference implementations of competitive-programming algorithms in C++, Java, Kotlin, Python or Rust and can work without a package manager install. Skip it when you need a versioned dependency you can declare in a build file, because the repository has no package manager entry. The Python and Kotlin implementations have no CI badge in the README, so check the .github/ workflows before depending on those. Before adopting a specific algorithm, confirm its language coverage in the README checklist and check whether the open issues (#28 through #34) affect the algorithm you need.

## FAQ

### What algorithms does codelibrary include?

The README lists data structures (segment trees, Fenwick trees, link/cut trees, treaps, k-d trees), graph algorithms (shortest paths, maximum flow, LCA), and string algorithms (Aho-Corasick, three suffix array variants, suffix automaton). Several algorithms are marked as missing with open GitHub contribution issues.

### How do I install or use codelibrary?

The README gives no install command or package manager entry. The adoption route is to clone the repository and copy the source file you need into your project.

### Which languages does codelibrary support?

The repository holds implementations in C++, Java, Kotlin, Python and Rust across separate directories. The README's CI badge set covers Java, C++ and Rust; Python and Kotlin directories exist in the repository but have no corresponding CI badge in the README.

### What graph algorithms are missing from codelibrary?

The README marks five graph algorithms as unchecked with open issues: planarity testing (#28), dynamic graph connectivity (#29), Chu-Liu/Edmonds' algorithm (#30), minimum augmentation to strong connectivity (#32) and minimum augmentation to biconnectivity (#33).

### Does codelibrary include string searching algorithms?

Yes. The string section includes Knuth-Morris-Pratt, Aho-Corasick, three variants of suffix arrays (radix sort O(n*log(n)), DC3 O(n), and SA-IS O(n)), suffix automaton, two suffix tree variants, trie, Z-function, hashing and parsing.

## Sources

- [indy256/codelibrary on GitHub](https://github.com/indy256/codelibrary)
- [Issues](https://github.com/indy256/codelibrary/issues)
- [License: Unlicense](https://github.com/indy256/codelibrary/blob/main/LICENSE)
- [README](https://github.com/indy256/codelibrary/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/indy256-codelibrary