Download Latest Version 4.2.0 release source code.zip (389.2 MB) Google Add to Preferred Sources
Home / 4.0.0
Name Modified Size InfoDownloads / Week
Parent folder
4.0.0 release source code.tar.gz 2026-08-19 389.1 MB
4.0.0 release source code.zip 2026-08-19 389.2 MB
README.md 2026-08-19 5.2 kB
Totals: 3 Items   778.3 MB 0

The first release built on the new publishing and binary pipeline. Every bundled ffmpeg moves from 4.4.1 to 9.0.x, five major versions, and the linux binaries are now built from source rather than taken from a publisher.

There are two breaking changes, both listed first.

Breaking

  • The 32 bit x86 packages are gone. jave-nativebin-win32 and jave-nativebin-linux32 are no longer published. ffmpeg itself stopped publishing builds for 32 bit Windows, so that binary could not be brought past 4.4.1 by any route, and 32 bit x86 Linux goes with it. Stay on 3.6.0 if you need either. 32 bit ARM is not affected and remains supported.
  • jave-nativebin-osx64, for intel macs, is deprecated. Apple ends support for intel hardware with macOS 27. It is still built, still published and still part of jave-all-deps, so nothing breaks today, but it will be removed in a later release. On apple silicon use jave-nativebin-osxm1.

ffmpeg 9.0.1 everywhere

Package ffmpeg
jave-nativebin-win64 9.0.1
jave-nativebin-win-arm64 9.0.1 — new
jave-nativebin-osx64 9.0.1 — deprecated
jave-nativebin-osxm1 9.0.x
jave-nativebin-linux64 9.0.1
jave-nativebin-linux-arm64 9.0.1
jave-nativebin-linux-arm32 9.0.1

The linux binaries are built from source now. The static builds this project always used are no longer reachable, and every remaining publisher links dynamically against glibc 2.28 or newer, which would have dropped older distributions and musl based images. Ours are compiled against musl and linked fully statically, so they carry no interpreter and no libc dependency at all and run anywhere the old ones did, and in Alpine containers besides, which the old ones could not. Each build is checked before it is accepted: that it is static, that it runs on glibc, that https and every codec the test suite uses are present, that it can transcode, and that it has not lost an encoder against the binary it replaces.

New

  • jave-nativebin-win-arm64, for windows on arm. Part of jave-all-deps, and needs no code change on your side.
  • jave-bom, a bill of materials. Import it and declare the jave artifacts without versions, so a project picking its own platform packages cannot end up with a core and a native binary from different releases (#273).
  • Encoder.getOptionAtIndex(). Reading an option was already possible, through a method called setOptionAtIndex that returns one, which is presumably why nobody found it. The old name still works and is deprecated (#180).

Fixed

Several of these broke against any modern ffmpeg, not just the bundled one, so they affected anyone pointing JAVE at their own binary:

  • setVolume killed the encoding. It was passed as -vol, which ffmpeg has removed, so the run died on Unrecognized option 'vol'. It now uses the volume filter, with the value converted from the 256 based scale, so callers change nothing (#44).
  • setVsync failed the same way. -vsync was removed in favour of -fps_mode, and the two never overlap, so the option is now chosen from what the ffmpeg in front of it actually accepts.
  • getSupportedEncodingFormats() and getSupportedDecodingFormats() returned nothing at all on ffmpeg 5 and newer, silently. They looked for a header ffmpeg renamed.
  • Concatenating sources threw a NullPointerException in any progress listener that read what it was handed, because the source information is read from a single input and sourceInfo was called with null regardless (#178).
  • AMR encoding works (#265), and animated webp (#253), both verified against the shipped binary.

Documented

  • SECURITY.md (github.com) sets out where the boundary lies between this library and the application calling it, and answers CVE-2023-48909 with the two properties that make its claim untrue: no shell is ever spawned, and paths are absolutised so they cannot be read as ffmpeg options. Both are covered by tests that fail if either stops being true.
  • Album art survives an audio conversion if you ask for the video stream and ask for it unchanged. Cover art is a video stream, so an audio only encoding drops it by definition. In Examples.md (github.com), with tests (#266).

Upgrading

If you use jave-all-deps and are not on 32 bit x86, change the version and nothing else.

:::xml
<dependency>
    <groupId>ws.schild</groupId>
    <artifactId>jave-all-deps</artifactId>
    <version>4.0.0</version>
</dependency>

If you pick platform packages yourself, consider the BOM:

:::xml
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>ws.schild</groupId>
            <artifactId>jave-bom</artifactId>
            <version>4.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Full changelog: https://github.com/a-schild/jave2/blob/master/Changelog.md

Source: README.md, updated 2026-08-19