Skip to content
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

Document Jigsaw requirements #7838

Open
Vampire opened this issue Apr 3, 2018 · 2 comments
Open

Document Jigsaw requirements #7838

Vampire opened this issue Apr 3, 2018 · 2 comments

Comments

@Vampire
Copy link
Contributor

@Vampire Vampire commented Apr 3, 2018

When using netty in a modular context, you need to add

  • requires jdk.unsupported to your module descriptor or --add-modules jdk.unsupported to the Java call in a javapackager downstripped JRE and
  • -Dio.netty.tryReflectionSetAccessible=true and
  • --add-opens java.base/java.nio=io.netty.common and
  • --add-exports java.base/jdk.internal.misc=io.netty.common to the Java call no matter whether downstripped JRE or full JRE

for the java.nio.DirectByteBuffer, java.nio.Bits, sun.misc.Unsafe and jdk.internal.misc.Unsafe recognitions in io.netty.util.internal.PlatformDependent0 to work properly and not get exceptions on DEBUG level.

This should be documented, e. g. in the readme where also the module names are mentionend and that you need to include everything manually.


Btw. you can produce multi-release JAR files easily that are full named explicit modules in modular context in Java 9 and up but are still usable fine with Java 8 and older. This way you can provide the dependency information for the modules properly, including the dependency on jdk.unsupported.

@normanmaurer

This comment has been minimized.

Copy link
Member

@normanmaurer normanmaurer commented Oct 15, 2018

@Vampire we would love a PR for documentation on all of this... That said I think it even works without all of this atm.

@Vampire

This comment has been minimized.

Copy link
Contributor Author

@Vampire Vampire commented Oct 16, 2018

As I said, as you have less performant / good / whatever fall-backs when the recognition does not find the respective classes, of course all works. But for the recognition to work, so that the optimized methods can be used and to not get exceptions printed on DEBUG level, you need those options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.