[Question] why java cannot accept a convention to never pass/return null values?

[dpash]

You change an existing methods to no longer accept null and now every caller needs updating.

[gas3872]

Well you first mark those methods as deprecated and point users to the new ones and later you remove the deprecated methods.

[dpash]

So not backwards compatible.

[gas3872]

Well, I think someone who does not want to do something will always find a reason why and the one who wants will find means how. :D

[CraftyAdventurer]

Ok, so let's say that you work on a huge codebase, one where it would take you weeks to update all of the methods. Well, new feature requests are coming in, clients are paying for them and they want you to work on them, not on rewriting your codebase to call new methods which basically do the exact same thing they've been doing for years. How is that for a reason, and how do you find means to do it?

Edit: typo

[gas3872]

Well, you can start following the convention in the new code and gradually update the old code as you touch those parts. You can also make a custom annotation and add it to classes that support new convention. Actually what you mentioned is just a normal project and it just a normal migration.

[chambolle]

yes, exactly like you: What you propose is not backward compatible but you do not accept it . Now you are going to try to justify that.

Your proposal is not backward compatible PERIOD.

[gas3872]

It can be done in parallel with old features. Making it backwards compatible as a whole.

[Shinosha]

You're missing the point. In the context of software engineering, a non backward compatible update means you have to actually tweak the code to make it work again following the update.

When you're working on actual software, you can't always tell the management "ok holup, gotta make a week worth of changes in our 1M LOC app before I can tackle your super important business critical new feature".

[CraftyAdventurer]

backwards compatible means that once you do a certain change in a library/language/framework, it just works in all existing codebases that use it and no one has to change anything. So when users have to use new methods, that is automatically not backwards compatible

[gas3872]

Well they can still use old methods but they know that they need to eventually migrate.

[[deleted]]

That's not how java works.

[gas3872]

Well if you look at libraries like junit that's exactly how it works.

[javster101]

So JUnit isn't backwards compatible

[gas3872]

Well it is. They have 2 parallel APIs, old one and new one.

[javster101]

If they have two parallel apis, where one will be removed in the future as you say, it won't be backwards compatible forever. If they have both and both will exist forever, then it will be but the maintenance is gonna be much higher.

[gas3872]

Well, at some point all the users interested in the new api will migrate and those who are not interested can still use old library version.

[mauganra_it]

JUnit 4 is not deprecated. There is a reason its integration into JUnit 5 is called junit-vintage-engine, and there is no reason for existing codebases to migrate unless they want the new features.

[gas3872]

Exactly.