Re: [fpc-pascal] pas2jni issues
> I answered to your original message. It seems you did not receive the answer. Sorry, I never got the e-mail, assumed it was a delay because of my first posting in the list so I re-posted. I read your answer from the archives. I will re-test and get back if needed. Thank you! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] pas2jni issues
On 11/4/2018 9:54 PM, kst...@gmail.com wrote: Hello, I would like to make a suggestion regarding the generated code of the pas2jni utility, and report an issue. I answered to your original message. It seems you did not receive the answer. Yuriy. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] pas2jni issues
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] pas2jni issues
On 10/31/2018 3:23 PM, kst...@gmail.com wrote:
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.
This issue happens when no classes are used in your code. If you add usage of
TObject, the Java code will work.
I've fixed this in trunk in r40179.
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.
In r40179 I've added the "-N" switch to pas2jni which prevents auto-loading of
the shared library.
Just get the latest trunk sources of pas2jni and compile it to get the fixed
version.
Yuriy.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] pas2jni issues
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
