Develop Reference

Mac app cannot run due to gatekeeper block jna*.tmp file generated at launch time

My app has already been signed and notarized successfully, but I got this error while trying to launch the app:
"jna7223640233751603426.tmp" cannot be opened because the developer cannot be verified
Does anybody have the solution for this?
How can I fix this problem? Can I block the file created while launching the app or make it valid for the Gatekeeper?

JNA releases have small precompiled binary JARs for each of its supported operating system/architecture combinations. These are not signed, although the source code is available if you wish to build and sign them yourself.
From a conversation on the JNA mailing list:
MacOS does not allow code created at runtime (which is typical malware behaviour), and that extracting a library at runtime looks like that code was created because it’s not visible outside the jar file in which it came.
A solution listed in that thread is:
by pre-extracting the library and bundling it as part of the installer.
In addition to this, you'll need to configure your application to tell JNA not to extract its own library but to use the one which you have signed and extracted as part of your installer. Source code from the above email thread:
boolean sandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
// Some 3rd party apps install to the system and can cause crashes
System.setProperty("jna.nosys", "true");
if(sandboxed) {
// Don't unpack the libraries
System.setProperty("jna.nounpack", "true");
// Tell JNA where the native libraries are
System.setProperty("jna.boot.library.path", "<path to native libs>");
}

Could not install JAR error 7515

I followed the tutorial below in order to create a simple Java UDF for Teradata. Simple Java UDF The problem that i am facing is when i try to deploy the JAR to the database server . I am getting the following error:

Simply check the Messages manual:
7515 Unable to create new DLL for the UDF/XSP/UDM.
Explanation:
The system was not able to create the new DLL for the UDF/XSP/UDM. In general this should not occur. It could be caused by either for a bad path to the UDF/XSP/UDM library directory or the directory has no space available. This is a system disk directory NOT part of the database.
Generated By:
AMP subsystem.
For Whom:
DBA.
Remedy:
The remedy is to make sure the UDF GDO configuration paths are pointing to a valid directory(s). Also make sure the directory has enough space to hold a UDF/XSP/UDM DLL (DLL: Dynamic Linked Library).

You may want to make sure the class / jar file are compiled to be compatible with the JRE bundled with Teradata.

.exe file Failed due to exception in main class

I made an app using javafx and packaged it as exe file. It works fine being started from eclipse but being installed it says
Failed due to exception in main class
no matter what pc it was started at. I've found a few same questions but everyone found solution by themselves but don't tell how. One question has an answer:
the issue were VM parameters I added in the build.xml in the
fx:platform / fx:jvmarg section. These params were put into the
package.cfg file which is called from the .exe file to initialize the
VM.
In my build.xml there is only one string related to the named fx:platform But in my case there is only <fx:platform basedir="${java.home}"/> and nothing else. What am I doing wrong?

An issue when trying to launch and deploy Jetty

I have an issue whenever I am trying to deploy Jetty on a specific machine (works with others), the machine is a non-English Windows machine.
[2013-02-15 04:14:05.894] [ERROR] Thread-39
System.err
java.lang.IllegalStateException: Cannot create tmp dir in
C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ for
context o.e.j.w.WebAppContext{/spdy,null},C:\Program
Files\server\work\tmp\my-app\webapps\spdy.war
[2013-02-15 04:14:05.894] [ERROR] Thread-39
System.err
java.io.IOException: Žw’肳‚ꂽƒpƒX‚ªŒ©‚‚©‚è‚Ü‚¹‚ñB
I tried to see if this is an issue related to admin rights but it is not, I am launching the process with admin rights.
Any suggestions are really appreciated.
Thanks!

Was able to find the issue out. Jetty does not create the TEMP folder if it doesn't exist so you have to check yourself and create the temp folder if it is not there.
In this instance, it ended up being that:
C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ does not exist although C:\Windows\system32\config\systemprofile\AppData\Local\ does and TEMP=C:\Windows\system32\config\systemprofile\AppData\Local\Temp\
Creating "Temp" directory in C:\Windows\system32\config\systemprofile\AppData\Local\ solved the issue!

This is pretty old post, but recently I had just the same problem, so I want to share my experience too.
Parts of the code causing the problem can be found here:
http://download.eclipse.org/jetty/stable-8/xref/org/eclipse/jetty/webapp/WebInfConfiguration.html#225, resolveTempDirectory (WebAppContext context) method (check last lines of the method, third case explained in the comments). So, another workaround for the problem can be also changing default java.io.tmpdir folder to point to an existing one.
I have already checked on some systems and C:\Windows\system32\config\systemprofile\AppData\Local\Temp folder doesn't exist on Windows: 7, 2008, 2012.

JPL/SWI Prolog configuration failure

I'm configuring the JPL right now, and wanna work with swi-prolog using java.
I downloaded the newest stable version of SWI-Prolog, which is 6.2.0, and installed in D:\swipl
First, I added the following path to the PATH virable: D:\swipl\bin, which should include all dll files needed.
Then, I added the following path to the CLASSPATH virable: D:swipl\lib\jpl.jar, which should be the jar file needed.
When I tried to run the versions example provided, I got the following error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: jpl.fli.Prolog.thread_self()I
at jpl.fli.Prolog.thread_self(Native Method)
at jpl.Query.open(Query.java:286)
at jpl.Util.textToTerm(Util.java:162)
at jpl.Query.Query1(Query.java:183)
at jpl.Query.<init>(Query.java:176)
at Versions.main(Versions.java:11)
After searching online, I found that many people just get java.lang.UnsatisfiedLinkError: no jpl in java.library.path which is because of the setting for the PATH variable, rather than the error I get here: java.lang.UnsatisfiedLinkError: jpl.fli.Prolog.thread_self()I (and yes, there is a "I" at the end of the line).
Has anyone gotten this error before? I've tried several previous version of SWI-Prolog, but also got other kinds of errors. I'm using Eclipse IDE for Java development -- have I missed anything?

I've sent the problem to the official mailing list (swi-prolog#lists.iai.uni-bonn.de) provided by swi-prolog.org, and luckily someone helped me to prove that there are some problems in the version 6.2.0. We then both tried the version 6.0.2, and it works perfectly. He mentioned that (and I noticed that) there is no swipl.dll in the bin folder of the version 6.2.0, which MAY causes the issue.
I've already reported the issue to the staff via Email, and at least for now, I suggest that people who want to configure JPL should download the version 6.0.2. Three things to remember:
add a new variable SWI_HOME_DIR under system variables in environment variables, and set the path to the place where you installed the SWI-Prolog (Mine is D:\swipl);
Add the path %SWI_HOME_DIR%\bin to your PATH variable, rather than use something like "D:\swipl\bin". (Otherwise [FATAL ERROR: Could not find system resources] will occur)
Add the path %SWI_HOME_DIR%\lib\jpl.jar to your PATH variable, rather than use something like "D:\swipl\lib\jpl.jar". (Otherwise [FATAL ERROR: Could not find system resources] will occur)
If you are using Eclipse for Java development, it seems that you DO NOT need to configure in your IDE. As long as you follow the 3 steps above and add the correct jar file as an external library, it should be fine.
I'm not sure whether the temporary solution works for everyone, but definitely, everyone who has the issue should try this method first. As long as the issue in the version 6.2.0 has been figured out, I'll add some comments here.
BTW, as far as I know, until now, people who have the issue are using 32-bit Windows.

Try adding your path to java.library.path via Run > Run Configuration > [project name] and add the following under "VM Arguments" tab.
-Djava.library.path="D:\swipl\bin;."
Furthermore, under the "Environment" tab, add the following:
VARIABLE: PATH
VALUE: D:\swipl\bin;${env_var:PATH}
After that, go to Project > Properties > Java Build Path, select "Libraries" tab.
Click "Add External JARS.." and find your jpl.jar.

Great Great Great, second answer is the solution
create SWI_HOME_DIR variable to set the swi prolog instalation directory
SWI_HOME_DIR ------- C:\Program Files\swipl
set PATH to point to the library and bin like this
PATH ------ %SWI_HOME_DIR%\bin;%SWI_HOME_DIR%\lib\jpl.jar
This fix my problem "Exception in thread "main" java.lang.UnsatisfiedLinkError: no jpl in java.library.path windows" it is a little bit rare but it works find.

I had the same problem. In addition to set the PATH, you need to verify if the installed SWI program has the same architecture (32 or 64) of your JVM.