You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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:
After all that and a few other minor changes, like changing javah to javac and -d to -h, things worked well for me.
The text was updated successfully, but these errors were encountered: