Discussions
Categories
- 197K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.8K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 556 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.4K SQL Developer
- 296.3K Development
- 17 Developer Projects
- 139 Programming Languages
- 293K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 158 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 205 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 468 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
Implicit Getters and Setters

I was wondering why Java forces us to bother with the code clutter of explicit getters and setters, when a compiler modification could add them as needed to each class property in compliance with their access modifiers.
For example, we could have something like this:
public class State { public int property; } public class ExtendedState extends State { private int counter = 0; public int getProperty() { return property + ++counter; } } public class Client { public void doStuff() { State state = new State(); state.setProperty(5); // implicit setter int stateValue = state.getProperty(); // implicit getter returns stateValue == 5 State extendedState = new ExtendedState(); extendedState.setProperty(5); stateValue = extendedState.getProperty(); // getter override returns == 6 } }
I'm thinking that there must be some good reason why this hasn't been implemented by now, but I can't think of one. No modification to the JVM would be required, so previously-compiled bytecode will still work. The set of code that will compile under this new specification is fully contained in the set of code that won't, so no issues exist with compiling legacy code. If someone has put a getter or setter on the class that is named as if it involves a property, but does something unrelated to it, the compiler will respect that and not overwrite what is specified in the code. Since the access modifiers of the getters and setters correspond to the access modifiers of the underlying properties, data encapsulation would be maintained. If for some reason, people object to it, it could even be implemented as an optional feature that is invoked with a compiler switch. There must be something I'm not thinking of here.
I looked into taking this question to the JCP, but it became immediately apparent that I'm not supposed to be wasting their time with half-baked ideas and intermediate-level questions, so I thought I was try here first.
Best Answer
-
You may have a look at Lombok. https://projectlombok.org/
Lombok supports adding Getter/Setters but also supports other patterns replated to constructors, builders or implicit toString().
Answers
-
Say hello to Delphi - which had a very simplistic but elegant property statement with a read and write clause to either a private variable or method. Over 20 years ago.
So no, your requirement is not unusual - or new.
-
You may have a look at Lombok. https://projectlombok.org/
Lombok supports adding Getter/Setters but also supports other patterns replated to constructors, builders or implicit toString().
-
I misspoke. I meant to say that the set of code that compiles under the existing specification is fully contained in the set of code that will compile under the specification described here.
-
I looked Lombok over, and it looks really cool. I'll give it a try. I suppose once it has become a standard part of everyone's development environment, Oracle will make it officially a part of the standard.