We Keep Coding

bash : java : command not found (Fedora)

On Fedora I installed (or at least tried to install) JDK-18. I rebooted my laptop and wanted to check if it succeeded. I used java --version, but it said bash : java : command not found.

Well all that I will write is subjective. It all depends upon how did you install java in Fedora. If you downloaded the jdk distribution and unzipped it to some folder. Then in your .bashrc, you need to provide the path where the binaries are available
export PATH=$PATH:/path/to/java/installation/folder/bin
You can also look at sdkman
https://sdkman.io/
This is a nice tool to manage your JDK(s) regardless of Linux distribution you are using. (disclaimer: I have no affiliation with sdkman - i find this tool very helpful)

JPackage Wrong Version (%JAVA_HOME% set to correct directory)

Please help. I'm having issues syncing up my JDK and jpackage versions for creating standalone java programs. The JDK version and the runtime version being included with jpackage are mismatched (JDK16 programs being paired with JDK15 runtimes).
Typing java -version into the command line, it matches up with the current %JAVA_HOME% environment variable configuration, showing JDK16.0.2 (located at C:\Program Files\Java\jdk-16.0.2). This is working correctly.
However the problem becomes more apparent when I type jpackage --version, it reports that it's using JDK15.0.1 - which as far as I know, I've never installed and I'm unsure of where it's running from. This is a problem, since I need to be able to build Java16 programs with jpackage. As it is now, this results incompatible runtimes and JAR files.
I've been googling to no avail. I can't compile my JDK16 programs into installers because it keeps trying to use JDK15.0.1 for the runtime.
For now, I've managed to bypass this strange and seemingly locked configuration by accessing JDK16's jpackage exe manually this way and adding the commands after:
“C:\Program Files\Java\jdk-16.0.2\bin\jpackage.exe”
Any advice is helpful. Perhaps this temporary workaround will be helpful to anyone else with the same problem down the line.

Use the Windows where command to find out what the jpackage command is actually resolving to. It seems clear that jpackage without the full path name is resolving to jpackage in a different installation of Java.
Note that %JAVA_HOME% does not determine how the Windows cmd.exe resolves commands. Command resolution is done according to %PATH%.
The symptoms you describe:
jpackage says %JAVA_HOME% is incorrect but %JAVA_HOME% refers to Java 16
jpackage -version says Java 15 (not Java 16)
"C:\Program Files\Java\jdk-16.0.2\bin\jpackage.exe" works
are all consistent with your %PATH% being incorrect ... and that you do have a Java 15 installation on your machine, and it is on the %PATH% ahead of, or instead of the Java 16 installation you are trying to use.
Note jpackage is no longer an "incubator" tool in Java 16. It has been promoted to full support; see JEP 392: Packaging Tool. So the warnings about incubator mudules are also consistent with jpackage resolving to the wrong Java installation.
This really boils down to understanding what the Windows %PATH% variable is and how it effects the behavior of Windows command shells. (It is analogous to $PATH in Linux, UNIX and Mac OSX command shells.)

Mac OSX. Java 7 or 1.7, which is the current version?

I am trying to run an application (on MacOSX) that relies on Java. Docs are telling me that I need to update from Java 1.6 to 1.7. I then found, downloaded and installed java 7 from Java.com, but I'm still getting java version error when running app. when I enter 'java -version' into terminal it tells me I am still running 1.6?
I'm sure there is a logical explanation for this, but at the moment I feel Like I am in the twilight zone. What is the current version, 1.7 or 7? Why is it that in System Preferences it says I have Java 7 installed, but 'java -version' says I have 1.6?
Help!

I just have this in my bash profile:
export JAVA_HOME=$(/usr/libexec/java_home)
... This should ensure that your Mac references Java 7 where applicable. Per the Apple docs:
The /usr/libexec/java_home tool dynamically finds the top Java version
specified in Java Preferences for the current user. This path allows
access to the bin subdirectory where command line tools such as java,
javac, etc. exist as on other platforms. The tool
/usr/libexec/java_home allows you to specify a particular CPU
architecture and Java platform version when locating a $JAVA_HOME.
(From Technical Q&A QA1170: Important Java Directories on Mac OS X)
EDIT re bash profiles:
If you don't know about shells and their configuration, you have a little work ahead ofyou. However, Nathaniel Landau's post, My Mac OSX bash profile may well help you.

VisualVM unable to sampler memory

I have a tomcat instance with the JMXRemote parameter configured. The local VisualVM is able to get a sampler on CPU, however, not for Memory. The memory button is grayed out with a summary saying: "Memory sampling: Not available. Cannot connect to target application. Make sure the application is running on a supported JDK 6 or JDK 7"
JMXRemote parameter:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Tomcat JDK version:
JDK1.6.0.30
VisualVM version:
Version: 1.6.0_30 (Build 1320-110325); platform 110131-9c8b3bfb3a1e
System: Windows Server 2008 R2 (6.1) , amd64 64bit
Java: 1.6.0_30; Java HotSpot(TM) 64-Bit Server VM (20.5-b03, mixed mode)
Vendor: Sun Microsystems Inc., http://java.sun.com/
Environment: Cp1252; en_US (visualvm)
Userdir: C:\Users\Administrator\AppData\Roaming\.visualvm\7
Clusters: C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\platform
C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\visualvm
C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\profiler
Tomcat version:
Tomcat 6.0.32
I am running both the VisualVM and Tomcat at win server 2008. Anything i did wrong?

I had the same problem before.
You must have downloaded the version from jvisualvm homepage, right?
Don't do it!
If you use new jdk 1.7, VisualVM is already packaged in your jdk folder.
Use this version, you will not have any problem with memory sample.

This blog post leads me to believe that the temp directories of JVisualVM and Tomcat need to be the same for memory sampling to work. One of the comments on the post:
the temp directory must be set to the one used by JVisualVM, which can be discovered from the VisualVM system properties tab (java.io.tmpdir). Once I set the CATALINA_TMPDIR directory properly, this worked beautifully.

I've just run into this same issue and the answers above solved my problem but it took me a while to figure out how. Just in case anyone else is still having trouble and ends up this far down the thread, I was using the JDK that is part of the weblogic server configured through Eclipse and not the JDK that I installed seperately. I'm still a junior programmer and I wasn't putting 2 and 2 together until I started looking through my eclipse settings and verified my Installed JREs.
Ran the jvisualvm.exe from the weblogic jdk and all worked.

I would check the version of VisualVM is exactly the same as the JVM.
VisualVM is very version specific. I assume its still under fairly rapid development.
(Re posted as an answer as it may be the solution)

I've faced similar issues with JVisualVM, I've even asked a question about it here
A couple of insights/advices:
So, in order to sample memory you don't need jmx options.
I would double check whether you have 64 bit jvms installed along with 32 bit jdks on the same machine (even if they're not running and all the environment vars defined properly), I've read somewhere that sometimes it drives the JVisualVM crazy :) (yes I know it doesn't sound reasonable to us, java developers)
If it doesn't work, just uninstall all jdks that you have and install only 1 that you need. It can solve the issue.
I hope it will help you to resolve the issue, after all like Peter said these things are new and evolving

Here is my solution for similar problem: https://stackoverflow.com/a/16330238/715483
You can resolved this error by
$ ssh -Y user#remotemachine
$ wget http://java.net/projects/visualvm/downloads/download/release135/visualvm_135.zip
$ unzip visualvm_135.zip
$ cd visualvm_135/bin
$ ./visualvm
This instance of visualvm will be full featured, including memory and CPU sampling.
Read more about it here: http://shahriarinia.blogspot.com/2013/05/java-cpumemory-heap-usage-monitoring.html
http://mshahriarinia.com/

Make sure your VirtualVM/JDK is a 32-bit copy if your JRE is. If you are using Eclipse, check the selected JRE on Installed JRE's section.

And I have the same problem.
I always launched tomcat as a service and connected it with visualvm through jmx connection.
When had corrected catalina.bat:
set JAVA_OPTS=%JAVA_OPTS%
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9090
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
and launched it with startup.bat, visualvm automatically determine tomcat, and memory sampling was active.

I've got the same problem but with different envirnoment. My server was a Linux machine, the client a Windows 7 machine, but the problem is the same.
The solution was to launch the jvisualvm in the same machine and with the same user that is running the targeted application. If i run jvisualvm with other other user (ex: root) the memory button became gray.

Firstly, JMX should be enabled. Add the linked command line environment variables necessary to activate JMX if you haven't.
The environment variable CATALINA_TMPDIR should be set to match the JVisualVM as seen in the "System properties" tab of the Local > VisualVM. You can open this by double clicking on the "VisualVM" labeled entry in the Applications pane on the left.
Environment variables can be set by searching for environment, "edit environment variables for your account". New... > Enter a name and value.
If you would like the temporary directory of VisualVM to be somewhere else, you'll have to launch VisualVM from the command line and add an argument.
C:\Program Files\Java\jdk1.8.0_65\bin>jvisualvm.exe -J-Djava.io.tmpdir=C:\Users\You\Temp

Finding the JRE on Windows

I know this question is going to sound very stupid but here goes nonetheless. I need to bundle the new version of the JRE with my applicaiton and I cannot find either a version of the JRE that is not in .exe nor can I find where the jre is installed to on Windows 7 (windows 7 search cannot find anything so it is not helpful). Can anyone tell me where I can download a version of the JRE the would be good to bundle or where I can find the path that windows installed the JRE too?

Not sure about Windows 7 but on Windows XP the installation defaults to C:\Program Files\Java\jre6

corsiKa is correct about Windows 7
I found that the file path for jre is
C:\Program Files (x86)\Java\jre7
For my purposes I needed to install the Connector/J JDBC driver in the ext directory.
jre7\lib\ext\

Alternatively, install a JDK, if you haven't done it yet, and take the jre folder in its installation directory.
The JDK can also install it in Program Files (64-bit on 64-bit Windows, always on 32-bit Windows) or Program Files (x86) (32-bit on 64-bit Windows) as explained above.
It also installs java.exe, javaw.exe and javaws.exe in C:\Windows\system32
It will be the last installed version...

I have found another, more generic solution that I'm using in Powershell. The problem is that Java is now using symlinks to java, javaw and javac, so you can't always rely on using "where.exe java" because it returns the symlink.
I now rely on Java to report where it's actually running from by using verbose mode and parsing the output.
$javapath=((java -verbose -version | ? {$_ -match "Opened" }).replace("[Opened ","")).replace("\lib\rt.jar]","")
It will find the path that java reports it's actually using and return the installation directory. The only problem I haven't quite resolved is that it outputs extra information because of the "-version" option, but the only other option is the help, which is worse. However, when run from a script, the console output can simply be ignored. If someone else has a way of keeping it quiet, I'd like to hear it.