Tablesaw: A Java Dataframe Library With a Plotly Wrapper and a Split Module Layout
Java dataframe and visualization library
At a glance
- What is it?
- Tablesaw is an Apache-2.0 Java dataframe and visualization library that handles import, cleaning, transformation and descriptive statistics, with charting delegated to a Plotly JavaScript wrapper. The core is one artifact; everything else, including JSON and Excel support, is a separate module you add yourself.
- Who is it for?
- Adopt Tablesaw if your data already lives in a JVM service and you want filtering, grouping, joins and descriptive statistics without leaving Java, or if you need charts rendered through Plotly from Java code. Do not adopt it as a replacement for a Python or R analysis workflow, and do not expect a Parquet reader in the main repository: that lives in tablesaw-parquet, which the README places outside the jtablesaw organization.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 39 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap Tablesaw Fills: Dataframes for Code That Cannot Leave the JVM
Most dataframe work happens in Python or R, and that is usually the right call. The problem Tablesaw addresses is the case where it is not. If your data pipeline is a Java service, an ETL job or a scheduled batch process, the conventional answer has been to export to CSV, run the analysis elsewhere, and import the result back. Tablesaw removes that round trip by giving Java a table abstraction with typed columns, plus the operations you would reach for in pandas: sort, group, filter, join, append, transpose, and map/reduce style operations. The README frames the audience plainly: "If you work with data in Java, it may save you time and effort." That is a narrow audience compared with a general data science library, and the project does not pretend otherwise. The stated scope is loading, cleaning, transforming, filtering and summarizing data, with descriptive statistics (mean, min, max, median, sum, product, standard deviation, variance, percentiles, geometric mean, skewness, kurtosis) and an explicit role as a preparation layer for machine learning libraries such as Smile, Tribuo, H20.ai and DL4J. Note what that means: Tablesaw positions itself upstream of the model, not as a modelling library.
Column Types, Module Boundaries, and a Plotly Wrapper Instead of a Native Renderer
The architecture visible from the repository is a core plus optional modules. tablesaw-core holds the dataframe itself and the transformation and statistics operations. Around it sit tablesaw-excel, tablesaw-html, tablesaw-json, tablesaw-jsplot and tablesaw-beakerx. That split is a deliberate trade-off. Importing from CSV or TSV needs nothing extra, but the moment you want a JSON or Excel source you are adding an artifact, and the README lists each one separately rather than bundling them. The visualization story is the most consequential design decision. Tablesaw does not draw charts in Java. According to the README, it "supports data visualization by providing a wrapper for the Plot.ly JavaScript plotting library," and charts come from the tablesaw-jsplot module. The gallery in the README shows box plots, scatter plots with two Y axes, time series, overlaid and 2D histograms, pie charts, 3D bubble charts, grouped bubble charts, area charts, heatmaps, grouped bar charts and OHLC charts. All of that rendering happens in JavaScript. For a Jupyter workflow that is fine, and the README leans hard into notebooks: BeakerX, IJava, and Google Colab are all named as supported routes, with several third-party tutorials linked. For a headless server process that needs a static PNG, the wrapper model is a constraint you have to plan around, because the drawing is not happening in the JVM.
Adding Tablesaw: One Required Artifact and Four Optional Ones
The README gives the Maven coordinates for the core artifact directly, with the version left as a placeholder pointing at the release notes:
<dependency> <groupId>tech.tablesaw</groupId> <artifactId>tablesaw-core</artifactId> <version>VERSION_NUMBER_GOES_HERE</version> </dependency>
The same groupId applies to the supporting artifacts, which the README lists as tablesaw-beakerx, tablesaw-excel, tablesaw-html, tablesaw-json and tablesaw-jsplot, each with a one-line purpose: BeakerX integration, Excel workbooks, HTML, JSON, and chart creation respectively. There is no BOM or aggregator mentioned in the supplied material, so version alignment across those artifacts is something you manage yourself. Parquet is handled differently. The README points to tablesaw-parquet, a project it explicitly labels as "outside of this organization," hosted at tlabs-data, and it links a separate issue tracker for it. That distinction matters at adoption time: the Parquet path is not covered by the same release cadence as the modules inside jtablesaw, and the README does not describe its compatibility guarantees. The documentation entry points are the getting-started page and the user guide, both under jtablesaw.github.io, with GitHub Discussions for questions and the issues tab for bugs and feature requests.
Where Tablesaw Is the Wrong Tool
The clearest limitation is the one the project itself implies by its module list. If your analysis needs Parquet as a first-class format, you are depending on a repository the README places outside the organization, and nothing in the supplied material describes how that project tracks core releases. Treat that as an unverified integration until you check it yourself. The second limitation is the visualization path. Because charting is a wrapper around a JavaScript library, any environment that cannot run that JavaScript, or that needs charts produced without a browser context, is a poor fit for tablesaw-jsplot; the README's own examples are notebook-oriented, and the recommended routes (BeakerX, IJava, Colab) all assume an interactive kernel. Third, and most fundamental: this is a Java library. If your team already works in Python, adopting Tablesaw means maintaining a second analysis stack in a second language, and the README offers no interoperability path to pandas or R that would justify that. The material also does not state memory characteristics, out-of-core support, or how the library behaves on tables larger than heap. Those are exactly the questions a Java team would ask before putting a dataframe library into a batch job, and the supplied README does not answer them. Absence of a claim is not a claim of absence, but it does mean you should measure before you commit.
Tablesaw Versus Doing It in pandas or R
The honest alternative is not another Java dataframe library. It is doing the analysis in the language the rest of the data ecosystem uses. pandas and R give you a far wider set of statistical and plotting packages, and the surrounding tooling (notebooks, plotting backends, format readers) is the default rather than an add-on module. The difference in approach is where the data crosses a process boundary. With pandas you typically move data out of the JVM into a Python process, which means serialization, a second runtime in your deployment, and a second set of dependency versions to track. With Tablesaw the data stays in the JVM and the analysis runs in the same process as the rest of your Java code. That is the entire trade: you give up ecosystem breadth in exchange for not having a boundary. For a service that computes summary statistics over records it already holds, the boundary is pure overhead and Tablesaw wins. For exploratory analysis where you will try six libraries in an afternoon, the boundary is worth paying and Tablesaw loses. The README's own framing supports this reading: it describes Tablesaw as something that can "prepare data for working with machine learning libraries like Smile, Tribuo, H20.ai, DL4J," which is preparation, not exploration.
Versions, Modules and the Apache-2.0 Licence
Tablesaw ships under Apache-2.0, stated in the README badge and confirmed by the repository metadata. That is a permissive licence, and it is the same licence as the Apache Parquet format project the README references, though the tablesaw-parquet integration is a separate codebase with its own terms to check. Apache-2.0 includes an explicit patent grant and requires attribution and notice retention; if you redistribute Tablesaw inside a product, those obligations travel with it. This is a description of the licence text, not legal advice, and anything involving redistribution, modification or a bundled commercial artifact should go to your own counsel. On upgrade cost, the release history in the supplied material shows three releases on the same day in January 2026 (v0.44.2, v0.44.3, v0.44.4), which is the pattern of a project that patches quickly rather than one that batches changes into large, infrequent drops. The zero-major version number is the more useful signal: at 0.44.x, the project is not claiming API stability, so pinning an exact version and reading the release notes before bumping is the reasonable posture. The module split adds a second dimension to that cost. A core upgrade can be compatible while a module you depend on, or the out-of-organization Parquet project, lags behind. Budget for checking each artifact you actually use, not just tablesaw-core.
Editorial conclusion
Adopt Tablesaw if your data already lives in a JVM service and you want filtering, grouping, joins and descriptive statistics without leaving Java, or if you need charts rendered through Plotly from Java code. Do not adopt it as a replacement for a Python or R analysis workflow, and do not expect a Parquet reader in the main repository: that lives in tablesaw-parquet, which the README places outside the jtablesaw organization. Before committing, verify three things against your own build: which module artifacts you actually need (core alone gives you no JSON, Excel or chart support), whether the jsplot wrapper fits your rendering environment, and whether the third-party Parquet project is maintained at the version you require.
Community notes