FAQ

  1. Why the name j’bang?

    I was reading up on how to use the new shebang (#!) feature support in Java 10 and came up with the idea of port kscript to Java and needed a name. From there came j’bang which is a "bad" spelling of how shebang is pronounced in French.

  2. Why use gradle resource locators rather than ?

    kscript used it and it’s nice as it is a one-liner and easily parsable.

  3. How does this compare to ?

    After releasing jbang in December 2019 I’ve learned about similar projects and others poppped up so thought it would be nice to have a list with some comparison. Below is a list in order when they were created.

blaze (November, 2014): a tool for using JVM languages for scripting. It’s goals are similar to early jbang but it’s more opinionated on how to setup and run scripts. Provides useful libraries for scripting thus actually useable from JBang as well as a dependency and jbang can be used torun it: jbang app install --name blaze com.fizzed:blaze-lite:RELEASE

kscript (March, 2016): provides scripting for Kotlin before Kotlin had support for it. Was the main inspiration/kickoff for JBang as: "Cool you can do this with Kotlin, but why can’t I just use Java?".

jgo (March, 2017): an alternative way to launch jars using maven coordinates. Implemented in python, depends on Java and Maven to be available. Not really for scripting but a novel way to launch java apps already packaged as a maven dependency.

mill (October, 2017): Object-oriented buil tool for the JVM. Has some scripting features similar to JBang but tied to be "inside" th project.

bld (May, 2023): Build tool for Java using Java.

bach (March, 2018): Build tool for Modules based Java projects using Java.

babashka (August, 2019): A native Clojure interpreter for scripting with fast startup. Offers scripting features similar to JBang but with a focus on Clojure; not for running Java applications.

jpm (July, 2024): A simple command line tool, taking inspiration from Node’s npm, to manage Maven dependencies for Java projects that are not using build systems like Maven or Gradle.

jpm (August, 2025): npm inspired package/build tool for Java projects.

Grind (Oct, 2025): Shares similar goals to JBang but instead of using Java it uses Go. This leave it at a disadvantage as have to re-implement alot of the dependency resolution instead of using Java.

Veles (Oct, 2025): Java cli, at least on surface looks very similar to JBang but focus more on replacing build tool rather than general use as JBang. Only target Java 25+.

Why is JBang scripting examples using lower case class names ?

JBang works with any valid Java class names including Java’s standard camel case conventions. The scripting examples are using lower case because the scripts can be used as a command line tool. i.e. ./hello.java. Just like people are used to Java using camel case for class names, they are also used to using lower case for command line tools. So JBang is just following the convention most relevant for the scripting use case. Thus helloworld.java instead of HelloWorld.java; but if you prefer the latter you can always use it.

Why would I use Java to write scripts ? Java sucks for that…​ Use groovy, kotlin, scala, etc. instead!

Well, does it really suck ? With Java 8 streams, static imports and greatly improved standard java libraries it is very close to what kscript and grape look like. With the following advantages:

  • works with plain Java without installing additional compiler/build tools

  • all IDE’s support editing .java files very well, content assist, etc.

  • great debugging

    And to be honest I built jbang just to see if I could and get my Java skills refreshed for the newer features in the language. Use it at your own risk :)

Why not use normal shebang(#!) in the header ?

You can use normal shebang (#!/usr/bin/env jbang) and the Java 10+ launcher (java test.java) will actually work with it from the command line. However the Java compiler will still not accept it (javac test.java with shebang fails.) This is thus not recommended, as many tools, code formatters ([example](https://github.com/google/google-java-format/issues/1214)), and especially IDE’s will start complaining about syntax errors as they don’t ignore the first line in this case.

By using the // form it is treated as both a bash/shell file AND a valid java file and thus works everywhere a java file will work.

It’s worth noting that Go uses a similar approach which is also where I learned it from.

HELP! My code formatter keeps breaking my // directives!

When using automated code formatting tools, some care and configuration must be made to prevent the tooling from rewriting and preventing jbang from working as expected.

Use the following configuration blocks to correctly configure your tool:

Table 1. Configuration Tool Settings:

Formatting Tool

Configuration

Google Java Format

see #1215 & #1214

Clang Format

CommentPragmas:  '^[^ ]'