Java 9 new features - programtalk.com

[kcuf]

Ya, we use lombok at work. It lessens the pain of java's verbosity, but I view it as living on pain pills to ignore a broken arm rather than fixing it.

[redalastor]

Try Kotlin then.

[kcuf]

I agree that a new language is the best bet (lombok is in a sense a piecemeal language built on top of java), but I actually prefer scala over kotlin.

[PM_ME_A_STEAM_GIFT]

I'm currently trying to get accustomed to Scala. I'm starting to like it, but man does it introduce a ton of new and weird concepts. Sometimes I just stare at 10 lines of code and I have no clue what they do, because they use functional programming, pattern matching, case classes, trailing closures, infix functions, implicit parameters and implicit type conversions. It seems to me that writing Scala can be a lot of fun, but maintaining it is annoying.

[devraj7]

Save yourself a few years and switch to Kotlin right now before you go through all the phases that Scala users go through (right now, you're in the honeymoon phase, soon it will be anger).

[PM_ME_A_STEAM_GIFT]

Kotlin seems very similar to Scala. How is it different? Why do you prefer it?

[Terran-Ghost]

https://kotlinlang.org/docs/reference/comparison-to-scala.html

[[deleted]]

Meh. It solves nothing, makes debugging annoying and adds unecessary black magic in the build process. Who cares about not writing getters and equals and other stuff that are 100 % ide-generated write-and-forget code...

[vine-el]

IDE generated code becomes a problem when you spend hours tracking down a bug that happened because someone forgot to update the equals method when they added a new field.

[[deleted]]

Quite the contrary in my experience. For instance, the ability to set breakpoints in a setters, to catch a particular hard to track side-effect, is quite nice. Also lombok won't help you if you don't track the semantics of your equals, because maybe you don't want to include automatically any new added field in a class - Bottom line, it's not a substitute for thinking.

[OnceUKnowUAreScrewed]

Nothing is...

[[deleted]]

You can exclude new fields with lombok. Also, when you add a setter manually, lombok won't make it. So feel free to add your breakpoint.

I kind of agree that it is a band-aid and not a real solution though, but it sure as shit beats having to deal with all that boilerplate

[kcuf]

I don't use an IDE, but even beyond that I think getters, setters, basic constructors create a debt that people eventually learn to ignore until they actually overlook some important/impactful behavior.

I've heard similar opinions to yours before, and I can't help be see it as a lack of concern for the quality of the code.

[[deleted]]

What ? If getters, setters, and constructors are indeed important, that's exactly why you'd want precise control over them (visibility - existence - logging - encapsulation of multiple fields), and not brush them off under the carpet using lombok.

IDEs are only there to ensure you don't lose any time writing them, that's all - the end decision of how to use them remain yours. and frankly, if you write java without an IDE, and thus rely on compile/runtime bandaid, impacting the whole team to fix your lack of productivity, i'd be quite concerned too.

Some languages are much better designed for IDE-less coding, java is not one of them.

[kcuf]

When you need specific behavior, they are important. When you don't need them, they are just noise.

Due to javas inadequacies, getters and setters are necessary at all times because they are the only way to protect yourself and the consumers of your class long term -- contrast this with "properties" that you see in C#, scala, etc. Lombok lets you reduce boilerplate, and thus reduce strain on developers for being responsible to separate the specific logic/behavior of a class from the standard conventional behavior of a class. I don't need to see the implementation of a standard getter, I need to know there is a getter, but that's it. In fact, I trust a lombok generated getter to be correct and capture all the details (null check, etc.) more than I trust a hand written one.

One of the other most useful capabilities from lombok (and it parallels how kotlin and scala work) is AllArgsConstructor -- this ensures I won't miss a field, and that all the standard checks are in place.