We Keep Coding

Can't run java applications

I have trouble when trying to open my jar files with the following command:
java -jar software.jar
They load until a certain point and then nothing happens.
I deinstalled default-jdk and OpenJDK with synaptic and re-installed it with apt-get, but nothing changed. I had a similar problem one month ago and solved it (apparently only temporarly) by deleting the package gcj-5-jre-lib (5.4.0-6ubuntu1~16.04.4) (Java runtime library for use with gcj (jar files))
The following outputs will help:
java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
javac -version
1.8.0_131
My variables $JAVA_HOME and $JRE_HOME were correctly added to my $PATH.
I'm on Ubuntu 16.04
EDIT
Here is an example of what I get when I try to start PhyDE.jar
java -jar PhyDE.jar
Welcome to PhyDE 0.9971!
Reading preferences.
Creating PhyDE-Application window
Checking for updates...
You are using the latest version of PhyDE
Done with checking for updates
When checking the core use with the command top I see that the process is active, but the user interface does not open as it usually does. I am located in the folder where the jar file is, and same happens with other jar files.

Getting "Error: Could not find or load main class " when invoking a JAR from a bash script

I built and ran a JAR on machineA as follows:
java -cp /foo/lib/dep1.jar:/foo/lib/dep2.jar:/foo/export/myjar.jar foo.bar.baz.MyMainClass ...
So myjar.jar is the JAR I built and the other two its dependencies. Ran without any issues.
I then wanted to do the same on machineB so I copied the 3 JAR files there, then tried:
/non/default/install/java -cp /bar/dep1.jar:/bar/dep2.jar:/bar/myjar.jar foo.bar.baz.MyMainClass ...
and got Error: Could not find or load main class. (NOTE: /non/default/install/java is a separate java install on machineB that I have to use instead of /usr/bin/java. Reason is "historical", i.e. I have no control over this)
On machineA, java -version gives
java version "1.7.0_91"
OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00)
OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
On machineB, /non/default/install/java -version gives
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
Both machines are running RedHat 6.
Why am I getting the error and how do I fix it?
Thx!
IMPORTANT UPDATE: I ran the commands below from command line on machineA. On machineB I originally ran them using a bash script. This means that I put them into run.bash and then ran bash run.bash from the command line. That's when I got the error. When I reran the same command from command line without using any scripts, it worked. So it seems that the problem had nothing to do with me copying the JAR form one machine to another but rather with the fact that I was invoking them form a script. And so the question really is now: how do I modify run.bash and/or the way I execute it to get rid of the error? (cuz I do need to use a script eventually)

How to change the version of Java that CDH uses

I currently have CDH 5 installed on CentOS 6.5 with java jdk1.7 and I am trying to get CDH to use jdk1.8.
I do know that Java 1.8 is not a recommended version of CDH, but it is only a test cluster, so it isn't a big deal.
I have installed both Java 1.7 and Java 1.8 from Oracle's website using the RPM installation, so both versions of Java are currently under /usr/java. Using ls -ld my Java directory looks like:
/usr/java/default -> /usr/java/latest
/usr/java/jdk1.7.0_75
/usr/java/jdk1.8.0_31
/usr/java/latest -> /usr/java/jdk1.8.0_31
I also have script set up in /etc/profile.d to set $JAVA_HOME to /usr/java/default. The contents of my profile.d script:
export JAVA_HOME=/usr/java/default
export PATH=${JAVA_HOME}/bin:${PATH}
So when felt that I have this right, I run:
$ which java
/usr/java/default/bin/java
Telling me that it is pointing to the version of Java symlinked in default. And to determine which version of java is running, I run:
$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
And I can see that I have Java 1.8 currently running.
Everything seems great, except when I try to start a Hadoop service. The easiest to start is ZooKeeper, because it only has one service. HDFS has multiple servers so it is more work that to just start and stop ZooKeeper.
Starting ZooKeeper is done with the following command:
$ sudo service zookeeper-server start
Then to check which version of java it is running, I search the running processes list for java:
$ ps -ef | grep java
495 7170 1 7 12:27 ? 00:00:00 /usr/java/jdk1.7.0_75/bin/java -Dzookeeper.datadir.autocreate=false -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,ROLLINGFILE -cp /usr/lib/zookeeper/bin/../build/classes:/usr/lib/zookeeper/bin/../build/lib/*.jar:/usr/lib/zookeeper/bin/../lib/slf4j-log4j12.jar:/usr/lib/zookeeper/bin/../lib/slf4j-log4j12-1.7.5.jar:/usr/lib/zookeeper/bin/../lib/slf4j-api-1.7.5.jar:/usr/lib/zookeeper/bin/../lib/netty-3.2.2.Final.jar:/usr/lib/zookeeper/bin/../lib/log4j-1.2.16.jar:/usr/lib/zookeeper/bin/../lib/jline-0.9.94.jar:/usr/lib/zookeeper/bin/../zookeeper-3.4.5-cdh5.3.0.jar:/usr/lib/zookeeper/bin/../src/java/lib/*.jar:/etc/zookeeper/conf::/etc/zookeeper/conf:/usr/lib/zookeeper/*:/usr/lib/zookeeper/lib/* -Dzookeeper.log.threshold=INFO -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /etc/zookeeper/conf/zoo.cfg
I know that runs off the screen, bu the important part is that Zookeeper is being started by /usr/java/jdk1.7.0_75/bin/java.
To fix this, I have tried a few things:
Looking at the conf files for Hadoop and ZooKeeper under /etc/hadoop/conf and /etc/zookeeper/conf, respectively.
I found nothing setting JAVA_HOME.
Looking at the /usr/bin/zookeeper script to see if JAVA_HOME was set elsewhere,
I did find the script /usr/lib/bigtop-utils/bigtop-detect-javahome has the ability to set JAVA_HOME, but my profile.d script overrides that.
Manually moving /usr/java/jdk1.7 to /tmp.
Sadly, this is the only thing that works. When I move the jdk1.7 dir to another directory, and start ZooKeeper, it will use Java 1.8. Moving the jdk1.7 dir back, reverts to ZooKeeper using Java 1.7.
Has anyone dealt with this problem and does anyone know how to deal with this? I feel that I have Java set up correctly, but something is telling ZooKeeper/Hadoop to use an old version of Java?

I came here because I was looking for ways to upgrade JDK from 1.7 to 1.8 on the latest Coudera QuickStart VM 5.8 (can't believe they still ship it with JDK1.7 by default!). The hints and suggestions in the above answers helped tremendously - but since they were not listing complete steps to achieve the upgrade - I thought I would add that to help others like me.
So, here is a complete set of steps to upgrade Cloudera QuickStart VM from JDK1.7 to 1.8:
check your current JDK version - out-of-the-box it is:
[cloudera#quickstart ~]$ java -version
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
download desired version of JDK1.8.xx - in my case: jdk-8u111-linux-x64.tar.gz
as user 'cloudera':
untar and move the resulting jdk1.8.0_111 dir to the /usr/java dir:
tar xzf jdk-8u111-linux-x64.tar.gz
sudo mv -f jdk1.8.0_111 /usr/java
shutdown all Hadoop services:
$ for x in `cd /etc/init.d ; ls hadoop-*` ; do sudo service $x stop ; done
update bigtop-utils file - set JAVA_HOME to your new JDK:
sudo vi /etc/default/bigtop-utils
updated lines:
# Override JAVA_HOME detection for all bigtop packages
export JAVA_HOME=/usr/java/jdk1.8.0_111
update 'cloudera' user's .bash_profile - export JAVA_HOME and add update PATH:
export JAVA_HOME=/usr/java/jdk1.8.0_111
PATH=$JAVA_HOME/bin:$PATH:$HOME/bin
export PATH
restart your VM
check Java version - should be the 1.8 one now:
[cloudera#quickstart ~]$ 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)
By the way, I did not setup the /usr/java/default with the 'latest' sym link as #milk3422 did, for the sake of simplicity, but it would have worked just as well.
thanks!

I hate to answer my own questions, but here is the answer:
The wrong version of $JAVA_HOME is getting set for 2 reasons:
Using the command service removes most environmental variables. From man service:
service runs a System V init script in as predictable environment as
possible, removing most environment variables and with current work-
ing directory set to /.
The /usr/lib/bigtop-utils/bigtop-detect-javahome script has the ability to be configured with the environment variable BIGTOP_JAVA_MAJOR to manually set which version of Java to use. I tried setting this as an environment variable, but service removes it :(. It is also important to note that this script will find all versions of java installed, but the order of preference is Java 6, Java 7, Java 8, Open Java. So if you have Java 6, and 8 installed, it will prefer 6 over 8.
In short, to fix my problem, I added the following to the top of /usr/lib/bigtop-utils/bigtop-detect-javahome:
BIGTOP_JAVA_MAJOR=8
You can also set JAVA_HOME in this file to specify a specific version or path.

I had the same problem. I set
JAVA_HOME=... below the file /usr/lib/bigtop-utils/bigtop-detect-javahome
to override the default detect value. That works great!

Java is configurable in the web UI. Open Cloudera Manger --> Hosts --> Configurations --> Advanced, then set the JAVA HOME. This overrides the CDH's Java detection mechanism.

Why doesn't netbeans 7.3 see that I've installed Java 1.7.0_21?

I've recently installed netbeans 7.3 on my Mac (Lion 10.7.5, up-to-date).
At the command line, I would get:
[129]$java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)
Today I went to the netbeans plugin window and found 18 updates to install. When I attempted to do this, I received a message that some of them require > Java 1.7, and I only have 1.6 (as indicated above). So I dutifully ran out to java.com and downloaded Java 1.7 Update 21 successfully.
When I run a Java version checker in various browsers I see a report that Java 1.7.0_21 is the installed version. In addition, the Mac's Java Control Panel also indicates that 1.7.0_21-b12 is the current version.
However, upon restarting netbeans, it still has the same complaint that Java 1.6 is in use. I've rebooted the machine and get the same result. And, the result of 'java -version' at the command line also still shows the same result as above (1.6.0_45).
And, finally, even if I try something like:
/usr/libexec/java_home -v 1.7.0_21 --exec java -version
I get:
Unable to find any JVMs matching version "1.7.0_21"
I'm baffled. Does anybody have any advice on this?
Thanks.
Doug

netbeans will be using it's own version of the the JDK try this
where-can-i-set-the-jre-jdk-which-is-used-to-run-netbeans-besides-the-command-line

Java program runs smoothly in Netbeans but slowly in Eclipse and as an executable jar

A java program that does frequent swing/awt painting animation (but nothing more advanced than g.fillOval(...)) runs at a consistent 60fps in Netbeans, and at about 6fps when ran in Eclipse or executed as a jar file from a unix terminal. The program was developed in Netbeans and is run-of-the-mill desktop application (not webstart or japplet or ...). This is occurring in Ubuntu 10 with java 1.6. How is this possible?
$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)
Set the default jvm to the sun version, and outputed the jvm used by netbeans and the unix terminal, which was the same for both:
java.runtime.name=Java(TM) SE Runtime Environment, sun.boot.library.path=/usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib/i386, java.vm.version=17.1-b03, java.vm.vendor=Sun Microsystems Inc.
However, this didn't make any difference as there is still a significant frame rate discrepancy. Is there some other factor that could be at play here?

One of possible reasons may be that NetBeans can use one JVM, and Eclipse and terminal "java" command can use another. Look into what platform NetBeans uses for your project, and compare it with Eclipse.
Also there can be something with arguments you passed to JVM. Check that too.

In Ubuntu there's a very handy utility. Try this:
sudo update-java-alternatives -s java-6-sun
in shell. It may output some errors...
update-alternatives: error: no alternatives for mozilla-javaplugin.so.
update-alternatives: error: no alternatives for xulrunner-1.9-javaplugin.so.
update-alternatives: error: no alternatives for mozilla-javaplugin.so.
update-alternatives: error: no alternatives for xulrunner-1.9-javaplugin.so.
That's only a problem with java plugin for Firefox. You may ignore this. If you have any other problem, than check which java you've got installed by issuing:
sudo update-java-alternatives -l
Or, you may use the interactive version:
sudo update-java-alternatives --config
(... this one I haven't tested).
If for any reason You don't have Sun's JDK listed post a comment.
EDIT
Are you using hardware acceleration? Try adding this JVM property:
-Dsun.java2d.opengl=True
To see details you might also use:
-Dsun.java2d.trace=log
Consult OpenGL acc for more details.