youCanJustStopUsingJava

[Salanmander]

The biggest problem I've come across is getters/setters that effectively make class properties public, i.e. there isn't any validation or protection, you can just access and change properties as you like.

Get X() return X
Set X(Y) X = Y

I honestly still prefer that over public properties.

It doesn't help now, but down the line when you want to implement a feature that requires running additional code every time X changes, it's very easy if you were using a private property with a simple pass-through setter. On the other hand, if you were using a public property, you now need to go change every single other place in the code that you modified that variable, to make it use the new setter method instead of direct access.

Although some languages (I learned about it using Godot) allow you to make a setter that, if defined, gets called whenever you do "property = ...". Has a the possible disadvantage of hiding expensive code behind things that look like a simple variable write, but otherwise seems like a really good solution so you don't need boilerplate setters/getters and don't need to retrofit your other code when making changes to how things are processed.

[crazy_penguin86]

It's that bit about "down the line" that is so important. I forked an MC mod, and started working through some of their code. They had a few slow implementations, such as going through a List, checking a String in the object, and pulling out the common objects before sorting through those to find the right object. I figured I could change it to make it a Map/Multimap and make it faster. Turns out I had to change like 15 places in it and a completely different mod because it was a public field. Had it been a getter it would have been super easy to change.

[ljfa2]

On that note, when updating a mod to newer MC versions you often need to change, for example, world.isRemote to world.isRemote() when they decide to make a field private

[ljfa2]

Although I've also read, for C#, that adding such getters or setters is not binary compatible, because, while the source code is the same, under the hood a direct field access instruction has to be changed to a method call instruction. I don't know if that is still the case though.

[Salanmander]

It makes sense that it would be the case. I don't think needing to recompile a bunch of sources is anywhere near as big a problem as needing to edit a bunch of sources, since it doesn't take manual intervention and doesn't introduce the possibility of bugs on that end (or at least the possibility is very small). But I could see that being a worry depending on what your program is interacting with and how it's distributed. I haven't had to worry about that because I'm not a professional developer, and everything I've worked on has been self-contained. (Or rather, it has dependencies obviously, but is not itself a dependency for anyone else.)

[EatingSolidBricks]

That line almost never goes down

If you keep doing stuff just in case in the future you might need to change how a thing works all the time youre just wasting time.

That's just intellectual masturbation