Skip to content

[DISCUSS] Future Roadmap, Technical Improvements and Community Growth #951

Open
Open
[DISCUSS] Future Roadmap, Technical Improvements and Community Growth#951
Labels
discussion welcomeWelcome to join the discussion together

Description

@psxjoy
psxjoy
opened on Jul 15, 2026

Hi community,

We are considering a new Apache Fesod(incubating) release around mid-August. The timeline is still tentative and will depend on development progress, testing results, and community feedback.

The upcoming release is expected to include routine improvements, such as:

  • Dependency upgrades
  • Bug fixes
  • New feature enhancements
  • Improvements based on community feedback

Besides the upcoming release, we would like to start a discussion about the future roadmap and development priorities of Apache Fesod(incubating).

The following items are initial ideas for discussion. We welcome feedback and suggestions from the community.

1. Introduce fesod-doc Module

Currently, Apache Fesod(incubating) mainly focuses on spreadsheet processing. As the ecosystem evolves, document processing capabilities may become a valuable extension.

We are considering introducing a new module:

fesod-doc

Potential goals:

  • Provide document processing capabilities within the Apache Fesod(incubating) ecosystem
  • Reuse existing Apache Fesod(incubating) design principles where applicable
  • Keep the module independent from the core spreadsheet functionality

Topics for discussion:

  • What document formats should be supported first?
  • What capabilities should be included in the initial version?
  • Should common abstractions be shared between different Apache Fesod(incubating) modules?
  • What is the right timing to introduce this module?

2. Add Benchmark Module

Performance is an important aspect of a data processing library.

We propose adding a benchmark module to provide a consistent way to evaluate:

  • Read/write performance
  • Memory usage
  • Large file processing capability
  • Performance changes between releases

The benchmark module would:

  • Be maintained as part of the Apache Fesod(incubating) project
  • Not be included in released artifacts
  • Provide reproducible performance tests for contributors and users

Possible implementation:

  • JMH-based benchmarks
  • Different data size and usage scenarios
  • Performance regression tracking

Topics for discussion:

  • Which benchmark scenarios are most meaningful?
  • Should benchmarks run periodically in CI?
  • How should benchmark results be shared with the community?

3. Gradually Reduce CGLIB Dependency

Some parts of Apache Fesod(incubating) currently rely on CGLIB.

Considering:

  • Long-term dependency maintenance
  • Compatibility with newer Java versions
  • Simplifying project dependencies

We would like to gradually reduce unnecessary CGLIB usage.

Possible approaches:

  • Replace CGLIB-based implementations with standard Java mechanisms where possible
  • Evaluate lightweight alternatives when needed
  • Ensure compatibility and performance are not negatively affected

This would be a gradual improvement rather than an immediate breaking change.

Topics for discussion:

  • Which components currently depend on CGLIB?
  • What migration approach would minimize compatibility impact?
  • Should this be treated as a long-term technical improvement?

4. Establish Regular Community Sync Meetings

As the Apache Fesod(incubating) community grows, regular communication may help contributors stay aligned on development progress, roadmap planning, and community activities.

We would like to discuss establishing regular community sync meetings, such as:

  • Bi-weekly community sync meeting
  • Monthly community meeting

Potential topics:

  • Release planning and progress updates
  • Roadmap discussions
  • Technical proposals
  • Contributor onboarding
  • Community activities

Possible formats:

  • Open community meeting
  • Optional attendance
  • Meeting notes shared publicly for transparency

Topics for discussion:

  • What meeting frequency works best?
  • What topics should be covered?
  • Which timezone and communication channel would be convenient?

Open Discussion

The items above are only initial proposals.

We would like to hear feedback from the community:

  • What features or improvements should Fesod prioritize?
  • Are there any pain points in current usage?
  • Are there areas where Fesod can better support users and developers?
  • Are there contributors interested in leading specific roadmap items?

Your feedback and ideas are highly appreciated.

Thanks!

Activity

  1. psxjoy
    added
    discussion welcomeWelcome to join the discussion together
    on Jul 15, 2026
  2. psxjoy
    pinned this issue on Jul 15, 2026

  3. delei commented on Jul 16, 2026

    @delei
    delei
    on Jul 16, 2026
    Member

    Support Apache POI version 6.x

    I suggest that we could add a support plan for Apache POI 6.0.0 in the roadmap, which is currently under development.

    It should be noted that the target of POI 6.0.0 might be Java 17. Once it is officially released, we will continue to discuss the version support and release maintenance policies.

    References

  4. delei commented on Jul 16, 2026

    @delei
    delei
    on Jul 16, 2026
    Member

    About the CGLIB library

    As discussed in issue #531 , and the approach based on the SAXParserFactory class.
    I suggest we try using byte-buddy as an alternative to cglib, but there are a few points to consider:

    • Design a well-structured API that enables users to select the supported ASM framework.
    • Ensure that there is no significant performance loss.
    • A transition period is needed.

    I believe our ultimate goal is not to remove support for cglib entirely, but to replace the default implementation. Ultimately, users will be able to choose from a range of supported ASM frameworks.

  5. bengbengbalabalabeng commented on Jul 16, 2026

    @bengbengbalabalabeng
    bengbengbalabalabeng
    on Jul 16, 2026
    Contributor

    About the fesod-doc Module

    Some of my thoughts on fesod-doc have been compiled here: #946

    Main content includes: format support, capability boundaries, and some of my thoughts on API-Style. To avoid repetition, please refer to the link for specifics.

  6. nkuprins commented on Jul 16, 2026

    @nkuprins
    nkuprins
    on Jul 16, 2026
    Member

    About the fesod-doc Module

    For the fesod-doc module, are you also considering a native data bridge with fesod-sheet? It would be amazing to be able to stream a massive Excel file row-by-row directly into a Word template to batch-generate thousands of documents (like invoices) on the fly, without ever loading the whole dataset into memory.

  7. nkuprins commented on Jul 28, 2026

    @nkuprins
    nkuprins
    on Jul 28, 2026
    Member

    About the fesod-doc and benchmarks

    How would contributors clearly identify which commits belong to fesod-sheet, which to fesod-doc, and which to benchmarks?

    I think this is a question worth asking (assuming these parts will be continuously updated). It may be considered superfluous, but IMO expanding the commit specification can be on the table. For example,

    • feat(sheet): support for xxx
    • feat(doc): support for xxx
    • bench: or perf: or feat(bench)...

  8. leehaut commented on Aug 9, 2026

    @leehaut
    leehaut
    on Aug 9, 2026
    Contributor

    Thanks for opening this discussion. A few concise thoughts:

    1. Priority: I’d suggest focusing first on a benchmark module and a gradual CGLIB reduction (e.g. a BeanPropertyAccessor SPI with a JDK-based default + migration period). These strengthen the core sheet story before expanding the ecosystem.

    2. fesod-doc: Agree with keeping it independent and starting small — .docx only, prioritize template fill / write, mark the first API as experimental. A sheet→doc streaming bridge is valuable, but better as a later integration than MVP scope.

    3. Also +1 to planning POI 6.x / Java baseline policy early, and adopting scoped conventional commits like feat(sheet|doc|bench):.

  9. bengbengbalabalabeng commented on Aug 16, 2026

    @bengbengbalabalabeng
    bengbengbalabalabeng
    on Aug 16, 2026
    Contributor

    About the CGLIB library

    Based on previous discussions with @delei and @leehaut

    Here is a proposal for decoupling the BeanWrapper architecture based on SPI.

    Draft:
    Phase 1 and Phase 2 refactoring and validation are completed. The draft implementation is available at: #1018

    1. SPI Design

    • BeanWrapper: Defines standard interfaces for property reading/writing ...
    • BeanWrapperProvider: SPI contract providing BeanWrapper create(Object target) and int getOrder() methods.
    • BeanWrappers: Factory utility class that handles SPI auto-discovery and priority sorting (via ServiceLoader based on getOrder()).

    2. Involved Modules & Responsibilities

    2.1 fesod-common

    • Role: Provides core SPI interfaces (BeanWrapper / BeanWrapperProvider), the factory utility (BeanWrappers).

    2.2 fesod-beans

    • Role: Parent module managing specific implementation modules such as cglib, byte-buddy, etc.

    2.3 fesod-beans/fesod-beans-cglib

    • Role: Encapsulates the SPI implementation backed by CGLIB BeanMap (Order = 500).
    • Dependencies: fesod-common, fesod-shaded

    2.4 fesod-beans/fesod-beans-bytebuddy (Experimental)

    • Role: Encapsulates the SPI implementation backed by Byte-Buddy dynamic bytecode (Order = 300).
    • Dependencies: fesod-common, byte-buddy ...

    3. Implementation Roadmap

    • Phase 1: SPI Abstraction & CGLIB Module Separation

      • Introduce SPI interfaces and the BeanWrappers factory in fesod-common.
      • Establish the fesod-beans-cglib module and complete CGLIB adaptation.

    • Phase 2: fesod-sheet Core Logic Refactoring & API Cleanup

      • Remove fesod-sheet's direct dependency on fesod-shaded, replacing it with fesod-beans-cglib.
      • Replace BeanMapUtils.create() usages with BeanWrappers.create().
      • Deprecate/clean up BeanMapUtils related APIs to prevent downstream build/runtime failures caused by hard CGLIB dependencies when switching fesod-beans-* implementations.

    • Phase 3: Establish fesod-beans-bytebuddy & Byte-Buddy Adaptation (Need more information)

  10. delei commented on Aug 16, 2026

    @delei
    delei
    on Aug 16, 2026
    Member

    About the CGLIB library

    ...

    • Phase 3: Establish fesod-beans-bytebuddy & Byte-Buddy Adaptation (Need more information)

    Hi @bengbengbalabalabeng

    I'm interested in this. In my spare time, could I cooperate to participate in this PR, such as Phase 3 ?

  11. bengbengbalabalabeng commented on Aug 16, 2026

    @bengbengbalabalabeng
    bengbengbalabalabeng
    on Aug 16, 2026
    Contributor

    About the CGLIB library

    ...

    • Phase 3: Establish fesod-beans-bytebuddy & Byte-Buddy Adaptation (Need more information)

    Hi @bengbengbalabalabeng

    I'm interested in this. In my spare time, could I cooperate to participate in this PR, such as Phase 3 ?

    Sure, welcome :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussion welcomeWelcome to join the discussion together

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions