Repository navigation
kt_jvm_test does not include native library paths in java.library.path #1088
Description
java_test collects the paths to native libraries from JavaInfo.transitive_native_libraries and specifies them in the java.library.path property. kt_jvm_test does not do this.
The current workaround if loading native libraries is to use a combination of java_test and kt_jvm_library instead. e.g.
kt_jvm_library(
name = "my_test",
srcs = ["MyTest.kt"],
)
java_test(
name = "MyTest",
test_class = "package.for.MyTest",
runtime_deps = [":my_test"],
)
Activity
restingbull commentedon Jan 5, 2024
Where are the native libraries coming from in the example?
SanjayVas commentedon Jan 8, 2024
Sorry, I guess I forgot to include that part in the workaround example. The native dep would be a shared library (cc_binary target with linkshared = True) specified in the
depsof the library target.TwoClocks commentedon Oct 1, 2024
This is also true for
kt_jvm_binary. You can not addcc_librarydep viatuntime_deps. Bothkt_jvm_binaryandkt_jvm_testfail with this error.Error in check_provider_instances: at index 0 of runtime_deps, got element of type NoneType, want JavaInfoFor
kt_jvm_binaryyou can work around this by usingjava_binary, and addingKtto the end of the class name.But there isn't a work around for
kt_jvm_test. AFAICT there is no way to write a test that requires a.sofrom the project.SanjayVas commentedon Oct 1, 2024
@TwoClocks The workaround I mentioned above (using
java_test) does work for running tests written in Kotlin transitively depending on a native library. In my project, we've made a reference to this issue every time we've used that workaround.TwoClocks commentedon Oct 1, 2024
@SanjayVas Works great. Thanks!
github-actions commentedon Mar 12, 2026
Thanks for your contributions to rules_kotlin!
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
SanjayVas commentedon Mar 13, 2026
Still needs fixing. We have many TODOs in our codebase waiting for this.
SanjayVas commentedon Sep 14, 2026
Looks like #1498 got reverted in #1740 so this issue should be reopened until the replacement #1742 is merged.
Bencodes commentedon Sep 15, 2026
I accidentally merged this PR and and revered so that the present changes could get re-reviewed by someone.
Are you able to test this out against your project and let us know if it works?
SanjayVas commentedon Sep 15, 2026
It's messy in our current set of modules to use unreleased versions of rules_kotlin.