This was a fun read, there have been a lot of efforts in recent years to cut down on boilerplate in Java, and it’s interesting seeing how it’s come together.
The post mentions JBang for making scripts easily executable, but it’s also worth mentioning that since Java 11 you can use shebang lines without any sort of external dependencies, in the format #!/path/to/java --source 11 (or whatever java version you’re using)
The file gets compiled on the fly, every time that I run the script. And that’s just the way I want it during development or later tinkering. And I don’t care during regular use because it’s not that slow. The Python crowd never loses sleep over that, so why should I?
Somebody should politely point out the __pycache__ folder to this professor. Lots of other little misunderstandings about Python in here, but this one I found annoying enough to comment on.
Overall though, if you really want to write your utility scripts in Java, sure, why not? Familiarity with an API is reason enough. One programmer’s cumbersome boilerplate is another’s comfy furniture; de gustibus non est disputandum.
If you use tcc, you don’t even need that cache construct. You barely notice any slowdown because the compilation is so damn fast (hat tip to this post)
I think allowing a shebang script to be the interpreter for another shebang script is a bash extension. This will fail if you need to exec the script from another program, or use another OS where the default shell isn’t bash.
EDIT: This appears to be linux specific behaviour, not bash.
You can always use cscript hello.cscript. That works fine on MacOS – I just had to either change the shell to bash instead of sh so echo -n worked, or else drop the commenting out of the script shebang and use tail +2 instead of cat.
Presumably you can also just write your interpreter in C and shell out to gcc. That will also obviously be less overhead.
It’s reasonable to cache compilation output, but I’m not sure why you’re feeling bothered about this post. Java doesn’t really need to cache compilation output because the compiler and the runtime (Hotspot JIT) are plenty fast for this particular use case (fooling around with scripts), and the ability to just point the java command at a source file is a nice usability improvement in a 30 year old language that has never really focused on making things easy.
You’re absolutely right, having a cache most likely doesn’t really add much in the way of performance gains for this kind of use. It’s even possible that the better runtime performance of Java outweighs any advantage that Python’s cacheing could provide, although we’d have to know more about the actual workload. And it’s one less line in your .gitignore, I guess.
I was just annoyed by the ignorance of the quoted statement. I could do more nitpicking in this vein but I’m trying not to slip too far into pedantry mode.
Python’s plenty fast for 99% of what I’d use it for in scripting. Just because Python is slow compared to C doesn’t mean that it’s not more than fast enough for automating the **** out of everything :)
But it’s also good that developers are never content, and always want to push performance higher. We all win from that work.
It kinda pains me that Python, a language I like and that is already pretty good for small scripts, seems to be always inching closer to https://packaging.python.org/en/latest/specifications/inline-script-metadata/ being usable. I see it has gone from PEP to spec, but I’m unsure you can use this in the wild reasonably. Although pipx and friends are pretty good already.
(Obligatory: I’m always surprised at how I thought Oracle would be the end of Java, and it’s been the opposite.)
Since switching to uv, I’ve been using inline script metadata recently, and I like it quite a bit. I always thought that the python package and environment tooling was the weakest part of the language ecosystem, but uv has raised the bar.
Yes! I have switched completely to uv. But still, I wish you could do inline script metadata with the bare Python you find on common Linux and macOS systems. Maybe my grandchildren will see this :)
uv is great. In the end, it was all about learning from rustup and cargo, I guess. (Or any other similar system- I don’t think Rust is the only ecosystem with these tools.)
This is fascinating. Java being a language with… consistent behavior is pretty important IMO.
One thing I will never forget about Java as a student is that, generally speaking, the IDE support is world class. The debugger, the way an IDE will report all errors in a project (instead of just the file you’re looking at), and do it without you asking. Of course, the autocomplete works so well too.
I’m very curious about how the terseness plays in the long run.
This post being about Java being “better than Python” in all these ways is odd though. They could just remove all those swipes and the post would be better. Plenty of subjective stuff in there
I didn’t get that vibe. More like “your tool is Java, you can do interesting stuff with it”.
I’ve worked at a couple of placed now where python code wouldn’t fly, but you can do every imaginable horror with JVM languages, or Java to be even more precise.
True about removing those swipes, but I (who likes Python more than Java) didn’t find it too annoying.
Interesting post, but I did a double take when I saw the domain. IIRC this is the author of my very first Amazon order, “Big Java” by Cay Horstmann, in 2001. (Nothing bad to say about it, it was ok - also one of the first books about programming I bought, as well). Amazing that he’s still writing about Java.
People in their 20s that pointed the huge gain in practicality of perl, python, PHP back then, are now in their 50s.
What’s the point of this at this point? It’s too late. The only thing the language has going for it is inertia, which it gets from massive overly engineered codebases that negate all things mentioned in this article.
Can you show us any form of research that would show even a minuscule fraction of productivity boost over java? Or of security? Correctness? Anything?
The only real productivity gain that is on an order of magnitude scale is reusing code (as per the famous Brooks paper, which still holds true today) - and java has one of the biggest ecosystems, the only other ecosystem of similar size is JS and Python, all 3 having slightly distinct profiles. It has state of the art observability (you can literally connect a debugger to a live application with minimal overhead), the best GCs and here it’s not even a competition, stellar performance and a huge job market.
I absolutely love language design, but it is in a strange position of having some objective properties, but plenty subjective ones that can easily overshadow the others - in my opinion it’s bordering on art, but the very least some social field (as code is just as much written for a fellow human, as to the computer). Like, there is not even conclusive evidence on static typing being “superior”.
And java has improved significantly over the last 5-10 years, you might want to swallow your prejudice and re-evaluate it afresh. It has type inference, algebraic data types, pattern matching, virtual threads, low-latency GC and is on its way towards value types. All the while still supporting almost 30 decades of already written software. Like, for a typical backend/generalist software niche the correct question might very well be why not to use java? There are of course valid answers, but it is a perfectly good default choice for all kinds of software.
Come on, lighten up. He’s a professor! He probably teaches in Java and that’s the only thing he’s motivated to learn. At least he’s learning and applying new language features.
Java is now JavaScript!
This was a fun read, there have been a lot of efforts in recent years to cut down on boilerplate in Java, and it’s interesting seeing how it’s come together.
The post mentions JBang for making scripts easily executable, but it’s also worth mentioning that since Java 11 you can use shebang lines without any sort of external dependencies, in the format
#!/path/to/java --source 11(or whatever java version you’re using)Somebody should politely point out the
__pycache__folder to this professor. Lots of other little misunderstandings about Python in here, but this one I found annoying enough to comment on.Overall though, if you really want to write your utility scripts in Java, sure, why not? Familiarity with an API is reason enough. One programmer’s cumbersome boilerplate is another’s comfy furniture; de gustibus non est disputandum.
I think he is simply pointing the equivalence of “java foo.java” with “python foo.py”.
That second invocation, however, does create a cached, compiled artifact.
Easy enough to do in C.
QaD PoC:
Obviously bigger savings with bigger programs.
If you use
tcc, you don’t even need that cache construct. You barely notice any slowdown because the compilation is so damn fast (hat tip to this post)I think allowing a shebang script to be the interpreter for another shebang script is a bash extension. This will fail if you need to exec the script from another program, or use another OS where the default shell isn’t bash.EDIT: This appears to be linux specific behaviour, not bash.
You can always use
cscript hello.cscript. That works fine on MacOS – I just had to either change the shell to bash instead of sh soecho -nworked, or else drop the commenting out of the script shebang and usetail +2instead ofcat.Presumably you can also just write your interpreter in C and shell out to
gcc. That will also obviously be less overhead.It’s reasonable to cache compilation output, but I’m not sure why you’re feeling bothered about this post. Java doesn’t really need to cache compilation output because the compiler and the runtime (Hotspot JIT) are plenty fast for this particular use case (fooling around with scripts), and the ability to just point the
javacommand at a source file is a nice usability improvement in a 30 year old language that has never really focused on making things easy.You’re absolutely right, having a cache most likely doesn’t really add much in the way of performance gains for this kind of use. It’s even possible that the better runtime performance of Java outweighs any advantage that Python’s cacheing could provide, although we’d have to know more about the actual workload. And it’s one less line in your
.gitignore, I guess. I was just annoyed by the ignorance of the quoted statement. I could do more nitpicking in this vein but I’m trying not to slip too far into pedantry mode.Python’s plenty fast for 99% of what I’d use it for in scripting. Just because Python is slow compared to C doesn’t mean that it’s not more than fast enough for automating the **** out of everything :)
But it’s also good that developers are never content, and always want to push performance higher. We all win from that work.
Kinda reminds me of this classic: https://www.teamten.com/lawrence/writings/java-for-everything.html.
It kinda pains me that Python, a language I like and that is already pretty good for small scripts, seems to be always inching closer to https://packaging.python.org/en/latest/specifications/inline-script-metadata/ being usable. I see it has gone from PEP to spec, but I’m unsure you can use this in the wild reasonably. Although pipx and friends are pretty good already.
(Obligatory: I’m always surprised at how I thought Oracle would be the end of Java, and it’s been the opposite.)
Since switching to uv, I’ve been using inline script metadata recently, and I like it quite a bit. I always thought that the python package and environment tooling was the weakest part of the language ecosystem, but uv has raised the bar.
Yes! I have switched completely to
uv. But still, I wish you could do inline script metadata with the bare Python you find on common Linux and macOS systems. Maybe my grandchildren will see this :)uvis great. In the end, it was all about learning fromrustupandcargo, I guess. (Or any other similar system- I don’t think Rust is the only ecosystem with these tools.)This is fascinating. Java being a language with… consistent behavior is pretty important IMO.
One thing I will never forget about Java as a student is that, generally speaking, the IDE support is world class. The debugger, the way an IDE will report all errors in a project (instead of just the file you’re looking at), and do it without you asking. Of course, the autocomplete works so well too.
I’m very curious about how the terseness plays in the long run.
This post being about Java being “better than Python” in all these ways is odd though. They could just remove all those swipes and the post would be better. Plenty of subjective stuff in there
I didn’t get that vibe. More like “your tool is Java, you can do interesting stuff with it”.
I’ve worked at a couple of placed now where python code wouldn’t fly, but you can do every imaginable horror with JVM languages, or Java to be even more precise.
True about removing those swipes, but I (who likes Python more than Java) didn’t find it too annoying.
Interesting post, but I did a double take when I saw the domain. IIRC this is the author of my very first Amazon order, “Big Java” by Cay Horstmann, in 2001. (Nothing bad to say about it, it was ok - also one of the first books about programming I bought, as well). Amazing that he’s still writing about Java.
Seriously? In friggin 2025?!
People in their 20s that pointed the huge gain in practicality of perl, python, PHP back then, are now in their 50s.
What’s the point of this at this point? It’s too late. The only thing the language has going for it is inertia, which it gets from massive overly engineered codebases that negate all things mentioned in this article.
Can you show us any form of research that would show even a minuscule fraction of productivity boost over java? Or of security? Correctness? Anything?
The only real productivity gain that is on an order of magnitude scale is reusing code (as per the famous Brooks paper, which still holds true today) - and java has one of the biggest ecosystems, the only other ecosystem of similar size is JS and Python, all 3 having slightly distinct profiles. It has state of the art observability (you can literally connect a debugger to a live application with minimal overhead), the best GCs and here it’s not even a competition, stellar performance and a huge job market.
I absolutely love language design, but it is in a strange position of having some objective properties, but plenty subjective ones that can easily overshadow the others - in my opinion it’s bordering on art, but the very least some social field (as code is just as much written for a fellow human, as to the computer). Like, there is not even conclusive evidence on static typing being “superior”.
And java has improved significantly over the last 5-10 years, you might want to swallow your prejudice and re-evaluate it afresh. It has type inference, algebraic data types, pattern matching, virtual threads, low-latency GC and is on its way towards value types. All the while still supporting almost 30 decades of already written software. Like, for a typical backend/generalist software niche the correct question might very well be why not to use java? There are of course valid answers, but it is a perfectly good default choice for all kinds of software.
Your comment led me to find this article about one result of Java’s improvements, which I submitted to Lobsters: Visitor Pattern Considered Pointless - Use Pattern Switches Instead (2021)
Come on, lighten up. He’s a professor! He probably teaches in Java and that’s the only thing he’s motivated to learn. At least he’s learning and applying new language features.