The GPars concurrency and parallelism framework for the JVM
Java Groovy Other
Latest commit f60a87a May 24, 2016 @russel russel Merge pull request #36 from ysb33r/master
Fixed Bintray org & repo names
Failed to load latest commit information.
artwork Add variant of logo for use of dark backgrounds. Dec 22, 2015
buildSrc File changes in a way inconsistent with being in version control. Mar 8, 2015
config/codenarc Amend all the files with \n\r ar EOL to be \n EOL, i.e. no \n\r EOLs … Mar 10, 2011
docs/JonKerridgeBook Amend all the files with \n\r ar EOL to be \n EOL, i.e. no \n\r EOLs … Mar 10, 2011
gradle/wrapper Upgrade Gradle. May 24, 2016
java-demo Updated the default project files to JDK 7 and Groovy 2.2.2 Apr 26, 2014
lib Rearrange some more dependencies, and back out of the Multiverse upda… Mar 29, 2013
licenses Tidy up the lib and licence hierarchy. Dec 11, 2011
src Update the CI inspection profiles, spellchecker dictionary and fix a … Dec 31, 2015
.gitignore Capitalize project name. Mar 8, 2015
.travis.yml Rename the TravisCI file. Nov 28, 2014
GPars_CI_only.iml Updated the default project files to JDK 7 and Groovy 2.2.2 Apr 26, 2014
GPars_CI_only.ipr Update the CodeStyle inspection profile Dec 31, 2015
LICENSE.txt user guide Dec 16, 2010
README.idea Updated the idea readme file May 24, 2013 Fixed links in README May 24, 2016
bambooBuild Updated the bamboo build script to correctly generated and package sn… Mar 30, 2012
bambooBuildRelease Added a bamboo script dedicated to release builds Oct 20, 2011
build.gradle Merge pull request #36 from ysb33r/master May 24, 2016 Update versions of things. Dec 22, 2015
gradlew Upgrade Gradle. May 24, 2016
gradlew.bat Upgrade Gradle. May 24, 2016
overview.html Updated the license header (removed GParallelizer) May 24, 2010
settings.gradle Capitalize project name. Mar 8, 2015

Travis-CI master branch: Travis-CI status master | jdk8 branch: Travis-CI status jdk8

Snap-CI master branch: Snap-CI status master | jdk8 branch: Snap-CI status jdk8

Codeship master branch: Codeship Status for GPars/GPars | jdk8 branch: Codeship Status for GPars/GPars


The GPars framework ( offers Java developers intuitive and safe ways to handle Java or Groovy tasks concurrently. Leveraging the enormous flexibility of the Groovy programing language and building on proven Java technologies, we aim to make concurrent programming for multi-core hardware intuitive, robust and enjoyable.

GPars - 'coz concurrency is Groovy

The traditional thread-based concurrency model built into Java doesn't match well with the natural human sense for parallelism. While this was not a problem at times, when the level of parallelism in software was low and concurrency offered only limited benefits compared to sequential code, nowadays, with the number of cores on a single main-stream chip doubling almost every year, sequential code quickly looses ground and fails to compete in performance and hardware utilization with concurrent code.

Inevitably, for concurrent programming to be effective, the mental models of concurrent systems interactions that people create in their heads have to respect the nature of human brains more than the wires on the chips. Luckily, such abstractions have been around for several decades, used at universities, in telephone switches, the super-computing industry and some other inherently concurrent domains. The current challenge for GPars is to bring these abstractions up to the mainstream software developers to help us solve our practical daily issues.

The framework provides straightforward Java or Groovy-based APIs to declare, which parts of the code should be performed in parallel. Collections can have their elements processed concurrently, closures can be turned into composable asynchronous functions and run in the background on your behalf, mutable data can be protected by agents or software transactional memory.

For the common scenario that one or multiple results are calculated concurrently but need to be processed as soon as they are available, GPars makes it a breeze to correctly model this with Dataflow. Dataflow variables and channels gives you a handy abstraction of single-assignment multiple-read data elements, while dataflow operators let you build efficient concurrent data-processing networks.

The concept of Actors as an approach to organizing concurrent activities has recently gained new popularity (thanks to the Scala, Erlang, and other programming languages). GPars implements this concept for Java and Groovy developers. With actors support you can quickly create several independent Actors, which consume messages passed to them and communicate with other actors by sending them messages. You then build your solution by combining these actors into a communication network.

For more details, visit the GPars project home page at