[Cronet] Call System.loadLibrary() from impl not API

[Cronet] Call System.loadLibrary() from impl not API

When a shared library is loaded, the caller's ClassLoader is used for two
important things:
1. to load classes for JNI bindings, and
2. to find the shared library
Since Cronet's shared library is tied to the implementation, Cronet should
be sure to call System.loadLibrary() from the implementation, not the API.
This way the impl's ClassLoader will be used which could be different from
the API's ClassLoader, and the impl's ClassLoader is the one that will be
able to load the impl classes and locate the shared library.

Committed: https://crrev.com/ae2265a39356fdec3fe217293c6e93e77893be15
Cr-Commit-Position: refs/heads/master@{#407452}

[kapishnikov, 2016-06-02 16:33:37]

kapishnikov@chromium.org changed reviewers:
+ kapishnikov@chromium.org

[kapishnikov, 2016-06-02 16:33:38]

https://codereview.chromium.org/2020373002/diff/1/components/cronet/android/j...
File
components/cronet/android/java/src/org/chromium/net/impl/CronetLibraryLoader.java
(right):

https://codereview.chromium.org/2020373002/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/impl/CronetLibraryLoader.java:45:
builder.libraryLoader().loadLibrary(builder.libraryName());
If the client passes the custom library loader but the Java implementation is
loaded from dynamite, calling the custom loader may not work. The custom class
loader has no way to access dynamite. I guess, we should somehow prohibit the
custom loader if the code is loaded from dynamite.

[pauljensen, 2016-07-22 14:18:05]

Andrei, would you like to review this?

https://codereview.chromium.org/2020373002/diff/1/components/cronet/android/j...
File
components/cronet/android/java/src/org/chromium/net/impl/CronetLibraryLoader.java
(right):

https://codereview.chromium.org/2020373002/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/impl/CronetLibraryLoader.java:45:
builder.libraryLoader().loadLibrary(builder.libraryName());
On 2016/06/02 16:33:38, kapishnikov wrote:
> If the client passes the custom library loader but the Java implementation is
> loaded from dynamite, calling the custom loader may not work. The custom class
> loader has no way to access dynamite. I guess, we should somehow prohibit the
> custom loader if the code is loaded from dynamite.

Ya, we'll probably want to @hide CronetEngine.setLibraryLoader()

[pauljensen, 2016-07-22 14:18:42]

https://codereview.chromium.org/2020373002/diff/1/components/cronet/android/j...
File
components/cronet/android/java/src/org/chromium/net/impl/CronetLibraryLoader.java
(right):

https://codereview.chromium.org/2020373002/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/impl/CronetLibraryLoader.java:45:
builder.libraryLoader().loadLibrary(builder.libraryName());
On 2016/07/22 14:18:04, pauljensen wrote:
> On 2016/06/02 16:33:38, kapishnikov wrote:
> > If the client passes the custom library loader but the Java implementation
is
> > loaded from dynamite, calling the custom loader may not work. The custom
class
> > loader has no way to access dynamite. I guess, we should somehow prohibit
the
> > custom loader if the code is loaded from dynamite.
> 
> Ya, we'll probably want to @hide CronetEngine.setLibraryLoader()

I should mention I added this to my TODO list for integration.

[kapishnikov, 2016-07-22 14:41:48]

Looks good. We should later make sure that CronetEngine.setLibraryLoader() is
hidden or functions properly. LGTM

[pauljensen, 2016-07-25 11:32:38]

The CQ bit was checked by pauljensen@chromium.org

[commit-bot: I haz the power, 2016-07-25 11:32:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-25 11:58:58]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-07-25 12:00:06]

Description was changed from

==========
[Cronet] Call System.loadLibrary() from impl not API

When a shared library is loaded, the caller's ClassLoader is used for two
important things:
1. to load classes for JNI bindings, and
2. to find the shared library
Since Cronet's shared library is tied to the implementation, Cronet should
be sure to call System.loadLibrary() from the implementation, not the API.
This way the impl's ClassLoader will be used which could be different from
the API's ClassLoader, and the impl's ClassLoader is the one that will be
able to load the impl classes and locate the shared library.
==========

to

==========
[Cronet] Call System.loadLibrary() from impl not API

When a shared library is loaded, the caller's ClassLoader is used for two
important things:
1. to load classes for JNI bindings, and
2. to find the shared library
Since Cronet's shared library is tied to the implementation, Cronet should
be sure to call System.loadLibrary() from the implementation, not the API.
This way the impl's ClassLoader will be used which could be different from
the API's ClassLoader, and the impl's ClassLoader is the one that will be
able to load the impl classes and locate the shared library.

Committed: https://crrev.com/ae2265a39356fdec3fe217293c6e93e77893be15
Cr-Commit-Position: refs/heads/master@{#407452}
==========

[commit-bot: I haz the power, 2016-07-25 12:00:07]

Patchset 2 (id:??) landed as
https://crrev.com/ae2265a39356fdec3fe217293c6e93e77893be15
Cr-Commit-Position: refs/heads/master@{#407452}