BioJava packages sequence, alignment and structure work into one framework

A framework for the formats and algorithms, not just a parser

BioJava describes itself as an open-source project dedicated to providing a Java library for processing biological data, and the README expands that into a framework for processing biological data that provides analytical and statistical routines, parsers for common file formats, reference implementations of popular algorithms, and allows the manipulation of sequences and 3D structures.

Four things in that list matter for an engineer choosing a library. The parsers for common file formats are the immediate time saver, because a format parser is unglamorous work that has to be correct and that every project ends up rewriting. The reference implementations of popular algorithms are the second, and the word reference is doing real work there: it means you can read the implementation instead of reimplementing an algorithm from a paper and hoping you matched the conventions. The analytical and statistical routines are the third, and the manipulation of sequences and 3D structures is the fourth, which is what turns a set of parsers into a framework.

The stated goal is to facilitate rapid application development for bioinformatics, and that is the audience. A lab with a Java codebase, a bioinformatics platform team, or a student who already lives in Java and needs to read a PDB file, an alignment or a sequence file has a reason to look here.

The project is not archived and the last push was on 2026-09-29. The homepage is biojava.org, and the licence is LGPL 2.1, which is a detail worth returning to later rather than now.

The module list is the feature list

BioJava is a multi-module Maven project, and the module names describe the scope better than any prose summary could.

At the centre is biojava-core, the artifact the quick installation section names, which holds the shared data model. Around it sit the domain modules. biojava-alignment covers sequence alignment, which the topic tags confirm as a focus area. biojava-structure is the structure module, and it is the one the documentation treats as the reference case. biojava-aa-prop handles amino acid properties, and biojava-modfinder is for finding sequence motifs. biojava-genome is the genomics module, biojava-ontology deals with ontologies, and biojava-protein-comparison-tool and biojava-protein-disorder address protein comparison and disorder.

Then there are the modules with a different character. biojava-survival holds the survival analysis routines, which is a specialised statistical area rather than a core bioinformatic one. biojava-ws is the web services module, the piece that talks to remote services rather than to local files. biojava-structure-gui is a graphical interface for the structure data rather than a library API, and biojava-integrationtest is the test harness that exercises the modules against each other.

The practical reading is that a consumer takes what it needs. The installation example says as much, with a comment marking that other modules are added as needed, and the module boundaries mean a project that only aligns sequences does not need the structure parser or the survival statistics on its classpath.

Getting BioJava onto a Maven classpath

The releases are published to Maven Central, and the quick installation section gives the coordinates for the core module:

    <dependencies>
      <dependency>
        <groupId>org.biojava</groupId>
        <artifactId>biojava-core</artifactId>
        <version>7.3.0</version>
      </dependency>
      <!-- other biojava modules as needed -->
    </dependencies>

The group is org.biojava and the version in the example matches the current release. Adding the alignment or structure modules is a matter of adding more dependency entries with the same group and version, which is the ordinary Maven arrangement.

Two practical notes. First, the version in the example is a fixed release, which is the right habit, and the release history shows a steady line: 7.3.0 on 2026-09-19, 7.2.5 on 2026-05-05 and 7.2.4 on 2025-12-10. Second, the CHANGELOG.md at the root of the repository is where a version jump should be checked before you take it, because a framework that spans alignment algorithms and file parsers can change behaviour in a way that matters to a published analysis.

The README also states that if you are using Maven you can add the BioJava repository by adding the XML to your project pom.xml file, which is the wording of a project that predates Maven Central hosting, while the same document also says the releases are available from Maven Central. In practice the coordinates above resolve without a custom repository declaration.

Three documentation sources, unevenly useful

The README points at three documentation resources, and it is honest about their relative quality, which saves time.

The BioJava tutorial is a separate repository and is described as a great place to get started, with the important qualifier that it is most complete for the biojava-structure module. So if you are working with protein structures, the tutorial is the best entry point. If you are working on alignment or on sequence properties, expect thinner material there.

The BioJava Cookbook contains an older and slightly outdated collection of simple examples that teach the basics of working with BioJava. The description is deliberately hedged, and it is the sort of thing that still answers a question about a core concept while leading you down a path for anything that has changed since.

Full javadocs are available at the BioJava website, at the docs/api path. For a library whose value is a large API surface of formats and algorithms, the javadocs are the reference to keep open, and the README's own advice is consistent with that: the documentation explains how to install and use BioJava and answers many of the questions you might have.

Taken together, the three sources cover different needs. Tutorial for guided learning, cookbook for quick basics, javadocs for the actual API. None of them is a substitute for the others, and the module with the best tutorial coverage is the one the documentation is most complete about.

How a release and a javadoc publish are actually done

The developer section documents the release mechanics, and the detail is useful if you want to understand how the artifacts you depend on come into existence.

Releasing to Maven Central is a two step Maven invocation under a release profile, first preparing the release and then performing it. The javadoc publication is separate: a site goal under the same profile writes the generated documentation into the target/site directory, and the contents of the apidocs subdirectory are then pushed to the biojava.github.io repository under a directory named after the version pattern, for example docs/api7.1.4, after which the docs/api path is linked to that version directory so it is served at biojava.org.

That two repository arrangement is a common pattern for a project with a stable site and a rolling API path, and it has a practical consequence for users. The API documentation at the general address tracks the latest release, so a link copied from a blog post or an issue may not describe the version you have pinned. The per-version directories are the stable reference.

The repository layout matches this arrangement. There is a pom.xml at the root with the module definitions, a development directory, the module directories themselves, and the usual governance files: CHANGELOG.md, CITATION.cff, CONTRIBUTING.md, SECURITY.md, SUPPORT.md and a KEYS file.

Questions go to a moderated list, development moved to GitHub issues

Support is arranged in two places, and the README explains the transition.

BioJava has one main mailing list, biojava-l, intended for general discussion, advice, questions, offers of help, announcements, expressions of appreciation, bug reports in release code and feature requests. The list only accepts postings from list members, and anybody can become a member. The README spells out the consequence of skipping that step: a message sent without subscribing may be caught in the moderation loop, which can cause a delay of several weeks.

The developer list used to exist and has been shut down. Development discussions now go through GitHub issues, with the instruction to search the existing issues first and submit a new one if the answer is not there. That is a reasonable arrangement for a project with a bug tracker, and it also means the search function of the issue tracker is part of the support model, which is worth remembering before opening a duplicate.

For a project at version 7.3.0 with a decade of accumulated questions, both channels are worth using in the right order: search the issues and the archives first, since most questions have been asked before.

LGPL 2.1, a citation to keep, and a steady release line

The licence is LGPL 2.1, and for a library like this that is a deliberate choice rather than an accident. A weak copyleft licence lets you use the library inside an application, including a proprietary one, while requiring that modifications to the library itself be shared. The practical implication is that a company can build a product on BioJava without publishing its own code, and the boundary sits at the library.

That is different from a permissive library, and it is different from a strong copyleft one. It also interacts with how you ship: distributing the library as a separate jar alongside your application is a materially different situation from statically linking everything into one artefact, and that is a question for your own legal review rather than for this article.

The project also asks to be cited. The README points to a PLOS Computational Biology paper, BioJava 5: A community driven open-source bioinformatics library, in volume 15 issue 2, article e1006791, with a list of authors and a DOI. The repository has a CITATION.cff file, which is the machine-readable form of the same request and the one that citation tools will read.

The release line itself is steady. Versions 7.3.0 on 2026-09-19, 7.2.5 on 2026-05-05 and 7.2.4 on 2025-12-10 show a project on a 7.x major line with regular minor releases. The last push was on 2026-09-29, ten days after the 7.3.0 tag, which suggests work continuing behind the release rather than a project that stops after tagging.

Editorial conclusion

BioJava fits a Java team that needs to read sequence, alignment and structure file formats without writing parsers, and that wants the algorithms to come with reference implementations rather than being reimplemented from papers. It is the wrong choice for a polyglot data pipeline where the format handling belongs in Python or R with the wider scientific ecosystem, and it is the wrong choice if the LGPL terms are a problem for the way you ship. Before adopting it, pick the modules you actually need rather than the whole set, read the tutorial for the module you care about, which is most complete for the structure module, and check the version you pin against the 7.3.0 release and the changelog.

Frequently asked questions

Official sources

1. biojava/biojava on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases