We Keep Coding

Having issues in initial ANTLR4 setup on macOS Monterrey

I am trying to setup ANTLR4 and I am having issues setting the classpath.
I followed the instructions in the book "The Definitive ANTLR 4 Reference 2nd Edition", in section "Installing ANTLR", also I followed the instructions here and I have not got any results running in command line antlr4 or grun (the alias created).
I am running on a MacbookPro M1, Monterrey. I tried this with java 11 and 8 and the results were the same. I use sdkman to handle multiple java versions. Also my default terminal is oh-my-zsh.
In my bash_profile I added ANTLR configurations like this:
and in file zshrc I am loading configuration from bash_profile.
This is the output from my terminal.

Mac OS is gradually locking things down tighter and tighter on the system volume. While I think there's a good argument that /usr/local/ shouldn't be a part of that, it looks like it is.
Try placing your antler jar file some place within you home directory (perhaps changing all references to /usr/local to just be ~ (or maybe ~/local if you'd prefer to separate them out.)
I just downloaded the latest:
cd ~/lib
sudo curl -O https://www.antlr.org/download/antlr-4.11.1-complete.jar
changed by .zshrc to reference the new version:
export CLASSPATH=".:$HOME/lib/antlr-4.11.1-complete.jar:$CLASSPATH"
alias antlr4='java -jar $HOME/lib/antlr-4.11.1-complete.jar'
alias grun='java org.antlr.v4.gui.TestRig'
grun is running just fine

cannot execute java class from bash script and also updatd the java_home to higher version and compiled the class in the lower version than mentioned

I had SunOs 5.10 unix server , where i had written a script to execute a java file which is as below
#!/bin/ksh -x
export JAVA_HOME=openjdk1.8.0_331/bin
$JAVA_HOME/java com.myclass.MyClient
in this script there is alot of code which includes log file, and other binaries class path added before exporting JAVA HOME. But when i am executing i am getting the below error
openjdk1.8.0_331/bin/java : Cannot execute
i had changes lot of java versions but getting the same error

Your JAVA_HOME is not an absolute path. This is broken; many tools will just fail when you do this. Just make it an absolute path. It may or may not explain your error, but it's a ticking timebomb.
JAVA_HOME cannot be bin; its the level above bin.
It looks like you're using JAVA_HOME as an ersatz script variable to make your script work, but this is wrong: JAVA_HOME is used by all sorts of tools and has a very specific meaning, and it's not whatever you think it is.
There are 2 obvious explanations for your error:
Some tool sees JAVA_HOME, attempts to run java based on this, and fails, because your JAVA_HOME is broken. There's a ton of infra that is 'custom' per OS, and it may well be that the SunOS setup didn't fail if you set JAVA_HOME to broken values, but it does fail here. The fix is to not have broken JAVA_HOME, not to start looking for a setup on your new OS that can deal with broken JAVA_HOME settings. In other words, your script was always broken, it just so happens that your specific set up on that specific server on that specific version of sun OS so happened to be capable of dealing with the mess.
A much simpler explanation is also possible: That executable does not run on your OS+Architecture combination. trivially testable: Do NOT set JAVA_HOME at all and just try to run that java executable by e.g. cd ing to the path and running ./java -version. See what happens. If that also gives you cannot execute, voila - the script isn't the problem (though it still has a broken JAVA_HOME you should be fixing), you need to install a JVM that works on your OS+Architecture.

Maven installation issues: JAVA_HOME should point to a JDK not JRE?

I'm super new to CS and very unfamiliar with UNIX/Bash vocab.
I'm currently trying to install Maven, and I made a few mistakes by copy pasting old installation instructions (with incorrect version numbers) and now the whole process is so messed up. I first tried to follow the given instructions on the website, that didn't work, then I tried a few other ones, and now I'm worried that I'm left with a mess by following different sets of instructions.
I've reached a point now where if I type in mvn -version I get the following:
The JAVA_HOME environment variable is not defined correctly
This environment variable is needed to run this program
NB: JAVA_HOME should point to a JDK not a JRE
Originally, my JAVA_HOME was set to jdk-install-dir, which still gave me the above error message. I tried redownloading the jdk (version 13.0.1) from Oracle, dragged that file to my home directory, and unzipped it. Then I set my JAVA_HOME to that unzipped file, jdk-13.0.1.jdk, and updated my PATH variable. After all this, I'm still getting this same error message, and I'm not sure what to do.
For the reference, here are what some relevant environment variables are set to (I didn't include irrelevant info from PATH):
~ echo $JAVA_HOME
jdk-13.0.1.jdk
~ echo $PATH
/usr/local/apache-maven/apache-maven-3.6.3/bin:/opt/apache-maven-3.6.3/bin:jdk-install-dir/bin:/usr/local/apache-maven/apache-maven-3.3.9/bin:/opt/apache-maven-3.6.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/allyson/apache-maven-3.6.3/bin:/Users/allyson/apache-maven-3.6.3/bin:jdk-12.0.1.jdk/bin:/Users/allyson/apache-maven-3.6.3/bin:JDK-13.0.1.jdk/bin
~ echo $M2
/usr/local/apache-maven/apache-maven-3.6.3/bin
~ echo $M2_HOME
/Users/allyson/apache-maven-3.6.3
One thing I'm curious about: for the M2 and M2_HOME variables, is it supposed to be that one is in my home directory (/Users/allyson) and one is for /usr/local?

OK, take a deep breath, and we'll walk through this. Each of these environment variables has a purpose, and once you understand what those purposes are, this makes a lot more sense. Mixing tutorials is not necessarily a problem, but you'll want to understand what you're doing, rather than just blindly copy values from the internet.
JAVA_HOME is intended to identify to the system environment where to find a java runtime environment. It needs to be set to the full path of where your JDK has been installed. On windows, this might be C:\Program Files\Java\jdk-13.0.1. On a Linux system, you have a bit more flexibility. Common locations might be /opt/java/jdk-13.0.1 or /usr/local/java/jdk-13.0.1. If you installed your JDK somewhere else, then you need to use that path instead. The message NB: JAVA_HOME should point to a JDK not a JRE refers to a common mistake when installing maven -- maven requires a JDK, not a plain JRE. This error is so common that any time JAVA_HOME points to a folder that isn't a JDK, it prints this warning (even if the folder in question isn't actually a JRE).
M2_HOME is supposed to be set to the full path where maven is installed (i.e. the place where you unzipped it). This more or less helps maven "find itself" if it should need to for whatever reason. Strictly speaking, this one isn't necessary. (It's not set on my system, and maven works fine for me). It's mostly a convenience for setting the next environment variable.
M2 is the full path to the folder where the maven executable is. This will almost always be $M2_HOME/bin, but it's certainly possible to do weird things, and this will let you work around those situations. Obviously, this won't work if you didn't specify $M2_HOME. This one isn't strictly necessary, either, and is mostly a convenient way of setting up the next one.
PATH is where your Linux system looks to find programs to run when you type their name on the command line. For ease of use, you'll want to make sure that the maven and java executables are included somewhere in the : delimited list. Most Linux distributions already have a default PATH set up for you in a shell resource file of some kind. You'll want to refer to their documentation for how to add another entry to the path, but a common idiom would be PATH=$PATH:$M2 (which would append the value of $M2 to the value of $PATH and then store the result back into PATH. If you didn't set up $M2 or $M2_HOME, you'll need to do something else.
So, TL;DR, if you installed your JDK in /opt/java/jdk-13.0.1 and unzipped maven into /opt/maven/apache-maven-3.6.3, your bear minimum working values are:
export JAVA_HOME=/opt/java/jdk-13.0.1
export PATH=$PATH:$JAVA_HOME/bin:/opt/maven/apache-maven-3.6.3/bin
And if you wanted a complete set
export JAVA_HOME=/opt/java/jdk-13.0.1
export M2_HOME=/opt/maven/apache-maven-3.6.3
export M2=$M2_HOME/bin
export PATH=$PATH:$JAVA_HOME/bin:$M2
It's worth noting that most Java IDEs will include a GUI for setting up maven and Java within the IDE (the settings will typically only work within that IDE). It's often much easier for beginners to get up and running that way.

$JAVA_HOME should be a full path, not the dir name.
scream#kafka1:~$ echo $JAVA_HOME
/opt/java/jdk-11.0.5/
scream#kafka1:~$

I'm working on Ubuntu 20, and my own issue was about the jdk version located in the JAVA_HOME variable, which wasn't the right version. This was my trip around that issue:
First, What is the JAVA_HOME value?
$ echo $JAVA_HOME
$ /usr/lib/jvm/jdk-11.0.10
Next question/step, where is the Java app pointing to?
(Source: https://stackoverflow.com/a/42706056/2373421)
$ java -XshowSettings:properties -version 2>&1 > /dev/null | grep 'java.home'
java.home = /usr/lib/jvm/jdk-11.0.12
So, the JAVA_HOME variable wasn't keeping the right value. Let's change that:
$ export JAVA_HOME=/usr/lib/jvm/jdk-11.0.12
The test outcome is right now:
$ mvn -v
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /opt/apache-maven-3.8.1
Java version: 11.0.12, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-11.0.12

I'm doing this for future me's bc after all the links in StackOverflow, the solution was to check mvn.cmd file on C:\Program Files\Maven\apache-maven-3.6.3\bin...
On line 52 it sets the JDK, but it didn't had the "/bin" where my OpenJDK 15 stored the java.exe
This fixed the issue on Windows 11 but it could serve as an idea for other OS. Hope that it helps!

Why can't Python execute java.exe via subprocess?

After upgrading Java from 1.6 to 1.7 x64 (on Windows 7), I suddenly can't launch java.exe via Python 2.7's subprocess module anymore. The following script used to just work:
import subprocess
subprocess.check_call([r"C:\Windows\system32\java.exe"])
Now it fails like this:
Traceback (most recent call last):
File ".\tst.py", line 2, in <module>
subprocess.check_call([r"C:\Windows\system32\java.exe"])
File "C:\Python27\lib\subprocess.py", line 506, in check_call
retcode = call(*popenargs, **kwargs)
File "C:\Python27\lib\subprocess.py", line 493, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python27\lib\subprocess.py", line 679, in __init__
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
I have also confirmed that C:\Windows\system32\java.exe does indeed exist, is an application, and can be executed from the command shell.
What goes wrong here?
EDIT:
I've found that I can start C:\Program Files\Java\jre7\bin\java.exe from Python, so C:\Windows\system32\java.exe must be some weird pseudo-shortcut although technically a Windows application. Version 1.7 must've messed it up somehow, since I just confirmed Version 1.6 is fine.

Assuming that there is a java.exe at "C:\Windows\System32" is not a particularly safe assumption. Even the assumption there is a "C:\Windows\System32" on the system isn't safe: Windows could reside on any fixed drive on the computer.
But even if there is a "C:\Windows\System32\java.exe", this might not be visible for 32-bit processes under Win64. Windows does some interesting things here in the name of backwards compatibility, you might want to look at http://en.wikipedia.org/wiki/WoW64.
Finding the Java version you're looking for - and there can be many - can be a thankless task. If you don't particularly care about which Java you find, try the JAVA_HOME environment variable. It's not always there, but if it is, you're done and it's probably the most portable way of finding a JVM. If it's not there, you can't go wrong by setting it, and many Java applications can make use of that variable.
Then again, Java just might be on the PATH, in which case removing the everything but 'java' in the subprocess call will do the trick. It can't hurt to try.

You might also want to check if the PATH environment variable has quotation marks "" around the jre's bin path. Python doesn't seem to like them:
C:\bin>set PATH=C:\Python27;c:\Program Files\Java\jdk1.6.0_35\bin
C:\bin>python -c "import subprocess; subprocess.Popen(['java', '-version'], stderr=subprocess.PIPE)"
C:\bin>set PATH=C:\Python27;"c:\Program Files\Java\jdk1.6.0_35\bin"
C:\bin>python -c "import subprocess; subprocess.Popen(['java', '-version'], stderr=subprocess.PIPE)"
Traceback (most recent call last):
[...]
WindowsError: [Error 2] The system cannot find the file specified
C:\bin>

Is there any remotely cross platform way to execute an external process?

I was looking for advice on how to execute a process that is somewhat cross platform.
I have written Java and Ruby implementations of my app, but its less of a language specific problem and more of a platform specific issue.
E.G on Ubuntu /usr/bin/ is searched for anything I do
# Ruby
`HandBrakeCLI #{args}` # works on Ubuntu and likely other linux distros since HandBrakeCLI is in /usr/bin/
For windows it will search the current directory I am running in. However, If copy the windows executable to the current directory a runtime linking error will cause it to crash (DLL not present)
The default install path for HandBrakeCLI is in "Program Files(x86)/HandBrake" (x86 only in 64 bit obviously), however Program Files isn't in the search path as far as I can tell.
For MacOSX I have no clue how to execute Mac "Application Folders" from the command line other than with the "open" command. But that is less of an issue since what I am really after is HandBrakeCLI which is just a normal executable. However HandBrakeCLI is not installed to /usr/bin or /usr/local/bin ( or any variation there of )
My best idea is to make a config file that has the path to HandBrakeCLI. If I go that route however it would be ideal to be able to detect what platform I am on, but that is another problem all together. One I have only done with C #ifdef sections and not in Ruby or Java.
I would appreciate any and all input.

You can get the current OS in Java using
System.getProperty("os.name")
In ruby:
require 'rbconfig'
puts Config::CONFIG['host_os']
Hope this helps :)