We Keep Coding

What is wrong with my attempt at Spring quickstart?

So I am trying out the very very simple spring quickstart. You can find it here.
I have have java 1.8 installed, but am downloading Java 11 in the mean time from the suggested location (AdoptOpenJDK) just to be sure that isn't the problem.
I followed all the instructions, but when running the project, I get... nothing...
~/spring/demo$ java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-8u275-b01-0ubuntu1~20.04-b01)
OpenJDK 64-Bit Server VM (build 25.275-b01, mixed mode)
~/spring/demo$ ./mvnw spring-boot:run
It has been like this for 30 minutes while I've been typing out this question. There are no logs or anything to suggest what might be wrong.
Any ideas?
UPDATE: I am now getting a zip error within maven. I am still using java 1.8
~/spring/demo$ ./mvnw spring-boot:run
Exception in thread "main" java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:225)
at java.util.zip.ZipFile.<init>(ZipFile.java:155)
at java.util.zip.ZipFile.<init>(ZipFile.java:169)
at org.apache.maven.wrapper.Installer.unzip(Installer.java:169)
at org.apache.maven.wrapper.Installer.createDist(Installer.java:86)
at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:121)
at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:61)

Trenin , Please check whether you have 7Zip/Winzip Software because during startup it looks for these to unzip certain dependencies that it downloads .

Hadoop resource manager jdk 8 dependency

When I am trying to create a single cluster Hadoop environment, I cannot load the Node Manager or Resource Manager. From the log I get the error:
Caused by: java.lang.ClassNotFoundException: javax.activation.DataSource
Caused by: java.lang.ClassNotFoundException: javax.activation.DataSource
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 83 more
I gather this is from a dependency on javax.activation from JDK8. The only online solution I could find involved changing these two lines in the yarn-env.sh file in the usr/local/Cellar/hadoop/{version}/libexec/etc/hadoop folder:
export YARN_RESOURCEMANAGER_OPTS="--add-modules=ALL-SYSTEM"
export YARN_NODEMANAGER_OPTS="--add-modules=ALL-SYSTEM"
This did not work and I continue to get the same error in the log when trying to run the YARN manager. Can anyone advise as to how to get around this dependency?
Environment:
Mac OS Catalina 10.15.2
Java(TM) SE Runtime Environment (build 13.0.1+9)
Java HotSpot(TM) 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)
Apache Hadoop 2.10.0

You can set JAVA_HOME variable in hadoop-env.sh to the location of a Java 8 installation, then it should start okay
Alternatively, use Docker or a pre-built quickstart VM such as those from Cloudera

Java Heap Dump error - Metadata does not appear to be polymorphic

I get this Stacktrace when trying to take a heap dump from a running Java process. What causes this and what do I have to do to make a proper heap dump?
Dumping heap to dump.bin ...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: java.lang.InternalError: Metadata does not appear to be polymorphic
at sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:278)
at sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102)
at sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:68)
at sun.jvm.hotspot.memory.DictionaryEntry.klass(DictionaryEntry.java:71)
at sun.jvm.hotspot.memory.Dictionary.classesDo(Dictionary.java:66)
at sun.jvm.hotspot.memory.SystemDictionary.classesDo(SystemDictionary.java:190)
at sun.jvm.hotspot.memory.SystemDictionary.allClassesDo(SystemDictionary.java:183)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClasses(HeapHprofBinWriter.java:942)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:427)
at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62)
at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)
... 6 more
Environment: CentOS 64 bit, Java OpenJDK Runtime Environment (build 1.8.0_31-b13) OpenJDK 64-Bit Server VM (build 25.31-b07, mixed mode)
Using ps to see the java version that is used:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/jre/bin/java
My first try was:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/bin/jmap -dump:format=b,file=dump.bin 14984
That got me :
14984: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
So I ran with the -F option
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/bin/jmap -F -dump:format=b,file=dump.bin 14984

Ok, I found it.
I was running the jmap command as root, but I had to run as the user that started the java process.
In my case:
sudo -u robau ./jmap -dump:format=b,file=/tmp/dump.bin 14984
Seems to be related to this JDK bug:
https://bugs.openjdk.java.net/browse/JDK-8075773

I ran into the same issue with trying to run jmap on an AWS ElasticBeanstalk instance. The command that fixed it was
sudo debuginfo-install java-1.8.0-openjdk-devel
BTW, jmap was installed on the AWS ElasticBeanstalk instance with command
sudo yum install java-1.8.0-openjdk-devel-1.8.0.91-0.b14.10.amzn1.x86_64

I had this issue on CentOS even when running as the user that started the process. What solved it for me was installing the debuginfo package corresponding to the package supplying the jmap utility.
To install the debuginfo package, see this answer (substituting your java package for glibc). It requires getting/using the debuginfo-install utility, and making sure the CentOS-Debuginfo.repo is set up correctly and enabled.

On Ubuntu, I resolved this issue by installing the openjdk-dbg package:
sudo apt-get install openjdk-8-dbg
I now suspect that this resolved my issue indirectly by upgrading the jdk to a version that corrected the bug. You might be able to resolve this issue with:
sudo apt-get install openjdk-8
Note: After java is upgraded, you must restart the java process in order to get a proper dump. If you don't, you will get something like this:
Attaching to process ID 21957, please wait...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: sun.jvm.hotspot.debugger.UnmappedAddressException: 7f21453c9bf8
at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208)
at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63)
at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:498)
at sun.jvm.hotspot.debugger.linux.LinuxAddress.getCIntegerAt(LinuxAddress.java:69)
at sun.jvm.hotspot.HotSpotTypeDataBase.getLongValueFromProcess(HotSpotTypeDataBase.java:604)
at sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:164)
at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:89)
at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:395)
at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)
at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)
... 6 more

Can't upgrade Maven on Mac Lion - Environment Variables

My vitals: OS 10.7.5 Lion, Java version "1.7.0_79", Maven version 3.0.3.
I'm quite new to Environment Variables here, and having a lot of trouble with Maven. I got my current version from Homebrew, but I need a more recent one. I followed snooze92's instructions from this page (Maven Install on Mac OS X) to try to install the latest version of Maven, 3.3.3. My current version, 3.0.3, is stored in /usr/share/java/maven-3.0.3, and there's also a shortcut to that directory at /usr/share/maven.
echo $JAVA_HOME returns /System/Library/Frameworks/JAVAVM.framework/Versions/CurrentJDK/Home.
But running mvn --version returns a bunch of details including:
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre (which is a different folder to the path JAVA_HOME points to.)
Normally, echo $M2_HOME returns nothing. In this case, Maven 3.0.3 works just fine. If I create the $M2_HOME environment variable, as snooze92 suggests, and add it to my path using the following commands:
export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.3
export M2=$M2_HOME/bin
export PATH=$M2:$PATH
Maven stops working; typing in mvn --version returns the following:
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at org.codehaus.plexus.classworlds.launcher.Launcher.getMainClass(Launcher.java:144)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:266)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Quitting Terminal (or deleting the above lines from my .bash_profile file and re-opening) makes Maven work fine again, although it always reverts to version 3.0.3.
I also tried adding the commands on this page (http://www.mkyong.com/maven/install-maven-on-mac-osx/) to my .bash_profile file:
export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.3
export PATH=$PATH:$M2_HOME/bin
This causes Maven to return the error message:
-Dmaven.multiModuleProjectDirectory system propery is not set. Check $M2_HOME environment variable and mvn script match.

You could edit your .bash_profile to export the dynamic path of your JDK 7 Mac OS installation. This can simply be achieved by adding as first line:
export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
Thereby, it should be guaranteed that no 1.6 style JDK (e.g., as delivered by Apple) is used at runtime, but a working JDK 7 of your system environment. Try to validate the output of
java -version
in a new terminal instance after you edited the .bash_profile file. It should give you 1.7.x Java. After this step your newer Maven version should work and can be validated via
mvn -version
Explanation:
If you use /System/Library/Frameworks/JAVAVM.framework/Versions/CurrentJDK/Home instead you will get something like this for your JAVA_HOME:
java version "1.6.0_65" Java(TM) SE Runtime Environment (build
1.6.0_65-b14-466.1-11M4716) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
which is not what you want/need for Maven 3.3.x

Weka ClassNotFoundException

I'm attempting to install Weka, which I have installed into /weka directory. I set the CLASSPATH variable, but that shouldn't matter anyway because I'm using -cp.
I enter this into SSH:
java -Xmx5G -cp /weka/weka.jar
weka.core.converters.TextDirectoryLoader -dir /home/myuser/test >
/home/myuser/test.arff
And it spits out:
Exception in thread "main" java.lang.NoClassDefFoundError:
weka/core/converters/TextDirectoryLoader Caused by:
java.lang.ClassNotFoundException:
weka.core.converters.TextDirectoryLoader
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266) Could not find the main class: weka.core.converters.TextDirectoryLoader.
Program will exit.
What wrong? There is no "weka/core/converters/TextDirectoryLoader" because its all stored in weka.jar, which is where it should be looking.
My Java version:
java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.10)
(rhel-1.23.1.9.10.el5_7-x86_64) OpenJDK 64-Bit Server VM (build
19.0-b09, mixed mode)
I just downloaded Weka today from the link on their downloads page, so there shouldn't be anything wrong with it.
Now I know that this would normally be because it can't find weka.jar, but I promise you that it is right there at: /weka/weka.jar. And I can also promise that both the /weka directory and weka.jar have execute permissions.
Please help!

Just downloading and running the .jar works for me:
carsten#dallas:~$ java -Xmx5G -cp /tmp/weka-3-6-5/weka.jar weka.core.converters.TextDirectoryLoader
Usage:
TextDirectoryLoader [options]
Options:
...
as well as java -jar /tmp/weka-3-6-5/weka.jar, which opens some GUI tool.
You sure that you installed Weka on the server you SSH into?

I happened the same to me in Mac OS when I used the jar released in the dmg packaged.
Instead of that one, I imported the jar file under:
Applications/Weka/Resources/java/weka.jar
To get it you have to:
go to Applications
right click over weka-3-x-x
Show package content
go to /Resources/java/weka.jar
import that one jar into your classpath