You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Rok Mihevc (Jira)" <ji...@apache.org> on 2023/01/11 07:11:03 UTC

[jira] [Updated] (ARROW-705) [Java] Make Arrow library more shade-friendly

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

Rok Mihevc updated ARROW-705:
-----------------------------
    External issue URL: https://github.com/apache/arrow/issues/16325

> [Java] Make Arrow library more shade-friendly
> ---------------------------------------------
>
>                 Key: ARROW-705
>                 URL: https://issues.apache.org/jira/browse/ARROW-705
>             Project: Apache Arrow
>          Issue Type: Improvement
>            Reporter: Li Jin
>            Priority: Major
>
> Sometimes user of Arrow library have conflict in its dependency such as netty and wants to shade Arrow's dependency. 
> Because arrow has public classes (such as ArrowBuf) under io.netty namespace that is part of Arrow API, relocate the entire io.netty package will cause user code to break.
> Next, I tried to exclude all classes created by Arrow under io.netty package. This also breaks - UnsafeDirectLittleEndian extends a package private class in netty, therefore I need to relocate UnsafeDirectLittleEndian as well.
> The feedback is it's not clear how to shade netty dependency for Arrow, for now I shaded every thing under io.netty except for ArrowBuf and it "appears" to work, but I don't know if another class under memory/io/netty/buffer can be returned by a public API. Does it make sense to put API such as ArrowBuf under arrow package namespace? (Not saying we should do this, just wondering if that makes sense)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)