If there's no logic in the getter and setters, just make the properties public.

That works until you want to add logic without breaking existing interfaces.

Or until you need to use them in beans and the like.

Play!Framework 2 for Java is awesome in this matter. You write public members, but at compilation it transforms them into private members with getters and setters (if not final). It means if you write the setter, it overrides the default one.

Lombok does the same ;)

But then you're using Lombok...

Can you clarify? I've heard similar negative feelings from devs. What's wrong with lombok?

Huh? Then they're just fields and not properties, maybe I'm misunderstanding what you're trying to say. And there are numerous reasons that Properties are preferable to Fields.

Unless someone else can help me, I think this is really bad advice for a C# developer.

>Huh? Then they're just fields and not properties

Nomenclature schmomenclature.

They're variables with object scope.

might want to checkout lombok. https://projectlombok.org/

Just keep in mind that some of the features are a bit iffy. If you use their vals IntelliJ will syntax highlight it as an error in red for the simple reason that it's non-compliant with the Java language spec. Also, you'll usually need a new version on Lombok every time a new version of Java comes out, otherwise what used to compile with the previous java version will no longer compile. If you use the auto constructor you're going to have fun finding usages since there's nothing to click on, and changing the order of fields in your class will silently change the ordering of parameters in your constructor - double the fun of the fields are of the same type. You'll also be left wondering why you went to all the trouble of adding dodgy language extensions instead of just using a language which provides those features anyway. That and your code (subjectively) looks really ugly plastered with annotations everywhere. Some people like Lombok, just make sure it's a choice you make going in with your eyes open.

We use Lombok heavily where I work, on > 5 projects and have yet to run into any problems like you describe. Everyone use IntelliJ apart from myself and haven't heard any issues with using 'val'. We started off just using it in tests but it's now spread throughout the code base, I can't imagine going back to pre Java 8 sans Lombok.

Builders etc. work fine, it's the vals that are permanently underlined in red, even with the plug in. It compiles OK with vals, but still highlights it as an error in red in the editor.

True. I've seen multiple teams putting a lot of effort into removing Lombok from their codebases after all the trouble it caused.

Lombok's val is the only thing I don't use in the Lombok library.

Isn't that just a boilerplate generator? I think the point is to have sane defaults and shorthand for common tasks so boilerplate generation isn't needed.

If I'm not mistaken, Lombok generates the boilerplate at the bytecode level, not at the source code level. Which makes it much more like a language feature, and while I haven't used it extensively seems like a decent library solution to what is normally considered a language problem.

I just stumbled on this today (before coming here), looks really nice to rid some boilerplate. Regardless for some reason I still love Java...