2026 Goals & Roadmap for JAM (Patreon)

Since the bugfixes situation for the latest public release seems to have stabilized, it’s time to start talking about the new version! As we step into 2026, I want to take a moment to share what I’m planning to work on next.

This project has grown far beyond what I originally imagined, and that’s entirely thanks to your continued support ❤ Without you, none of what follows would be realistically possible.

So, let’s talk about the big goals for JAM in 2026.

1) Migration from Apache HttpClient to OkHttpOne of the most important internal changes will be moving away from Apache HttpClient library and fully adopting OkHttp.

OkHttp is the networking library used by modern Android applications as well, actively maintained and updated to the latest standards. It is highly optimized for handling multiple concurrent requests, which makes it especially well-suited for a downloader. It also provides built-in support for using third-party DNS providers (such as Google and Cloudflare) without requiring any system-level configuration, along with more modern and robust handling of slow connections and network errors. It’s significantly faster, more efficient with resources, and handles modern web protocols (like HTTP/2) much more gracefully.

This will bring several major advantages for you:

Better performance and lower overhead

More modern and actively maintained networking stack

Improved handling of HTTPS, redirects, cookies, and edge cases

Support for custom DNS

Greater flexibility when dealing with “problematic” servers and unusual responses

In short: fewer random issues, better stability, more efficient with resources, and a much stronger foundation for future features!

2) Full modularization: JAM as a plugin-based platform!Another huge milestone will be restructuring JAM into a true plugin-based system.One of the features I have always wanted to implement in JAM is turning it into a downloader similar to the famous jDownloader, where each supported website has its own external module instead of being hard-coded directly into the main program.Until now, the main issue was that achieving this would have required not only rewriting the entire core of the application, but also rewriting all the site modules from scratch, one for each supported website. With JAM now supporting over 50 websites, this was a task I never really had the time to take on.This time, however, I committed to it during the Christmas holidays and finally rewrote the core to support this functionality. I’ve also started rewriting the first modules and verifying that everything works as expected. For now, only about ten sites have been migrated, but little by little I’ll move them all over 💪

What this means in practice for you:

Website support will live in separate plugins

New sites can be added or updated without releasing a full JAM update, so I can add or update support for specific websites without touching the core program

Fixing a broken site will no longer take months waiting for a full release!

Instant fixes for broken sites and more frequent updates for them

I can work on deep core improvements without blocking website updates (and vice versa)

This change will make JAM far more flexible, faster to update, and much easier to maintain long-term. It’s a big architectural step, but one that will massively pay off 💪

3) Python integration with real web browser automation (like Selenium & co.)I plan to introduce Python support to JAM in order to leverage real browser automation through tools like Selenium and derivates.

I’ve already tested this feature with websites that were previously impossible to support, such as Mangafire, Kagane, and Mangalib, and they all passed the test successfully!

Why this is such a game changer:

JAM will be able to use a real web browser, not a simulated one!

Cloudflare defenses will cease to be a barrier. By leveraging a legitimate web browser instance, we trigger fewer red flags. Plus, in extreme cases, this will allow you to interact with the page directly to clear any blocks/captcha whenever necessary.

JavaScript-heavy websites are no longer a problem and they will not require anymore the use of a JS engine like GraalVM or convert the JS code in Java

Image scrambling protections and dynamic loading can be handled properly

Essentially, if you can view the site in a web browser, JAM can too!

This opens the door to supporting websites that were previously impossible or extremely unreliable to handle with classic HTTP-based approaches.

4) Local JDK support (no system installation required)Another important feature I want to introduce is support for loading a JDK directly from a local folder. This will allow users to take advantage of the power and performance improvements of the latest, more modern JDK versions without having to install them system-wide.This is especially useful on machines with administrative restrictions, where installing software at the OS level can be problematic or outright impossible. At the same time, it gives more advanced users the freedom to choose exactly which Java version to run JAM with.For those who prefer to stick with a JRE-only setup, this approach also avoids any potential conflicts between JRE and JDK installations, making the overall experience cleaner, safer, and more flexible!

A Heartfelt Thank You ❤

All of this takes an enormous amount of time, testing, and experimentation. I’ll be honest: JAM is a labor of love, but it’s your subscriptions that will allow me to dedicate the hundreds of hours needed to pull off these massive changes in 2026.

So, genuinely: thank you for being here, for supporting the project, and for believing in it. You are the legends making this happen. Thank you 🙏

Stay tuned for the first nightly builds coming soon!

Here’s to an exciting 2026 for JAM 🚀