Java in the Small

Anecdotal, but I had an intro to programming class in high school and the teacher was a wonderful woman, but not a programmer. She didn't know that this was a function declaration or its meaning, so she would just have us repeat out loud "public static void main string box args". I get a laugh whenever I think of that. I hope she's doing well.

I haven't written Java in a million years.. so I'm trying to understand better.

But what does this code even mean..? Isn't Java's whole simplifying model that everything lives in "Objects"? This seems to break that fundamental paradigm and makes the language more complicated. If you needed something like global functions then in vanilla Java as I remember you'd stick it into static final Objects that acts as a namespace of sorts. So you don't need to worry about functions floating around in a global namespace soup.

If you're gunna just have free floating functions in your file.. then why not just cut to the chase and have a

    println("Hello world");

It took almost 30 years to get here. I never thought I'd see the day.

What really threw me for a loop is the article author mentions: "I knew plenty of professors who were bothered by [the public static void main thing]." I could have sworn that OOP die-hards in academia _wanted_ the formal class boilerplate in the original design. Maybe they aged out? Perhaps, times are changing.

Song version: https://www.youtube.com/watch?v=yup8gIXxWDU

I disagree. Working through each keyword until you understand the full signature felt great when learning.

It’s the Python if __name__ == __main__ trash that was the worst. You’ll never understand it and it doesn’t fit in the language.

You might also like Kotlin script.

   #! /usr/bin/env kotlin

   println("Hello world")

IMHO Kotlin is underused as an alternative to python currently for data science stuff. It's surprisingly capable out of the box even with just the standard library and there are a lot of nice data science libraries that make it more useful. Not for everyone; but fairly easy to get started with.

Kotlin scripting is unfortunately not necessarily very user friendly (e.g. imports can be a bit tedious and IDE support is a bit meh). But it can be a nice way to embed some kotlin stuff in a script. Generally, Jetbrains could give this topic a lot more love and attention and it wouldn't even take that much to level up the experience.

KTS works in jupyter as well (there is a kotlin engine for that). And that of course is nice if you want to use Java libraries in jupyter. And developing kotlin DSLs for stuff and then using them in a script is kind of a power move.

One is

    void main(String[] args) {
        println("Hello world");
    }
 
 and the previous one ...

   class HelloWorld {
      public static void main(String[] args) {
          System.out.println("Hello, World!"); 
      }
  }

Should we allow somebody who cannot handle the second one, go on and programming because of the first one?

>less crufty than the old "public static void main(String[] args)" thing. I always felt that was a terrible introduction to programming

I somewhat agree, but it was kind of exciting to learn what each of those previously meaningless words meant.

Kind of a sneak preview... Tune in for next week when we learn what static means!!

Really Java has always been kinda okay - the really horrible part of Java was always the "enterprise OOP" programming patterns that were basically a given in any commercial codebase - little things like pointing out the verbosity of a basic single file project are just shorthand for "look at all this shit people have written".

As the adage goes - Java programmers can write Java in any language.

I agree that can serve as terrible intro to programming. But, often when we have tools either designed for a purpose in mind or a dominant paridigm or reaction to existing set of tooling, this can result in understandable yet extreme abstractions.

Java is designed with OOP in mind and it kind of makes sense to have the user to think in terms of lego blocks of interfaces. Every method or class needs to have clear understanding of its users.

public - software handle is for all users

protected - software handle for current and extending classes

default - software is exposed to current package

private - software is restricted to be used in current class alone and nowhere else

So, the beginning of java programming starts with interface exposed to the user or other programmers. Is it weird and extreme. Yes. At least, it is consistent.

You don't need the args!

  void main() {
      println("Hello world");
  }

They've also done quite a bit of work to make things such as hosting a web service much much simpler, through the addition of things like SimpleFileServer, as well as some better convenience methods.

It makes it far far closer to the python experience.

> than the old "public static void main(String[] args)" thing

you forgot surrounding class definition.

It's a good local improvement, but the other hand that old traditional syntax was a good effective "keep away" sign in Java that saved many CS students from being fed Java as a first language. And it's still a bad first language after this change. I wonder if this small improvement might make things worse in the big picture.

Records being allowed in methods has been great for me when doing things like path finding. Makes it easy to write something like:

    record Node(int cost, int row, int col){}
    var pq = new PriorityQueue<Node>(Comparator.comparingInt(Node::cost));

So it’s almost as good as C#? Which would be my favorite language if not for strong ties to MS ecosystem.

Just to be clear, the implicit class thing is still a preview feature as of Java 24, which should come out next March. It might be finalized for Java 25, in the coming September. But no guarantees. Until then you'd need to explicitly enable it with a cli parameter.

> debugger hot reload

Hey, that's (close to) the traditional Smalltalk introduction-trick! And this has been available since 1.1? How does one concretely do that in Java and why is it not widely known?

> But probably the best magic trick for Java programmers is debugger hot reload. You write some empty methods, start the debugger, and then code iteratively, reloading as needed. (Set up the data and interfaces right, and change method bodies as you wish.)

Do you have any example you can point to for this ?

I agree it'll work, but from a broader ecosystem perspective it feels like a mismatch, given PHP's historic focus on webstack stuff, and the projected likelihood that someone maintaining the system will know PHP versus Python etc.

But perhaps we can both agree that it shouldn't be in JS/Node. :p

That's true for every other mainstream interpreted language. Is PHP better than Ruby or Python for those use-cases?

Few languages pull off the balancing act Java does, supporting decades of code while rolling out big new features like project Loom in a backward compatible way. Oracle’s work really feels like a lesson in how to evolve a language.

It's hard to fault Java at this point: arguably the best runtime of them all from a perf perspective, great tooling from JetBrains, large, high-quality ecosystem whose quality far exceeds npm on average, and sealed classes as an acceptable sum type. My only remaining issue is how prevalent nulls are, but there's some work in progress on improving that. Until then, I'll prefer Kotlin slightly.

Definitely one of those things where the comment section is only good at spouting ancient memes with little regard to the truth of them.

PHP syntax does add to the line widths, so breaking long lines in multiple lines by extracting variables can help with readability. Using return, continue and break early reduces indentation so that helps too, as well as creating smaller functions.

I use Ruby for scripting because it has a big standard library (unlike javascript) and an expressive syntax. The syntax is also very readable and short. It's also easy to install gems globally and use them. Things only need to be imported once.

I wouldn't say these things are qualities for big projects though. I like Typescript for big projects.

It looks like they took lots of inspiration from Kotlin with these new implicit imports and their structure.

Are you in the comfort zone with Spring as well?

Also scala-cli https://scala-cli.virtuslab.org/docs/getting_started

I still like to use Ammonite as a REPL, but scala-cli has replaced it for me in those cases where i get fed up writing bash.

exactly my thought. If you think java makes a good scripting language, you will be really happy with scala

Scala-cli would be even better. It explicitly supports Java too!

Python packaging continues to be a pain, but you can specify dependencies for single-file scripts with inline script metadata, see: https://packaging.python.org/en/latest/specifications/inline...

Maybe it's sort of not the same because it's compiled with graalvm and so not trivial to add any arbitrary Java dependency, but the tech that scratches that itch for me is babashka — a proper REPL, because it's a lisp, sensible Clojure syntax, and easy IO. And all the core Java libraries, available in a much snappier form than Clojure or other compiled languages

I use Java extensively for my personal work and never use Gradle/Maven/Ant. I run Python scripts that marshal javac and java calls, it works great. I do cute tab completion tricks that examine the class layout and extend based on what it finds. I even have a "SmartCompJava" script that finds .java files that have newer modtimes than their corresponding .class files and just compiles them - a bit dangerous if you're not careful, but it's super-fast!

Ah.. the old days of java programming - set up your CLASSPATH and done.. Nowadays; however, most libraries have tons on other dependencies and doing this manually is tedious and a pain in the neck - download the wrong version of the dependency, and you are in for a rabbit-hole trying to figure out the compilation errors. Do not get me wrong, Maven is ugly and disgusting(so are the other dependency managers for java), but gone are the days of CLASSPATH.. unless you avoid using libraries bloated 3rd part libraries at any cost.

>Lightweight Java has always been a thing for those who appreciate Java-the-language but despise Java-the-ecosystem.

I always disliked Java until I was converted by some developers of that group in a past job. I suppose it is fair to judge a language by the overall flavour of its ecosystem, but it is a bit disappointing. I wish more people could see how simple and _good_ it can be when you use the JDK itself, and not go through other overcomplicated systems to use it. For example, Spring Boot is basically a massive pile of hacks (regardless of whether you consider it good or bad), and Java only really serves as an underlying support technology for it.

java -cp .:* OneOffTestCase.class

> Yeah it can be annoying if you're not good at keeping track of your own typing hints

If you write all the code you deal with, then sure. My experiences on big projects tend to be typing problems introduced by libraries. The kind where documentation and the decorators suggest it'll only ever return some specific value type, but then very occasionally it'll return a tuple of that value type and a message.

Great is pretty domain-specific!

Java has been great for larger projects for a while, but I think smaller things like one-off scripts have been firmly out of reach so far.

It's good to see that change, as being able to use it in the small has obvious synergies.

Every function call is 4 lines in Go. No basic error propagation support means Go code bloats up very fast in line count.

  result, err := callFoo()
  if err != nil {
      return nil, err
  }

Go is good for middleware coding thanks to Go-routines and and excellent networking support in the standard library but is cumbersome slow and inexpressive for scripts.

Also go.mod does NOT separate dev/test/prod dependencies - unlike Java Maven or Rust Cargo. You don't want your script dependencies coming into production code.

Go is severely less expressive than Java, so.. disagree. You will end up with longer files with more boilerplate for questionable benefits.

Also, in many areas Java's standard library is more expansive.

Can you tell us about how you use Go in the small? I like Go, but it doesn't strike me as particularly nimble for scripty use cases like this - error handling is part of it, but I know that's fixable with the Must() pattern.

For the small I like Groovy. Especially as Grapes is like Maven but in annotations that you include in the script file. Being Java-based means that if it goes from "in the small" into something larger you are already on a stable foundation.

Go refuses to compile if you have an unused variable and that is the opposite of quick and nimble.

and you get a nice little portable binary that doesn't force someone to install a compatible version of an interpreter/virtual machine to run.

Seems very similar https://kotlinlang.org/docs/kotlin-tour-hello-world.html although I haven't ever used Kotlin like a "script replacement" (e.g. https://kotlinlang.org/docs/run-code-snippets.html#command-l... ) to compare and contrast

Overall, I think Kotlin is a vastly superior language to Java and spanks Scala in discoverability and legibility (less magick moar bettar, IMHO)

Also, see my comment about kotlin scripting (kts) elsewhere in this thread.

But, in short, you can write kts shell scripts; import any library you want, use anything in the JVM or the Kotlin or Java library ecosystem that you need, etc.

Works on the command line (you need a jvm and kotlin installed from your favorite package manager). The Kotlin Jupyter kernel also uses kts and this is a nice way to use Java stuff in jupyter.

Kotlin is much better in that regard.

I use Kotlin scripts (.main.kts) as a replacement for Bash scripts for years.

You can inline dependencies without additional tooling, and Kotlin is still much more expressive than Java.

I'd consider it equal or better in all regards.

- Top-level functions/main is supported - data classes are approximately as good as records - A scripting mode comes built in, and can use annotations to import and use dependencies within the same file - There's a repl - The keyword 'var' exists, and the keyword 'val' is more ergonomic than 'final var'

The only thing I remember missing from the article is the implicit imports which I don't remember Kotlin having. Regardless, I'd reach for Kotlin every time. I think funnily enough Java never fully clicked for me until I started using Kotlin, which in many ways is "Java, except many best practices are on by default".

Babashka is truly wonderful and has taken over almost all my scripting projects. But the author started by saying they didn't want to use a language without types so Clojure is probably out!

Have a look at any "mature" Java project on Github and you'll quickly come away with the opposite:

"Wow! It's even worse than I remember!"

"Wow! How many files and directories does this project NEED? It's like someone decided that it's easier to manage files than code..."

...and there's still XML everywhere :(

This is obviously valid, but it's definitely more common in a language like Python to just dump data inside a dict. In a dynamic language it's a far more flexible structure, it's the equivalent of HashMap<? extends CanBeHashed, LiterallyWhatever>, which is obviously a double edged sword when it comes to consuming the API. Luckily more rigid structures are becoming more popular at the API boundary.

That's deranged, just use a namedtuple and some functions. Even decorators for something this simple are a code smell.

What do you do when another module needs ymin, inheritance?

OO is dead, leave it buried umourned.

Checked errors are not unique to Java. Rust, HNs darling baby, is praised on this forum every day for checked errors. Swift, F# and countless other languages have checked errors.

There is nothing wrong with checked exceptions and there is really no difference between a Result and a function with a checked exception.

    fn a() -> Result<String, SomeError>
    String a() throws SomeException

Programmers across every language ecosystem are moving towards checked errors and away from unchecked runtime crashes. Even Kotlin, a language that shipped with unchecked errors, is planning on adding a form of checked error handling [1].

[0] https://docs.scala-lang.org/scala3/reference/experimental/ca... [1] https://youtrack.jetbrains.com/issue/KT-68296

> `java hello.java` is in the 360-390 ms range.

That's still pretty negligible. I don't think he's making a strict comparison, just saying that in both cases it's barely noticeable.

https://github.com/jtaccuino/jtaccuino

The problem with Java since Java 8 has never been Java. It's been about the appalling ecosystem that infected it with reflection frameworks. It was bonkers that "POJO" was ever a thing that had to be defined.

It feels like these frameworks are now just falling away, which is great. I'm not even hearing about Spring anymore, and if there is any reason to not use it, it would be this cringe "how do you do fellow kids?" blurb I just saw on their front page:

> Level up your Java™ code

> With Spring Boot in your app, just a few lines of code is all you need to start building services like a boss.

I personally would reach for Go by default, but I have no ill-will to Java.

First time I hear those claims about Postgres. Was that the sentiment 30 years ago?

what parts do you enjoy now ?

I do agree that new ecosystems (js for instance) makes you miss some of the old big languages development feel. less churn

The last part seems like a very 'gate keepy' point of view.

If you want to introduce someone to programming, you probably don't want them to worry about what all those 'magic words' do.

At least for their first steps, they won't need to know what a class is or what `public` and `static` mean.

I'm of two minds about it. On the one hand, the verbosity is arguably noise if you are first learning to program, or just want to write something quick, so I can see why people dislike it.

On the other hand, viability, classes, and "staticness" are all fundamental structural concepts in Java. Hiding them for a special case is sort of like lying, and, in the long term, I can actually see this special case causing more confusion for new learners. It's sometimes better to be upfront and transparent and force your users to work with the paradigm and semantics they chose to adopt, rather than pretend it doesn't exist. If Java had been designed to allow for top-level functions from the start, it'd be a different story. I think special casing is a generally bad way to evolve a programming language.

> Removing the public static void main(String[] args) business seems like pandering to a non-existent audience, or at least a miniscule and insignificant one.

Perhaps the audience doesn't exist because of that business. There are many times when I would have used Java over Python to write simple programs for no other reason than having the ability to create a GUI without resorting to third-party libraries. Yeah, Python has tk but it has never clicked with me in the sense that Swing does. Unfortunately, cramming every last thing into an OOP model means that simplicity is rapidly lost. (The same can be said of Python, except Python has not forced it. Java, historically did.)

I agree that for experienced programmers working on large projects a little bit of verbosity around `main` is insignificant. But first impressions matter, especially when there is pervasive word of mouth about "verbosity".

Pretend you are a college student and you are taking your first programming class (e.g. CS 1) and your friends have told you that Java is "verbose". You start with "hello world" and you have to type `public static void` etc. One of your friends shows you the same code as a Python 1-liner.

Or similarly you're a beginning programmer in the workforce and your employer asks you to solve a problem using Java. You've heard Java is verbose and when you start with "hello world" you find that what you heard was true.

This is not a non-existent/minuscule audience. They should have fixed this decades ago. Better late than never.

I've been impressed with the modernization of Java over the last 10+ years. Simplifying "hello world" is a minor change relative to the others, but still an important one.

The problem is when java is used as a first language, this is needless complexity that gets in the way of the actual fundamentals of programming. Access privileges are irrelevant for a beginner who is hopefully not writing libraries that will be consumed by anyone. The distinction between an instance and static method is also confusing and irrelevant. It's just pointless ritual for the student.

Now, if one is learning java as a second language, that's a different story.

javax.json has been around since Java 7.

Depends on the platform, some don't have any .NET productivity available. :)

I’d be curious to hear more about how you’re using F#? I’ve previously used Python for scripting, but just started developing for a company pretty deeply entrenched in .NET. Currently they’re migrating a lot from VB to C#, but I’ve missed having a handy scripting language like Python for small tools or test applications. Do you think F# could fill that roll?

There are reasons to not like Java, but this isn't one of them. Java is a fantastic language for large long lasting projects. I can't think of a more suited language for large long lasting projects in fact.

I'll bite. Explain, please.

Dr. Horstmann was my advisor in college, San Jose State.

I just loved his lectures, very dry sense of humor, and extremely funny.

He was just getting started writing books in the early 90s. He has this awesome way of thinking about programming, that I imparted to my own students when it came my turn to teach programming. I wish there some videos of his classes that I could go back to and share with people.

Good website also, https://horstmann.com/

The picture on the website with him in the row boat has a funny story with it. When asked why he is in a row boat, he would reply, "Students are in the row boat with me, learning to program. At some point I push them out of the boat into the eel infested lake. The ones who are clever enough to make it back to the shore will be good programmers." All of this said with a faint hint of a German accent and a sly smile.

If you happen to read this, Dr. Horstman. I made it to shore. Thanks! It has been an awesome journey!

> lend itself to making a team productive over making the individual productive

That's a really insightful way of presenting this. I think if that's how I'd been introduced to Java I might even have tolerated it.