[
https://issues.apache.org/jira/browse/ARROW-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16789265#comment-16789265
]
Praveen Kumar Desabandu commented on ARROW-4819:
------------------------------------------------
Hi,
Thanks for trying this out.
Couple questions
# Is this a temporary solution until Drill moves to Arrow completely? If yes
can this change reside in a private fork?
# If not - then another solution would be have another JNI layer probably
living in Drill that invokes the Gandiva C++ library directly.
# I am a bit hesitant to make these methods public as it breaks the
encapsulation we had for the java binding layer..
If you are planning to pass in drill value vector buffers to the Gandiva
execution layer, the runtime behavior might be unexpected since we assume arrow
buffer format in a lot of places for e.g. decimal to be always 16 bytes in
little endian format etc.
[~jacq...@dremio.com] [~Pindikura Ravindra] for more opinions.
Thx.
> [Java] Make JniWrapper native method be public
> ----------------------------------------------
>
> Key: ARROW-4819
> URL: https://issues.apache.org/jira/browse/ARROW-4819
> Project: Apache Arrow
> Issue Type: Improvement
> Components: Java
> Reporter: weijie.tong
> Priority: Major
>
> The goal is to integrate Gandiva into apache Drill project. Now drill and
> arrow has some differences at the column in memory representation. Drill has
> a 2.0 plan to integrate arrow. Now I want to do some prior work to integrate
> arrow lib into drill project. The first thing is to make JniWrapper's package
> level methods be public ones. Maybe we can rename this classes as
> UnsafeJniWrapper like java's Unsafe class to allow others to invoke these
> methods directly.
> So what's your opinion about this advice ? If ok , I will submit a
> corresponding PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
