• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Why doesn't Java remove need hot getter and setters in POJOs unlike C#

 
Ranch Hand
Posts: 1172
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why doesn't Java remove the need for  getter and setter  for POJOs instead of keeping it less lines of code like C# where getters and setters need not to be mentioned and are implicitly understood ?

Thanks
 
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Find out about properties in JavaFX; it should be possible to use the same concept in ordinary Java®.
 
Monica Shiralkar
Ranch Hand
Posts: 1172
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. It means it is also possible in Java using an additional step. But why is additional step needed. Why don't they make it implicit and not required to write setters and getters.
 
Master Rancher
Posts: 172
7
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One could use Project Lombok in order to avoid writing the boilerplate code related to getters and setters (and use annotations instead). Recently there was an interesting thread here on the forum.

 
Marshal
Posts: 7070
491
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Brecht Geeraerts wrote:One could use Project Lombok


Thanks but no
 
Rancher
Posts: 477
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:

Brecht Geeraerts wrote: Project Lombok


Thanks but no


Why not?
 
Saloon Keeper
Posts: 10494
224
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons sums it up nicely in the thread that Brecht linked to.

Note that neither Lombok nor JavaFx do what C# properties do: A property in C# is basically a pair of operator overloads for the assignment and retrieval operators, except scoped to a single field. You can let them execute any arbitrary code.

JavaFx properties can execute arbitrary code, but you still access properties by calling methods on them, not by assigning or retrieving values to or from them.

Lombok just generates simple getters and setters. It doesn't do any parameter checking. It's like writing your own getters and setters, but worse.

As much as I enjoy properties in C#, they are overrated. They are NOT much quicker to write than getters and setters and auto-properties don't do parameter checking. Additionally, many inexperienced programmers are tempted to write complex or long-running algorithms inside them so that a simple access may be the cause of a lot of latency or unexpected state changes. It's easy to just glance past an assignment when you're debugging code.

Here's a gem: I once encountered a statement like: foo.Bar = foo.Bar; believing it was redundant, I removed it from the code, and the entire application came crashing down. Turns out that the assignment had a side effect that caused it to read some data from a configuration file.

Properties are like operator overloading in another regard: it's awesome when you do it. It sucks when somebody else does it.
 
Master Rancher
Posts: 4208
47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
Here's a gem: I once encountered a statement like: foo.Bar = foo.Bar; believing it was redundant, I removed it from the code, and the entire application came crashing down. Turns out that the assignment had a side effect that caused it to read some data from a configuration file.



Ooh.
I just had flashbacks to my fear of triggers in Oracle...

I hate anything that allows invisible side effects like this.
 
Campbell Ritchie
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Dave Tolls wrote:. . . invisible side effects . . .

Those invisible side effects should produce visible side effects, like a knuckle sandwich for whoever wrote it
 
Dave Tolls
Master Rancher
Posts: 4208
47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm telling you...the invisible ones are the worst.
You never see them!

(Damn!)
 
Liutauras Vilda
Marshal
Posts: 7070
491
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Al Hobbs wrote:

Liutauras Vilda wrote:

Brecht Geeraerts wrote: Project Lombok


Thanks but no


Why not?


Stephan explained it really well + the linked thread contains lots of info.

As an another thing, bunch of annotations personally to me makes readability worse, moreover, I can generate getters and setters with an IDE with less effort than adding those annotations by hand on each and every field so they'd get generated by Lombok. Also you get an extra dependency to your project just to generate few lines of code. If you say it is not few but A LOT, then question is, why your classes are so big, probably they are responsible for too many stuff which is not cohesive.
 
No matter. Try again. Fail again. Fail better. This time, do it with this tiny ad:
Enterprise-grade Excel API for Java
https://products.aspose.com/cells/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!