JVCL: six hundred Delphi components that the JEDI community still ships

A component library assembled from donations, not written from scratch

JVCL is described in the README as a library of over 600 Delphi visual and non-visual Delphi/C++Builder components, supporting Delphi and C++Builder 6 and newer. The origin story is the part that explains the shape of the code.

The README states that the library is built upon code donated from the JEDI community, and that this donated code is reformatted to achieve a common look and feel, tested, and merged into the library. So the components are not one author's design; they are the accumulated output of many contributors, normalised into a single library.

That process has visible consequences. A component set assembled this way covers an enormous surface, which is exactly what you want if you are building a desktop business application and do not want to write a chart control, a docking panel system and a database component hierarchy yourself. It also means internal consistency is a goal the maintainers worked towards through reformatting and testing rather than something that came from a single original design.

The components are grouped into several packages, according to the README, so a project can take what it needs rather than everything.

The audience is narrow and clear: a developer working in Delphi or C++Builder who wants an existing, tested component set. This is desktop, Windows-era, native GUI work, and a reader looking for a component library for a modern web application is in the wrong place entirely.

The MPL is the licence that lets it sit inside commercial software

The licensing is stated several times in the README, which is a sign that the question comes up. The library is released to the public under the terms of the Mozilla Public License, and the README says that as such it can be freely used in both freeware and shareware, open source and commercial projects. The entire library, including the document and all source code and ancillary files, is distributed under the MPL.

There is a detail here that matters more than the headline. The README notes that source files included in the JVCL carry a header explicitly stating the MPL, as the licence requires, but that unless noted otherwise, all files including those without an MPL header are also subject to the MPL. In other words, there is no unlicensed gap in the package. Everything is MPL, whether or not the individual file says so.

The MPL is a file-level copyleft licence. Use the library in a commercial product and the MPL obligations attach to the MPL-covered files themselves, not to your whole product, provided you keep those files available in source form and keep the notices intact. That is the practical reason a permissive-looking library like this can be dropped into a commercial Delphi application, and it is worth having the actual LICENSE file read by whoever owns the compliance question in your organisation, since the repository root carries a LICENSE.md and GitHub itself does not classify the licence automatically.

The alternative to consider is not another Delphi component library but a different platform. If the constraint driving the choice is the licence, a permissive-licensed set of components or a rewrite away from Delphi resolves it more simply than licence interpretation does.

Installing means cloning two repos and running a Windows batch file

There is no package manager step, and the README is direct about the sequence. You clone the repository:

> git clone https://github.com/project-jedi/jvcl.git jvcl

and the README is explicit that this gets you the JVCL repository and that you also need the JCL, which lives in a separate project-jedi repository. Then the install instructions are two steps: install the JCL first, and start the install.bat script under the jvcl directory.

The dependency order is not optional. The batch file expects the JCL to be in place, and the README lists installing the JCL as step one. Anyone who skips it will find the install script looking for something that is not there.

The use of a Windows batch file for installation is the clearest signal about who this library is for. This is a component library for native Windows GUI development, and the install procedure assumes a Windows environment with a Delphi or C++Builder installation already present. There is no mention of a Linux or macOS path, and no package registry entry. For a team whose build machines are all Windows, that is a non-issue. For a team that has moved to a mixed or non-Windows environment, it removes the library from consideration regardless of how good the components are.

For those who want the latest state rather than a tag, the README points to daily snapshot downloads hosted on SourceForge at jvcl.sourceforge.net/daily, which is the usual way to track a library that is developed in a public repository rather than behind a release process.

Package groups, tests and the daily snapshot workflow

The repository layout shows how the library is organised. The jvcl directory holds the components themselves, the tests directory holds the test projects, the help directory the documentation, donations the funding files, and websites the per-package or per-component pages. There is a readme.md at the root alongside the LICENSE.md, a .gitattributes and a .gitignore.

Grouping into packages is the mechanism that keeps 600 components usable. A Delphi developer installing the whole library gets a lot of units on the search path, and the package structure is what lets a project depend on a coherent subset instead. The README also links a build results page in the project-jedi tools repository, which is where the per-package build status is published, so a broken package in one compiler version is visible without compiling the whole library yourself.

The tests directory is worth pausing on, because the README claims donated code is tested before being merged. A test project per area, run against multiple Delphi versions, is a substantial ongoing commitment for a volunteer project, and the presence of a tests directory and published build results is the evidence for that claim rather than the claim alone.

The daily snapshot workflow is the other operational detail. A library whose last tagged release is JVCL3_50 from September 2025, and whose last push to the repository was on 2026-05-29, is not one where the tags tell you what is current. Anyone tracking it seriously should be pulling from the repository or taking a daily snapshot rather than waiting for a version number to move.

The release history is where the maintenance question is answered

The tag history is the most informative fact in the listing. JVCL3_48 was published in May 2014, JVCL3_49 in September 2015, and then a long gap, followed by JVCL3_50 in September 2025. A decade between 3.48 and 3.49 is not a sign of neglect, it is a sign that the version number stopped moving while the work continued.

This is the pattern of a mature, low-churn component library. The components are stable, the API of a Delphi component does not need to move often, and the effort goes into compiler compatibility, fixes and the occasional new component. The jump from 3.49 to 3.50 in September 2025 suggests a change of release conventions rather than a change of pace.

The last push was on 2026-05-29 and the repository is not archived, so the code is still being worked on. What it does not have is a GitHub releases feed, a changelog you can read in the repository listing, or a stated support policy for any given compiler version. For a team that needs to answer an auditor's question about which version they are running and why, that is a real gap, and one that the daily snapshots do not fill.

The bug reporting route is also worth noting before you adopt. The README asks for detailed reports with reproduction steps, code attached as a zip with source only and no third party dependencies, and it says explicitly to be prepared to monitor the report since additional information is often needed. It also asks you to include a solution if you have one. That is a reasonable, contributor-oriented policy, and it also tells you that a fix may depend on you rather than on them.

Community support runs on newsgroups, which is the real constraint

The support model is the part of this project most likely to surprise a modern team. The README says the JVCL is built by the community, but more importantly, for the community, and then points to newsgroups as the most active forums for discussing the library.

The specific group is jedi.jvcl on the news server at news.delphi-jedi.org, and the README recommends subscribing to at least jedi.general and jedi.jcl as well. A web gateway is provided for people who cannot reach the newsgroups directly because of firewalls or company policy.

So the help you will get, and the help you can give, happens over NNTP. That is an unusual choice today, and it is a direct consequence of the age of the project and its community. The same age explains the compiler support range, since Delphi 6 is a 2000 release, and the SourceForge hosting for daily snapshots.

There is a good side to it. A newsgroup is threaded, permanent, searchable by topic, and it does not have the churn of a chat channel. Fifteen years of jedi.jvcl threads is a serious archive, and for a component library with a slow-moving API, that archive is genuinely valuable.

There is a bad side too. Search engines index the web gateway unevenly, so a search for a specific component problem may not surface the answer that already exists on the server. And a team that does not have NNTP configured at all, or that wants answers in a ticketing system, will find the channel awkward.

The bug tracker is separate, at the Delphi JEDI issue tracker, with a login and a registration link, and the README notes it is quick to register so you receive email updates as your report moves.

Where JVCL is the wrong choice

The first wrong-tool case is a greenfield project. Nothing here argues against Delphi for a long-lived business application, but a new product with no legacy constraints should be evaluated on current tooling, and the current Delphi component ecosystem is a different conversation from what the JEDI community assembled.

The second is the platform constraint. The installation procedure is a Windows batch file that assumes a Delphi or C++Builder installation, and the README documents no other path. A team that builds on Linux, even to target Windows, has to solve that themselves before the library is usable at all.

The third is upstream cadence and governance. This is a volunteer-run, donation-supported project with a decade-long gap between version tags, no stated support policy, and a help channel on newsgroups. If your organisation needs a component library with a support contract behind it, this is not that, and the README does not pretend otherwise.

The fourth is a component you already have. Delphi's own RTL and the JCL, which the JVCL install depends on, cover a lot of ground, and FireMonkey, the modern VCL, and third party vendors cover the rest. Pulling in 600 donated components to use three of them means taking on the maintenance surface of all of them, including the ones that never get used and the ones that will conflict with something else on your search path.

The last case is a specific component you could write in a day. A lot of what people want from a component library is a small custom control for an internal tool, and adopting 600 components for that is a poor trade.

Editorial conclusion

JVCL fits a team maintaining or extending a Delphi or C++Builder application that needs the batteries-included component set the JEDI community has assembled, and who can accept a Windows-only install path and a code base whose origins are decades of donations. It is the wrong choice for a greenfield project, for a team on a non-Windows development environment, or for anyone who needs a component library with an active upstream and a predictable release cadence. Before adopting it, read LICENSE.md at the repository root, install the JCL first as the README requires, and check whether the component you need already exists in the 600 already provided.

Frequently asked questions

Official sources

1. Issues
2. project-jedi/jvcl on GitHub
3. README
4. Releases