Quasar for the JVM: the javaagent requirement, the six modules and the 0.8.0 ceiling

The instrumentation agent is not optional at runtime

Quasar does not work as a plain library call. When running code that uses it, the instrumentation agent must run, added to the `java` command line as `-javaagent:path-to-quasar-jar.jar`. That single line is the whole runtime contract the README gives, and it is the step most easily missed: a build can compile and pass its tests and still fail at launch, because the fiber scheduling, channel and actor machinery is put in place by that agent rather than by the classes on your classpath. The path in the flag is a placeholder for your own layout, so the line has to be rewritten per environment. Anything that starts a JVM for you, a test runner, a container entry point or a build plugin, needs the flag as well, and the README says nothing about wiring it into those launchers.

Five artifacts, and only one of them is required

Dependencies arrive as Maven or Gradle coordinates, split by feature rather than shipped as one bundle. Core is the entry marked required: `co.paralleluniverse:quasar-core:0.8.0`. Everything else is opt-in and names exactly one integration surface: `co.paralleluniverse:quasar-actors:0.8.0` for actors, `co.paralleluniverse:quasar-reactive-streams:0.8.0` for Reactive Streams, `co.paralleluniverse:quasar-disruptor:0.8.0` for Disruptor channels, and `co.paralleluniverse:quasar-kotlin:0.8.0` for Kotlin on JDK8 or newer. The granularity is the useful part, since a project that only needs fibers pulls core alone. Every coordinate carries the same version, 0.8.0, so mixing Quasar versions inside one build is not a shape the README supports.

quasar-galaxy/ sits in the tree with no artifact name

The repository lists six Quasar module directories. Five of them have a coordinate in the dependency table. One does not.

quasar-core/
quasar-actors/
quasar-disruptor/
quasar-kotlin/
quasar-reactive-streams/
quasar-galaxy/

`quasar-galaxy/` appears in the tree with no artifact name, no feature row and no explanation of what it holds. That single unexplained directory is the kind of gap that costs an afternoon: someone looking for a clustered or distributed feature finds a module named after galaxies and nothing to put in a build file. Treat it as unverified rather than as a hidden capability. The only defensible statement is that the source is in the repository and no coordinate is named for it, so confirm the artifact before designing around it.

gradlew install is the whole source build

Building from source is one command:

./gradlew install

The wrapper is committed twice, as `gradlew` and `gradlew.bat`, so the same invocation works from a Unix-like shell and from Windows, and the tree also carries `build.gradle`, `settings.gradle` and a `gradle/` directory holding the wrapper itself. Because the task is `install` rather than `build`, the wrapper publishes into the local Maven repository, which is what lets a multi-module project resolve `co.paralleluniverse` coordinates without pointing at a remote repository. Two more root directories tell you what a build produces: `baselib/`, the shared base library the modules sit on, and `docs/`. A `.travis.yml` and a `travis/` directory sit next to them as the continuous integration setup this project carries.

The dual EPL and LGPL grant reads as an unasserted license

Quasar is free software published under a choice of two terms: the Eclipse Public License v1.0 as published by the Eclipse Foundation, or, at the licensee's choosing, the GNU Lesser General Public License version 3.0 as published by the Free Software Foundation. The copyright line reads 2013-2018, Parallel Universe Software Co. The texts ship in the repository four times over, in `COPYING`, `COPYING.LESSER`, `LICENSE` and a separate `epl-1.0.txt`, with `NOTICE` alongside them for the attribution the Eclipse license requires. The license metadata attached to the repository reports no assertion rather than naming one, which is a classifier failing on a dual grant rather than an absence of terms. If your compliance process reads a license field from a package index instead of the repository, plan to read `NOTICE` yourself.

Artifacts say 0.8.0 while the last push is dated 2024-01-21

Version numbers and repository activity point in different directions, and the gap has a practical consequence. The published releases stop at v0.8.0 on 2018-11-02, preceded by v0.7.10 in June 2018 and v0.7.9 in July 2017, and every coordinate in the dependency table is 0.8.0, so what most projects install is the 2018 build. The last push on the default branch, master, is dated 2024-01-21, well after those releases. Read that as work continuing on master without a new tagged artifact, not as a published version anyone can resolve. A team that depends on the coordinates gets the 2018 code, and the changes that landed afterwards exist only in the repository. Nothing in the README states a release plan, so treat 0.8.0 as the ceiling of what you can install and read master directly if you need more.

The help path starts in the docs, not the issue tracker

The support instructions have an order. Before filing anything, you are asked to check two named sections of the documentation: System Requirements and Troubleshooting, reached from the docs site at docs.paralleluniverse.co/quasar. Open issues come next, and the preferred channel for questions and suggestions is a forum and mailing list, with a new GitHub issue reserved for bug reports and feature requests, including the explicit advice to reach the community first when you are not sure which one you have. Pull requests are handled through `CONTRIBUTING.md`. Given that the last release is v0.8.0 from 2018 and the last push is dated 2024-01-21, the troubleshooting section is where to look before assuming a defect, because the agent configuration and JDK compatibility questions it covers recur unchanged.

Pulsar and Comsat cover what the core library leaves out

Two sibling projects from the same group are named as the extension points. Pulsar is Quasar's Clojure API, and Comsat integrates Quasar with the JVM's web APIs. Together they mark the boundary of the repository: fibers, channels and actors live here, while the Clojure front end and the web-facing integration live next door and are versioned on their own schedules. Adding the wrong one of those costs you a dependency you did not need. Three routes into the API shape are given as well: the documentation, the Javadoc at docs.paralleluniverse.co/quasar/javadoc, and the examples inside the actors module, under quasar-actors/src/test/java/co/paralleluniverse/actors. That last path is worth knowing, since the sample code a newcomer would write a test against ships inside the test tree rather than in a separate examples directory.

Editorial conclusion

Take Quasar when you need fibers, actors or channels and you can accept a dependency whose published version stopped at 0.8.0 in November 2018, and stay away if your process launches JVMs you do not control or your compliance tooling reads a single license field. Before you commit, confirm that the agent flag reaches every JVM you start, pick modules by the feature rows rather than by directory name, and read the System Requirements and Troubleshooting sections in the docs, since the last push on master is dated 2024-01-21 and post-2018 work is only visible there.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes