Hi Charlie, Kishor, Thanks to both of you for the thoughtful perspectives—this kind of exchange really helps us align on what matters most.
Charlie, your point about off-heap’s limited performance impact and maintenance overhead is well noted. Kishor, I appreciate the broader context and the strategic lens—especially around integrations and potential future directions. For now, keeping off-heap while treating it as a candidate for future simplification seems like a balanced approach. If we decide to move forward with changes or deeper exploration, we’ll need to create a ticket to track the work. In the meantime, here’s the main Jira ticket for anyone who’d like to follow, link or contribute: GEODE-10467: https://issues.apache.org/jira/browse/GEODE-10467 Appreciate the collaboration—looking forward to where this leads. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/> From: Charlie Black <[email protected]> Date: Saturday, September 20, 2025 at 1:39 PM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Proposal for Apache Geode 2.0.0 – Call for Community Input and Reviewers EXTERNAL I wouldn’t put too much weight on “off-heap.” It only stores the serialized bytes—keys and indexes still reside in the JVM heap. Each get call requires deserializing the value, so the performance benefit is limited. The implementation isn't really pluggable. Snappy, which was built on Geode, used the same off-heap approach/code. While “check-the-box” features can be useful, the reality is that our contributor community is relatively small. Simplifying the codebase by removing off-heap could reduce maintenance overhead. That said, I’m fine either way - whether the feature is kept or removed. Even removal comes with its own cost, so retaining features can sometimes be the simpler path. As for Arrow - I can see it replacing off heap to add value to the native heap blobs geode uses. Net effect of swapping out implementation is “opaque bytes you must deserialize” → “typed, columnar buffers you can compute on immediately.” Maybe just something for version 3.0 if someone wants to run with it. Charlie On Sat, Sep 20, 2025 at 4:50 AM Kishor Bachhav <[email protected]> wrote: > These are interesting insights, Charlie. > Lucene looks interesting. I would like to explore more but if it has some > interesting practical use cases to test. > Jinwoo, do you have any use cases around it? > > About off-heap, yes it was introduced to overcome long STW pauses for CMS. > The interesting use of Geode is its tight integration with query engines > like SparkSQL, Presto/Trino. I mean Geode Cache Server and Spark Executor > in the same JVM. Its like a caching layer. SnappyData/Ampool were the > companies that did the same and got acquired. OffHeap has played a big role > over there. New age query engines are born (like DataFusion, Velox) which > leverages Apache arrow in memory columnar storage. Can Geode be used there? > Another company which may get acquired. Off heap is very useful there. Just > an idea... > > My suggestion is rather than removing those features, let's keep it and > keep working in the same as and when time needs. This way we will still be > comparable to redis. It will give Geode an extra edge. > > Regards > Kishor > > > > On Sat, Sep 20, 2025 at 9:33 AM Charlie Black <[email protected]> > wrote: > > > Long time Geode user here. > > > > For Spring, the community is set to release Spring 7 in November 2025. It > > may make sense to skip Spring 6 and move directly to 7. > > > > I know that updating Lucene was blocked in earlier Geode versions because > > of the need to maintain Java 8 compatibility. Unless someone in the > > community is willing to take on completing Lucene indexing, I’d recommend > > removing it entirely to simplify the codebase. The feature was never > really > > finished. > > > > HOWEVER - One item that is cool about Lucene was the ability for > > nearest neighbor queries, so if we want to make Geode into a vector > store I > > am pretty sure we can use that Lucene indexing feature. This would > very > > much like how elastic search can support AI use cases. KNN indexing was > > introduced in Lucene 9 which requires JDK 11. > > > > My current usage of Geode just revolves around the core - gets, puts and > > listeners - I am not sure I would pick up finishing Lucene myself. > > > > Another candidate I would suggest for removal is off-heap memory. While > it > > was an interesting feature, it’s difficult for operations teams to > monitor > > effectively. With modern JVMs and pause-less garbage collectors like ZGC, > > its original purpose of making large heaps manageable under CMS GC is no > > longer relevant. > > > > Charlie > > > > On Fri, Sep 19, 2025 at 12:08 PM Jinwoo Hwang > <[email protected] > > > > > wrote: > > > > > Hi Leon, > > > > > > You’ve raised a very valid concern, and I appreciate you taking the > time > > > to review the pull request as well. > > > > > > Given the age of those libraries, we would probably need to move > forward > > > with upgrading Jetty to 12 and Lucene to 9. It’s worth evaluating > whether > > > those modules are still essential or if deprecation is the more > > sustainable > > > path. > > > > > > Thanks again for your thoughtful input. > > > > > > > > > Best regards, > > > > > > Jinwoo Hwang (he/him/his) > > > > > > > > > > > > SAS® Research and Development > > > > > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWViNGM1NjljMWQ3MzFmNzE5MzAyMGVmMjJhODUwZDU6Nzo3NDQ5OjIwZDE0MTJiMTY5ZmQ4NDVlMzA0OTUwZDRmYWJkNzI5YmNiNDIxNzZlZTkxY2MyY2JmNTUwMzk0N2FiZTU1OGM6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C69777ae10c004a6b958d08ddf86c9330%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638939867429619964%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=caNLHz4n92nkY7gU7iPQU%2BgZM4sQEIcOzol8dzvB8dM%3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2Fjinwoohwang.com%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWViNGM1NjljMWQ3MzFmNzE5MzAyMGVmMjJhODUwZDU6NzpkMzhiOmE3MDdjODM1MDNlNjMzNWFjZWVmYTA4N2UzNjYxNjcyZWUwNTZkMDViZDliOWIzYWEyN2FhZmQxMWMyZWU2OTk6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C69777ae10c004a6b958d08ddf86c9330%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638939867429630880%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7hqSCHTUYTOudwdECyFiE94KDGetTjfEz9eDOhxoW5U%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWViNGM1NjljMWQ3MzFmNzE5MzAyMGVmMjJhODUwZDU6Nzo3NDQ5OjIwZDE0MTJiMTY5ZmQ4NDVlMzA0OTUwZDRmYWJkNzI5YmNiNDIxNzZlZTkxY2MyY2JmNTUwMzk0N2FiZTU1OGM6cDpUOk4> > > > > > > > > > > > > From: Leon Finker <[email protected]> > > > Date: Friday, September 19, 2025 at 2:49 PM > > > To: [email protected] <[email protected]> > > > Subject: Re: [DISCUSS] Proposal for Apache Geode 2.0.0 – Call for > > > Community Input and Reviewers > > > > > > EXTERNAL > > > > > > Hi Jinwoo, > > > > > > Thanks to everyone for picking up the geode and moving forward! > > > > > > I want to mention a few other major libraries that are left behind on > EOL > > > versions now: Jetty and Lucene (6 years old). Not sure if they are even > > > needed and maybe those modules should be deprecated if there is no > > interest > > > in maintaining them. > > > > > > On Fri, Sep 19, 2025 at 7:29 AM Jinwoo Hwang <[email protected]> > wrote: > > > > > > > Dear Apache Geode Developer Community, > > > > > > > > Thank you for your continued support in delivering version 1.15.2. > > After > > > a > > > > three-year hiatus, this milestone reflects the resilience and > > > collaboration > > > > that define our community. Special appreciation to Niall for > resolving > > > the > > > > SVN permission issue—the last mile to our finish line. > > > > Now that we are almost at the finish line, let’s not slow down—let’s > > > > accelerate. > > > > > > > > I would like to propose Apache Geode 2.0.0, a major modernization > > effort > > > > that positions the project for long-term sustainability, stronger > > > security, > > > > and better developer experience. Below is a draft roadmap of proposed > > > > upgrades—each representing a significant leap forward: > > > > > > > > > > > > > > > > *Proposed Upgrades for Apache Geode 2.0.0* > > > > *Upgrade Java Runtime from 1.8 to 17* > > > > > > > > - Addresses numerous known vulnerabilities reported since 2019. > > > > - Brings performance improvements and modern language features. > > > > - Aligns with long-term support (LTS) standards. > > > > > > > > *Upgrade Spring Framework to Version 6* > > > > > > > > - Resolves numerous CVEs that have been reported in prior > versions. > > > > While we cannot confirm whether Apache Geode is directly affected, > > > > upgrading is a proactive step toward minimizing exposure. > > > > - Aligns with Java 17 and Jakarta EE 9. > > > > - Introduces cleaner APIs and reactive programming support. > > > > > > > > *Upgrade Spring Security to Version 6* > > > > > > > > - Addresses several high-severity vulnerabilities. Again, while we > > > > cannot confirm Geode’s exposure, upgrading ensures alignment with > > > > current > > > > security best practices. > > > > - Simplifies configuration with SecurityFilterChain. > > > > - Aligns with Jakarta EE 9 and modern security practices. > > > > - Offers a zero-known-vulnerability baseline in current releases. > > > > > > > > *Migrate from Java EE to Jakarta EE 9* > > > > > > > > - Required for Java 17+ compatibility. > > > > - Provides updated specifications and active community support. > > > > > > > > *Update Build Configuration for Java 17 Compatibility* > > > > > > > > - Upgrade Gradle Version 6 to 7.3.3 to Support Java 17 Tool Chain. > > > > - Enables consistent builds across environments. > > > > - Improves build performance and dependency resolution. > > > > - Aligns with modern standards and mitigates known risks. > > > > > > > > *Remediation of any undisclosed security vulnerabilities* > > > > > > > > > > > > These are not just technical upgrades—they are strategic investments > in > > > the > > > > future of Apache Geode. They will help us stay relevant, secure, and > > > > performant in a rapidly evolving ecosystem. > > > > > > > > To make this vision a reality, we need your help. This release is > > already > > > > generating excitement—so much so that I’ve been personally contacted > by > > > > individuals asking how they can contribute to the Geode community. > That > > > > kind of energy is rare, and we’d be remiss not to harness it. > > > > > > > > We’re looking for: > > > > > > > > - Feedback to make this roadmap more comprehensive and aligned > with > > > > community needs. > > > > - Volunteers to help review pull requests as we finalize these > > > changes. > > > > - Contributors interested in shaping the future of Apache Geode > > > through > > > > code, documentation, testing, and ideas. > > > > > > > > > > > > Whether you’re a long-time committer or a new contributor, your > > > > participation will be instrumental in making Apache Geode 2.0.0 a > > > reality. > > > > Let’s build the future of Geode, together—with clarity, purpose, and > > > > momentum. > > > > > > > > Best regards, > > > > Jinwoo Hwang (he/him/his) > > > > > > > > SAS® Research and Development > > > > > > > > > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YzAzMjljOWVhOTkxMGJhN2U5YjcyODFkMDk5ZGJkZGQ6Nzo3N2M5OmYwYjgxYzIwNWUxZjM1NDFjNDZhZTk5YzhmZWMwMzZlN2ExODJjNmM4NjUwZWU2MTgzNDU5NDM2ZTAxYmQyMjE6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C69777ae10c004a6b958d08ddf86c9330%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638939867429637135%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ab8SsNxBO3vBWr1yaJXSvhYY%2BzkOG%2BIT7TZM8aPXR%2F4%3D&reserved=0<https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YzAzMjljOWVhOTkxMGJhN2U5YjcyODFkMDk5ZGJkZGQ6Nzo3N2M5OmYwYjgxYzIwNWUxZjM1NDFjNDZhZTk5YzhmZWMwMzZlN2ExODJjNmM4NjUwZWU2MTgzNDU5NDM2ZTAxYmQyMjE6cDpUOk4> > > > < > > > > > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YzAzMjljOWVhOTkxMGJhN2U5YjcyODFkMDk5ZGJkZGQ6Nzo3N2M5OmYwYjgxYzIwNWUxZjM1NDFjNDZhZTk5YzhmZWMwMzZlN2ExODJjNmM4NjUwZWU2MTgzNDU5NDM2ZTAxYmQyMjE6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C69777ae10c004a6b958d08ddf86c9330%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638939867429643159%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FBx8MPOAGYdENUucpFnyUM7VmLCB82HkhSDzN1lJ4Lg%3D&reserved=0<https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YzAzMjljOWVhOTkxMGJhN2U5YjcyODFkMDk5ZGJkZGQ6Nzo3N2M5OmYwYjgxYzIwNWUxZjM1NDFjNDZhZTk5YzhmZWMwMzZlN2ExODJjNmM4NjUwZWU2MTgzNDU5NDM2ZTAxYmQyMjE6cDpUOk4> > > > > > > > > > > > > > > > > -- > Thanks & Regards > Kishor P. Bachhav >
