Open Java modules for Snowflake setup #9664
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
In the absence of other workarounds we need to ensure that every Java process is started with extra options: `--add-opens=java.base/java.nio=ALL-UNNAMED` Verified locally. Note: this only affects LS and cli will continue to crash on examples using Snowflake. Closes #9475.
hubertp
added
the
CI: No changelog needed
hubertp
requested review from
jdunkerley,
radeusgd,
GregoryTravis,
AdRiley,
4e6,
JaroslavTulach and
Akirathan
as code owners
JaroslavTulach
approved these changes
Apr 10, 2024
Akirathan
approved these changes
Apr 10, 2024
distribution/lib/Standard/Snowflake/0.0.0-dev/src/Snowflake_Details.enso
Outdated
Show resolved
Hide resolved
I think I don't understand. Does this not affect the launcher as well? If I use |
radeusgd
approved these changes
Apr 10, 2024
|
Btw. the proper way to address the needs of Snowflake JDBC driver is to load each library's JAR files as a separate |
Tracked in #7082 |
You can always prefix Having said that, I will add it to the script by default, for convenience. |
hubertp
added
the
CI: Clean build required
hubertp
added a commit
that referenced
this pull request
Jan 30, 2025
This change adds Snowflake's jdbc library packaged in a fat jar. It's not a straightword inclusion mostly due to the complicated way how the jar itself is constructed: - it's a fat jar so includes other dependencies which we sometimes include - they are patching some of the dependencies and putting them under their subpackage making it impossible to use the `snowflake-jdbc-thin` dependency - a number of configs are spurious and need to be disabled - `FileTypeDetector` provider leads to runtime-/build-time initialization confict that is impossible to workaround without disabling it - need to open `java.base` module, similarly to #9664, due to Arrow's usage - `java.nio.DirectByteBuffer` constructor changed its signature in JDK21 from `(long, int)` to `(long, long)` which caused problems for the constructed NI and needed to be reflected in the config
2 tasks
hubertp
added a commit
that referenced
this pull request
Jan 30, 2025
This change adds Snowflake's jdbc library packaged in a fat jar. It's not a straightword inclusion mostly due to the complicated way how the jar itself is constructed: - it's a fat jar so includes other dependencies which we sometimes include - they are patching some of the dependencies and putting them under their subpackage making it impossible to use the `snowflake-jdbc-thin` dependency - a number of configs are spurious and need to be disabled - `FileTypeDetector` provider leads to runtime-/build-time initialization confict that is impossible to workaround without disabling it - need to open `java.base` module, similarly to #9664, due to Arrow's usage - `java.nio.DirectByteBuffer` constructor changed its signature in JDK21 from `(long, int)` to `(long, long)` which caused problems for the constructed NI and needed to be reflected in the config
mergify bot
pushed a commit
that referenced
this pull request
Feb 3, 2025
This change adds Snowflake's jdbc library packaged in a fat jar. Closes #12151. # Important Notes It's not a straightforward inclusion mostly due to the complicated way how the jar itself is constructed: - it's a fat jar so includes other dependencies which we sometimes already include (possibly room for improvement, if we are willing to risk some incompatibilities) - they are patching some of the dependencies and putting them under their subpackage making it impossible to use the `snowflake-jdbc-thin` dependency - a number of configs are spurious and need to be disabled - `FileTypeDetector` provider leads to runtime-/build-time initialization conflict that is impossible to workaround without disabling it - need to open `java.base` module, similarly to #9664, due to Arrow's usage - `java.nio.DirectByteBuffer` constructor changed its signature in JDK21 from `(long, int)` to `(long, long)` which caused problems for the constructed NI and needed to be reflected in the config
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.
Pull Request Description
In the absence of other workarounds we need to ensure that every Java process is started with extra options:
--add-opens=java.base/java.nio=ALL-UNNAMEDVerified locally. Note: this only affects LS and cli will continue to crash on examples using Snowflake.
Tested manually.
Closes #9475.
Important Notes
Some workarounds are being considered but we need this change sooner than later.
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
./run ide build.