jni.h-没有这样的文件或目录-正确设置JAVA_HOME环境变量

如何解决jni.h-没有这样的文件或目录-正确设置JAVA_HOME环境变量

我目前正在尝试在Linux的Windows子系统中使用jni.h。

每当我尝试设置/运行它时，都会收到此错误消息。

我只是想知道如何成功地正确设置我的Java_HOME变量，以便它可以找到JNI.h

由于我还不知道如何设置路径，因此我真的不知道从哪里开始，因此非常需要任何帮助。

到目前为止，我的两个build.gradle文件都包含以下内容：

这是我的c子项目中的build.gradle

plugins {
    // We're actually using C++,but we can essentially pretend that it's C.
    // The cpp-library plugin compiles our C/C++ code and generates a library file.
    id 'cpp-library'
}

    tasks.withType(CppCompile).configureEach 
    {
    
    // The actual 'jni.h' file lives in the 'include' directory,but there are 
    also a series of 
    // other,platform-specific header files in 'include/linux' and/or 
    'include/win32'. Your actual
    // JDK may only have one of these platform-specific directories.
    
    includes "$System.env.JAVA_HOME/include"
    includes "$System.env.JAVA_HOME/include/linux"
    includes "$System.env.JAVA_HOME/include/win32"
    includes "$System.env.JAVA_HOME/include/win64"
}

library {
    // Define the library's name. (The file produced will be 'lib<baseName>.so' on Linux or 
    // '<baseName>.dll' on Windows.)
    baseName = 'example_c_library'

    // Create a 'shared' library only (not a 'static' library).
    linkage = [Linkage.SHARED]
    
    // What is the target platform?
    targetMachines = [
        machines.linux.x86_64,machines.windows.x86_64,machines.macOS.x86_64
    ]
}

这是我的Java子项目中的build.gradle

plugins {
    id 'java'
    id 'application'
}

// We need Gradle to finish configuring the other sub-project first,because we need to
// refer to two of its tasks below.
evaluationDependsOn ':c_library'

def libTasks = project(':c_library').tasks
def debugLibTask = libTasks.matching{ it.name.startsWith('linkDebug') }.first()
def releaseLibTask = libTasks.matching{ it.name.startsWith('linkRelease') }.first()

dependencies {
    // Make this subproject ('java_app') depend on the file produced by the linking task in the 
    // other subproject.
    runtimeOnly files(releaseLibTask.linkedFile)
    
    // This declaration is more convoluted than you might expect. We can't simply depend on the 
    // other subproject as a whole,because that makes the Java plugin complain that it isn't 
    // another Java project. There's no automated logic for tying a C library into a Java 
    // application.
    
    // Instead,this dependency simply causes our C library file to be included as part of the Java 
    // application's distributable .zip file. We then have to do some setting up,in 'run{}' and 
    // 'startScripts{}',to ensure that Java will be able to load the library.
}

application {
    mainClassName = 'org.example.ExampleJavaApp'
}

run {
    // Make 'gradlew run' set the library path correctly. There is a Java "system property" for 
    // this,which needs to be set to the *directory* containing the shared library.
    
    // We first depend on the 'linkDebug' task that creates the debug version of the library,to
    // ensure that task runs before the 'run' task. Then we make a few more calls to extract the 
    // actual directory,and set the library path.
    
    // Debug vs release? Gradle builds two versions of our C code with different compiler options,// one intended for debugging (which is what we're theoretically doing when we execute 'run'),// and one for release (which is what the final .zip file is for).
    
    dependsOn debugLibTask
    systemProperty 'java.library.path',debugLibTask.linkedFile.get().asFile.parentFile
}

startScripts {
    // Make the start-up scripts (both UNIX and Windows) set the library path correctly,so that 
    // our application is properly distributable.
    
    // When our application is distributed,the native library will live inside the same 'lib/' 
    // directory that contains the rest of our code. So the library path needs to be the 'lib/' 
    // directory. However,we can't hardcode the location of this directory,because we can't know 
    // in advance where the user has installed the application. Instead,we have to get the 
    // start-up script (both the UNIX and Windows version of it) to figure it out.

    // How we do *that* is a bit hacky though. We first tell the script generator how to set the 
    // path,but at the "last minute" we go in and tweak the result,because the actual path 
    // depends on a variable in the script that we can't access in the first instance.
    
    defaultJvmOpts = ['-Djava.library.path=APP_HOME_PLACEHOLDER/lib']
    
    doLast {
        unixScript.text = unixScript.text.replace('APP_HOME_PLACEHOLDER','$APP_HOME')
        windowsScript.text = windowsScript.text.replace('APP_HOME_PLACEHOLDER','%APP_HOME%')
    }
}