System.getenv exists, so getting is easy... But setting env vars generally involves a convoluted process.

You can modify the JVM's buffer, or spawn a new ProcessBuilder, or a few other things. But it's a nasty place to be.

1) java shell starts 2) read getenv into a java hashmap 3) evaluate shell input - any sets update the hashmap, any gets read from the hashmap 4) when you get to a point where you need to exec a process you use the hashmap to pass envvars into process builder - which is going to call execvpe for you.

So yeah you definitely could (there'd be other reasons why java wouldn't be a good choice).

TBH reading that folks were calling setenv before an exec to propagate env vars to a child made me sad. I would guess that other use cases were leveraging environ as a poor man's global variable - which is also unfortunate.

execve(2) and friends allow you to specify a new processes's environment variables. How Java may choose to expose that I don't know. Assuming they do, that is all a shell needs. You do not strictly need to call setenv(3) to change a variable that gets evaluated with $, etc. You do need to pass the modified environment to a child process.

You can pass a new environment to a process you spawn, which I think is adequate? You just can't modify the environment of your existing process.

There are tons of reasons you can't write a POSIX shell in Java, starting from the lack of support for non-UTF-8 paths :)