[fpc-pascal] pas2jni issues

ksterg at gmail.com ksterg at gmail.com
Wed Oct 31 14:23:54 CET 2018


Hello,
I would like to make a suggestion regarding the generated code of the
pas2jni utility, and report an issue.

This utility generates a java file called system.java. First thing is that
there is a reference to TClass which is a non-existent Java class:
  static TClass GetTClass(int index) { TClass c = new TClass(null);
c._pasobj=GetClassRef(index); return c; }

In order to compile the generated system.java I had to comment out this
line. I didn't look too deep to see how/where it is used, yet for my needs
this did the work. I assume something simple is missing there.

Second thing is the way this file has hard-coded the loading of the .dll
file: There is a static IniJni() method that is called with a static class
initializer:
  static { com.imagetrust.launch.winutils.system.InitJni(); }
This is a technique that excludes any other way of dynamically loading the
.dll file. This is a show-stopper for cases where dll files are packaged in
a jar file and are loaded dynamically with System.load. As the code is
written, the assumption is that the jni dll file always exists in
java.library.path.

Let me please suggest to add a public method that sets the _JniLibLoaded to
true, for those cases that the calling code takes care of that, e.g.:
public static void setJniLibLoaded(boolean value){
  this._JniLibLoaded = value;
}
and remove the static initializer completely. As I see the code, the
PascalObject statically calls the InitJni() method, which will check if the
jni lib is already loaded, so this will not break anything and will still
work with the same assumptions.

These changes seem trivial, yet unless they end up in pas2jni they need to
be made later either by hand or with a code manipulation tool, which is not
ideal.

Thanks for considering,
Costas





More information about the fpc-pascal mailing list