New language features since Java 8 to 17

The gap between Java and C# has grown very slowly but surely for many years, and more people feel Java is changing too quickly than too slowly. Different people prefer different things, some will always prefer Pepsi (although C# will probably not be that Pepsi, as it's lost too much ground and MS seems to be losing interest in it, as they tend to do), and our goal isn't to adopt the strategy of less successful products, but to forge our own, even if some on HN have other ideas.

> that is you define what happens encapsulated in a class

Apart from that it is really unintuitive to have something "static" within a class (which is commonly understand as a template), it is not encapsulated because it is static _and_ public. _And_ now you can search for this thing everywhere - and what happens if you find two of them?

Yeah no, the idea of "public static void main" wasn't a great one, no matter how I look at it.

It's much better to be explicit and ask the user to decide which file they want to use as the starting point.

> Of course implicit imports are needed, like what else would you have without

They are of course not needed. You could also just import everything manually. Okay, Java's import suck, but in a better language you could do "import prelude._" in the beginning of every file and otherwise you are left with keywords only. Not saying that's a great idea, but it certainly can work without implicit imports.

That's not the point - try having 2 or 3 way diff, pull request with just var. It's =awful=. I know most of the standard APIs (incl. overloaded methods and what not) by heart but not every little function and class in a million lines of code project.

To me var adding is mosttly an anti-feature - when using an IDE, I dont even bother to declare the stuff, it gets auto completed. When I read code outside the IDE - well it sucks. It's not the level of 'perl - write only', but at least it aspires to be.

> it's lost too much ground and MS seems to be losing interest in it

wat

> our goal isn't to adopt the strategy of less successful products

This sounds like "we don't care if some other languages have great quality of life improvements, we pretend that success (for some unknown definition of success) is the only thing that matters, so we'll keep implementing one or two features every 10 years that don't work with half the language and standard lib, and still require hundreds of lines of boilerplate to work with."

In a sibling comment you're pretending that withers is a thing that will ever happen. It won't, not for another ten years. Meanwhile we're left with a language that has to resort things like Lombok to try and cut down on the ridiculous amounts of code one still has to write for even the simplest things. Or almost but not quite incompatible lists and collections (none of which have even a pretence of a DX for easy construction). Or value types that have been a proposal for 9 years, and generics with primitive types that has been a proposal for 7. And the list (or collection? or stream? or?...) just goes on and on and on.

Thank god we finally got multiline text blocks and some form of pattern matching. Wait. Those come from less successful languages. How could you?

Easier construction for records will come to Java. As with most Java features, it will come once it's been carefully considered, and done in a way that gives the most bang for the buck (e.g. we do want easier object construction, but if we add a feature for that, we'll try to get more than just easier object construction out of it).

> And don't get me started on array vs list vs collections none of which are compatible with each other.

This is not true. Lists are collections, and while arrays are different, Arrays.asList() gives you a list view of arrays.

> And hundreds of other QoL improvements that are begging to be implemented, and are not.

First of all, just in the past five years we got local variable type inference (var), switch expressions, records (with much more to come), sealed classes, and basic pattern matching (with much more to come), and string templates are around the corner. All of those are significant QoL improvements.

Second, every feature comes at the expense of all others -- both because of opportunity cost and overall language complexity budget -- and the question is one of priorities. Not everyone has the same priorities.

Finally, because Java is expected to remain extremely popular for at least a couple more decades, we must be very careful about adding features. While other languages are trying desperately to gain many developers right away, we're looking ahead to ensure that we'll be attractive to developers in ten and twenty years from now, and so must spend the complexity budget carefully.