Judging from NetBeans RCP mailing lists, etc. there’s no shortage of enterprise desktop applications being developed. I assume other platforms (Eclipse?) may be similar. (my usage of the NetBeans platform for Praxis LIVE is definitely atypical usage. 
)
I’m enterprise java, but all the work is straight J2SE. All our frameworks are in-house and half the devs are C# / C++.
Anything EJB, Spring, WS or whatever is firmly legacy code.
Well, it won’t happen with any technology nowerdays… :o
C# has some really nice getter setter stuff going on. If only Java would take a little more from C#… mumbleoperator overloadsmumble
That would sound extremely depressing.
But they’re not rocket science. Shouldn’t be something you need to practice.
editor-code-collapse
Yeah, actually you can just let them generate and refactor by any decent IDE.
There’s a theory that says that when a computer is able to write your code for you, either your code is unnecessary … or you are.
Cas 
I think some of you are missing my point…you don’t need to learn how to write a getter/setter. It’s obvious. Like you don’t need to practice 4 space indentation (assuming you like say 2). Or naming variables like this: a_varaiable_name. Someone requires you do so, then you can without practice. Or you’re in trouble.
Who needs to learn to write getters and setters? I am missing your point.
This is getting a lot of medals! I’m intrigued what your suggested replacement is?
There seems to be an assumption here that setters just set a variable and getters just return a variable. The majority of uses of setters in my code do much more than that - validate values, fire listeners, invalidate caches, etc. Even for those minor cases that it is a ‘pure’ setter, I’d rather leave the option open to add these things in without massive refactoring - even in a private codebase that’s still more of a PITA than writing a few setters!
2c ;D
public fields.
a good IDE can track write access, so it’s as good as tracking the “usage” of a setter.
Did you read my second paragraph?! 
This is about run-time tracking changes, which an IDE ain’t much use for.
If your setters are doing that much stuff you are doing it wrong.
No, that’s actually one of the main reasons to use a setter.
Yes, better file a bug, 'cause there’s loads of classes in the JDK doing all those things!
In fact, firing events and validating values are kind of a key part of the JavaBean standard - see PropertyChangeListener, VetoableChangeListener, etc.
JFTR, it’s not that I’m a great fan of the JavaBeans getter / setter pattern - I prefer fluent interfaces - but just using public fields unless we’re talking proper value objects … yuck!
I have to agree with HeroesGraveDev, if you don’t ever validate info passed to your setter then your’re doing it wrong. You can’t expect every user to pass valid info all the time…and setting a variable could very well require doing other work.
I think this conversation is interesting and I meant to jump in sooner. The real problem that I see with traditional getters / setters is that they become awfully fragile across module boundaries in terms of code changes (3rd party library for instance). Architecturally speaking they are a horrible way to retrieve various resources from a main model or control (re: say a custom Activity in Android). Dependency Injection is a partial solution, but still pretty weak IMHO (especially constructor injection!) and has inherent maintenance concerns too.
Yes yes… Component architectures with implicit lookup comes to the rescue IMHO. This is one of the super strong points of this approach such that across module boundaries lookups are implicit and don’t require specialized getter / setter methods to connect everything together at runtime. It’s great too because the component architecture API itself is super standardized across all modules that use it and dependencies aren’t leaked between module boundaries (exposed in traditional getter / setter method signatures). JGO will hate me for this, but I’ll get buzz wordy and say it’s essentially “In-process microservices”.
Going beyond implicit lookup is the EventBus pattern (not Guava / Otto, etc.). At least my EventBus implementation allows setting up adhoc message passing between producer / consumer relationships and one can setup two way messaging (input / output ports). This allows passing messages across module boundaries that otherwise would be method invocations. For instance in my video engine efforts I have a camera manager. When I want to start a video stream for the camera. I send a “start video” message to the input port defined by a series of extensible enums that define a nested category indicating some sort of camera manager is receiving the message. And then camera frame received messages start streaming over the output port.
I could go on in this direction, but in the past JGO has been overly critical for little reason on the directions I’ve taken even though they solve a lot of problems with traditional OOP; especially the getter / setter debacle.
That exactly what the majority of getter/setters you see in the wild exactly do.