DataCleaner is a Java toolkit for profiling and cleansing data

Profiling, correcting and enriching in one Java toolkit

DataCleaner is described as a data quality toolkit that lets you profile, correct and enrich your data. The three verbs describe three distinct jobs that most teams end up doing with a mix of ad hoc SQL, spreadsheet formulas and one off scripts. Profiling means understanding what is in a data set: what columns exist, what the distributions look like, where the values break expectations. Correcting means applying transformations, whether that is standardising formats, handling nulls or trimming values. Enriching means adding information from elsewhere. The stated use cases span ad-hoc analysis, recurring cleansing, and what the project calls a swiss-army knife in matching and Master Data Management solutions, so the audience is broader than data engineers with a pipeline to repair. It is a desktop application first, with a Swing based interface in the desktop/ui module, backed by a component system where each data source, transformation and output is a pluggable component. Language is Java throughout, and the project is published under the Lesser General Public License.

The api module is the contract, not an afterthought

The module structure is the most informative thing in the repository, because it tells you how a DataCleaner deployment is meant to be assembled. The api module is described as the public API of DataCleaner, mostly interfaces and annotations that you should use to build your own extensions. That single line decides the adoption question for many teams. If you want to run DataCleaner as a desktop tool for one-off profiling, the api module is irrelevant to you. If you want to embed the engine in a Java service, expose a job endpoint, or write your own connector for an internal system, the api module is the whole point, and the annotation driven design suggests it is intended for that use rather than being an afterthought exposed after the fact. Alongside api sit resources for static resources, oss-branding for icons and colors, and testware, which holds useful classes for unit testing of DataCleaner and of extension code. That last one is the detail experienced Java teams will notice. A testware module shipped in the main build tells you the authors expected people to write extensions and to test them, and it lowers the cost of doing so compared with a tool where testing support is an afterthought.

engine/core, xml-config and running outside the desktop app

The engine directory splits into three parts that matter for how you deploy. core is the piece that allows execution of jobs and components as per the API, which is the runtime that turns a job definition into work against a datastore. xml-config contains the utilities for reading and writing job files and configuration files, so a DataCleaner job is a file you can check into version control, diff and review, which is the property that separates it from clicking through a GUI. env holds different and alternative environments DataCleaner can run in, and the project names two of them: Apache Spark and a webapp cluster. That is the architectural claim worth understanding, because it means the same job definition is not tied to the desktop application. The datastores directory at the top level of the repository reinforces the same point from the data side, since connecting to sources and sinks is separated from the execution engine. For a team that already runs Spark, a DataCleaner job that executes in a Spark environment is a different proposition from a profiling tool that runs on a laptop, and it is the reason to consider this toolkit rather than a lighter weight script.

Components as the extension surface

Under components, the structure is described as many sub modules containing built-in as well as additional components and extensions to use with DataCleaner, and one named project is singled out: standard-components, a container project that depends on all the components normally bundled in the DataCleaner community edition. The word container is the important one. It means the bundle is assembled by dependency rather than by a hard coded list, so a build that includes a component you do not want is a matter of changing which container project you depend on. For a distribution, that is exactly what you want, since it lets you pin a curated set of connectors and transformations instead of shipping everything. It also explains why the api module is framed around interfaces and annotations: components are the plug-in surface, and the api is how they talk to the engine. The practical constraint to keep in mind is that a component has to be maintained by somebody. The community edition bundles a set of them, and anything you build yourself is code you now own, which is the same trade-off as writing the transformation directly against your database.

Maintained, but not actively developed

The project is unusually direct about its own status, which is rare and useful. The documentation states that the project is maintained, but is not being actively developed, and then spells out what maintenance means here. They ensure DataCleaner runs on modern versions of Java on major operating systems. They take security bugs seriously and try to keep dependencies up to date whenever vulnerabilities are detected. They are open for bug reports, contributions and discussions. And new features are driven by pull requests. Read that list as a maintenance contract rather than a roadmap, and the practical reading is that you get compatibility and security fixes but you should not expect a new connector to appear on a schedule. The dates support the same picture. The last push to the repository was on 2026-07-27, and the most recent tagged release is DataCleaner 5.9.0 from 2024-11-16, ahead of 5.8.1 from 2022-02-09 and 5.7.1 from 2020-05-27. The gap between a recent push and an old release tag tells you where the recent work has gone: compatibility and dependency maintenance rather than versioned feature drops. The current maintainer is listed as @kaspersorensen.

Getting the desktop app: the community site, not the repository

One point catches newcomers out. The repository is not where you download the application. The documentation points end users to the DataCleaner community website at datacleaner.github.io for downloads, news and documentation, and to a Gitter chat channel for questions, while stating that GitHub markdown pages and issues are used for developers and technical aspects only. That split tells you the repository audience. If you want to run the product, you are a visitor to the community site; if you want to extend it, the repository is your place. There is also no homepage field set for the repository, and the top level entries show a conventional Maven layout with a pom.xml, api, components, datastores, desktop, engine, oss-branding, resources and testware directories, plus files a Java shop expects: HEADER.txt for licence headers, NOTICE.txt, COPYING.txt, a RELEASE_GUIDE.md, and Formatter-Eclipse.xml and Formatter-IDEA.xml files that carry the code formatting rules so you can import them into your IDE. Those formatter files are a small courtesy that says the project expects outside contributions.

When a query and a spreadsheet are the better answer

DataCleaner is the wrong tool in a few clear situations. If you have one table with a handful of obvious problems, a profiling query and a spreadsheet will be faster, and you will understand the result better. If you need a feature that does not exist yet, remember that new features are driven by pull requests, so the cost is yours to pay in engineering time. And if your whole stack is Python, the Java runtime, the XML job files and the component dependency model are overhead you have accepted for nothing. The genuine alternative worth naming is building on the api module yourself: take the interfaces and annotations, drive the engine from your own service, and write only the components that differ from what is bundled. That is more work up front and it gives you full control over the pipeline, whereas the community edition gives you a finished desktop application with a large bundled component set. Choose the desktop application when you want the finished product and the api route when the pipeline has to live inside something you own.

Editorial conclusion

Adopt DataCleaner if you are a Java team that needs repeatable profiling and cleansing jobs, want to ship the logic inside your own application through the api and engine modules, or need the same job definition to run on Apache Spark. Do not adopt it if you expect an actively developed product roadmap, since the project describes itself as maintained but not actively developed, or if a spreadsheet and a few SQL queries would cover your problem. Verify two things before you commit: that the version you get still runs on the Java release your team uses, and whether the extension you need already exists in components, because the maintainers are explicit that new features arrive as pull requests rather than as releases. A practical first step is to download the community edition from datacleaner.github.io, run one profiling job against a database you already know, and compare the profile against your own understanding of the data before automating anything.

Frequently asked questions

Official sources

1. datacleaner/DataCleaner on GitHub
2. Issues
3. License: LGPL-3.0
4. README
5. Releases