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

Various issues prevent fixing javah for jdk11+ #361

Open
wrestang opened this issue Aug 20, 2020 · 0 comments
Open

Various issues prevent fixing javah for jdk11+ #361

wrestang opened this issue Aug 20, 2020 · 0 comments

Comments

@wrestang
Copy link

wrestang commented Aug 20, 2020

The given/accepted workaround for javah not existing in java 10+ does not work when the java classes are not explicitly in the same module. While that is probably not the proper project setup, it worked with javah.
In order to work around this I first had to tackle the issue where the bcel dependency does not work with java 11 class files. This change actually precipitates the need for several other changes. Newer versions of the bcel dependency cannot actually be used as it is set up because the enforcer plugin will not allow it. The current maven plugins parent version brings in an enforcer that does not allow a version such as 11 or 1.11, so I had to update that version.
There may be an intermediary version, but the most up to date plugins version, 34, adds two features that break building completely. There is a rat plugin which ensures valid license files and a checkstyle plugin which enforces code styling. Fortunately, these can be skipped to prevent massive overhaul with the following properties:

<rat.ignoreErrors>true</rat.ignoreErrors>
<checkstyle.skip>true</checkstyle.skip>

After updating all of that, a newer bcel can be brought in... At that point, instead of just getting class files from bcel and investigating if they have a native method, a .java file can be created with the native methods themselves... something like the below:

private Set<String> generateJavaFiles(Set<JavaClass> javaClasses) throws IOException {
    Set<String> filePaths = new HashSet<>();
    // This would have to be added as a parameter, as well as a method that makes it not null like the others.
    // @Parameter(defaultValue = "${project.build.directory}/nar/java-files", required = true)
    // private File javaGenerateDirectory;
    getJavaGenerateDirectory().mkdirs();
    for(JavaClass javaClass : javaClasses) {
      File classPackage = new File(javaGenerateDirectory, javaClass.getPackageName().replaceAll("\\.", "/"));
      if(!classPackage.exists()) {
        classPackage.mkdirs();
      }
      String className = javaClass.getClassName();
      className = className.substring(javaClass.getClassName().lastIndexOf('.') + 1);
      File classFile = new File(classPackage, className + ".java");
      List<String> newContents = new ArrayList<>();
      newContents.add("package " + javaClass.getPackageName() + ";");
      newContents.add("public class " + className + " {");
      for (final Method element : javaClass.getMethods()) {
        if (element.isNative()) {
          newContents.add(element + ";");
        }
      }
      newContents.add("}");
      Files.write(classFile.toPath(), newContents);
      filePaths.add(classFile.getAbsolutePath());
    }
    return filePaths;
  }

After all that and a few other minor changes, like changing javah to javac and -d to -h, things worked well for me.

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

No branches or pull requests

1 participant