[Java] Move Netty memory manager into a separate module

[asfimport]

Move Netty memory manager into a separate module such that the basic allocator does not depend on it.

Reporter: Liya Fan / @liyafan82
Assignee: Ryan Murray / @rymurr

Related issues:

• [Java] Remove Netty references from ArrowBuf and move Allocator out of vector package (is a child of)

PRs and other links:

• GitHub Pull Request #6782
• GitHub Pull Request #7347

_{Note: This issue was originally created as ARROW-8230. Please see the migration documentation for further details.}

[asfimport]

Liya Fan / @liyafan82:
@rymurr Please feel free to assign it to yourself, if you are interested

[asfimport]

Ryan Murray / @rymurr:
Hey [~fan_li_ya],

I have had a look and I think I understand what the ticket wants, I thought it would be useful to double check before going into implementation.

The end goal of ARROW-4526 is to remove all the dependencies on Netty from arrow-memory. Correct?

This particular ticket is meant to create a new module (eg arrow-memory-netty) and remove all netty dependencies from arrow-memory. arrow-memory-netty will depend on arrow-memory but not the other way around. Does this sound roughly correct?

At first glance there are still a few references to netty in arrow-memory, including: ArrowBuf, BaseAllocator, BufferAllocator, BufferLedger as well as some usages of PlatformDependent in the Hasher classes. Some of which have already been marked Deprecated. Is the goal of this ticket to reconcile all of these references? I assume that given the deprecated flag was added by you only recently we only want to mark some things as deprecated rather than outright remove them

[asfimport]

Liya Fan / @liyafan82:
@rymurr
I think my understanding is close to yours.

However, it may not be feasible to remove the netty dependency completely in a single PR, as some refactoring work is required before we are ready to remove it completely.

So I think in this issue, we need to create the new module, move some classes there, mark some as deprecated, and leave the rest as future work.

[asfimport]

Ryan Murray / @rymurr:
Thanks [~fan_li_ya]!

I am thinking the same. Will post a patch soon. I think we will end up with a circular dependency between arrow-memory and arrow-memory-netty which I don't like but its temporary. Can discuss further once I post the PR

[asfimport]

Liya Fan / @liyafan82:
@rymurr Sounds good to me. Please go ahead with your PR.

[asfimport]

Liya Fan / @liyafan82:
Fixed by https://issues.apache.org/jira/browse/ARROW-9236