Welcome to GPars - Groovy Parallel Systems
The GPars project offers developers new intuitive and safe ways to handle Java or Groovy tasks concurrently, asynchronously, and distributed by utilizing the power of the Java platform and the flexibility of the Groovy language.
- Concurrent collection processing
- Asynchronous operations
- Fork/Join abstraction
- Actor programming model
- Dataflow concurrency constructs
- Agent - an thread-safe reference to mutable state
- STM (Software Transactional Memory) - planned
If you want to start experimenting with GPars right away, use our Fast Track to get up and running within minutes.
Project's main values
- Clever and clean design
- Elegant Java and Groovy APIs
- Flexibility through meta-programming
- Application-level solutions that scale with number of cores
- Distribution through "scripting" - shipping groovy scripts over the wire
What people say about GPars
Check out the User Voices to hear the opinions of people walking here before you.
The framework provides straightforward Java or Groovy-based APIs to declare, which parts of the code should be performed in parallel. Collections are enhanced with parallel methods like eachParallel(), collectParallel() and others, to perform collection-based operations in parallel. Also, closures can be turned into asynchronous functions and these can then be safely composed into complex asynchronous calculations running in the background on your behalf.
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. Groovy actors do not depend on an exclusive thread. You can have much more actors than threads.
Actor do not necessarily need to reside on the same physical machine. Gpars supports distributed actors, which may exchange message irrespective of their actual location in the network.
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 Dataflow. Dataflow variables and channels gives you a handy abstraction of single-assignment multiple-read data elements.
Concurrency is all about managing state. If there is no mutable state, concurrency becomes a non-issue. However, as soon as we integrate with Java and it's libraries, we inherently deal with mutable state. What GPars adds to alleviate this situation is the concept of a Agent - a non-blocking mt-safe reference to mutable state that is inspired by "agents" in the Clojure language.
Let the fun begin!