# jvarkit packs a bioinformatics toolbox into one Java jar

> jvarkit is a set of Java utilities for bioinformatics that since 2023 have been packaged into a single application, so a tool that used to run as java -jar toolname.jar now runs as java -jar jvarkit.jar toolname. It is distributed as a pre-compiled jar, a conda recipe, a Singularity container and a Docker image that also carries samtools, bcftools, bedtools and Picard.

**lindenb/jvarkit** — Java utilities for Bioinformatics

- Repository: https://github.com/lindenb/jvarkit
- Website: https://jvarkit.readthedocs.io/
- Stars: 526 · Forks: 131
- Language: Java
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/lindenb-jvarkit

## One jar, many tools, and a change that breaks scripts

jvarkit is a set of Java utilities for bioinformatics, and the packaging is the first thing to understand.

Since 2023, most tools, but not all, are packaged into one application called jvarkit.jar. Tools that were executed like java -jar toolname.jar are now executed as java -jar jvarkit.jar toolname. The documentation is not always up to date on this point, and the readme says so explicitly.

That admission matters more than a small detail usually would. A script that still says java -jar bcftools.jar now fails, and it fails in the way a Java program fails, with a stack trace rather than a helpful message. If you are adopting the tool into an existing pipeline, this is the change to search for, and the reason to read the documentation rather than trusting the examples you remember.

The project is written in Java and hosted at jvarkit.readthedocs.io. The author is Pierre Lindenbaum, and the repository topics are bioinformatics, biology, genomics, java, next-generation-sequencing, ngs and science.

The style is a collection rather than a framework. There is no plugin architecture and no configuration layer, just a set of small tools that do one file format task each, which is the shape a bioinformatics utility collection tends to take.

## Four ways to get it, and the one that is not really supported

The distribution options are listed plainly in the readme.

A pre-compiled jar is available, hosted on an uncloud.univ-nantes.fr share. A conda package created by DrYak is available through bioconda. jvarkit is also available as a Singularity container through the Galaxy Project depot, and the readme warns that GUI and Swing applications might not work there.

That last warning is a real constraint rather than boilerplate. A Swing application needs a display, and a Singularity container built for a headless pipeline environment will not have one, so the tools with a graphical interface are the ones that break. A container that silently cannot run a third of its entry points is worth knowing about before you depend on it.

The presence of the bioconda recipe and the Galaxy depot entry is a signal about who uses this. Those are the two channels that exist for people running bioinformatics pipelines in reproducible environments, so the tooling is aimed at people who want a fixed, pinned environment rather than at people who will install a build from source.

The repository also carries badges for being in conda and in nf-core, the latter being a framework for pipeline development, which suggests at least some of the tools are used inside nf-core pipelines.

## The Docker image, which is really a bioinformatics environment

The Dockerfile is more interesting than a typical build file, because what it produces is not just jvarkit.

It starts from ubuntu:22.04 and installs a Java 17 JDK, make, R and the libraries needed to build, including the compression and curl development packages and datamash. Then it fetches Picard, from a pinned release, into /opt/picard.

Then it clones jvarkit itself, checks out a pinned commit, builds it with gradle and moves it into place, and builds bedtools and htslib from source with pinned versions.

The label at the top of the file states the result plainly: the jar archive for jvarkit is located in /opt/jvarkit/dist/jvarkit.jar, and the container also includes R, datamash, bwa, samtools, htslib, bcftools, bedtools and /opt/picard/picard.jar.

So the container is a working genomics environment with jvarkit as one component, and the tags on the label are Bioinformatics, NGS, Genomics, BAM and VCF.

The versions are pinned through build arguments: a jvarkit commit hash, htslib 1.17, bedtools 2.30.0, a bwa commit, and Picard 2.27.5. Pinning by commit hash rather than by tag for the two GitHub-hosted tools is the right call for reproducibility, since those repositories move their branches.

## The build, and the DTDs generated from NCBI

The Makefile shows the development workflow, and one part of it is unusual for a Java project.

The main build target runs gradle with the jvarkit task, optionally passing a local GATK 4 jar path and a testng flag. The docker target builds the image and tags it with the same jvarkit version argument, and docker-clean removes images by the same pattern. The test targets run the suite with testng and a testng.xml from the test resources, and there is a quick-test target that runs the tests without compiling jvarkit first.

The unusual part is the schemas target, which depends on five generated bindings, and each of those is an xjc run against a schema published by someone else:

```makefile
schemas : dtd-pubmed dtd-blast dtd-insdseq dtd-gb xsd-uniprot

dtd-pubmed:
	./xjc -nv -d src/main/java -p gov.nih.nlm.ncbi.pubmed -dtd  "https://www.ncbi.nlm.nih.gov/corehtml/query/DTD/pubmed_100101.dtd"
```

So the PubMed DTD, the BLAST output DTD, the INSDSeq DTD and the GenBank DTD are fetched from NCBI and compiled into Java bindings with the xjc tool, and the UniProt XML schema is fetched from the UniProt FTP and compiled the same way.

That is a meaningful design decision. Rather than hand-maintaining parsers for a dozen bioinformatics formats, the project generates the bindings from the schemas the format owners publish, which means the parser tracks the format instead of drifting from it. The cost is a build step that needs network access, and a dependency on the remote schemas being where the Makefile expects.

## Citing the tool, and the wider research context

The repository has a CITATION.cff file and a CITATIONS.md, and it is a Java project that a research group has been maintaining for a long time.

The release tags are dated versions: v2026.04.30 from 2026-04-30, v2024.08.25 from 2024-08-25 and v2024.08.01 from 2024-08-01. The last push was on 2026-10-14, so the branch is active well past the last release, which for a tool distributed as a pre-compiled jar means the released artefact and the current source differ.

The repository layout is larger than a typical utility collection. There is a src directory for the main code, separate directories for the bcfparser and the xjc tooling, a tests directory, a doc and a docs directory for the documentation, an articles directory, a conda directory, gradle build files including a wrapper, an apptainer.def definition, and both a Makefile and a Makefile.legacy.

The presence of an articles directory and a CITATIONS.md suggests the maintainer tracks the papers that cite or relate to the tooling, which is a reasonable thing to keep for a project that has been running for years and has a scholarly audience.

The licence is a custom one that the platform cannot classify, with the file named LICENSE.txt, so that is the one to read before redistributing the jar inside a pipeline image.

## Conclusion

Adopt jvarkit if you need a self-contained set of file format utilities for genomics work and you want a single artefact to ship around rather than a toolchain to install. Do not adopt it if your pipeline is built around the standard command line tools, since the container exists largely because jvarkit alone does not replace samtools, bcftools or bedtools. Before you use it, check three things: that your invocation uses the current one-jar form, since the documentation is not always up to date on that change, which is a detail that breaks scripts silently, whether the pre-compiled jar matches your Java version, and whether you need the Singularity container or the Docker image, since the readme warns that GUI and Swing applications might not work there.

## FAQ

### How do you run a jvarkit tool?

Since 2023 most tools are packaged into one application, so a tool that used to run as java -jar toolname.jar now runs as java -jar jvarkit.jar toolname. The readme notes that the documentation is not always up to date on this point, so existing scripts may need updating.

### How can I get jvarkit?

As a pre-compiled jar hosted by the University of Nantes, as a conda package through bioconda created by DrYak, or as a Singularity container from the Galaxy Project depot. The readme warns that GUI and Swing applications might not work in the container.

### What is inside the jvarkit Docker image?

The jvarkit jar at /opt/jvarkit/dist/jvarkit.jar, plus R, datamash, bwa, samtools, htslib, bcftools, bedtools and the Picard jar at /opt/picard/picard.jar. It is based on ubuntu:22.04 with a Java 17 JDK, and the versions of each component are pinned through build arguments.

### How does jvarkit handle bioinformatics file formats?

It generates Java bindings from the schemas the format owners publish, using the xjc tool. The Makefile fetches the PubMed, BLAST output, INSDSeq and GenBank DTDs from NCBI and the UniProt XML schema from the UniProt FTP, so the parsers track the formats rather than being hand-maintained.

### How often is jvarkit released?

The tags are v2026.04.30, v2024.08.25 and v2024.08.01, with the last push on 2026-10-14, so the branch moves faster than the releases. The project is MIT unclassified by the platform, with a custom licence in LICENSE.txt, and the author is Pierre Lindenbaum.

## Sources

- [Issues](https://github.com/lindenb/jvarkit/issues)
- [lindenb/jvarkit on GitHub](https://github.com/lindenb/jvarkit)
- [Project website](https://jvarkit.readthedocs.io/)
- [README](https://github.com/lindenb/jvarkit/blob/master/README.md)
- [Releases](https://github.com/lindenb/jvarkit/releases)

---

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