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.
Related
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.
I need to run java in 32 bit mode under windows 8.1 64 bit.
I have installed java 7 jre under c:\Program Files\Java\jre7 (64bit JVM) and under c:\Program Files (x86)\Java\jre7 (32bit JVM).
However, if from cmd I issue java -d32 -version, I get this error:
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
Without the -d32 switch it confirms its running the 64 bit JVM:
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
So I opened the java control panel and added the 32bit JVM to the user installed JRE (system tab does not allow me to change anything even if running as administrator), but nothing changes.
I've read some posts of users saying that with java 7+ the -d32 mode should be supported but I can't get it.
Note: Please note that I cannot remove the 64bit JVM because I need it for other applications
According to this FAQ :
How do I select between 32 and 64-bit operation? What's the default?
The options -d32 and -d64 have been added to the Java launcher to
specify whether the program is to be run in a 32 or 64-bit
environment. On Solaris these correspond to the ILP32 and LP64 data
models, respectively. Since Solaris has both a 32 and 64-bit J2SE
implementation contained within the same installation of Java, you can
specify either version. If neither -d32 nor -d64 is specified, the
default is to run in a 32-bit environment. Other Java commands
(javac, javadoc, etc.) will rarely need to be executed in a 64-bit
environment. However, the -d32/-d64 options may be passed to these
commands and then on to the Java launcher using the established -J
prefix option (eg: -J-d64).
All other platforms (Windows and Linux) contain separate 32 and 64-bit installation packages. If both packages are installed on a
system, you select one or the other by adding the appropriate "bin"
directory to your path. For consistency, the Java implementations on
Linux accept the -d64 option.
I've found another solution to that.
By using launchj4 I can wrap my jar into an exe and I can specify the JRE I want to use and force it to search for a 32bit JVM, set min and max version etc (see the JRE).
The wrapper will automatically search installed JRE's and chose the one that meets the requirements.
Also wrapping my jar into an exe is more convenient for deploying my application.
You can have both 32bit and 64 bit installed on the same machine. Infact you can have multiple version of each of 32bit and 64bit installed (eg - java6 and java7). Because each JRE will be installed in different folders, it usually does not matter.
When running different versions of jre, your application will search for the Java executable using the PATH variable. So if Java 32bit is first on the PATH, you will have problems running a Java 64bit application. You can modify the path to use a certain Java version e.g. by defining a environment variable JAVA32HOME with the value C:\java\java6 (32bit) and change the command to
%JAVA32HOME%\bin\java ...
Or you can manually add the version you want to use, first in the PATH variable. Remember the first instance of java.exe found while searching your PATH will be the one that is executed.
Why don't you just install the 32-bit version of Java as well from the link below:
Java Downloads for All Operating Systems
Consider going to your settings , choosing your active profile then click on advanced settings , now on the menu that pops up and choose the version you would like to work with . Once everything is configured use the terminal to verify the usage of the right version. Now incaqse thus pdate-alternatives --config java. through the terminal and update any values by selecting the version you like and pressing down on the enter key on the output you get
I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?
The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer
The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.
"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!
I have installed a 64 bit Java on a 64 bit Centos machine. My query is that if I dont specify the -d64 option will the JVM run in 32 bit mode even if there is no 32 bit JVM installed ?
Also I was a bit curious if we can use the -d64 option with "javac". If yes, then what does it imply or where could it be used? I came across this when reading this article.
Thanks
The selection of the data model (bits) for the JRE is to constrain the operation of the application to only run in one mode. The java byte code is designed to work in both data models, so for the 100% pure java applications, will work according the behavior and benefits of each architecture.
But, if your application use native libs that work only in one mode, then the application will fail under the not supported one. For that, you must explicitly indicate in which mode it should run.
When you set -d32 or -d64 the JRE will not start your application if it can't run in the selected mode.
From the Oracle document you linked to:
How do I select between 32 and 64-bit operation? What's the default?
The options -d32 and -d64 have been added to the Java launcher to specify whether the program is to be run in a 32 or 64-bit environment. On Solaris these correspond to the ILP32 and LP64 data models, respectively. Since Solaris has both a 32 and 64-bit J2SE implementation contained within the same installation of Java, you can specify either version. If neither -d32 nor -d64 is specified, the default is to run in a 32-bit environment.
Other Java commands (javac, javadoc, etc.) will rarely need to be executed in a 64-bit environment. However, the -d32/-d64 options may be passed to these commands and then on to the Java launcher using the established -J prefix option (eg: -J-d64).
All other platforms (Windows and Linux) contain separate 32 and 64-bit installation packages. If both packages are installed on a system, you select one or the other by adding the appropriate "bin" directory to your path. For consistency, the Java implementations on Linux accept the -d64 option.
(emphasis mine)
So, according to the document you linked to, the default is to run in a 32-bit JRE, and it is possible to run javac in a 64-bit JRE by passing -J-d64 rather than simply -d64.
However, note that this document also says that it applies to Java 1.4, and says nothing about more recent versions of Java.
I'm developing a java application, using a 32Bit native library which I'm accessing via JNA. On MacOS X Snow Leopard it's possible to pass the parameter "-d32" to the JVM, which causes the JVM to start in 32Bit mode. I've got a launcher application, which sets some environment variables and then starts the main application. This is also the place where it is decided to launch the main application with the -d32 switch, if the program is executed on MacOS.
So here's my question: Is there a similar way to solve this on Windows or Linux?
It would be the best if it was possible to run the 64Bit JVM in 32Bit mode. But I'm not really afraid to tell my users to install an additional 32Bit JVM, that's not the problem. The problem is, that I would have to tell my launcher application where the 32Bit JVM can be found, as the first one in the PATH variable could be the 64Bit one.
Thanks in advance,
aRestless
If you bundle the 32-bit JVM with your application, it can run fully independent of any installed JRE and system path. This is allowed by Java SE 6: http://java.sun.com/javase/6/jdk-6u2-license.txt. You can also start JVM by loading jvm.dll, thus showing only your launcher image in task manager. You can even avoid writing a native launcher at all if you use WinRun4J: http://winrun4j.sourceforge.net/
Hope that helps!