The End of “Python for Scripts, Java for Systems” (Maybe)

We all know the joke.

Python: read a file in two lines.
Java: create a project, write a pom.xml, summon public static void main, and hope the universe is in a good mood.

For years, my rule was simple:

Java for the enterprise. Python for the weekend.

Then I tried something that made me a little uncomfortable.

I rewrote a handful of “Python-only” scripts in modern Java.

Not as Maven projects. Not as Gradle builds. As scripts.

And… Java didn’t just keep up. It looked way too good.

The twist: Java wasn’t the problem. Java ceremony was.

Most “Java vs Python” debates are really “workflow vs workflow.”

Python feels like magic because the workflow is perfect:

1. Open a file
2. Write code
3. Run python script.py

Java historically fought you on step 1.

That’s the whole story.

So what happens if you remove the ceremony?

That’s where JBang + Java 21 enters.

• JBang lets you run a single .java file like a script.
• You can declare dependencies inside the file (yes, inside the file).
• Java 21 gives you a much cleaner single-file entry point (no “Main class” boilerplate).

The new workflow looks like this:

1. Create script.java
2. Add a dependency as a comment
3. Run jbang script.java

That’s it.

And once you try it, the “Python for scripts, Java for systems” rule starts to wobble.

A tiny example: a web server in one file

Python has Flask. Java has… a surprising answer.

Save this as Server.java and run it with jbang Server.java.

///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS io.vertx:vertx-web:4.5.1

import io.vertx.core.Vertx;
import io.vertx.ext.web.Router;
import io.vertx.ext.web.handler.StaticHandler;

void main() {
    var vertx = Vertx.vertx();
    var router = Router.router(vertx);

    router.route("/*").handler(StaticHandler.create("."));

    vertx.createHttpServer()
        .requestHandler(router)
        .listen(8080);

    System.out.println("Server running on http://localhost:8080");
}

The important part is not Vert.x.

It’s the experience:

• No project setup
• No build file
• No dependency wrangling
• Just run it

That is the “Python feeling.” In Java.

The bigger point (and why this matters)

When you remove the startup pain, Java becomes a very different tool:

• You can prototype in the same language you ship.
• You can keep JVM performance and tooling.
• You get types, refactoring, and strong libraries without the “rewrite cliff.”

But that’s also where the real debate begins.

Because Java doesn’t just “match Python.”
It shifts where you pay the cost: early friction vs long-term maintenance.

And modern Java changes that trade-off in a way most people haven’t internalized yet.

Want the real proof?

In the full article, I go further:

• More “Python-only” tasks rewritten in modern Java
• A short but brutal “prototype to production” reality check
• Why types are surprisingly nice for scripts
• A visual curve that explains why this shift feels so big

If you have not tried JBang lately, this will probably change your mental model.

👉 Read the full piece on The Main Thread:
https://www.the-main-thread.com/p/java-is-the-new-python-jbang-java-21