[jira] [Issue Comment Deleted] (ARROW-5579) [Java] shade flatbuffer dependency

["Ji Liu (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARROW-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ji Liu updated ARROW-5579:
--------------------------
    Comment: was deleted

(was: Thanks for your reminder [~emkornfield@gmail.com], I have just tried this and it works fine.

Meanwhile I found a new work-around has similar effect, if we just remove <module>arrow-format</module> from parent pom just like adapter and gandiva, and it works fine.

Do you think this is this is reasonable solution since developers won't do anything?)

> [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: Ji Liu
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 0.14.0
>
>          Time Spent: 3h
>  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)