My experience using Java to do CLI Scripting

[David Alayachew]

Hello Amber Dev Team and Kulla Dev Team,

(I made a reddit post too, if you prefer to interact there instead --
https://www.reddit.com/r/java/comments/1jx87ys/)

The following JEP's have released recently.

   - JEP 495: Simple Source Files and Instance Main Methods
   <https://openjdk.org/jeps/495>
   - JEP 330: Launch Single-File Source-Code Programs
   <https://openjdk.org/jeps/330>
   - JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
   <https://openjdk.org/jeps/222>

These have made it really easy for me to do CLI scripting in Java, as
opposed to Bash. However, I've run into some pain points, as I've relied
more and more on Java.

For starters, the hand off from Java --> Bash is kind of ugly. Bash -->
Java is not bad, due to void main(final String[] args), as well as Bash's
xargs. But Java --> Bash is ugly, and here is an example demonstrating
how/why.
------------------------------

I use AWS CLI to manage my dev environment. It's super powerful, and is all
available directly from the CLI, using simple Bash or even CMD.

Let's say I use AWS CLI to gather some ad-hoc information about my entire
dev environment. How do I manage the multiple handoffs back and forth
between AWS CLI and Java?

There are no good answers.

   1. Store the results into a file, then use JShell/java(c) to process the
   output file from Bash/AWS CLI.
      - There's multiple handoffs back and forth between AWS CLI and Java.
      So, every handoff from Java ---> AWS CLI means generating a new
file, thus
      increasing the complexity and cruft. It's unideal.
   2. Use Java's ProcessBuilder
   <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ProcessBuilder.html>
   and Process
   <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Process.html>
   classes.
      - This works, but is heavy-handed. Look at the examples in those
      links. That is multiple lines of code to represent a single bash command.
      It does appear to be the idiomatic way, though.
   3. Do all upstream processing with AWS CLI in Bash directly, then do
   only a single handoff to Java, once I have done all I need to with AWS CLI.
      - This is definitely the least painful, but it also means I don't use
      much Java at all. And any changes in upstream processing must be done in
      Bash to avoid handoff headaches from AWS CLI ---> Java.
   4. Download the AWS SDK Jar files and just do it all in Java.
      - Ignoring the fact that some things are much harder to do via the
      AWS Java SDK's, there's actually some functionality that just isn't
      available via the Java ones. I'd have to recreate it myself, and it would
      be a significant lift.

Option 4 is best when I am building an application, but for ad-hoc checks
that I want to do on the fly (my most common use-case by far), I have been
using Option 3.

I just wish I could use more Java. It's a *FAR BETTER*tool than Bash, but I
can't justify the level of effort for ad-hoc use cases because of the poor
hand off from Java --> Bash. And since AWS CLI is only available via
Bash/CMD, I'm stuck with a bunch of not-good choices.
------------------------------

CLI Scripting in Java is great, but I wanted to highlight this pain point
to spread awareness.

Can you relate?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250412/a3e476ab/attachment.htm>