Develop Reference

IBM i Access doesn't start on Fedora

Here is my setup:
System76 Gallago Pro
Fedora 30
OpenJDK 1.8.0_201 (I did try Oracle as well)
I installed per IBM's instructions, using the installer script from the command line. I went through the installer menu and got to the success screen. I have done this a half dozen times on other machines and with OS upgrades on this same machine.
When I use the super key to find the program it is there; I click on the icon and my box returns to the desktop - but i Access doesn't start.
If I start via the command line using the start script, I get MSGGEN045 - A graphical user interface is not available.
If I run the java program directly
java -Xmx1024m -jar /opt/ibm/iAccessClientSolutions/acsbundle.jar I get the same message as when using the start script.
How can I get past this error? Or,what else can I do to track down what is happening?

I've had two issues when running iACS on Fedora. The first was the OS had a headless JVM installed by default. The second was something to do with sound.
Based on "MSGGEN045 - A graphical user interface is not available", I'd suspect a headless JVM.
HTH
Edit:
I checked for the headless JVM at the direction of IBM support. I don't remember the exact wording, but the name of the installed package was a dead giveaway. A simple "rpm -qa" was all it took.

I don't have anything Fedora specific but it seems that you either didn't install a Java Runtime Environment or just a headless version of it (jre-headless). Install a full JRE and everything should be fine.
You could check this with yum:
yum list installed | grep jre

Fedora is running wayland and not X11. Java doesn't play nice with wayland as of yet. As far as I know there are no plans yet to fix that. This is a good place to start https://www.ibm.com/developerworks/community/forums/html/topic?id=1b366edf-0e70-40d5-8d92-30d401edd97a

Java -jar No Sound Error with cgoban.jar

Situation
The problem I have encountered is that there will be no sound output from running my *.jar file. I will start it with java -jar cgoban.jar and it works fine except there is no sound.
Possible Solutions
There is a workaround for this problem discussed here: https://senseis.xmp.net/?CgobanProblemsAndSolutions.
It says to employ the Java Web Start with
LIBXCB_ALLOW_SLOPPY_LOCK=true padsp javaws http://files.gokgs.com/javaBin/cgoban.jnlp
and use the jlnp file from here: http://files.gokgs.com/javaBin/cgoban.jnlp.
However, since this workaround includes downloading the jar-file on every start this is not an option for me (as I use an offline machine, bandwidth limitations etc.)
A possible solution might be to run (since it works with javaws)
LIBXCB_ALLOW_SLOPPY_LOCK=true padsp java -jar cgoban.jar
but there is still no sound. I don't understand why it works for javaws, but not for java -jar.
Unluckily it did not help to run
java -jar -Dsun.sound.useNewAudioEngine="false" cgoban.jar
But thanks for commenting.
Another possible solution that I attempted was to download and edit above jlnp-file. I don't want to download the jar-file every time the application starts. So maybe it is possible to download the jar-file once and then have the local jlnp-file point to the local copy (instead of the remote jar-file). However, as my programming skills suck, I have not been able to pull this off.
Additional Information
I'm running an Ubuntu machine with Java installed. java -version gives me the following output:
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
An up-to-date version of cgoban.jar for download is available from here:
http://files.gokgs.com/javaBin/cgoban.jar

Java applications don't start via .apps in Finder

I have Mac OS 10.9.3 installed, and when entering java -version in the Terminal it shows:
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
My problem is that applications which use Java don't work when double-clicking on the .app folders. For example, TuxGuitar just does nothing, and Eclipse gives the No Java virtual machine error. When launching them with the command
open TuxGuitar.app
open Eclipse.app
.. they work both. What could be the problem?

I had the same problem and I fixed this by installing a patch from apple at
http://support.apple.com/kb/DL1572?viewlocale=en_US.

Something is different in the environment of the shell you get in Terminal, compared with the environment Finder.app is running in. You need to figure out what's different.
A few relevant facts:
OS X windowed applications do not read your shell startup files like ~/.bash_profile, so changes you make there to your ${PATH} or ${JAVA_HOME} will not affect windowed applications.
It used to be the case that OS X windowed applications read ~/.MacOSX/environment.plist but apparently that's no longer true in 10.9 Mavericks; see for example this other StackOverflow question.
Java on Mac OS X keeps changing, and can be installed and controlled in a variety of ways. So it's hard to give a general answer; it depends on the history of your system.
Java Mac GUI applications can place restrictions on which JVM will run them, in Contents/Info.plist of the application bundle; look for key JVMOptions and in particular at JVMVersion within that.
Things to try:
Open System Preferences and see if you have a Java Control Panel. If you do, you can use it to select which JVMs are available for running GUI applications, and in what order they will be tried.
Open a "clean" shell by running env -i /bin/sh and then try running /Applications/TuxGuitar.app/Contents/MacOS/TuxGuitar inside that shell; you may get a useful error message.
Use /usr/libexec/java_home -V to see a list of JVMs the OS knows about.
/usr/libexec/java_home -v 1.7 to see which JVM the OS would choose for an application that needs Java 7.

I have the exact same issue after upgrading to Mavericks and I noticed it with muCommander.
As I can run the app manually from the command line, I have the following workaround which I am quite happy with:
Create a shell script workflow using Automator:
Spotlight -> Automator -> Workflow -> "Run Shell Script" -> [shell command]
Then save the Worflow, but instead of .workflow, choose file format Application. Now you have an App you can double-click.
Addendum 1: This is not the answer to your original question as I don't know exactly what the problem is (jbyler's answer might point you in the right directions here).
However, I assumed that your question implies Can I get double-click to work again?, and this workaround helped me to do that.
Addendum 2: I have JAVA_HOME set up and the same version installed as you have. This is a screenshot for the Workflow in Automator:

I managed to fix this by installing the developer kit.
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

I had the same problem. Open the /Applications/TuxGuitar.app/Contents/MacOS/TuxGuitar with your favourite text editor (it's a shell script) and add "-d32" option to the last line "exec java ...." (position doesn't matter). This will launch java in 32-bit mode. Alternatively you can launch TuxGuitar with "-d32" option (it passes arguments to java) from the terminal.

Java Exception when Trying to Run Grails

All - I just downloaded the latest grails (2.1.0) and JDK (1.7.0_07) on my Win7 64bit machine and configured my machine as follows:
1.) Added environment variables for Java and Grails
2.) Update PATH as appropriate
3.) Verified that everything installed correctly by executing java -version and grails -version
The java -version command works, and shows the following:
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
but the grails -version command yields the following error:
Exception: java.lang.RuntimeException thrown from the UncaughtExceptionHandler in thread “main”
I tried debugging by completely uninstalling all Java, then reinstalling, but the same error occurs. I verified that I installed the 64 bit version of Java.
More information about the error can be found at this website (Mike [the owner] directed me to Stackoverflow for more help).
Any idea is to why this occurred? What can I do to get Grails working? Thanks in advance for your help.
-Tom
Edit 1 from Vector's comment:
All variables are set properly and shown here:
GRAILS_HOME = C:\grails\grails-2.1.0
JAVA_HOME = C:\Program Files\Java\jdk1.7.0_07
Path = [lots of other stuff];%JAVA_HOME%\bin;%GRAILS_HOME%\bin;
Edit 2 Fixed java version number at top of problem statement (version is 1.7.0_07) per #crudolf

Answer: Thou shalt ensurest that thine box is set to Administrator . . . and the people rejoiced.
Apparently, Grails wants to write to C:\Users\Administrator.grails and C:\Users\Administrator.groovy. Even though I had admin rights on my machine (since I successfully installed Java), I apparently needed to click through into the Administrator folder in order for the preferences to be written that I wanted to use JDK.
All is well. Thanks everyone for your help.

I ran into this error after attempting to upgrade from Grails 2.1.0 to Grails 2.2.1 on Windows 7.
I simply had to delete the C:\User\%USERNAME%\.grails and C:\User\%USERNAME%\.groovy folders created by and leftover from Grails 2.1.0.
It appeared that Grails was loading some leftover cached JARs or configuration files of .grails and .groovy instead of %GRAILS_HOME%.
It took hours, but I learned my lesson - delete ".grails" and ".groovy" before running a new version of Grails!

I ran into this problem with Grails 2.4.0 and 2.2.4 on Windows 8.1 Pro. I noticed that the problem did not occur if I ran the grails command in an administrator cmd-shell. I then checked my Appdata\Local\Temp. It turned out that the security setting for the temp folder needed to be changed. After I gave Everyone the full access to Appdata\Local\Temp folder, the problem was solved. But you may need to check the security setting often because some Windows Apps reset the security setting.

I was having the same problem. I was having a working grails-2.2.4 with java-1.7.25 on a Windows 7 x86. But it suddenly stopped working today. I tried removing ~/.groovy and ~/.grails, but still got java.lang.RuntimeException thrown from the UncaughtExceptionHandler.
Finally, the problem was solved by removing ~/.m2 as well.
BTW, "set DEBUG=1" before starting "grails" in a Command Prompt will show the environment and parameters to launch Java.exe.

I was having a similar problem but in Ubuntu 12.04. I solved it by removing $GROOVY_HOME environment variable. If you also have $GROOVY_HOME variable try removing it.

Try deleting the file .grails_history file located in your %Home% directory.
This worked for me on Windows 8.1

Java applet in firefox linux makes Java application launcher crash/exit

I have a Java applet that downloads data from where it's hosted, using HTTP. The applet has default permissions for an applet, that is, not many. Randomly during download, maybe 90% chance of reproductibility, at a specific part of the log, the java executable hosted by Firefox will exit abruptly, and the Java Console will be closed.
I thought it was my first JVM crash after just a few weeks of Java, but could not find the Fatal Error Log. Until I found out that when Chromium is used to open the applet, it works 100% (many tries in various conditions, alterning with Firefox)
Both browsers execute use the same commandlines for the java executable
Firefox: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=20972388862 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.5712.287531591049678510.AF_UNIX
Chromium: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=20858056974 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.5428.6724684151611746860.AF_UNIX
Then I booted a Windows 2000 partition and also noticed that the applet was working 100% with the same version of Firefox and JRE. Could not try Chrome, not available on this platform.
Now I'm not necessarily asking for a solution as my 'client' will use Windows 2000 to run the applet. I was posting this to know if someone experimented with java crashes could find an explanation to this. Is it the communication between Firefox Linux and java that could make java exit? If you had to make this work, how would you proceed? Try to produce an SSCCE for Mozilla?
Versions:
Firefox 9.0.1 (both on Linux and Windows 2000)
Chromium 9.0.597.45 (70550) Built on Debian 6.0, running on Debian 6.0.2
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
EDIT: I found more information. When listening to Firefox's stderr, running the applet and then exiting Firefox after java exits, I get this. Not so useful though, it just tends to show that Firefox didn't even know that java exited.
Exception in thread "main" netscape.javascript.JSException: Plugin instance for applet ID 1 was already released
at sun.plugin2.main.server.LiveConnectSupport.getInfo(LiveConnectSupport.java:405)
at sun.plugin2.main.server.LiveConnectSupport.shutdown(LiveConnectSupport.java:41)
at sun.plugin2.main.server.JVMInstance.unregisterApplet(JVMInstance.java:1300)
at sun.plugin2.main.server.JVMInstance.recycleAppletID(JVMInstance.java:385)
at sun.plugin2.main.server.JVMManager.recycleAppletID(JVMManager.java:316)
at sun.plugin2.main.server.MozillaPlugin.stopApplet(MozillaPlugin.java:325)
at sun.plugin2.main.server.MozillaPlugin.destroy(MozillaPlugin.java:225)

Try to produce an SSCCE for Mozilla?
Yes. (I recommend that.)
You will need it for a bug report to either Oracle or Mozilla. Unless reported, problems do not get fixed.