[
https://issues.apache.org/jira/browse/ARROW-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868186#comment-16868186
]
Ji Liu commented on ARROW-5579:
-------------------------------
[[email protected]] Any update for this? I do have some new thoughts, I
tried two different ways:
1、add arrow-shaded module and relocate package, then add this dependency in
arrow-format instead of flatbuffers, but in flatbuffer-generated code the
import is still origin package path and cause error.
2、Another approach is relocate package only in arrow-format since other modules
depends on this and replace "com.google.flatbuffers.*" such imports with new
relocated path such as "arrow.format.com.google.flatbuffers.*", in this way all
arrow-related modules use the same flatbuffers and will not conflict with user
applications. In this way, maven build fine but seems Intellij not support
resolve shaded dependencies(see
[https://youtrack.jetbrains.com/issue/IDEA-93855]), so manually run tests still
cause errors which is still a big problem.:(
> [Java] shade flatbuffer dependency
> ----------------------------------
>
> Key: ARROW-5579
> URL: https://issues.apache.org/jira/browse/ARROW-5579
> Project: Apache Arrow
> Issue Type: Task
> Components: Java
> Reporter: Pindikura Ravindra
> Assignee: Micah Kornfield
> Priority: Major
> Labels: pull-request-available
> Fix For: 0.14.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Reported in a [github issue|[https://github.com/apache/arrow/issues/4489]]
>
> After some [discussion|https://github.com/google/flatbuffers/issues/5368]
> with the Flatbuffers maintainer, it appears that FB generated code is not
> guaranteed to be compatible with _any other_ version of the runtime library
> other than the exact same version of the flatc used to compile it.
> This makes depending on flatbuffers in a library (like arrow) quite risky, as
> if an app depends on any other version of FB, either directly or
> transitively, it's likely the versions will clash at some point and you'll
> see undefined behaviour at runtime.
> Shading the dependency looks to me the best way to avoid this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
