Released in Java 21
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.
Everything beyond 8 has been nice to have but 8 was the big one.
(I'll ignore Kotlin... I don't get why people like it.)
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.
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#.
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.
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
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.
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.
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!)
C# does this well by letting you OOPfy your other code but doesn’t require you to use OOP for this monstrosity.
I wouldn't consider OO the way Ruby and other actually well designed languages do it flawed.
The same things people use free functions for in any other programming language.
It's just syntactic sugar.
[1]: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
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...
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.
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.
> 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 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.
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");
}
}
print "Hello world"
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).
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!
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".
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
As much as I love hating Oracle, they pushed the language forward much more than Sun ever did.
The only reason Java is still somewhat relevant is ironically Android/Kotlin, and SAP/heinous-dual-stack-blobs product lines.
Best regards, =3
Pulling the oracle card when java is mentioned is a useless stunt.
Do you actually use that option at enterprise scale? =3
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
(I somehow mostly avoided learning Java, and my last passing contact with it was 20+ years ago, so these are honest questions).
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:
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"
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...
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.
If you can't have other top-level functions in Java, then it's a special case, which is ugly.
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 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.
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.
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.
public static void main(String... args)
How does it affect you this change day to day?
(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.)
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.
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.
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!"
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.
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.
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
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.
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.
Btw: in the compact example! The IO class is implicitly imported, so that example truly works without any import at all!
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.
abhiyerra•1h ago
riffraff•1h ago