Java applications don't start via .apps in Finder - java

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.

Related

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

Uninstalling Java From Mac not working

I removed all the dependencies using the link
Removing Java 8 JDK from Mac
But even after that java is not uninstalled from my system. If i run the command java -version then i get the following result. I need to install java 7. But i am stuck at this point.
MacBook-Air:Library mislam$ java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
Is there anyone who faced similr problem before? Any help?
for removing the java runtime you need to copy these two lines in your terminal
sudo rm -fr /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin
sudo rm -fr /Library/PreferencePanes/JavaControlPanel.prefpane
then if you open the system prefrences you can see the java icon is gone
The java development kit is different than the runtime, and to remove that, you’ll need to run a different command and look in a different folder to see if it even is installed (usually it’s not). Open up a Terminal window and type in (or paste) the following command to switch to the correct folder:
cd /Library/Java/JavaVirtualMachines
And then use “ls” at the prompt to see if there is anything in there. if there was. So then you’ll type in the following:
sudo rm -rf jdk1
And then use the TAB key to make the shell complete the file name.
It’s easy enough to make sure that Java is completely dead. You should already have noticed that closing and reopening System Preferences is enough to make the icon there go away, but to be really sure, you can open up a terminal and simply type “java”. You’ll be presented with the message, “No Java runtime present, requesting install”.
And then a little dialog box will pop up with the OK button highlighted, indicating that everything is going to be OK now.

Launching JNLP from CentoOS 7 Gnome Desktop with PATH

I have a JNLP application that uses the local $PATH variable. It launches and behaves correctly from the web, command line, menu system, and Java control panel. When I launch it from the desktop shortcut on CentOS 7, the $PATH is simply
/bin:/lib:/usr/bin:/usr/lib:/usr/share/bin:/usr/share/lib
regardless of what else I put in the /etc/profile.d/, or ~/.bashrc, or anyplace else that I can find. It only seems to affect CentOS 7. CentOS 6.x, OS X, and Windows all behave normally when launching from their Desktop environments.
I am using Oracle's 32-bit Java 1.8.0_60 on the 64-bit CentOS 7 for specific application requirement reasons. I have uninstalled IcedTea, but still have OpenJDK 1.7 installed, though it is not used by the JNLP application and the alternatives have been configured to use Oracle's.
The best solution that I have found is:
Disable shortcut creation in the Java control panel > Advanced settings
Create a shell script that contains these two lines:
source /etc/profile
javaws < location-of-jnlp >
Create a .desktop file that calls the shell script
It's not an ideal solution, but it works for the short run.

Java bluetooth bluecove application

I'm working on a bluetooth java application under eclipse in OS X 10.10.1 Yosemite 64bit with the blue cove-2.1.0 jar. When I run the application I get the error message:
Native Library bluecove not available
Through a web search I found that the issue is caused by the 64 bit version of Java, but when I try to run the application with the -d32 argument passed to the VM I get the error:
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
Is there anyway to run this application despite the 64 bit configuration? or is there any other library despite bluecove that can manage a 64 bit environment?
A similar thing happened to me with a different java application (jruby), around which I was able to work by resetting my JAVA_HOME to a JVM that supports 32-bit mode. Essentially your 64-bit JVM is trying to tell you that it won't run in 32-bit mode, even when you specify the -d32 option.
To work around this, try running: /usr/libexec/java_home -d32
On my 64-bit Yosemite machine, that command returned /Library/Java/JavaVirtualMachines/1.6.0_65-b14-462.jdk/Contents/Home, which is the path to a JVM on my machine that will run in 32-bit mode. If you have one or more 32-bit-capable JVMs on your machine, you'll get a path to one of them, which you can then use to set your JAVA_HOME variable accordingly and you'll be off to the races.
If you don't have a 32-bit-capabile JVM on your machine, you will need to install one via the Oracle web site or homebrew and then set your JAVA_HOME accordingly.
If you want to skip a step or two, just do this -- export JAVA_HOME=`/usr/libexec/java_home -d32` -- which will automatically set your JAVA_HOME to the first detected instance of a JVM capable of running in 32-bit mode.

Eclipse only sees JDK with sudo

I have to start by saying that I have just switched to Ubuntu from Windows and I am new to Linux in general. Coming from Windows, I really am not familiar with how exactly the permissions work, the Linux file system, where I am able to create folders that I can use without the sudo command etc.
I use eclipse on a daily basis for android development and other simple java swing projects. I was able to download and extract the latest available version of eclipse (kepler) to this path: /opt/eclipse. Inside this directory is the eclipse executable and other eclipse related files.
I also installed the JDK and verified with the java -version command. It says:
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
I am running on a 64 bit CPU architecture so both programs are the 64 bit version.
Now, my problem is that if I open eclipse from the Unity dash or from the file explorer, it give me this error:
However if I run sudo eclipse in the terminal, everything runs just fine as long as I do it as the super user. I have a hunch that the JDK is installed in a folder that is restricted to normal users and only works if I run the sudo command but this is just a hunch. As I said, I am new to Linux and I am not really sure what I am doing wrong here, I am learning as I go. I need a good explanation as to how to make it start from the Unity dock without the sudo command. Thanks in advance!
You'll want to use the chmod command from the terminal to change the permissions on the Java folder. See this link for more information:
http://www.linux.org/threads/file-permissions-chmod.4094/
Well after running the which java cmd, I noticed that the path to the JDK from the eclipse.ini file was not pointing to the correct location. I fixed the path and now it works. I don't know how the sudo cmd overrides the eclipse.ini path to JDK but well, it works

Categories

Resources