New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix a bug where Netty fails to load a shaded native library #12358
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Related: netty/netty-jni-util#13 Motivation: Netty can't load a shaded native library because `netty-jni-util` has a bug that appends an extra `/` when attmpting JNI `FindClass`. For example, `parsePackagePrefix()` returns `shaded//` instead of `shaded/`, leading to a bad attempt to load `shaded//io/netty/...`. Netty also doesn't handle the case where a shaded package name contains an underscore (`_`), such as `my_shaded_deps.io.netty.*`, because it simply replaces `.` with `_` and vice versa. JNI specification defines a mangling rule to avoid this issue: - https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#resolving_native_method_names Modifications: - Replace `_` into `_1` so that `parsePackagePrefix()` in `netty-jni-utils.c` can get the correct package name later. - Update the `docker-compose.yaml` so that the integration tests in `testsuite-shading` are always run as a part of CI, so we don't have a regression in the future. Result: - A user can use a functionality that requires a native library even if they shaded Netty *and* the shaded package name contains an underscore (`_`). Note: - This PR will not pass until we: - release `netty-jni-util 0.0.6.Final` - update `netty-tcnative` and this PR to depend on `netty-jni-util-0.0.6.Final`; and - release a new version of `netty-tcnative`.
trustin
added a commit
to netty/netty-tcnative
that referenced
this pull request
May 4, 2022
normanmaurer
pushed a commit
to netty/netty-tcnative
that referenced
this pull request
May 4, 2022
Motivation: We did not correctly escape chars when shading is used. Modifications: - Update jni-utils to fix bug Result: Fixes escaping Related: - #420 - netty/netty-jni-util#13 - netty/netty#12358
normanmaurer
added a commit
to netty/netty-incubator-codec-quic
that referenced
this pull request
May 5, 2022
Motivation: We did not correctly escape chars when shading is used. Modifications: - Update jni-utils to fix bug Result: Fixes escaping Related: - netty/netty-jni-util#13 - netty/netty#12358
normanmaurer
added a commit
to netty/netty-incubator-codec-quic
that referenced
this pull request
May 5, 2022
Motivation: We did not correctly escape chars when shading is used. Modifications: - Update jni-utils to fix bug Result: Fixes escaping Related: - netty/netty-jni-util#13 - netty/netty#12358
normanmaurer
pushed a commit
that referenced
this pull request
May 5, 2022
Related: netty/netty-jni-util#13 Motivation: Netty can't load a shaded native library because `netty-jni-util` has a bug that appends an extra `/` when attmpting JNI `FindClass`. For example, `parsePackagePrefix()` returns `shaded//` instead of `shaded/`, leading to a bad attempt to load `shaded//io/netty/...`. Netty also doesn't handle the case where a shaded package name contains an underscore (`_`), such as `my_shaded_deps.io.netty.*`, because it simply replaces `.` with `_` and vice versa. JNI specification defines a mangling rule to avoid this issue: - https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#resolving_native_method_names Modifications: - Replace `_` into `_1` so that `parsePackagePrefix()` in `netty-jni-utils.c` can get the correct package name later. - Update the `docker-compose.yaml` so that the integration tests in `testsuite-shading` are always run as a part of CI, so we don't have a regression in the future. Result: - A user can use a functionality that requires a native library even if they shaded Netty *and* the shaded package name contains an underscore (`_`).
normanmaurer
added a commit
that referenced
this pull request
May 6, 2022
…12362) Related: netty/netty-jni-util#13 Motivation: Netty can't load a shaded native library because `netty-jni-util` has a bug that appends an extra `/` when attmpting JNI `FindClass`. For example, `parsePackagePrefix()` returns `shaded//` instead of `shaded/`, leading to a bad attempt to load `shaded//io/netty/...`. Netty also doesn't handle the case where a shaded package name contains an underscore (`_`), such as `my_shaded_deps.io.netty.*`, because it simply replaces `.` with `_` and vice versa. JNI specification defines a mangling rule to avoid this issue: - https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#resolving_native_method_names Modifications: - Replace `_` into `_1` so that `parsePackagePrefix()` in `netty-jni-utils.c` can get the correct package name later. - Update the `docker-compose.yaml` so that the integration tests in `testsuite-shading` are always run as a part of CI, so we don't have a regression in the future. Result: - A user can use a functionality that requires a native library even if they shaded Netty *and* the shaded package name contains an underscore (`_`). Co-authored-by: Trustin Lee <t@motd.kr>
@normanmaurer The |
Will check |
raidyue
pushed a commit
to raidyue/netty
that referenced
this pull request
Jul 8, 2022
) Related: netty/netty-jni-util#13 Motivation: Netty can't load a shaded native library because `netty-jni-util` has a bug that appends an extra `/` when attmpting JNI `FindClass`. For example, `parsePackagePrefix()` returns `shaded//` instead of `shaded/`, leading to a bad attempt to load `shaded//io/netty/...`. Netty also doesn't handle the case where a shaded package name contains an underscore (`_`), such as `my_shaded_deps.io.netty.*`, because it simply replaces `.` with `_` and vice versa. JNI specification defines a mangling rule to avoid this issue: - https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#resolving_native_method_names Modifications: - Replace `_` into `_1` so that `parsePackagePrefix()` in `netty-jni-utils.c` can get the correct package name later. - Update the `docker-compose.yaml` so that the integration tests in `testsuite-shading` are always run as a part of CI, so we don't have a regression in the future. Result: - A user can use a functionality that requires a native library even if they shaded Netty *and* the shaded package name contains an underscore (`_`).
franz1981
pushed a commit
to franz1981/netty
that referenced
this pull request
Aug 22, 2022
) Related: netty/netty-jni-util#13 Motivation: Netty can't load a shaded native library because `netty-jni-util` has a bug that appends an extra `/` when attmpting JNI `FindClass`. For example, `parsePackagePrefix()` returns `shaded//` instead of `shaded/`, leading to a bad attempt to load `shaded//io/netty/...`. Netty also doesn't handle the case where a shaded package name contains an underscore (`_`), such as `my_shaded_deps.io.netty.*`, because it simply replaces `.` with `_` and vice versa. JNI specification defines a mangling rule to avoid this issue: - https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#resolving_native_method_names Modifications: - Replace `_` into `_1` so that `parsePackagePrefix()` in `netty-jni-utils.c` can get the correct package name later. - Update the `docker-compose.yaml` so that the integration tests in `testsuite-shading` are always run as a part of CI, so we don't have a regression in the future. Result: - A user can use a functionality that requires a native library even if they shaded Netty *and* the shaded package name contains an underscore (`_`).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related: netty/netty-jni-util#13
Motivation:
Netty can't load a shaded native library because
netty-jni-util
has abug that appends an extra
/
when attmpting JNIFindClass
. Forexample,
parsePackagePrefix()
returnsshaded//
instead ofshaded/
,leading to a bad attempt to load
shaded//io/netty/...
.Netty also doesn't handle the case where a shaded package name contains
an underscore (
_
), such asmy_shaded_deps.io.netty.*
, because itsimply replaces
.
with_
and vice versa. JNI specification definesa mangling rule to avoid this issue:
Modifications:
netty-jni-utils
to0.0.6.Final
which contains the fix forparsePackagePrefix()
._
into_1
so thatparsePackagePrefix()
innetty-jni-utils.c
can get the correct package name later.docker-compose.yaml
so that the integration tests intestsuite-shading
are always run as a part of CI, so we don't havea regression in the future.
Result:
ShadingIT
fails on macOS and Linux #12351they shaded Netty and the shaded package name contains an underscore
(
_
).Note:
netty-jni-util 0.0.6.Final
netty-tcnative
and this PR to depend onnetty-jni-util-0.0.6.Final
; andnetty-tcnative
.