# Preview: Potential XAM successor library

**URL:** <https://discourse.julialang.org/t/preview-potential-xam-successor-library/140079>\
**Category:** Biology, Health, and Medicine\
**Created:** [October 17, 2026, 7:28pm UTC](https://discourse.julialang.org/t/preview-potential-xam-successor-library/140079 "2026-10-17T19:28:46Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jakobnissen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobnissen/32/13477_2.png) [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)\
**Post date:** [October 17, 2026, 7:28pm UTC](https://discourse.julialang.org/t/preview-potential-xam-successor-library/140079/1 "2026-10-17T19:28:46Z")

</div>

Hello, fellow Biojulians!  
I’m in the process of making a new library for reading SAM and BAM files. This post is intended to allow you to get a sneak peek, to inform stakeholders in the existing XAM.jl. Specifically, I would like to get your input on:

1. Should this implementation replace XAM.jl with this, given it’s a complete rewrite and thus thoroughly breaking? Or, would it be better to publish this as a competing package, since it might undergo rapid evolution in its beginning?
2. Do you have any concerns about the current implementation?

You can find the work-in-progress repo here: [GitHub - jakobnissen/XAM2.jl: Experimental rewrite of XAM · GitHub](https://github.com/jakobnissen/XAM2.jl). I recommend asking an agent to summaize it for you before you dig into details.  
As of October 16th, many features are still missing, and only SAM reading and BAM reading, writing and record querying is implemented.

### Why rewrite a XAM package?

All the way back in 2020, I was mildly displeased with XAM.jl’s [many violations of the SAM spec](https://github.com/BioJulia/XAM.jl/issues/24). Since then, I tried twice to address these issues in XAM.jl. Both times I found that these issues are deeply tied to the API, and I therefore couldn’t manage to fix the issues incrementally. Both times the PRs ended up as sweeping, massively breaking change, and both times, my efforts lost steam and it never got merged.

In the six years since then, the situation has changes, as we know have significantly upgraded the Julian software stack underpinning BAM parsing:

- XAM.jl de/compresses with CodecZlib.jl; we now have the faster LibDeflate.jl.
- XAM.jl reads BGZF via CodecBGZF.jl; I have written BGZFLib.jl since then.
- CodecZlib.jl and CodecBGZF.jl is based on buffering via TranscodingStreams.jl, whereas BGZFLib buffers via the relatively new package BufferIO.jl.
- We now have string views in Base, which pair nicely with the also-new MemoryViews.jl for fast, zero copy aliases strings.
- When writing an unrelated PAF parser, I implemented BAM/SAM auxiliary data parsing via XAMAuxData.jl, and CIGAR parsing via CIGARStrings.jl

Rewriting XAM on top of this stack places it at a better position, since the abstractions in these packages are both, faster, more correct in edge cases, and generally would allow us to offload more into separate packages.

So, the main reasons for the existence of XAM2 is the much better software stack now, and the fact that adherence to the SAM specs is somehow easier with a greenfield specification-focused rewrite instead of incremental adaptations.

There is one more factor motivating me to write XAM2: For my work, I need a tool which does coverage aware subsampling. More on that tool in a future announcement. I’ve used that tool to dogfood XAM2, and found it to be very fast, and with a quite nice API so far. In tests, performance is something like 20% behind htslib (i.e. `samtools`), which I consider a reasonable performance ceiling.

In brief, compared to XAM.jl, the XAM2 rewrite is:

- Faster
- More specification compliant
- With harder-to-misuse APIs, e.g. with invariants are encoded in the type system
- Fully trimmable, mostly thanks to the new package stack.

Anyway, let me know what you think about it. This package will exist regardless, but it can co-exist with XAM.jl as an alternative high performance API, or it could be the replacement.  
I envision to register the package probably within the next 6 months or so (no promises).