GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Decide on sync vs async DataFrame methods · Issue #25 · apache/datafusion-java

Decide on sync vs async DataFrame methods #25

New issue
Copy link
New issue
Copy link
Open
Feature
Open
Decide on sync vs async DataFrame methods#25
Feature
Copy link
Labels
enhancementNew feature or requestNew feature or request

Description

@andygrove
andygrove
opened on May 13, 2026
Issue body actions

Is your feature request related to a problem or challenge?

The current design is using synchronous execution. In https://github.com/pgwhalen/datafusion-java everything seems to be async.

Let's decide how we want to handle this before we add too much more code.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

Activity

  1. andygrove
    added
    enhancementNew feature or requestNew feature or request
    on May 13, 2026
  2. andygrove
    added the
    Feature
    issue type on May 13, 2026
  3. andygrove commented on May 13, 2026

    @andygrove
    andygrove
    on May 13, 2026
    MemberAuthor
    More actions

    @pgwhalen fyi

  4. pgwhalen commented on May 13, 2026

    @pgwhalen
    pgwhalen
    on May 13, 2026
    More actions

    While the old bindings in that repo present CompletableFutures, the newer ones I've written are synchronous. The work I've done is all on the datafusion-ffi-java branch in the datafusion-ffi-* directories, and I decided to follow the pattern this repo uses: presenting synchronous java calls with the rust bridge code using block_on.

    I know the state of that fork is very confusing, sorry; I intended to clean it up a bit more before publicizing and I will try to find some time in the next couple of days to do that.

    I originally had the goal of preserving the old bindings and marking them as deprecated, but with this new repo I'm not sure there's much point in that.

    Reacted by Andy Grove
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

    enhancementNew feature or requestNew feature or request

    Type

    Feature

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.