One thing I'll miss about this was the way this arcane writing increasingly made sense over time as you became a better programmer.
I learned Java only after Python and I remember being not quite familiar with types so even the 'void' and 'String[]' where a bit mysterious. After learning basic types that part made sense. Then you start learning about Classes and objects, and you understood that main is a static method of this class Main that must be required somehow. As you dive deeper you start learning when this class is called. In a weird way what started as complete, unknowable boiler plate slowly evolved into something sensible as you began to understand the language better. I have no doubt that seasoned Java devs see a lot more in that invocation that I do.
Good riddance indeed. The last 30 years of software teaching basically trained developers to produce complexity for its own sake, while calling it engineering. I'm not sufficiently full of myself to link to my own writing (yet) but I'm full of myself enough to self-paraphrase:
1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.
2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.
3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.
At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.
4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.
I remember our "intro to programming course at university" started with this program and the tutor said "I'm mostly gonna try and explain all the code I show you, as I show it, but this is the exception, you just have to accept this nonsense bit for now".
And yeah, it was pretty cool looking back on it later and realising I knew what it all meant!
Except a static class method is just a hand-wavy way of denying reality: that a program has a single entry point that has nothing to do with classes
As much as C++ has a lot of problems, them and other languages (python/ruby/etc) never denied that the procedural world existed, while Java wants to blindfold you and push you through a corridor until you get out of it and into the "perfect (not) OOP world"
But in Java, a program doesn't have a single static entry point. You can have as many different classes as you want, each with its own static void main, and choose which to use as the entry point when you start up your JVM.
> python/ruby/etc never denied that the procedural world existed
Interestingly, those two languages use very different mechanisms for top-level functions - although I’m not sure if there’s a significant difference in practice.
Python has true standalone functions, whereas in Ruby’s they’re really methods of a `main` object.
That's just Stockholm Syndrome. Think about it: what more crazy garbage could you add that is useless for the beginner but "will make sense later"?
The answer is: infinitely much. You could have to write each character in strings as separate characters for example. It would be absolute utter madness but it "would make sense later".
As we become more and more acquainted with programming, a lot of what we do why we do it is incoherent nonsense to a beginner, but important nonetheless.
The limit is actually your time and effort. But nobody likes to write optimal assembly by hand, the balance has to be struck somewhere.
But there is nothing important or useful in all that Java garbage. You could write entire programs without classes! That's the class, the static, AND the final keywords.
You can't really escape String[], which imo is fine. It's better than argv/argc in C at least.
Yup... if you're familiar with the old class-based approach, the new style raises more questions than it answers. Did they really turn "everything-is-an-object"-Java into a procedural language? What do you do if you do need command line arguments? Etc.
(I somehow mostly avoided learning Java, and my last passing contact with it was 20+ years ago, so these are honest questions).
In general, Java made OO design trivial to implement, but due to a clear specification standard requirement a lot more planning/time is needed.
Thus, many sub-optimal project coordination approaches ended up fighting the design patterns. Java is a good student language, but there are so many better options now... with fewer footguns, and without Oracles farts. =3
Interesting opinion, but that is only applicable for enterprise clients. The public gets a NERF'd legacy option full of known problems, limitations, and legal submarines.
The only reason Java is still somewhat relevant is ironically Android/Kotlin, and SAP/heinous-dual-stack-blobs product lines.
It is not "an interesting opinion". It is an opinion of a mid-level engineering manager who spent the last decade hiring and building teams across various parts of the industry.
Java/JVM is literally everywhere. And let me get this clear: not a fan of both java-the-language and java-the-culture.
Interesting perspective, the exact same argument was made for COBOL and Fortran.
Most Enterprise level Java I saw was not clean OOP, but rather a heinous kludge sitting next to a half-baked design pattern. The 3.6B Android OS users in the world probably are more relevant in terms of development projects, and keeping your team staffed. Good luck =3
I am not speaking of some legacy systems, java is THE language right now, the same way Fortran was the only one in the first couple of decades of existance.
In my opinion, ideally a well-planned/templated object structure focused around well documented design-patterns without bodged-on/polyglot binary objects.
Thus, people that actually leveraged the OO paradigm properly, and in a way that may be sustainably regression-tested/maintained over many continuous integration cycles. That kind of "clean" code tree usually only needs juniors to study around <5 files to understand even the most complex modules operation, helps mitigate bugs, and team-leads can weed out quality "issues" in minutes.
People that churn teams usually discover a YOLO and OO paradigm are fundamentally incompatible concepts. People won't know everything they need in the first release, and they will have stuff they don't need but now have to live with by the third release.
This is not a Java specific problem... but it does make it easy.
Nothing integration "teams" do will likely matter much compared to a 3.6B user-base policy change. Have a great day =3
"Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )
While Android/Kotlin keeps Java in the spotlight, Java also powers financial services, high--frequency trading systems, payment gateways, logistics platforms, and even modern microservice deployments. These are not all “legacy”,they’re mission-critical platforms handling billions of transactions daily.
The exact same argument could be said for COBOL and Fortran.
>high--frequency trading systems
Probably not the Java stack itself, given GC latency and precision timing skew would translate into millions of lost dollars a second. However, people do silly things in the wrong languages all the time. =3
It looks like you're not up-to-date, ZGC has pauses on the microsecond dimension.
Even since before ZGC was added, there are open source libs for HFT that optimize allocations to avoid GC: https://github.com/openhft =3
FWIW, I've seen job ads for Java developers in HFT.
It did look weird, of course, but they're also using Go (which iiuc has worse GC latency) or other garbage-collected languages (OCaml being a famous example).
Java is essentially open source enough that you can ignore oracle. All the development of java happen in openjdk, of which oracle is a contributor (along with red hat and many others). Oracle’s java is just an openjdk distribution, with some additional proprietary bits.
Pulling the oracle card when java is mentioned is a useless stunt.
Yep, same for me, it's been a long time since I did java and while the publicstaticvoidmain mantra felt familiar I was a bit confused by the Scanner thing and couldn't say why.
My experience may be different from the rest of people at HN. But I am used to work in large projects that last decades. How main is written is totally irrelevant for my day to day work or my career.
Or if you're an Android developer then main doesn't exist at all and never has
But yeah I don't understand why the author is so excited about this. How "ugly" a trivial "Hello, World!" does not really matter much and isn't a good indication of anything about the language's ability to handle more than "Hello, World!"
I think it does say something about what a language thinks is important.
Java (historically) is famous for going a bit too hard core into overly abstract & verboseobject oriented design patterns - create a factory to get another factory to get a different factory and whatnot. The hello world is where java shows that style of code is what historical java felt was the ideal.
Factories are a pattern that is not unique to Java. They're used prolifically in C++ at least, and I'm sure in other languages.
The factory pattern is tightly coupled with polymorphism. If you're not using polymorphism, then you may not typically need factories. But if you are, then at some point you're going to have some conditional logic about what concrete type of class you're going to create of a particular interface.
Modern Java is lending itself more towards data oriented programming, and coders are trending in that direction. This may or may not last, like every trend. But even then, at the moment this tends to still involve using sealed interfaces and records, so you still have some form of instance creation and polymorphism.
How do you avoid factories? Doesn't you code end up littered with worse code?
> How do you avoid factories? Doesn't you code end up littered with worse code?
Easier for me to use "public abstract class" and then leave open methods inside like "protected abstract doAction();" that are forcefully implemented on each variation of that class.
There is still just one base implementation, I guess the main difference is using strong typed classes that keep the specific code inside specific classes. With factories one tends to end up with a very large source code file that details with too many specific different topics, was making maintenance and testing harder afterwards.
Or maybe I just never really understood properly the value of factories.
Yeah sorry, I don't mean to cause offense but that doesn't make sense. If you've got abstract methods that require implementation in concrete classes, you've got polymorphism, and at some point you're going to be choosing which concrete class to instantiate.
If you always know which concrete class to instantiate and use at each point in the code, it doesn't sound like you need polymorphism in the first place.
Usually when I have polymorphism I have some algorithm that operates on an array or graph of mixed instances of BaseClass. For any particular graph I know statically which concrete nodes I want and their arrangement. Factory really only made sense to me if you want to delay the actual creation of the array members, if the decision comes from something external, or if their creation is deeply entangled with their environment in a way you couldn't otherwise avoid repeating.
I agree that you can write java any way you want. My point is that the protypical hello world is a cultural artifact representing the cultural ideals of the java language designers. Its symbolic of what they thought was good programming at the time the language was designed. So it says something about both the language design and the culture surounding the language. Or at least it did 20 years ago. That doesn't mean every java program follows that ideal.
>How "ugly" a trivial "Hello, World!" does not really matter much and isn't a good indication of anything about the language's ability to handle more than "Hello, World!"
Sure, but for beginner programmers who don't have the discipline down yet, it's unnecessarily hard. I bought a Java programming book as a kid and got stuck because of a typo that produced an error message I couldn't understand. This was the time before StackOverflow and Reddit. In retrospect, this delayed my programming journey by at least a year.
Longer Hello Worlds make frustration and getting stuck like this more likely.
I learnt C at Uni (after having taught myself BASIC, Z80 machine code (not assembly), and x86 assembly), when we were taught C it was explained to us what all that sort of thing meant. But having said that most of the class failed to understand.
Now we can type out the same semantics, and remain clueless about what it means, but with a new obfuscated syntax which stops us from asking about the semantics.
Still for the better, because each token you don’t have to type when first learning programming is a token you can’t mistype.
(Though the ultimate conclusion of this line of thinking is that programming 101 courses should be taught in as concise and syntax-light a language as possible, giving the learner as few opportunities to screw up the input as possible. I’m a fan of teaching programming in Ruby, personally. Not theory of programming, mind you; just programming as an iterative human process.)
> programming 101 courses should be taught in as concise and syntax-light a language as possible
100% this. To make Java be the all-language makes it a mess without a defined goal. It is better to start learning with a language better suited for it. And then the learner can specialize and expand to other languages. This also helps to create awareness that different languages have different use cases.
Probably not in the least for developers, but it does affect beginners a lot.
I used to teach Java, and the total sum of magic incantations you needed before starting to actually "Hello, world" were an instant turn off for many students.
I didn't teach intro to C or C++, so I can't compare for certain.
From my recollections as a student, compiling C or C++ in intro classes was just a matter of calling `gcc myprogram.c` or `g++ myprogram.cpp`, followed by `./a.out` for testing, which is rather easy to explain to students who already know what a command-line is.
Java sometimes has a culture of "the proper way to do this is to take all these little pieces and put them together in a specific way" which probably makes sense for an object oriented purist but is a bit of a drag day to day.
The scanner class is one such thing, but you also have things like wrapping a Reader in a BufferedReader to add buffering, and building a Pattern object to build a Matcher object which has a few different methods you can call to actually do anything useful
It is very OO, but it's also a bit annoying, and more modern java libs tend to give you a more comfortable API. Sadly modern java also tends to come with springboot and people who can't do anything, unless they use springboot
> Sadly modern java also tends to come with springboot and people who can't do anything, unless they use springboot
Spring Boot (and Spring generally) is more of a “Java culture” issue — someone on this thread used the term “framework fetishism” and it’s spot on.
Thankfully there are teams, typically in mobile or polyglot microservices environments, who are moving away from this. But yeah — still far too common.
Before Spring it was JBoss. Awfully slow and bloated frameworks which then become mandatory in enterprises. In the end they all go back to POJO when things really need to work.
It's a shame that they only introduced this as a feature only for single-file programs.
It would make Java a much better language in my eyes if it allowed package-level methods, or even multiple records/classes per file. But apparently "impact on how Java code is written in general" is not wanted.
I'm someone who wrote a lot of 'raw' Java and C++ without frameworks, which meant there was a lot less boilerplate and indirection etc. And for me, the big usability boon came about 10 years ago, around the same time for both Java and C++, when they started supporting lambda functions. I started passing code into algorithms and, although it sounds quite complicated, it simplified my programs substantially. Before that syntactic sugar gave the affordance I hadn't been organising my programs that way.
For the longest time Java had been very keen to be explicit, to the point of needing a log of cruft where it just felt like the compiler was checking you spelt every letter of the incantation correctly because both the compiler and you knew unambiguously what simple thing you were trying to achieve. But this tone changed in Java around the time the new entrants like Kotlin started taking over as what you develop in in a way that scala and clojure never managed. And suddenly all the get-out-of-your-way of lambdas saving you typing out classes and anonymous classes arrived and Java became a much nicer experience imo.
Now if we could just wean some more of the ecosystem away from the framework fetishism... there's no reason java programs have to be so huge, unwieldy and slow to start.
No reason apart from the framework epidemic that's supposed to make things easier for developers, but in the end hamstrings them and weighs everything down.
(to the downvoters - I am a java developer and this is very real to me at the moment!)
In fact, it was welcomed in open arms even being originally interpreted, because writing portable C or C++ code in 1996 was still a mess, even across UNIX flavours.
On my university no one got Sun's marketing money in 1998, yet the distributed systems, compilers design, and graphics programming, all adopted Java as the language for new teaching materials, as it sorted out several problem with the assignments.
OWL was quite good and one of my favourite C++ frameworks, but not something that was being used at my university on assignments that were mostly done on UNIX, which was my point.
Only bad experience I remember from Java was the int/Integer primitive/object issue and boxing.
Also of course the misuse and overuse of classes when designing systems, but the complexity at design time is also the counterpart of the ease of use of well designed APIs. I remember using an IDE to write some code and it skipped the whole documentation and run/compile error phase, I could just cast mismatching types as needed.
Probably C# and Swift/Objective C would only be above Java as top languages, being actually funded by paying customers instead of used by companies that depend on volunteer developed open source software and end-users that equate paying for software with evilness.
Being forced to use anonymous classes to simulate lambdas prior to 8 was the biggest source of annoying boiler plate IMO and was genuinely a bad experience in sufficiently complex or large code bases.
Everything beyond 8 has been nice to have but 8 was the big one.
Agree, for the most part, but I think records and pattern matching are essential. I started using Scala (2.x) in 2014 or so, and case classes and pattern matching completely blew my mind. if/else trees and switch statements felt so archaic, limited, and verbose after that. I used to joke that Java would eventually adopt enough of Scala to be a pleasant language to work in, and I don't think I was that far off.
(I'll ignore Kotlin... I don't get why people like it.)
I too adopted Scala in 2014 and was really satisfied with FP side and how it all was tied with JVM. Honestly I always felt that JVM is a nice platform with a horribly verbose “assembly” language that is Java.
Fast forward to around 2020 and I had to organize a team to build search engine in JVM. Given how hard it is to find decent Scala developer I surrendered and did this project in Kotlin. Java devs easily pick up and write sensibly FP-style even code, and builtin coroutines are cool. Even though I had to open up the internals of coroutines to get tracing to work they felt a very welcome change compared to say monadic explicit async.
So for me Kotlin is kind of watered down Scala for typical Java folks and I could tolerate it compared to perspective of writing plain Java.
> Only bad experience I remember from Java was the int/Integer primitive/object issue and boxing.
Heh, I once had to work in a code base that used an `Integer premiumDefenseLevel`. It contained the level of premium defense a player had purchased, or null if the player didn't have any levels of premium defense purchased in the recent times.
This was in fact annoying to remove, because a 0 after a 1 was treated differently than a null some time for advertisement reasons: Someone who had bought premium defense in the past is more likely to re-buy than someone who didn't, so they are pestered with ads. But it eventually turned into a neat little domain object.
> the int/Integer primitive/object issue and boxing.
That's a deal-breaker. If you can't tie together a few values in a record/struct without being forced to box them/heap allocate them, the language will never be used anywhere where you even remotely care about performance.
This is not a difficult problem to solve - C# did it in a very elegant way with structs, and as a direct result, probably for half of all videogames written today, the gameplay portion is written in C#.
imo it's worse than that. of they'd just hid the boxing in the runtime, Java would be a kind of slow language that didn't feel awful. by exposing the unboxed primitives to the user, they created a horrible duality of incompatible types.
You Guys haven’t used Java since the 90’s right? Boxed types convert to primitive values automatically, you never need an explicit cast! What horrible duality are you talking about?
What are you criticizing exactly? You can have primitive integers in Java records or classes just fine. If you have many you can use an int[] like in C, no one forces you to use generic containers.
It's not a terrible language, but it's not too good either.
For a very long time it completely stagnated and all the features we see added now should've been there 10 years ago, at least, and a bunch of other improvements on top. All because "our goal isn't to adopt the strategy of less successful products, but to forge our own" which now turned into busily adopting all the features that the "less successful products" have had for years: https://news.ycombinator.com/item?id=28985688
this one. Java is far from the worst out there. I've used MuMPS and know of the horrors of TCL, but Java is once of those languages where everything takes 5x more more code than it should, and the result always feels ugly.
part of my dislike is probably that I'm a math person, and the lack of operator overloading really makes any math not using the built-in types dreadful to read.
I really hope you mean this as it has (amazing backwards compatibility) and (package management), because describing the package management in Java as anything more than "I guess it's better than C" feels overly generous
As a java guy and think python is weird, I don't think this sucks.
But, I also agree that can serve as terrible intro to programming if you start programming right away without understanding the basics of abstractions. 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.
This heavyweight syntax has nothing do with OOP. No common definition of OOP (before Java came into existence) said that functions cannot exist outside of a class.
Java choose to adopt object oriented purity in a very weird way. Sun has initially rejected the idea of standalone functions (static import was introduced in Java 5, closures in Java 8 and compact source files/instance main is only coming now). Even with static imports and compact source files, there is still a class holding these methods behind the scenes (for practical and compatibility reasons, more than to achieve any ideological or theoretical goals at this point). That seems like Sun was trying to keep the purity of "everything is an object", but at the same time they've introduced primitive values, which are clearly not objects. This was a pretty bad decision in my opinion. There is no practical benefit from requiring every function to be defined inside a class[1]. On the other hand, being able to have methods defined on an integer is a pretty nice feature.
If we look at a Smalltalk, which is generally considered be an example of a "pure" OOP language, we see a striking difference. This is Hello World in Smalltalk:
'Hello, world!' printNl
Smalltalk allows you to freely define functions outside of classes and even write code that is not part of a class (directly in the REPL).
I agree, this is the whole point of "Hello world", which is to show the boilerplate required to start a program capable of outputting text, as well as the actual code that outputs that text. It's also the chance to get the build tools setup, people forget that some of the 'boilerplate' is the actions required to build, which often are much more involved for newer tools and frameworks.
You can just say initially e.g. when I learned C++ that "#include <iostream>" can be "mostly ignored for now, but just know iostream stands for Input / Output stream, and this line is necessary to e.g. output with std::cout"; and there are no scars left from this.
Some scars... as cout << was always a bad idea, and taught people early on in their C++ development that being overly clever with operator overloading was expected
Which I think most people understood not to do themselves when they encountered their first issue with the precedence of << vs other operators in expressions they wanted to print.
C# has had top level statements since version 9.0 (Nov 2020), and it's still just a compiler trick that produces a static method behind the scenes. Top level functions work too, but in a similar way.
There are several valuable compiler transformations that happen under the hood in languages like this. Closures as types, iterator/generator functions, async state machines. This is just another example.
I really hated that change when I came out. I'm still not a big fan, but I made my peace with it understand that it benefits the poor users who have to deal with programs whose termination statuses are pseudo-random. Especially users doing scripting.
I write "return 0" at the end of main in all my programs if that end is reachable.
> If you can't have other top-level functions in Java, then it's a special case, which is ugly.
I assumed this meant that you could have free functions, but you're saying you can ONLY have `main` as a free function? Ok, then I agree this is also garbage.
What’s with Java devs and not including `import` lines in example code? Even here, when intending to demonstrate how dumb Java’s boilerplate is. But I notice it everywhere.
Because usually you have an ide that manages imports for you automatically. So unless you are using a library that has multiple imports, usually you know the import to include, and in almost all cases it is automatically included.
Btw: in the compact example! The IO class is implicitly imported, so that example truly works without any import at all!
I mean, the IDE can totally write out the import statements for you as you type and choose resolutions for identifiers; but if you paste in a random code snippet that references ambiguous identifiers from a third-party lib, no IDE can magically generate the import statements required to discriminate the correct resolutions. You have to go through and resolve the symbols yourself (or advance through them as error sites to get the class to compile.)
Or, to put that another way: import statements aren’t pure boilerplate that should be thrown away; they encode real information (ambiguous symbol resolutions); and so, by eliding them from code examples, you’re discarding that information and forcing the learner to re-derive it.
Which is especially bad when your code examples are referencing ambiguous undocumented static inner classes nested deep inside your library’s package namespace, where all the potential resolutions differ only by the particular package they exist in (since they’re all e.g. essentially batteries-included extensions of the base library implementing the same interface.) And where all this structure is as ugly as it is precisely because you didn’t expect the end-user of the library to need to understand it / interact with it. Yet your own [usually “advanced” or “feature demonstrating”] code examples force exactly that.
Why not abstract away the public static void main(String[] args) method with a top-level statement paradigm, similar to C#'s entry point simplification, to reduce boilerplate and enhance code conciseness?
Why should the entry point be a random special case? You're already admitting at this point that OOP is flawed so you might as well just have the balls to design a proper alternative (rather than a kludge)
This pattern isn't OOP, there is no objects here. And Java generally isn't a good example of an OO language to me. It's more like Class Oriented Programming. That is mighty flawed but was for some reason quite fashionable.
I wouldn't consider OO the way Ruby and other actually well designed languages do it flawed.
The unnamed class approach to global variables sounds nice. You can do hot-reload, but still have unencumbered syntax.
OTOH, since Java files are named after their public class, it would have made more sense to just say the `public class X { }` wrapper is optional and only needed for attributes and inheritance. I don't quite understand why they need an anonymous class.
> The Java compiler will compile that file to the launchable class file HelloWorld.class. In this case the compiler chooses HelloWorld for the class name as an implementation detail, but that name still cannot be used directly in Java source code.
What we seem to have forgotten is just how c like java was compared to other programming languages being advocated at the time. Objects made sense (remember Ada?) but c++ was a mess. Java was a breath of fresh air with lots of c legacy.
Exactly. All wrong assumptions, and all needed to be tagged on to Java in later versions.
I dont find Java's first versions well designed. The JVM was quite well designed, but the language not.
And changing a popular language is hard. I think Java's dev do it very well (the process of changing it IS "well designed"). But still the language itself suffers a lot from the bad choices in the beginning.
I like Kotlin: an OO language with as much FP in there as makes sense for an OO language.
Learning Java in high school, I loved how the very first lesson (focused on Hello World) had you type this out, only for the teacher to say “This will make sense later on but for now just type it in”.
In a pyproject.toml file you can create/define scripts that reference an entry function. E.g.:
# myapp/app.py
def main():
print('Hello!')
and in the pyproject.toml:
[project.scripts]
app = "myapp.app:main"
You can still use the __name__ check at the end of the file, e.g.:
if __name__ == '__main__':
main()
That way it works both as a standalone and when installed via pip/uv. -- Note: The scripts created by the installer are slightly more complicated versions of that __name__ check that handle the application argument (arg 0) and the exit code as the return value from main().
It's not gone per se -- you can still write out the long form version if you want (this is required for backward compatibility).
What's now permitted is:
1. a simpler way of declaring a main method on a class -- you don't need the public or static, and the args is optional, so you can declare a `void main() { ... }` method on a constructable class;
2. declaring a main function (and other variables/functions) outside of a class -- here, the startup code will handle calling the main function, although I don't think the ability to call anonymous functions currently extends outside of the main function/file.
This hits home... literally. My high school kid had Python last year, and this year they started him on Java, and his very first reaction on coming back from school was, "WHY THE HECK DO I HAVE TO WRITE ALL THIS STUFF JUST TO PRINT HELLO WORLD??!?"
C++ calls them free functions, and I always found them rather elegant. A common pattern, at least a few years ago, was to use free functions for anything that'd be a method in Java, but doesn't actually require access to anything non-public.
Back in 2005 or so, Java felt like "C++, but we know better" to me. I had no choice but to use it, but boy did they omit some stuff that was actually useful. The boilerplate back then (driven by both the limitations of the language and a surge in architecture astronauts) was absolutely insane. Don't even get me started on anything labelled "Java Enterprise" in the 2000s, bloat, slowness and bugs everywhere. IBM, Oracle and friends were running quite the circus. Creating working, performant software in that environment was a brutal challenge. I think Java, the language, is only partly to blame, but it was limited enough to spawn pretty complex code generators and frameworks.
Took the industy a decade or two to arrive at typed languages that were an actually good subset of C++ features. Java, in my opinion, wasn't one.
They are associated with a class, but the class is basically the file. There are limitations by doing it this way but it is out of preview and officially supported as of Java 25.
It's somewhat implicit in the JVM spec, but functions are always bound to classes as methods. [2] The only kinds of heap objects you can have a reference to are class instances and arrays. [3]
The lack of free functions is really only a minor inconvenience for language implementers. Clojure, for instance, just compiles new classes to hold functions as methods.
From a programmer's perspective, you can write lambdas, but again, it's just syntactic sugar over an inner class.
I think all functions are associated with some class. But these classes sometimes are hidden from you and you don't need to know about them. Does that help you? What for would you use true free functions?
I'm visibly shaking at this statement. What are you even saying here? A function is the most basic, fundamental unit of code organization. What Java does with its forced classes is a complete perversion of computation, sanity and anything reasonable.
Presumably these exist in a Main.java file and the java class is implied. Similarly the string params are also implied, and the non param main() function is just an alias or a wrapper for main(String).
Ugly? Sure. But isn't this the identity of Java? Taken away for almost no gain, there's literally no real issue stemming from requiring a verbose incantation to write a main routine, this is something you learn like day 1 on learning java, and it's something you write once in a blue moon, like 0.001% of the code you are going to write.
It reminds me of the attempt at removing Richard Stallman from the FSF, yeah, you could do that and fix a problem, but then what you are left with isn't really the same thing as it was before, it's now actually the same soulless thing as the rest of the competing things.
Saving grace is that obviously, you can still recite the incantation, it's not like public static void main(String[] args) is gone, just that you can skip it.
> this is something you learn like day 1 on learning java, and it's something you write once in a blue moon, like 0.001% of the code you are going to write.
I think this is the exact audience for this change: for newbies in day 1 of 10 years in their programming journey. Less boilerplate to just swallow, less time spent debugging an otherwise-fine lab exercise if not for the wrong instantiation of Scanner, more time actually focusing on the basics they should be focusing on.
Granted, I still think Java is a horrible first language to learn from or teach with but this is a step in the right direction. Might revisit this opinion in a few years, who knows.
Oh also, we use Java in production so we also have a bunch of ad-hoc "scripts" written in Java for mostly one-off interactions. Nonetheless, these scripts can get unwieldy fast. You'd think I'm exaggerating the benefit here but I, for one, welcome one less level of indentation in these scripts.
Sure you could argue that it's better to learn java like this. But also you could argue that it was fine to learn java with an incantation. It's the first day of class, of course you are not going to understand everything you type. And you are getting exposure to important java concepts that you are going to circle back to later in your journey.
Fwiw, other JVM languages like SCALA have already done this exact thing way before. But whatever, it isn't either good or bad. And I can still use the old way out of respect for tradition.
Eh. I used to teach Java as a first programming language and this always went "Just ignore the incantations for the time being, you'll learn more about them as time goes."
This (and IO) was also one of the reasons for which my students tended to like OCaml much better than Java.
I distinctly recall early in my first university programming courses the instructor saying something to the effect of "Just wait until you learn 'public static void main'". I think we had only used BlueJ until that point in the course.
public class Main {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.print("What is your name? ");
String name = scanner.nextLine();
System.out.println("Hello, " + name);
}
}
Scala 2 (2006):
object Main extends App {
val name = readLine("What is your name? ")
println(s"Hello, $name")
}
Scala 3 (2021):
val name = readLine("What is your name? ")
println(s"Hello, $name")
Java (2025) [code sample from the article]:
void main() {
var name = IO.readln("What is your name? ");
IO.println("Hello, " + name);
}
What I would like to see deprecated is over using objects and design patterns and SOLID and Uncle Bob principles, so we see less FizzBuzz Enterprise Edition and Java feels less as the Kingdom of Nouns.
The goal is go make java easier to learn for people new to programming.
When they start with the old style there is an overload of concepts where the teacher just have to say "ignore all this", which is not ideal. With new style they grasp fewer concepts at first.
I'm not truly convinced this is such a big deal, but I lived through my university switching from Pascal to Java in the first programming class, and I can confirm people did get much more confused during the first few classes (to be fair they got way less confused later not having to deal with pointers tho).
Some people have so much time or so few things to do during the day that they can write a blog post about meaningless programming languade aestheticisms that only other frivolous people will understand and enjoy.
That's what I wanted to know too, but all we get is this one line:
> 1: When I was a Freshman in High School I asked a Junior what it meant. He had no clue.
OK... so it's confusing for juniors. A lot of stuff is. I probably didn't know what it all meant when I started either, but so what? You copy and paste it and move on. Eventually it makes sense. Not a big deal.
I don't understand how anyone ever didn't know what this meant. You have a class. It has a static method. The runtime starts your program by calling the method, passing it an array of command-line arguments. What's mysterious about this?
The fact that you have to explain what classes are, and what static methods are, a huge load of information, for a hello world program. And what's worse, it will leave students rightly confused about what the point of the class is, if it only has static members... Making it more likely they don't retain any of the information. Or alternatively, just say "type it exactly like this, don't think about what the magic words mean" which is a great way to ruin programming for people
The first book I read on Java managed to explain "public static void main(String[] args)" by the end of the first chapter. It wasn't a long chapter, either.
I don't like Java, and the excessive boilerplate is a big part of that opinion. But it was never nearly as arcane as some people here are making it.
When you first learn programming, you don't know what a class is, or a method, let alone a static method.
But if you teach people using Java, you have to teach them to write this:
public class Main {
public static void main(String[] args) {
System.out.println("Hello world");
}
}
...instead of just:
print "Hello world"
The latter is easy for a student to understand. With the former, you just have to tell them to use it without understanding it, and that they'll understand it later.
One thing I'll miss about this was the way this arcane writing increasingly made sense over time as you became a better programmer.
I learned Java only after Python and I remember being not quite familiar with types so even the 'void' and 'String[]' where a bit mysterious. After learning basic types that part made sense. Then you start learning about Classes and objects, and you understood that main is a static method of this class Main that must be required somehow. As you dive deeper you start learning when this class is called. In a weird way what started as complete, unknowable boiler plate slowly evolved into something sensible as you began to understand the language better. I have no doubt that seasoned Java devs see a lot more in that invocation that I do.
Good riddance though!
Good riddance indeed. The last 30 years of software teaching basically trained developers to produce complexity for its own sake, while calling it engineering. I'm not sufficiently full of myself to link to my own writing (yet) but I'm full of myself enough to self-paraphrase:
1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.
2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.
3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.
At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.
4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.
I remember our "intro to programming course at university" started with this program and the tutor said "I'm mostly gonna try and explain all the code I show you, as I show it, but this is the exception, you just have to accept this nonsense bit for now".
And yeah, it was pretty cool looking back on it later and realising I knew what it all meant!
And yeah, good riddance nonetheless!
Except a static class method is just a hand-wavy way of denying reality: that a program has a single entry point that has nothing to do with classes
As much as C++ has a lot of problems, them and other languages (python/ruby/etc) never denied that the procedural world existed, while Java wants to blindfold you and push you through a corridor until you get out of it and into the "perfect (not) OOP world"
If you're speaking of `main()`, that's not true in Java: you can have many entry points and decide upon launch which one you're using.
If you're speaking of `__main()`-style entry point, though, you're right, and Java makes it... complicated.
Yes I meant the latter
But in Java, a program doesn't have a single static entry point. You can have as many different classes as you want, each with its own static void main, and choose which to use as the entry point when you start up your JVM.
> python/ruby/etc never denied that the procedural world existed
Interestingly, those two languages use very different mechanisms for top-level functions - although I’m not sure if there’s a significant difference in practice.
Python has true standalone functions, whereas in Ruby’s they’re really methods of a `main` object.
In python you are recommended to use
and not put any code that is executed at the top-level. Otherwise its also executed when you import the file.Yeah, I agree with this sentiment. The boilerplate was oddly helpful when I was starting out.
That's just Stockholm Syndrome. Think about it: what more crazy garbage could you add that is useless for the beginner but "will make sense later"?
The answer is: infinitely much. You could have to write each character in strings as separate characters for example. It would be absolute utter madness but it "would make sense later".
I agree specifically, but disagree generally.
As we become more and more acquainted with programming, a lot of what we do why we do it is incoherent nonsense to a beginner, but important nonetheless.
The limit is actually your time and effort. But nobody likes to write optimal assembly by hand, the balance has to be struck somewhere.
But there is nothing important or useful in all that Java garbage. You could write entire programs without classes! That's the class, the static, AND the final keywords.
You can't really escape String[], which imo is fine. It's better than argv/argc in C at least.
Yup... if you're familiar with the old class-based approach, the new style raises more questions than it answers. Did they really turn "everything-is-an-object"-Java into a procedural language? What do you do if you do need command line arguments? Etc.
(I somehow mostly avoided learning Java, and my last passing contact with it was 20+ years ago, so these are honest questions).
The class is still there, implicitly.
The main function can be written with `String[] args` if you need it.
This is a decent summary of the changes:
https://www.happycoders.eu/java/main-method/
Further details:
https://openjdk.org/jeps/512
,,Since an implicitly declared class cannot be accessed from outside, it must always contain a main method.’’
This looks like a hack just for the main file, it would have been good if these functions can be called from other files.
And now to know what it does you have to read a book.
The IO class is good. The rest is information hiding. Now if you could write anything else in Java in this form,it would make sense.
If it's anything like dotnets change the void params are still a valid input.
In general, Java made OO design trivial to implement, but due to a clear specification standard requirement a lot more planning/time is needed.
Thus, many sub-optimal project coordination approaches ended up fighting the design patterns. Java is a good student language, but there are so many better options now... with fewer footguns, and without Oracles farts. =3
None of the Java and OOP problems were created ar Oracle.
As much as I love hating Oracle, they pushed the language forward much more than Sun ever did.
Interesting opinion, but that is only applicable for enterprise clients. The public gets a NERF'd legacy option full of known problems, limitations, and legal submarines.
The only reason Java is still somewhat relevant is ironically Android/Kotlin, and SAP/heinous-dual-stack-blobs product lines.
Best regards, =3
It is not "an interesting opinion". It is an opinion of a mid-level engineering manager who spent the last decade hiring and building teams across various parts of the industry.
Java/JVM is literally everywhere. And let me get this clear: not a fan of both java-the-language and java-the-culture.
Interesting perspective, the exact same argument was made for COBOL and Fortran.
Most Enterprise level Java I saw was not clean OOP, but rather a heinous kludge sitting next to a half-baked design pattern. The 3.6B Android OS users in the world probably are more relevant in terms of development projects, and keeping your team staffed. Good luck =3
I am not speaking of some legacy systems, java is THE language right now, the same way Fortran was the only one in the first couple of decades of existance.
Besides, what is "clean OOP" even?
In my opinion, ideally a well-planned/templated object structure focused around well documented design-patterns without bodged-on/polyglot binary objects.
Thus, people that actually leveraged the OO paradigm properly, and in a way that may be sustainably regression-tested/maintained over many continuous integration cycles. That kind of "clean" code tree usually only needs juniors to study around <5 files to understand even the most complex modules operation, helps mitigate bugs, and team-leads can weed out quality "issues" in minutes.
People that churn teams usually discover a YOLO and OO paradigm are fundamentally incompatible concepts. People won't know everything they need in the first release, and they will have stuff they don't need but now have to live with by the third release.
This is not a Java specific problem... but it does make it easy.
Nothing integration "teams" do will likely matter much compared to a 3.6B user-base policy change. Have a great day =3
"Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )
While Android/Kotlin keeps Java in the spotlight, Java also powers financial services, high--frequency trading systems, payment gateways, logistics platforms, and even modern microservice deployments. These are not all “legacy”,they’re mission-critical platforms handling billions of transactions daily.
The exact same argument could be said for COBOL and Fortran.
>high--frequency trading systems
Probably not the Java stack itself, given GC latency and precision timing skew would translate into millions of lost dollars a second. However, people do silly things in the wrong languages all the time. =3
It looks like you're not up-to-date, ZGC has pauses on the microsecond dimension. Even since before ZGC was added, there are open source libs for HFT that optimize allocations to avoid GC: https://github.com/openhft =3
Indeed, it is likely some naive kludge like RTSJ
Tend to deprecate Java services for a number of other reasons =3
FWIW, I've seen job ads for Java developers in HFT.
It did look weird, of course, but they're also using Go (which iiuc has worse GC latency) or other garbage-collected languages (OCaml being a famous example).
The "heinous-dual-stack-blobs" joke refers to loading native binary objects in the JVM, but its probably some newer naive kludge like RTSJ.
I guess it is like using a Fiat Coupe as a gravel dump-truck. lol =3
Java is essentially open source enough that you can ignore oracle. All the development of java happen in openjdk, of which oracle is a contributor (along with red hat and many others). Oracle’s java is just an openjdk distribution, with some additional proprietary bits.
Pulling the oracle card when java is mentioned is a useless stunt.
The OpenJDK has come a long way, but is still less than ideal.
Do you actually use that option at enterprise scale? =3
Everywhere I’ve worked has used Eclipse Temurin or another open source release: the Oracle JVM isn’t used all that often because of license issues.
Ditto. Even things like Java flight recorder are open source now and work with any JDK distribution.
YOLO =3
https://openjdk.org/groups/vulnerability/advisories/
https://app.opencve.io/cve/?product=openjdk&vendor=oracle
So tell us what the better options are in your opinion?
A lot of folks prefer Scala or Kotlin even on a janky JVM.
Depends on the use-case, but I also like Elixir/Erlang, Julia, and Go.
Not all are very popular, yet each offer something uniquely beautiful. =3
Yet the only ecosystem with a mature library for every use case under the sun and that is not riddled with footguns is Java.
(One might argue Go comes close, though)
Javas selling point is that it can do everything reasonably well and has a huge talent pool.
I learned to read line as the following in Java 1.2 so the Scanner class is new to me. :p
Yep, same for me, it's been a long time since I did java and while the publicstaticvoidmain mantra felt familiar I was a bit confused by the Scanner thing and couldn't say why.
Same here, oddly pleased that the Scanner class is deprecated before I even knew about it.
My experience may be different from the rest of people at HN. But I am used to work in large projects that last decades. How main is written is totally irrelevant for my day to day work or my career.
How does it affect you this change day to day?
Or if you're an Android developer then main doesn't exist at all and never has
But yeah I don't understand why the author is so excited about this. How "ugly" a trivial "Hello, World!" does not really matter much and isn't a good indication of anything about the language's ability to handle more than "Hello, World!"
I think it does say something about what a language thinks is important.
Java (historically) is famous for going a bit too hard core into overly abstract & verboseobject oriented design patterns - create a factory to get another factory to get a different factory and whatnot. The hello world is where java shows that style of code is what historical java felt was the ideal.
That is just a coding style. I don't use factories in Java, they are just confusing when there are simpler ways to get the job done.
Factories are a pattern that is not unique to Java. They're used prolifically in C++ at least, and I'm sure in other languages.
The factory pattern is tightly coupled with polymorphism. If you're not using polymorphism, then you may not typically need factories. But if you are, then at some point you're going to have some conditional logic about what concrete type of class you're going to create of a particular interface.
Modern Java is lending itself more towards data oriented programming, and coders are trending in that direction. This may or may not last, like every trend. But even then, at the moment this tends to still involve using sealed interfaces and records, so you still have some form of instance creation and polymorphism.
How do you avoid factories? Doesn't you code end up littered with worse code?
Thanks for the explanation, very detailed.
> How do you avoid factories? Doesn't you code end up littered with worse code?
Easier for me to use "public abstract class" and then leave open methods inside like "protected abstract doAction();" that are forcefully implemented on each variation of that class.
There is still just one base implementation, I guess the main difference is using strong typed classes that keep the specific code inside specific classes. With factories one tends to end up with a very large source code file that details with too many specific different topics, was making maintenance and testing harder afterwards.
Or maybe I just never really understood properly the value of factories.
Yeah sorry, I don't mean to cause offense but that doesn't make sense. If you've got abstract methods that require implementation in concrete classes, you've got polymorphism, and at some point you're going to be choosing which concrete class to instantiate.
If you always know which concrete class to instantiate and use at each point in the code, it doesn't sound like you need polymorphism in the first place.
Or I could just be missing something.
Usually when I have polymorphism I have some algorithm that operates on an array or graph of mixed instances of BaseClass. For any particular graph I know statically which concrete nodes I want and their arrangement. Factory really only made sense to me if you want to delay the actual creation of the array members, if the decision comes from something external, or if their creation is deeply entangled with their environment in a way you couldn't otherwise avoid repeating.
Fair, that makes sense.
I agree that you can write java any way you want. My point is that the protypical hello world is a cultural artifact representing the cultural ideals of the java language designers. Its symbolic of what they thought was good programming at the time the language was designed. So it says something about both the language design and the culture surounding the language. Or at least it did 20 years ago. That doesn't mean every java program follows that ideal.
the verbosity is a feature not a bug
that's why java programmers are the most productive programmers ever
if you count productivity by lines of code
>How "ugly" a trivial "Hello, World!" does not really matter much and isn't a good indication of anything about the language's ability to handle more than "Hello, World!"
Sure, but for beginner programmers who don't have the discipline down yet, it's unnecessarily hard. I bought a Java programming book as a kid and got stuck because of a typo that produced an error message I couldn't understand. This was the time before StackOverflow and Reddit. In retrospect, this delayed my programming journey by at least a year.
Longer Hello Worlds make frustration and getting stuck like this more likely.
Many of us took programming 101 in Java and so typed this dozens of times without having a clue what it meant.
I learnt C at Uni (after having taught myself BASIC, Z80 machine code (not assembly), and x86 assembly), when we were taught C it was explained to us what all that sort of thing meant. But having said that most of the class failed to understand.
Now we can type out the same semantics, and remain clueless about what it means, but with a new obfuscated syntax which stops us from asking about the semantics.
Still for the better, because each token you don’t have to type when first learning programming is a token you can’t mistype.
(Though the ultimate conclusion of this line of thinking is that programming 101 courses should be taught in as concise and syntax-light a language as possible, giving the learner as few opportunities to screw up the input as possible. I’m a fan of teaching programming in Ruby, personally. Not theory of programming, mind you; just programming as an iterative human process.)
> programming 101 courses should be taught in as concise and syntax-light a language as possible
100% this. To make Java be the all-language makes it a mess without a defined goal. It is better to start learning with a language better suited for it. And then the learner can specialize and expand to other languages. This also helps to create awareness that different languages have different use cases.
Probably not in the least for developers, but it does affect beginners a lot.
I used to teach Java, and the total sum of magic incantations you needed before starting to actually "Hello, world" were an instant turn off for many students.
How to compile a C or C++ program is also a turnoff, right?
I didn't teach intro to C or C++, so I can't compare for certain.
From my recollections as a student, compiling C or C++ in intro classes was just a matter of calling `gcc myprogram.c` or `g++ myprogram.cpp`, followed by `./a.out` for testing, which is rather easy to explain to students who already know what a command-line is.
It would matter for CLI, but doubt many CLIs are written in Java
I think it’s been at least 5 years since I saw a main in the codebase.
Now that I think of it I rarely even write a truly new class from scratch, usually you just implement/extend some framework-specific thing.
Java sometimes has a culture of "the proper way to do this is to take all these little pieces and put them together in a specific way" which probably makes sense for an object oriented purist but is a bit of a drag day to day.
The scanner class is one such thing, but you also have things like wrapping a Reader in a BufferedReader to add buffering, and building a Pattern object to build a Matcher object which has a few different methods you can call to actually do anything useful
It is very OO, but it's also a bit annoying, and more modern java libs tend to give you a more comfortable API. Sadly modern java also tends to come with springboot and people who can't do anything, unless they use springboot
> Sadly modern java also tends to come with springboot and people who can't do anything, unless they use springboot
Spring Boot (and Spring generally) is more of a “Java culture” issue — someone on this thread used the term “framework fetishism” and it’s spot on.
Thankfully there are teams, typically in mobile or polyglot microservices environments, who are moving away from this. But yeah — still far too common.
Before Spring it was JBoss. Awfully slow and bloated frameworks which then become mandatory in enterprises. In the end they all go back to POJO when things really need to work.
It's insignificant for day-to-day programming for experienced developers, but has importance for learners.
Frieren working on projects that last decades. Ya don't say... ;)
JEP 445: Unnamed Classes and Instance Main Methods
Released in Java 21
https://openjdk.org/jeps/445
It's a shame that they only introduced this as a feature only for single-file programs.
It would make Java a much better language in my eyes if it allowed package-level methods, or even multiple records/classes per file. But apparently "impact on how Java code is written in general" is not wanted.
People change their minds once they get used to something. There's reason to have patience.
:-) So not even remotely dead.
It's amazing that ~30 years on, Java is finally becoming a not horrible programming language.
I'm someone who wrote a lot of 'raw' Java and C++ without frameworks, which meant there was a lot less boilerplate and indirection etc. And for me, the big usability boon came about 10 years ago, around the same time for both Java and C++, when they started supporting lambda functions. I started passing code into algorithms and, although it sounds quite complicated, it simplified my programs substantially. Before that syntactic sugar gave the affordance I hadn't been organising my programs that way.
For the longest time Java had been very keen to be explicit, to the point of needing a log of cruft where it just felt like the compiler was checking you spelt every letter of the incantation correctly because both the compiler and you knew unambiguously what simple thing you were trying to achieve. But this tone changed in Java around the time the new entrants like Kotlin started taking over as what you develop in in a way that scala and clojure never managed. And suddenly all the get-out-of-your-way of lambdas saving you typing out classes and anonymous classes arrived and Java became a much nicer experience imo.
Yeah, as someone with a background in FP, I found anonymous Runnable classes quite awkward.
Now if we could just wean some more of the ecosystem away from the framework fetishism... there's no reason java programs have to be so huge, unwieldy and slow to start.
No reason apart from the framework epidemic that's supposed to make things easier for developers, but in the end hamstrings them and weighs everything down.
(to the downvoters - I am a java developer and this is very real to me at the moment!)
Java was never a horrible programming language. The hate is wildly overblown.
The culture of insane overengineering around it is the problem, not the language itself.
In fact, it was welcomed in open arms even being originally interpreted, because writing portable C or C++ code in 1996 was still a mess, even across UNIX flavours.
On my university no one got Sun's marketing money in 1998, yet the distributed systems, compilers design, and graphics programming, all adopted Java as the language for new teaching materials, as it sorted out several problem with the assignments.
Yeah, migrating from C++ was such a breath of fresh air!
Both awt and then Swing were pretty bad for anything beyond toy programs, though.
Comparing to writing X11/Athena or Win32 in raw C?
Which is what the respective department was doing before.
Swing is great, it does suffer from bad defaults though.
Anyone serious about it, would be getting books like Filthy Rich Client, and additional libraries like JGoodies.
Granted, they only came to be around Java 1.4 timeframe.
I was using OWL at the time, which I recall as pretty good.
Swing was nice to program, but had sluggish reaction time and more than a few bugs (speaking of Swing 0.9/1.0, never went much further).
OWL was quite good and one of my favourite C++ frameworks, but not something that was being used at my university on assignments that were mostly done on UNIX, which was my point.
Yeah, under UNIX, the UX landscape was really bad. I think that Qt was available already, but not quite open source.
Swing is so bad they built an entire product line of IDE out of it.
Do you know any other product built in Swing?
In 2012 managing the JVM was a nightmare. Java is fine now.
Only bad experience I remember from Java was the int/Integer primitive/object issue and boxing.
Also of course the misuse and overuse of classes when designing systems, but the complexity at design time is also the counterpart of the ease of use of well designed APIs. I remember using an IDE to write some code and it skipped the whole documentation and run/compile error phase, I could just cast mismatching types as needed.
Probably C# and Swift/Objective C would only be above Java as top languages, being actually funded by paying customers instead of used by companies that depend on volunteer developed open source software and end-users that equate paying for software with evilness.
Being forced to use anonymous classes to simulate lambdas prior to 8 was the biggest source of annoying boiler plate IMO and was genuinely a bad experience in sufficiently complex or large code bases.
Everything beyond 8 has been nice to have but 8 was the big one.
Agree, for the most part, but I think records and pattern matching are essential. I started using Scala (2.x) in 2014 or so, and case classes and pattern matching completely blew my mind. if/else trees and switch statements felt so archaic, limited, and verbose after that. I used to joke that Java would eventually adopt enough of Scala to be a pleasant language to work in, and I don't think I was that far off.
(I'll ignore Kotlin... I don't get why people like it.)
I too adopted Scala in 2014 and was really satisfied with FP side and how it all was tied with JVM. Honestly I always felt that JVM is a nice platform with a horribly verbose “assembly” language that is Java.
Fast forward to around 2020 and I had to organize a team to build search engine in JVM. Given how hard it is to find decent Scala developer I surrendered and did this project in Kotlin. Java devs easily pick up and write sensibly FP-style even code, and builtin coroutines are cool. Even though I had to open up the internals of coroutines to get tracing to work they felt a very welcome change compared to say monadic explicit async.
So for me Kotlin is kind of watered down Scala for typical Java folks and I could tolerate it compared to perspective of writing plain Java.
> Only bad experience I remember from Java was the int/Integer primitive/object issue and boxing.
Heh, I once had to work in a code base that used an `Integer premiumDefenseLevel`. It contained the level of premium defense a player had purchased, or null if the player didn't have any levels of premium defense purchased in the recent times.
This was in fact annoying to remove, because a 0 after a 1 was treated differently than a null some time for advertisement reasons: Someone who had bought premium defense in the past is more likely to re-buy than someone who didn't, so they are pestered with ads. But it eventually turned into a neat little domain object.
> the int/Integer primitive/object issue and boxing.
That's a deal-breaker. If you can't tie together a few values in a record/struct without being forced to box them/heap allocate them, the language will never be used anywhere where you even remotely care about performance.
This is not a difficult problem to solve - C# did it in a very elegant way with structs, and as a direct result, probably for half of all videogames written today, the gameplay portion is written in C#.
imo it's worse than that. of they'd just hid the boxing in the runtime, Java would be a kind of slow language that didn't feel awful. by exposing the unboxed primitives to the user, they created a horrible duality of incompatible types.
You Guys haven’t used Java since the 90’s right? Boxed types convert to primitive values automatically, you never need an explicit cast! What horrible duality are you talking about?
What are you criticizing exactly? You can have primitive integers in Java records or classes just fine. If you have many you can use an int[] like in C, no one forces you to use generic containers.
Uhh. Most big data platforms are jdk based. Java handles scalable long running applications incredibly well for a fraction of the cognitive load.
It's not a terrible language, but it's not too good either.
For a very long time it completely stagnated and all the features we see added now should've been there 10 years ago, at least, and a bunch of other improvements on top. All because "our goal isn't to adopt the strategy of less successful products, but to forge our own" which now turned into busily adopting all the features that the "less successful products" have had for years: https://news.ycombinator.com/item?id=28985688
Meanwhile some languages like Python still suck 30 years later.
Most likely you have not seen horrible languages or your bar for being not horrible is quite high.
Or they've seen enough good languages to push Java down.
this one. Java is far from the worst out there. I've used MuMPS and know of the horrors of TCL, but Java is once of those languages where everything takes 5x more more code than it should, and the result always feels ugly.
part of my dislike is probably that I'm a math person, and the lack of operator overloading really makes any math not using the built-in types dreadful to read.
Even so. It has amazing backwards compatibility and package management.
I really hope you mean this as it has (amazing backwards compatibility) and (package management), because describing the package management in Java as anything more than "I guess it's better than C" feels overly generous
From my previous comment in hn:
As a java guy and think python is weird, I don't think this sucks.
But, I also agree that can serve as terrible intro to programming if you start programming right away without understanding the basics of abstractions. 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.
This heavyweight syntax has nothing do with OOP. No common definition of OOP (before Java came into existence) said that functions cannot exist outside of a class.
Java choose to adopt object oriented purity in a very weird way. Sun has initially rejected the idea of standalone functions (static import was introduced in Java 5, closures in Java 8 and compact source files/instance main is only coming now). Even with static imports and compact source files, there is still a class holding these methods behind the scenes (for practical and compatibility reasons, more than to achieve any ideological or theoretical goals at this point). That seems like Sun was trying to keep the purity of "everything is an object", but at the same time they've introduced primitive values, which are clearly not objects. This was a pretty bad decision in my opinion. There is no practical benefit from requiring every function to be defined inside a class[1]. On the other hand, being able to have methods defined on an integer is a pretty nice feature.
If we look at a Smalltalk, which is generally considered be an example of a "pure" OOP language, we see a striking difference. This is Hello World in Smalltalk:
Smalltalk allows you to freely define functions outside of classes and even write code that is not part of a class (directly in the REPL).[1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
> Smalltalk allows you to freely define functions outside of classes
Please show an example.
I agree, this is the whole point of "Hello world", which is to show the boilerplate required to start a program capable of outputting text, as well as the actual code that outputs that text. It's also the chance to get the build tools setup, people forget that some of the 'boilerplate' is the actions required to build, which often are much more involved for newer tools and frameworks.
You can just say initially e.g. when I learned C++ that "#include <iostream>" can be "mostly ignored for now, but just know iostream stands for Input / Output stream, and this line is necessary to e.g. output with std::cout"; and there are no scars left from this.
Some scars... as cout << was always a bad idea, and taught people early on in their C++ development that being overly clever with operator overloading was expected
Which I think most people understood not to do themselves when they encountered their first issue with the precedence of << vs other operators in expressions they wanted to print.
If it is just syntactic sugar that has to create a class under the hood, it's just lipstick on a pig's turd.
If you can't have other top-level functions in Java, then it's a special case, which is ugly.
C# has had top level statements since version 9.0 (Nov 2020), and it's still just a compiler trick that produces a static method behind the scenes. Top level functions work too, but in a similar way.
Decompiled example: https://lab.razor.fyi/#41rAyMUVUJSfXpSYq5dcLDSRsbQ4My9dIbiyu...
> lipstick on a pig's turd
There are several valuable compiler transformations that happen under the hood in languages like this. Closures as types, iterator/generator functions, async state machines. This is just another example.
I feel the same way about C/C++ having default return of 0 in main() only.
I really hated that change when I came out. I'm still not a big fan, but I made my peace with it understand that it benefits the poor users who have to deal with programs whose termination statuses are pseudo-random. Especially users doing scripting.
I write "return 0" at the end of main in all my programs if that end is reachable.
I write "return EXIT_SUCCESS;" maybe that constant might change... :-)
0 is guaranteed to mean 'success', although not guaranteed that it's equal to EXIT_SUCCESS, so you can always use 0.
> If you can't have other top-level functions in Java, then it's a special case, which is ugly.
I assumed this meant that you could have free functions, but you're saying you can ONLY have `main` as a free function? Ok, then I agree this is also garbage.
Foesn't this show other top level functions besides main? From the JEP
```Top-level members are interpreted as members of the unnamed class, so we can also write the program as:
String greeting() { return "Hello, World!"; }
void main() { System.out.println(greeting()); }```
What’s with Java devs and not including `import` lines in example code? Even here, when intending to demonstrate how dumb Java’s boilerplate is. But I notice it everywhere.
Because usually you have an ide that manages imports for you automatically. So unless you are using a library that has multiple imports, usually you know the import to include, and in almost all cases it is automatically included.
Btw: in the compact example! The IO class is implicitly imported, so that example truly works without any import at all!
Among other things, I think a lot of Java IDEs automatically manage imports anyway.
I mean, the IDE can totally write out the import statements for you as you type and choose resolutions for identifiers; but if you paste in a random code snippet that references ambiguous identifiers from a third-party lib, no IDE can magically generate the import statements required to discriminate the correct resolutions. You have to go through and resolve the symbols yourself (or advance through them as error sites to get the class to compile.)
Or, to put that another way: import statements aren’t pure boilerplate that should be thrown away; they encode real information (ambiguous symbol resolutions); and so, by eliding them from code examples, you’re discarding that information and forcing the learner to re-derive it.
Which is especially bad when your code examples are referencing ambiguous undocumented static inner classes nested deep inside your library’s package namespace, where all the potential resolutions differ only by the particular package they exist in (since they’re all e.g. essentially batteries-included extensions of the base library implementing the same interface.) And where all this structure is as ugly as it is precisely because you didn’t expect the end-user of the library to need to understand it / interact with it. Yet your own [usually “advanced” or “feature demonstrating”] code examples force exactly that.
i forgot. sorry.
Why not abstract away the public static void main(String[] args) method with a top-level statement paradigm, similar to C#'s entry point simplification, to reduce boilerplate and enhance code conciseness?
See Brian's article "Paving the on-ramp": https://openjdk.org/projects/amber/design-notes/on-ramp
Why should the entry point be a random special case? You're already admitting at this point that OOP is flawed so you might as well just have the balls to design a proper alternative (rather than a kludge)
A special static class that cannot be instantiated is not OOP already.
C# does this well by letting you OOPfy your other code but doesn’t require you to use OOP for this monstrosity.
This pattern isn't OOP, there is no objects here. And Java generally isn't a good example of an OO language to me. It's more like Class Oriented Programming. That is mighty flawed but was for some reason quite fashionable.
I wouldn't consider OO the way Ruby and other actually well designed languages do it flawed.
And Ruby is basically Smalltalk with a friendly syntax and lots of FP-goodness where it makes sense.
Or, Ruby is a cute (mostly subset of) Perl.
And after some Kotlin I must say: Kotlin is an acceptable "Ruby with static types".
It always was and is a random special case.
The unnamed class approach to global variables sounds nice. You can do hot-reload, but still have unencumbered syntax.
OTOH, since Java files are named after their public class, it would have made more sense to just say the `public class X { }` wrapper is optional and only needed for attributes and inheritance. I don't quite understand why they need an anonymous class.
> The Java compiler will compile that file to the launchable class file HelloWorld.class. In this case the compiler chooses HelloWorld for the class name as an implementation detail, but that name still cannot be used directly in Java source code.
https://openjdk.org/jeps/445
What we seem to have forgotten is just how c like java was compared to other programming languages being advocated at the time. Objects made sense (remember Ada?) but c++ was a mess. Java was a breath of fresh air with lots of c legacy.
Oh, I do remember the narrative: OOP is amazing but Cpp is not pure OOP let's make the OOPiest language possible.
I also remember casts all over the place in Java because polymorphism wasn't OOP enough.
And then lambdas and functions were not OOP enough to be first class values and that's why we needed numerous "verb-classes" everywhere.
And of course printf() is not OOP enough...
Exactly. All wrong assumptions, and all needed to be tagged on to Java in later versions.
I dont find Java's first versions well designed. The JVM was quite well designed, but the language not.
And changing a popular language is hard. I think Java's dev do it very well (the process of changing it IS "well designed"). But still the language itself suffers a lot from the bad choices in the beginning.
I like Kotlin: an OO language with as much FP in there as makes sense for an OO language.
Learning Java in high school, I loved how the very first lesson (focused on Hello World) had you type this out, only for the teacher to say “This will make sense later on but for now just type it in”.
I haven't written Java since college CS, over 20 years ago, and I still remember that one line. It's burned in my memory.
This is not a prank right ? Is it really gone ?
It is, and it will be back soon just like Python's "if __name__ == '__main__'"...
It makes sense to still have a main function. It doesn't make sense to have a class only to wrap that main function.
What? When did that go away? What is the alternative?
In a pyproject.toml file you can create/define scripts that reference an entry function. E.g.:
and in the pyproject.toml: You can still use the __name__ check at the end of the file, e.g.: That way it works both as a standalone and when installed via pip/uv. -- Note: The scripts created by the installer are slightly more complicated versions of that __name__ check that handle the application argument (arg 0) and the exit code as the return value from main().It's not gone per se -- you can still write out the long form version if you want (this is required for backward compatibility).
What's now permitted is:
1. a simpler way of declaring a main method on a class -- you don't need the public or static, and the args is optional, so you can declare a `void main() { ... }` method on a constructable class;
2. declaring a main function (and other variables/functions) outside of a class -- here, the startup code will handle calling the main function, although I don't think the ability to call anonymous functions currently extends outside of the main function/file.
This hits home... literally. My high school kid had Python last year, and this year they started him on Java, and his very first reaction on coming back from school was, "WHY THE HECK DO I HAVE TO WRITE ALL THIS STUFF JUST TO PRINT HELLO WORLD??!?"
Looks like C# to me
We got there just after we got the ability to legitimately create useful small programs without understanding any of the thousands of lines of code.
You will not be missed!
could java please also learn that stand-alone functions are cleaner than static methods? even if it's just syntax sugar...
C++ calls them free functions, and I always found them rather elegant. A common pattern, at least a few years ago, was to use free functions for anything that'd be a method in Java, but doesn't actually require access to anything non-public.
It looks more like C++ or C now. Never really became a java programmer. Hopefully never will have to.
Back in 2005 or so, Java felt like "C++, but we know better" to me. I had no choice but to use it, but boy did they omit some stuff that was actually useful. The boilerplate back then (driven by both the limitations of the language and a surge in architecture astronauts) was absolutely insane. Don't even get me started on anything labelled "Java Enterprise" in the 2000s, bloat, slowness and bugs everywhere. IBM, Oracle and friends were running quite the circus. Creating working, performant software in that environment was a brutal challenge. I think Java, the language, is only partly to blame, but it was limited enough to spawn pretty complex code generators and frameworks.
Took the industy a decade or two to arrive at typed languages that were an actually good subset of C++ features. Java, in my opinion, wasn't one.
We're solving real problems now.
Did it slow down compile times at all to support two different file structures?
So, Java now supports free functions (not associated with some class). Or not really yet?
If so, are we observing a move towards Universal Suffrage in the Kingdom of the Nouns? [1]
[1]: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
They are associated with a class, but the class is basically the file. There are limitations by doing it this way but it is out of preview and officially supported as of Java 25.
https://openjdk.org/jeps/512
No, these are just default imports. Module import declarations are in for JDK 25 to make this kind of thing even easier: https://openjdk.org/jeps/511
Nope. It's just sugar. [1]
It's somewhat implicit in the JVM spec, but functions are always bound to classes as methods. [2] The only kinds of heap objects you can have a reference to are class instances and arrays. [3]
The lack of free functions is really only a minor inconvenience for language implementers. Clojure, for instance, just compiles new classes to hold functions as methods.
From a programmer's perspective, you can write lambdas, but again, it's just syntactic sugar over an inner class.
[1] https://www.happycoders.eu/java/main-method/ [2] https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.h... [3] https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.h...
I think all functions are associated with some class. But these classes sometimes are hidden from you and you don't need to know about them. Does that help you? What for would you use true free functions?
> What for would you use true free functions?
The same things people use free functions for in any other programming language.
Cluttering up global namespaces? ;-P
> What for would you use true free functions?
I'm visibly shaking at this statement. What are you even saying here? A function is the most basic, fundamental unit of code organization. What Java does with its forced classes is a complete perversion of computation, sanity and anything reasonable.
Presumably these exist in a Main.java file and the java class is implied. Similarly the string params are also implied, and the non param main() function is just an alias or a wrapper for main(String).
It's just syntactic sugar.
Might come back to Java
I don't get the hate ... yes, it is a lot of boilerplate, but at the same time it is very explicit and doesn't hide complexity.
It ADDS complexity that doesn't actually exist. There's no "class" in the C entrypoint of a program. That's just nonsense.
But there are no classes in C?
Exactly the point yes.
Reminds me when Google Translate came out about 20? years ago, I pasted in "public static void main (String[] args)"
and out came in Spanish:
"Secuencia pública de la cañería del vacío de los parásitos atmosféricos"
(Public Sequence of the Vacuum Pipe of Atmospheric Parasites)
C# has top level statements since 4 years ago. Not only you don't need a class, but you don't even need a Main() method.
Ugly? Sure. But isn't this the identity of Java? Taken away for almost no gain, there's literally no real issue stemming from requiring a verbose incantation to write a main routine, this is something you learn like day 1 on learning java, and it's something you write once in a blue moon, like 0.001% of the code you are going to write.
It reminds me of the attempt at removing Richard Stallman from the FSF, yeah, you could do that and fix a problem, but then what you are left with isn't really the same thing as it was before, it's now actually the same soulless thing as the rest of the competing things.
Saving grace is that obviously, you can still recite the incantation, it's not like public static void main(String[] args) is gone, just that you can skip it.
> this is something you learn like day 1 on learning java, and it's something you write once in a blue moon, like 0.001% of the code you are going to write.
I think this is the exact audience for this change: for newbies in day 1 of 10 years in their programming journey. Less boilerplate to just swallow, less time spent debugging an otherwise-fine lab exercise if not for the wrong instantiation of Scanner, more time actually focusing on the basics they should be focusing on.
Granted, I still think Java is a horrible first language to learn from or teach with but this is a step in the right direction. Might revisit this opinion in a few years, who knows.
Oh also, we use Java in production so we also have a bunch of ad-hoc "scripts" written in Java for mostly one-off interactions. Nonetheless, these scripts can get unwieldy fast. You'd think I'm exaggerating the benefit here but I, for one, welcome one less level of indentation in these scripts.
Sure you could argue that it's better to learn java like this. But also you could argue that it was fine to learn java with an incantation. It's the first day of class, of course you are not going to understand everything you type. And you are getting exposure to important java concepts that you are going to circle back to later in your journey.
Fwiw, other JVM languages like SCALA have already done this exact thing way before. But whatever, it isn't either good or bad. And I can still use the old way out of respect for tradition.
To each their own
but I need my public static void main arg arg arg
Mr Krabs!?
Eh. I used to teach Java as a first programming language and this always went "Just ignore the incantations for the time being, you'll learn more about them as time goes."
This (and IO) was also one of the reasons for which my students tended to like OCaml much better than Java.
I distinctly recall early in my first university programming courses the instructor saying something to the effect of "Just wait until you learn 'public static void main'". I think we had only used BlueJ until that point in the course.
Timeline:
Java 5 (2004) [code sample from the article]:
Scala 2 (2006): Scala 3 (2021): Java (2025) [code sample from the article]:Funny how shaming and competition worked wonders for Java, instead of that bureaucratic mess that was first versions
It hasn't been for over 20 years with Java 5.
public static void main(String... args)
What I would like to see deprecated is over using objects and design patterns and SOLID and Uncle Bob principles, so we see less FizzBuzz Enterprise Edition and Java feels less as the Kingdom of Nouns.
Why did it suck exactly?
The goal is go make java easier to learn for people new to programming.
When they start with the old style there is an overload of concepts where the teacher just have to say "ignore all this", which is not ideal. With new style they grasp fewer concepts at first.
I'm not truly convinced this is such a big deal, but I lived through my university switching from Pascal to Java in the first programming class, and I can confirm people did get much more confused during the first few classes (to be fair they got way less confused later not having to deal with pointers tho).
> The goal is go make java easier to learn for people new to programming.
"public static void main (String[] args)" teaches A LOT if one takes the time to inquiry about every keyword in there.
Yes, but not all of that you want to learn on your first day learning to code.
Excessive boilerplate code.
Some people have so much time or so few things to do during the day that they can write a blog post about meaningless programming languade aestheticisms that only other frivolous people will understand and enjoy.
That's what I wanted to know too, but all we get is this one line:
> 1: When I was a Freshman in High School I asked a Junior what it meant. He had no clue.
OK... so it's confusing for juniors. A lot of stuff is. I probably didn't know what it all meant when I started either, but so what? You copy and paste it and move on. Eventually it makes sense. Not a big deal.
I don't understand how anyone ever didn't know what this meant. You have a class. It has a static method. The runtime starts your program by calling the method, passing it an array of command-line arguments. What's mysterious about this?
The fact that you have to explain what classes are, and what static methods are, a huge load of information, for a hello world program. And what's worse, it will leave students rightly confused about what the point of the class is, if it only has static members... Making it more likely they don't retain any of the information. Or alternatively, just say "type it exactly like this, don't think about what the magic words mean" which is a great way to ruin programming for people
The first book I read on Java managed to explain "public static void main(String[] args)" by the end of the first chapter. It wasn't a long chapter, either.
I don't like Java, and the excessive boilerplate is a big part of that opinion. But it was never nearly as arcane as some people here are making it.
When you first learn programming, you don't know what a class is, or a method, let alone a static method.
But if you teach people using Java, you have to teach them to write this:
...instead of just: The latter is easy for a student to understand. With the former, you just have to tell them to use it without understanding it, and that they'll understand it later.Why there is a class in the first place
Not understanding why having a well-defined function declaration "sucked", but alright, I guess!
I mean even this part:
``` var name = IO.readln("What is your name? "); IO.println("Hello, " + name); ```
is _worse_. `IO.readln` doesn't tell you whether that's file I/O or stdin/out. The more explicit the better, if you ask me.
"Hitler dead Wat nau?"