Page tree
Skip to end of metadata
Go to start of metadata

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 our main community contact Chris Engelbert, Hazelcast Evangelist via:

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

After discussion easiest way to submit your proposal is to use the following online questionnaire:

Apart from that you might want 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:

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

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 ProcessOngoingChristoph Engelbert
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.CoreOngoingDenis Sukhoroslov
4Spring Data Integration Phase 1 (commons)A first phase implementation for Spring Data Integration into Hazelcast, implementing "commons" features.IntegrationOngoingNeil 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.IntegrationSuspendedWolfgang Haag
8Hazelcast Distributed File System Layer

HZDFS 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.

IntegrationPrototypeSven Ruppert

Open Proposals

TransactionalQueue Bulk-OperationsTransactionQueue lacks support for bulk operations such as addAll like IQueue does. Those batching methods will be implemented as part of this HEP.CoreJerry Scott
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 Engelbert

Closed Proposals

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
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

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 / MultiMapLoaderML
Compression SPI + snappy compression RIMM
Add ILock::intentDestroy (soft destroy)SM
Add IMap::putAllAsyncSS
(Un-)register Serializers at runtimeMM
A CDI integrationMM
Define named instances in the XML configurationSS
Add ItemListener::itemUpdatedSS
EvictionPolicy, TTL and Idle-Timeout for MultiMapMS
General Eviction SPI (based on ICache Eviction)MS
Lock Holder InformationSM
ILock LocalLockStats APIMS
Cache Immutable Objects for DeserializationMM
Support for Spring Transaction APIMM
Predicate support for MultiMapLM
Rename IdentifiedDataSerializable::getIdSM
DistributedExecutorService and durable tasksLL
QueueStore write-behind feature requestSM
Distributed Map: Add support for getQuiet operationMM
com.hazelcast.partition.MigrationEndpoint should be part of the SPI packageSS
More helper methods PortableWriter/PortableReader API & improvement with JavaDocSS
ClassLoading Strategy SPIML
Add a no-listeners hook for topic publishingSS
ICompleteableFuture support (or similar) on most operationsLM
Distributed/Remote ClassLoaderML
Provide access to co-located entries from MappersML
Add Queue Consumer to support Enterprise Integration PatternsMM
Add MultiMap::deleteSM
Automatic port selection (port 0) supportSS
Allow up/down arrows to navigate command historySS
Binary Protocol Support for Hazelcast Memcache ClientML
Add IQueue:putAll (and maybe other bulk operations)MM
Add ITopic::publishAll (and maybe other bulk operations)MM
Add IAtomicReference listenerSM
Support for load/store on ITopicML
Factory Id's of DataSerializerHook's should be taken from a single placeMS
EvictionPolicy for ReplicatedMapMM
Add GroupBy/Having, Combined aggregations to Hazelcast AggregationsMM
SqlPredicate and custom typesML

  • No labels


  1. Should I put the new Progressive OperationExecutor to the HEP as well? It is the one with the caller runs optimization that allows for very fast local calls.

  2. If you would like to do it with the community, why not - I guess there might be some interested people out there (smile)

Write a comment…