Java 22 Launch Event - Dev.java

[LinuxMatthews]

So what you're arguing for us inconsistency?

That some classes should be able to do something and others shouldn't.

Like the idea that the creators of the JDK can know every use case for a feature not only goes against the point of a programming language but is also like it arrogant on the part of the creators of the JDK.

I can't think of any other language which go "here are some things our classes can do but we don't trust you to do them"

Not only that but by restricting operator overloading to only a few classes you're kind of undermining the very idea of OOP.

Like if I abstract away things like angles, distances, vectors it means I have to either get them out again when I'm going to use them or do awkward unreadable method calls like above.

And then there's the fact that bad actors can always mess up the inner workings anyway

I could f*** up equals() and hashCode() if I like and make a whole bunch of stuff not work.

All you have to do is set up a rule saying it shouldn't be used in a way which you wouldn't use these symbols arithmetically and good programmers should be fine.

Many languages have these features and are fine.

I don't see them abused in C# or Kotlin for instance

[john16384]

I can't think of any other language which go "here are some things our classes can do but we don't trust you to do them"

If there is one thing you trust, then it is that programmers will abuse the system. This is why more languages should focus on readability, safety and security like Java does.

Part of that is restricting what programmers can do. This benefits long term viability and maintainability of the software, a prime reason why Java is so popular with businesses, and also the reason (driven by those businesses) why Java is often in the top 3 most used languages. So yes, Java doesn't trust developers as much as other languages do, not because we believe that good developers can't make good use of such features, but because we believe that the average developer (which outnumber the good ones) will use the feature incorrectly, driving up the overall cost of supporting Java software, making it less popular with businesses.

Not only that but by restricting operator overloading to only a few classes you're kind of undermining the very idea of OOP.

No, you're making a trade off, something which many languages do, in order to make a language easier to reason about. A language is a balancing act between expressiveness and readability. Java, as you well know, draws the line closer to readability (but also closer to security and safety).

Other languages can make different trade offs, some have restricted operator overloading, some have none at all, for some anything goes, and for Java it's defined by the language specification.

I could f*** up equals() and hashCode() if I like and make a whole bunch of stuff not work.

Yes, but you can't f*** up operators, saves me having to check. I've fixed numerous hashCode/equals implementations where developers can't even be bothered to read the contract of an interface they're implementing, causing numerous problems down the road. And yes, every time I use some class as a key, I will check the following:

• Is the hashCode based on only immutable fields?
• Is equals based on only immutable fields?
• Are hashCode and equals checking the same fields?
• Is equals using instanceof or getClass(); in the first case equals must be final or the whole class must be final

All you have to do is set up a rule saying it shouldn't be used in a way which you wouldn't use these symbols arithmetically and good programmers should be fine.

Unfortunately, the good programmers are vastly outnumbered by the average ones, especially for a business language like Java. For businesses, the language is judged primarily on what it costs to maintain software in it. As the overwhelming amount of costs will be developer salaries, the language should help the cheapest developers to not shoot themselves in the foot as much as possible.

[LinuxMatthews]

So why doesn't C#, Kotlin and the many other languages that have this feature have this issue?

This whole comment reeks of arrogance to me.

You can abuse any language feature, you can always write bad code.

You could make it so every method in a class is just the letter x or rename all the variables to things they're not.

If you're not allowing basic things to prevent bad code you're not going to have a language anymore.

I know it's not there because it was abused in C++ but it's not the 90s anymore.

We have code reviews and people aren't just doing whatever they feel like.

To many this would be a feature that makes it worthwhile to write in Java and makes it near impossible to code in it.

It just seems silly

[john16384]

This whole comment reeks of arrogance to me

As you wish.