Hazelcast Enhancement Proposals

What is a Hazelcast Enhancement Proposal?

Hazelcast Enhancement Proposals ("HEPs") are proposals for new community driven features or enhancements to Hazelcast. The HEP procedure is inspired by OpenJDK's JEP process and helps organizing, planning and implementation of the prior named enhancements.

Why the Enhancement Proposals?

First of all we are always super excited to accept external contributions, this is what open source is all about, teamwork!

We want to ensure you get your changes merged in with the minimum fuss. For smaller changes just send a pull request (PR) just as you always did. Bigger features can be trickier as they often require a non-trivial amount of communication, synchronization and time. There is nothing more disappointing than refusing a nice contribution, that took a lot of effort and work, just because someone else is already working on it.

We value the time of our contributors and the Hazelcast Incubator is our attempt to provide our feedback as quickly as possible. We want to provide transparent work, a set of comprehensive rules and a simple process to help people find other interested companions, to encourage teamwork on amazing features and to prevent people from becoming upset about spent time when a pull request cannot be merged into the Hazelcast code base.

How to Submit a HEP Request?

HEPs are generally contributed by our community members. Hazelcast encourages its own employees to work with the community and help on questions asked. For questions specific to the HEP procedure please feel free to contact us at :

The best idea is to just drop a line and discuss your idea.

After discussion the easiest way is to use the wiki template to create your proposal and send it via mail: Hazelcast Enhancement Proposal ("HEP") Template, Version 1

What is the procedure?

The submitted Hazelcast Enhancement Proposals will be written to this wiki as quickly as possible. After submission there is a 1 week period of internal discussion with the team that is responsible for the selected component, as well as discussion from the community side. Things we look at in deciding to accept a HEP:

  • Alignment with the features and architecture direction of Hazelcast
  • Viability of the community team to develop
  • Viability of the community team to maintain 

Normally you can expect a HEP to be accepted but there might be cases where the proposal is not yet detailed enough, does not meet internal standards or is denied for other reasons. In any of those later cases we will always reason our decision and if there is a chance help on improving the proposal to resolve the denial reasons.

The Hazelcast Incubator procedure itself is documented in HEP 1 - Hazelcast Incubator and Hazelcast Enhancement Proposal ("HEP").

Once accepted, a repository is created at the Hazelcast Incubator Github repository and an initial fork for the new HEP is added. Any active work on the incubated enhancement happens here, specifications, documentation and issues will also be collected in this single place. In addition a public Gitter channel is registered for discussions to take place. Further interested people might also request to join the HEP at this point as contributors.

All additional information that are mentioned in the above template but are not in the online questionnaire will be filled out with the expected values by the community lead.

How to contribute to existing HEPs?

If a HEP is already existing and not yet finished, the best way to offer help or interest is to drop one of the authors a short line on twitter, jump into the HEP's Gitter channel or, if available, writing a mail. Interested people are expected to be accepted as new members to the HEP by the current team, if reasonable. Pull requests to an Incubator repository on Github are generally welcomed if not otherwise specified by the team working on the HEP.

After completing a HEP the enhancement will be merged into the Hazelcast code base. No further work can be done on the incubator repository and it will eventually be deleted. Therefore no new members can be accepted after completion of a HEP.

To extend a previously completed HEP or to create a maintenance release please issue a new proposal mentioning the reasons or enhancements over the old one.

Home of HEPs

HEPs are collected in a single place to give interested people a simple way to find out about existing proposals and start working themselves into the codebase of the enhancement. Pull requests against an Incubator repository of the project are welcomed!

HEPs are kept in the Hazelcast Incubator Github repository at: https://github.com/hazelcast-incubator

Once accepted, a repository is created here. Active work on the incubated feature happens here, issues and so on. In addition a public Gitter channel matching the HEP's shortname is created and used for further discussion.

Accepted HEPs


Open Proposals

Hazelcast SPI for Indexing ServicesThe Hazelcast Indexing SPI will provide an extension SPI to implement arbitrary / user defined types of indexes. So far Hazelcast provides an indexing system for simple key/value indexed attributes but common questions include indexes for geospatial or partial indexes. CoreChristoph Engelberthttps://gitter.im/hazelcast/hazelcast

Closed Proposals

1Hazelcast Incubator and Hazelcast Enhancement Proposal ("HEP")This proposal defines the coverage and the limits for the new Hazelcast Incubator. It is meant to help community members to work together and give them guidance on how to successfully help enhancing Hazelcast upon their ideas and visions.Community ProcessCompletedChristoph Engelbert
2Hazelcast Discovery SPIThe Hazelcast Discovery SPI will provide an extension SPI to attach external cloud discovery mechanisms. Discovery is meant to find other Hazelcast instances based on certain filters and provide their corresponding IP addresses.IntegrationCompletedPaulo Pires
3Entry Cost Calculator SPIIn the currently available memory cost calculator implementation, memory cost is not calculated when In-Memory-Format is not BINARY, thus eviction policy based on memory consumption can't be used at all. It would be beneficial to allow users assign their own memory-cost-calculator for such case via Config interfaces and in xml configuration.CoreSuspendedDenis Sukhoroslov
4Spring Data Integration Phase 1 (commons)A first phase implementation for Spring Data Integration into Hazelcast, implementing "commons" features.IntegrationCompletedNeil Stevenson
5Quartz JobStore IntegrationThis proposal contains a Cluster-Job-Store based on Hazelcast objects to be used with Quartz  > V2.2. The job store is a derivation of the JDBC-Job-Store, delivered with the Quartz package.IntegrationDeadWolfgang Haag
6Cascading IntegrationCascading is a data processing API and processing query planner used for defining, sharing, and executing data-processing workflows on a single computing node or distributed computing cluster. Per default Cascading runs on either in single-node (local-mode) setup or on top of hadoop using the hadoop mapreduce framework or Apache tez (in upcoming version 3). Hazelcast would be a good fit to act as an underlying execution framework alongside the already existing ones.IntegrationDeadAlexander Toktarev
7Hazelcast Python ClientThis project aims to create a semi-functional Python client.  The client will be able to execute operations on supported Hazelcast data structures.  In addition, the client will be able to register for updates from the cluster and be able to keep track of them.ClientSupersededJonathan Brodie
8Hazelcast Distributed File System LayerHZDFS the Hazelcast Distributed Filesystem Layer is a filesystem with simple access rights management and the possibility to store files larger than 2GB (chunked) in Hazelcast.IntegrationSuspendedSven Ruppert

Some Open Feature Requests

The following list shows a aggregation of open feature requests that might be interesting to be implemented by the community. If you are interested to any of those feature request to implement it in form of a HEP please drop a line on the above contact possibilities.

Effort and Difficulties are defined in 3 different types: S, M, L

DescriptionExpected EffortExpected DifficultyGithub Issue
MultiMapStore / MultiMapLoaderMLhttps://github.com/hazelcast/hazelcast/issues/42
Compression SPI (+ snappy compression RI?)MMhttps://github.com/hazelcast/hazelcast/issues/175
Add ILock::intentDestroy (soft destroy)SMhttps://github.com/hazelcast/hazelcast/issues/40
(Un-)register Serializers at runtimeMMhttps://github.com/hazelcast/hazelcast/issues/564
EvictionPolicy, TTL and Idle-Timeout for MultiMapMShttps://github.com/hazelcast/hazelcast/issues/47
Lock Holder InformationSMhttps://github.com/hazelcast/hazelcast/issues/1055
ILock LocalLockStats APIMShttps://github.com/hazelcast/hazelcast/issues/737
Cache Immutable Objects for DeserializationMMhttps://github.com/hazelcast/hazelcast/issues/716
Predicate support for MultiMapLMhttps://github.com/hazelcast/hazelcast/issues/593
QueueStore write-behind feature requestSMhttps://github.com/hazelcast/hazelcast/issues/1586
Distributed Map: Add support for getQuiet operationMMhttps://github.com/hazelcast/hazelcast/issues/1540
More helper methods PortableWriter/PortableReader API & improvement with JavaDocSShttps://github.com/hazelcast/hazelcast/issues/1227
ClassLoading Strategy SPIMLhttps://github.com/hazelcast/hazelcast/issues/3312
Add a no-listeners hook for topic publishingSShttps://github.com/hazelcast/hazelcast/issues/1996
Add Queue Consumer to support Enterprise Integration PatternsMMhttps://github.com/hazelcast/hazelcast/issues/2783
Add IQueue:putAll (and maybe other bulk operations)MMhttps://github.com/hazelcast/hazelcast/issues/4233
Add ITopic::publishAll (and maybe other bulk operations)MMhttps://github.com/hazelcast/hazelcast/issues/4233
Add IAtomicReference listenerSMhttps://github.com/hazelcast/hazelcast/issues/4086
SqlPredicate and custom typesMLhttps://github.com/hazelcast/hazelcast/issues/4427