We Keep Coding

Is it a good practice to pass object as a paramater than separate variables to a function?

Is it a good practice to pass object as a paramater than separate variable. I have a class below. Instead of passing separate paramaters to calc function, is it a good practice to create an object say CalcFields and store z,l,y, product,user and code in it and pass that object to calc function. My concern is this list of paramters may grow in future, say 5 more fields need to be passed
Class ABC{
private test(Order o){
String z = //some logic to evaluate z
String y = // some logic to evaluate y
int p = calc(z, y, o.getProduct(), o.getUser(), o.getCode())
}
}
Class Calculate{
public int calc(String a, String b, Product a, User b, String d){
..........
}
}

Answer to your question is yes, especially in Java where the only way to provide a parameter by reference is by using an object and calling its methods.
Parameter by reference means the function may change the value of the variable outside the scope of the called function. If you're not using an object, those parameters are always sent by value, meaning that only a copy of the value is sent to the function/method and the variable used in the function call will not change.
image source
Both are important in programming, it just depends on what your function is supposed to do.
Moreover, using an object as an argument in a function call encapsulates the data that is related together anyways.
That said, a good class design will avoid grouping objects too deeply (the screw in the piston of the engine that is in the car in a warehouse might not be relevant to a car seller's inventory application). Prefer the bare minimum, but don't be afraid to make an object hold an other one either. Perfect balance does not exist, but imbalance does­. This is not a problem in your case, just something to keep that in mind. The final goal being to write as little readable code as possible
A problem I see in your design though is that you are breaking the object to manipulate the data outside it. Hold the urge to break an object inside an other object and prefer declaring a method inside the first object to call it from the second.
In you example, it would be preferable to call calc directly from the order object and add parameters as needed.
Class ABC{
private test(Order o){
String z = //some logic to evaluate z
String y = // some logic to evaluate y
int p = o.calc(z, y)
}
}
Class Order {
public int calc(String a, String b){
//Product, User and your code are already stored in this object anyways
}
}

Depends, if you would only call your function like this: calc(z, y, o.getProduct(), o.getUser(), o.getCode()), then there is no point having 5 paramters and you should just use 3 parameters and pass the entire o object.
On the other hand, if you would want to pass different arguments as well, for example calc(z, y, o.getProduct(), o.getUser(), "anotherString"), the best practice is to have methods like this:
public int calc(String a, String b, ABC c) {
return this.calc(a, b, c.getProduct(), c.getUser(), c.getCode());
}
public int calc(String a, String b, Product a, User b, String d) {
//do the calculation here
}
The first function offers the convinience of passing only 1 parameter, while the second function offers the flexibility of passing different parameters.

Passing and setting booleans - Java/Android

I have a class like so:
public class Achievements(){
boolean score100_Earned_Offline;
boolean score1000_Earned_Offline;
final String score100 = "xxxxxxxxxx" //where xxxxxxxxxx would be replaced with the achievement's Google Play Games ID
final String score1000 = "xxxxxxxxxx" //where xxxxxxxxxx would be replaced with the achievement's Google Play Games ID
}
In my Game class, I check the state of the achievements every tick and act on them as necessary like so (assume all methods to be valid and defined - this is cut down to provide the code necessary to the question).......
public class Game(){
public void checkAchievements(Achievements achievements){
if (score>=100){
unlockAchievement(achievements.score100, achievements.score100_Earned_Offline);
}
if (score>1000){
unlockAchievement(achievements.score100, achievements.score1000_Earned_Offline);
}
}
public void unlockAchievement(String achievementToUnlock, boolean thisAchievementOfflineFlag){
//If user is signed in, then we are ready to go, so go ahead and unlock the relevant achievement....
if (checkSignedIn()){
Games.Achievements.unlock(getApiClient(), achievementToUnlock);
//Otherwise, I want to do is set the relevant flag to true so it can be checked when the user does eventually log in
else{
thisAchievementOfflineFlag=true;
}
}
}
Pass by value
In the 'unlockAchievement' method, the boolean 'thisAchievementOfflineFlag' does get set to true if the user is not logged in, however, it doesn't effect the actual boolean that was originally sent into the method (which as you can see is defined in my 'Achievements' class). I'm guessing this is because Java is Pass by Value and is therefore, creating a local copy of the variable which is valid inside the method only. I did try using Boolean too (wrapper class) but got the same results.
Other ways to achieve this?
I've currently got it set up so I can define each achievement as an enum so each one will have it's own copy of the boolean flag. However, I'm aware that it's not recommended to use enums in Android so if there is a better way that I am missing, I would rather avoid them.
Please note that I don't want to use if checks or switch statements as this is taking place in a game-loop.
Any suggestions appreciated

This is all because Java's implementation of Boolean (also, for example String) is immutable for safety reasons. You can see it here: http://www.explain-java.com/is-string-mutable-in-java-why-wrapper-classes-immutable-in-java/
You can solve your problem by introducing an object wrapper for that boolean:
public class BooleanWrapper {
private boolean value;
public void set(boolean value) {
this.value = value;
}
public boolean get() {
return value;
}
}
Now, this object reference will be passed by value but will still point to the same BooleanWrapper object on the heap. You can simply use getters and setters to change the inner boolean value.
Then your code would become:
public void unlockAchievement(String achievementToUnlock, BooleanWrapper thisAchievementOfflineFlag){
if (checkSignedIn()){
Games.Achievements.unlock(getApiClient(), achievementToUnlock);
else {
thisAchievementOfflineFlag.set(true);
}
}
Java is pass-by-value:
When you pass boolean then you for sure passed it by value, while it is a primitive type. When you pass Boolean, you would think it's an object and that you can change it's state, but actually you cannot because Boolean is implemented as an immutable object (as already said). You can confirm this just by reading the code of java.lang.Boolean.
But if you create your own wrapper class, and in a sense, you control whether you implement it in immutable or mutable way. BooleanWrapper I wrote lets you change the state of that object. And when you pass an object such as this one to the method, it's passed by value. That means that another reference is created, but it points to the same object on heap (see image below).

You could use an AtomicBoolean, which will have pass-by-reference semantics.

What's the point of get and set methods [duplicate]

This question already has answers here:
Set and Get Methods in java?
(16 answers)
Closed 8 years ago.
In my CS class I am just learning about classes and OOP.
So when you create a class you initialize a certain number of private variable.
I know you make them private because if they were public they would be easily changeable and could lead to a lot of bugs.
So we use get and set methods to change the variable. But that once again makes the variables very easy to change right? So whats the point of making them private in the first place?

Some benefits of using getters and setters (known as encapsulation or data-hiding):
1. The fields of a class can be made read-only (by only providing the getter) or write-only (by only providing the setter). This gives the class a total control of who gets to access/modify its fields.
Example:
class EncapsulationExample {
private int readOnly = -1; // this value can only be read, not altered
private int writeOnly = 0; // this value can only be changed, not viewed
public int getReadOnly() {
return readOnly;
}
public int setWriteOnly(int w) {
writeOnly = w;
}
}
2. The users of a class do not need to know how the class actually stores the data. This means data is separated and exists independently from the users thus allowing the code to be more easily modified and maintained. This allows the maintainers to make frequent changes like bug fixes, design and performance enhancements, all while not impacting users.
Furthermore, encapsulated resources are uniformly accessible to each user and have identical behavior independent of the user since this behavior is internally defined in the class.
Example (getting a value):
class EncapsulationExample {
private int value;
public int getValue() {
return value; // return the value
}
}
Now what if I wanted to return twice the value instead? I can just alter my getter and all the code that is using my example doesn't need to change and will get twice the value:
class EncapsulationExample {
private int value;
public int getValue() {
return value*2; // return twice the value
}
}
3. Makes the code cleaner, more readable and easier to comprehend.
Here is an example:
No encapsulation:
class Box {
int widthS; // width of the side
int widthT; // width of the top
// other stuff
}
// ...
Box b = new Box();
int w1 = b.widthS; // Hm... what is widthS again?
int w2 = b.widthT; // Don't mistake the names. I should make sure I use the proper variable here!
With encapsulation:
class Box {
private int widthS; // width of the side
private int widthT; // width of the top
public int getSideWidth() {
return widthS;
}
public int getTopWIdth() {
return widthT;
}
// other stuff
}
// ...
Box b = new Box();
int w1 = b.getSideWidth(); // Ok, this one gives me the width of the side
int w2 = b.getTopWidth(); // and this one gives me the width of the top. No confusion, whew!
Look how much more control you have on which information you are getting and how much clearer this is in the second example. Mind you, this example is trivial and in real-life the classes you would be dealing with a lot of resources being accessed by many different components. Thus, encapsulating the resources makes it clearer which ones we are accessing and in what way (getting or setting).
Here is good SO thread on this topic.
Here is good read on data encapsulation.

As the above comment states, getters and setters encapsulate (i.e. hide) inner details of your class. Thus other classes that interact with yours, do not need to know about the implementation details.
For example, in the simple case you describe, instance variables are exposed via getters and setters. But what if you wanted to change your class so that you no longer used instance variables, but rather you persisted the values to disk. You could make this change to your class without affecting the users of your class.
Keep in mind also that getters and setters need not always be provided. If you do not want your class to provide a way to set or read these properties, then don't. Simply make them private.

get is used to obtain a value for an attribute and set is used to put a value to an attribute
ex:
private int variable;
public int getVariable(){
return variable;
}
public void setVariable(int aux){
variable=aux;
}
In general, is used to encapsulate an attribute.
reference:
Set and Get Methods in java?

Encapsulation or data hiding gives u more control on what values can be set to a field. Here is an example if you don't want a class attribute to have a negative value:
class WithoutGetterSetter {
public int age;
}
class WithGetterSetter {
private int age;
public setAge(int age) {
if(age < 0)
// don't set the value
else
this.age = age;
}
}
public class testEncapslation {
public static void main(String args[]) {
WithoutGetterSetter withoutGetterSetter = new WithoutGetterSetter();
withoutGetterSetter.age = -5;
WithGetterSetter withGetterSetter = new WithGetterSetter();
withGetterSetter.setAge(-5);
}
}

Get and Set methods are preferable to "public" variables because they insulate the users of a class from internal changes.
Supposing you have a variable "StockQty" and you made it public because that seemed like the easiest thing to do.
Later on you get a user requirement to track the history of stock over time. You now need to implement a SetStockQty() method so you can save the old quantity somewhere before setting the new quantity.
Now all the users of your class have to change there code, re-document and re-test.
If you had SetStockQty() method to begin with only you would need to change and test your code.
The second reason is you can have Getters without Setters effectivly making the variable "read only".

Traditionally, they are justified in terms of encapsulation. By providing moderated access to read and write the fields of a class, we supposedly reduce coupling.
In simpler language: by controlling the ways in which other classes can read and change our data, we reduce the ways in which our class's data can change. This means that the connections between classes are reduced, which reduces complexity.
However, the same logic says that getters and setters should generally be avoided unless there's an actual need for them, and there very seldom is such a need. For the most part, a class should "tend to its own knitting" - if there's a calculation to be done on this class's data, it should do it. If a value should be changed, it should do the changing.
For example, consider an object in space. It has a location specified as (x,y,z). We could possibly allow other classes to just set those arbitrarily - this would be horrible, obviously, but it's not obvious that a setter for these would be any better. What you really want is a constructor to set an initial position, and then methods to influence that position - for example, to register an impact or an acceleration. Then you're doing OO programming.

One word, Encapsulation.setters also allow you to control how values are entered into your program. Many new programmers like myself are often confused by this concept. I strongly advice you read this SO question

Being objective: it's all about best pratices!!!
1) IF necessary, expose your attributes with get methods.
2) IF necessary, allow attribute modification (state modification) using set methods;
Have both public get and set methods without treatment is the same as have the attributes public.

Understanding classes and variables in java [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am new to Java and this was a example I found in the book I am reading.There are several things I do not understand in this code.Please help me to understand it.
/*
* CalculatorModel
* Encapsilates the data model used by the calculator Application
*/
public class CalculatorModel{
private double operand1;
private double operand2;
public void setOperand1(double value){
operand1=value;
}
public void setOperand2(double value){
operand2=value;
}
public double getOperand1(){
return operand1;
}
public double getOperand2(){
return operand2;
}
public String toString(){
String s = "operand 1=" + operand1 + "operand 2=" + operand2;
return s;
}
}
/*
* CalculatorHelper
* A class that performs mathematical functions for a calculator program
*/
public class CalculatorHelper{
private CalculatorModel calcModel;
public CalculatorHelper(){
calcModel=new CalculatorModel();
}
public void setOperand1(double value){
calcModel.setOperand1(value);
}
public void setOperand2(double value){
calcModel.setOperand2(value);
}
public double add(){
return calcModel.getOperand1()+calcModel.getOperand2();
}
public double subtract(){
return calcModel.getOperand1()-calcModel.getOperand2();
}
public double multiply(){
return calcModel.getOperand1()*calcModel.getOperand2();
}
public double divide(){
return calcModel.getOperand1()/calcModel.getOperand2();
}
}
Please help me to understand what is done by
private CalculatorModel calcModel;
public CalculatorHelper(){
calcModel=new CalculatorModel();
}
in the calculatorHelper class. Is calcModel a variable a variable of type CalculatorModel? What is the difference of having a object as a data type than a primitive data type to a variable?
If calcModel is a variable what is done by the line calcModel=new CalculatorModel();
I don't understand why it is important to have two classes as CalculatorModel and CalculatorHelper.
What is done with the method
public void setOperand1(double value){
calcModel.setOperand1(value);
}
in the helper class as there's already a setmethod in CalculatorModel class.
This is what I tried and what's wrong with this code?
public class Calculator{
private double num1,num2;
public void setValue1(double value1){
num1=value1;
}
public void setValue2(double value2){
num2=value2;
}
public double getValue1(){
return num1;
}
public double getValue2(){
return num2;
}
public double add(){
return getValue1()+getValue2();
}
public double subtract(){
return getValue1()-getValue2();
}
public double multiply(){
return getValue1()*getValue2();
}
public double divide(){
return getValue1()/getValue2();
}
}

"What is the difference of having a object as a data type than a primitive data type to a variable?"
Programming is all about data. Classes you can consider as complex data, and primitives as simple data. Say you have a class School
public class School {
}
What does school have? It has students. You can't represent a student with an of primitive types, because it just doesn't make sense for a student to be a double, int boolean, etc. So a student is another complex data type, like a school. So in order for the student to be represented as data contained by the school, you need a Student class also, which can hold the student's name, address and such
public class Student{
String firstName;
String lastName;
String address;
int age;
So to fully represent the student being in the school you use the has-a relationship, where School has-a Student
public class School {
Student student;
}
To delve even deeper, does a school only have one student? No, it should have many students. So you would represent that as a School having an array of Students
public class School {
Student[] students;
}
So in terms of data, you have a data tree like this now
School
Student
firstName
lastName
address
age
Student
firstName
lastName
address
age
This is the basic idea behind Object Oriented Programming. It's a lot easier to comprehend when you look at objects as actual physical objects. It makes it easier to understand the relationships.

Yes, your assumption that calcModel is a variable object of type CalculatorModel is right. when you say calcModel = new CalcModel(); it is actually creating another object in memory for storing the data that is to be stored(both operands) and storing the address of that object in calcModel. This way you can refer to object you created earlier. If you have worked with c earlier you can easily say calcModel is a pointer where as the object created is the data in the address located in the pointer.
The difference between a primitive type variable and object type variable is that the actual data that is to be stored in the variable is much more complex. For example the class CalculatorModel is a combination of two doubles... You can carry both operands as one entity by combining them(encapsulating) in a class. An object may also contain methods that can do some operations on the data stored in its member variables.
It is not necessary to have two classes, some people like it that way. I'm positively sure there is no need to create two classes in this case. Both can be merged as you have obviously did. Mind you there are no right and wrong ways to code, some ways of doing it are more preferable because they are more popular and avoids readability issues in long run. setOperand1() method is just using calcModel.setOperand1() so I don't see a necessity to have it done that way, calcModel.setOperand1 can be called directly from where ever setOperand1() is called. However, there can be case where you want to hide which function of setOperand1 is to be called or some complex operations are to be performed before calling calcModel.setOperand1. In such cases where you want to reduce burden for the callers of calcModel.setOperand1 by created setOperand1().
There is nothing wrong with the code. However you don't have to use getValue1() & getValue2() function in your add, subtract and other mathematical operations. you can simply say return num1+num2 Because, num1 & num2 are member variables of the same class.

private CalculatorModel calcModel;
public CalculatorHelper(){
calcModel=new CalculatorModel();
}
in the calculatorHelper class. Is calcModel a variable a variable of
type CalculatorModel ?What is the difference of having a object as a
data type than a primitive data type to a variable? If calcModel is a
variable what is done by the line calcModel=new CalculatorModel();
The variable calcModel is an instance of CalculatorModel, but is a class variable to the class CalculatorHelper. If you want to know about primitive data type vs object data type, check this article out. This line calcModel=new CalculatorModel(); is initializing the variable. You must do this in order to actually use the methods. Read more here.
I don't understand why it is important to have two classes as
CalculatorModel and CalculatorHelper.
There are cases where helper classes/methods are useful when it comes to separating large chunks of logic. Check this article out.
public void setOperand1(double value){
calcModel.setOperand1(value);
}
in the helper class as there's already a setmethod in CalculatorModel
class.
Yes, and it's calling that same exact set method but from the CalculatorHelper class.
This is what I tried and what's wrong with this code?
There seems to be nothing wrong with the code. I'm assuming you're using it properly from the main method (or whatever method you're using the class in).

This is essentially a Delegate Pattern by which the author has implemented the Calculator.
The Calculator serves the abstraction of the real-life Calculator.
By providing the helper/delegate class , I separate the behavior of the object.I am free to write my own implementation of add / subtract using a helper class. Calculator will serve as the Model of your calculations.
Consider this , If you try to modify the behavior you need to change the whole Calculator class and distribute it to the Client. However , I don't have to modify the Calculator but only the Helper which the client does/might not ship.
There is nothing wrong in what you have done - but consider this - what if you want to have Single instance of the Calculator - you can control instantion using helper class (in this case)

private CalculatorModel calcModel;
public CalculatorHelper(){
calcModel=new CalculatorModel();
}
is composition which is used here to separate concerns. The CalculatorHelper's concern is to know how to do addition, substraction, .. while the CalculatorModel knows the values, how to provide them to the outside and how to store them.
CalculatorHelperhas therefore an instance ofCalculatorModel` to which it can delegate all the things it does not know about. E.g.
public void setOperand1(double value){
calcModel.setOperand1(value);
}
The overall design is still questionable. First of all is it a bad encapsulation of a "calculator" because none of math operation reflect back to the model in any way. There needs to be a third class (CalculatorHelperHelper?) that knows how to deal with more than two operands.
It is also questionable whether or not a CalculatorModel should have two values at once. Two separate value objects would IMO make a lot more sense and would result in more modular code that would also be easier to understand as composition of objects.
The last point in this example is that encapsulating "storage" of values into CalculatorModel does not provide any real benefit here. It would if there was some kind of database backend or otherwise "complicated" logic that does not belong into CalculatorHelper. I would have taken more or less your approach in a simple real world scenario. Your code is not wrong. It's just a different approach.
The code in the context of the book and given that it is an example to show some design techniques is ok for that purpose. I would just do it very much different if I was to write a calculator. OO design is on the other hand not right or wrong and people can argue a lot about what good design is.

(no) Properties in Java?

So, I have willfully kept myself a Java n00b until recently, and my first real exposure brought about a minor shock: Java does not have C# style properties!
Ok, I can live with that. However, I can also swear that I have seen property getter/setter code in Java in one codebase, but I cannot remember where. How was that achieved? Is there a language extension for that? Is it related to NetBeans or something?

There is a "standard" pattern for getters and setters in Java, called Bean properties. Basically any method starting with get, taking no arguments and returning a value, is a property getter for a property named as the rest of the method name (with a lowercased start letter). Likewise set creates a setter of a void method with a single argument.
For example:
// Getter for "awesomeString"
public String getAwesomeString() {
return awesomeString;
}
// Setter for "awesomeString"
public void setAwesomeString( String awesomeString ) {
this.awesomeString = awesomeString;
}
Most Java IDEs will generate these methods for you if you ask them (in Eclipse it's as simple as moving the cursor to a field and hitting Ctrl-1, then selecting the option from the list).
For what it's worth, for readability you can actually use is and has in place of get for boolean-type properties too, as in:
public boolean isAwesome();
public boolean hasAwesomeStuff();

I am surprised that no one mentioned project lombok
Yes, currently there are no properties in java. There are some other missing features as well.
But luckily we have project lombok that is trying to improve the situation. It is also getting more and more popular every day.
So, if you're using lombok:
#Getter #Setter int awesomeInteger = 5;
This code is going to generate getAwesomeInteger and setAwesomeInteger as well. So it is quite similar to C# auto-implemented properties.
You can get more info about lombok getters and setters here.
You should definitely check out other features as well.
My favorites are:
val
NoArgsConstructor, RequiredArgsConstructor, AllArgsConstructor
Logs!
Lombok is well-integrated with IDEs, so it is going to show generated methods like if they existed (suggestions, class contents, go to declaration and refactoring).
The only problem with lombok is that other programmers might not know about it. You can always delombok the code but that is rather a workaround than a solution.

"Java Property Support" was proposed for Java 7, but did not make it into the language.
See http://tech.puredanger.com/java7#property for more links and info, if interested.

The bean convention is to write code like this:
private int foo;
public int getFoo() {
return foo;
}
public void setFoo(int newFoo) {
foo = newFoo;
}
In some of the other languages on the JVM, e.g., Groovy, you get overridable properties similar to C#, e.g.,
int foo
which is accessed with a simple .foo and leverages default getFoo and setFoo implementations that you can override as necessary.

public class Animal {
#Getter #Setter private String name;
#Getter #Setter private String gender;
#Getter #Setter private String species;
}
This is something like C# properties. It's http://projectlombok.org/

You may not need for "get" and "set" prefixes, to make it look more like properties, you may do it like this:
public class Person {
private String firstName = "";
private Integer age = 0;
public String firstName() { return firstName; } // getter
public void firstName(String val) { firstName = val; } // setter
public Integer age() { return age; } // getter
public void age(Integer val) { age = val; } //setter
public static void main(String[] args) {
Person p = new Person();
//set
p.firstName("Lemuel");
p.age(40);
//get
System.out.println(String.format("I'm %s, %d yearsold",
p.firstName(),
p.age());
}
}

Most IDEs for Java will automatically generate getter and setter code for you if you want them to. There are a number of different conventions, and an IDE like Eclipse will allow you to choose which one you want to use, and even let you define your own.
Eclipse even includes automated refactoring that will allow you to wrap a property up in a getter and setter and it will modify all the code that accesses the property directly, to make it use the getter and/or setter.
Of course, Eclipse can only modify code that it knows about - any external dependencies you have could be broken by such a refactoring.

My Java experience is not that high either, so anyone feel free to correct me. But AFAIK, the general convention is to write two methods like so:
public string getMyString() {
// return it here
}
public void setMyString(string myString) {
// set it here
}

From Jeffrey Richter's book CLR via C#: (I think these might be the reasons why properties are still not added in JAVA)
A property method may throw an exception; field access never throws an exception.
A property cannot be passed as an out or ref parameter to a method; a field can.
A property method can take a long time to execute; field access always completes
immediately. A common reason to use properties is to perform thread synchronization,
which can stop the thread forever, and therefore, a property should not be
used if thread synchronization is required. In that situation, a method is preferred.
Also, if your class can be accessed remotely (for example, your class is derived from
System.MarshalByRefObject), calling the property method will be very slow, and
therefore, a method is preferred to a property. In my opinion, classes derived from
MarshalByRefObject should never use properties.
If called multiple times in a row, a property method may return a different value each
time; a field returns the same value each time. The System.DateTime class has a readonly
Now property that returns the current date and time. Each time you query this
property, it will return a different value. This is a mistake, and Microsoft wishes that
they could fix the class by making Now a method instead of a property. Environment’s
TickCount property is another example of this mistake.
A property method may cause observable side effects; field access never does. In other
words, a user of a type should be able to set various properties defined by a type in
any order he or she chooses without noticing any different behavior in the type.
A property method may require additional memory or return a reference to something
that is not actually part of the object’s state, so modifying the returned object has no
effect on the original object; querying a field always returns a reference to an object
that is guaranteed to be part of the original object’s state. Working with a property
that returns a copy can be very confusing to developers, and this characteristic is frequently
not documented.

If you're using eclipse then it has the capabilities to auto generate the getter and setter method for the internal attributes, it can be a usefull and timesaving tool.

I'm just releasing Java 5/6 annotations and an annotation processor to help this.
Check out http://code.google.com/p/javadude/wiki/Annotations
The documentation is a bit light right now, but the quickref should get the idea across.
Basically it generates a superclass with the getters/setters (and many other code generation options).
A sample class might look like
#Bean(properties = {
#Property(name="name", bound=true),
#Property(name="age,type=int.class)
})
public class Person extends PersonGen {
}
There are many more samples available, and there are no runtime dependencies in the generated code.
Send me an email if you try it out and find it useful!
-- Scott

There is no property keyword in java (like you could find it in C#) the nearest way to have 1 word getter/setter is to do like in C++:
public class MyClass
{
private int aMyAttribute;
public MyClass()
{
this.aMyAttribute = 0;
}
public void mMyAttribute(int pMyAttributeParameter)
{
this.aMyAttribute = pMyAttributeParameter;
}
public int mMyAttribute()
{
return this.aMyAttribute;
}
}
//usage :
int vIndex = 1;
MyClass vClass = new MyClass();
vClass.mMyAttribute(vIndex);
vIndex = 0;
vIndex = vClass.mMyAttribute();
// vIndex == 1

As previously mentioned for eclipse, integrated development environment (IDE) often can create accessor methods automatically.
You can also do it using NetBeans.
To create accessor methods for your class, open a class file, then Right-click anywhere in the source code editor and choose the menu command Refactor, Encapsulate Fields.
A dialog opens. Click Select All, then click Refactor.
Voilà,
Good luck,

For me the problem is two fold:
All these extra methods {get*/set*} cluttering up the class code.
NOT being able to treat them like properties:
public class Test {
private String _testField;
public String testProperty {
get {
return _testField;
}
set {
_testField = value;
}
}
}
public class TestUser {
private Test test;
public TestUser() {
test = new Test();
test.testProperty = "Just something to store";
System.out.printLn(test.testProperty);
}
}
This is the sort of easy assignment I would like to get back to using. NOT having to use 'method' calling syntax. Can anyone provide some answers as to what happened to Java?
I think that the issue is also about the unnecessary clutter in the code, and not the 'difficulty' of creating the setters/getters. I consider them as ugly-code. I like what C# has. I don't understand the resistance to adding that capability to Java.
My current solution is to use 'public' members when protection is not required:
public class IntReturn {
public int val;
}
public class StringReturn {
public String val;
}
These would be used to return value from say a Lambda:
StringReturn sRtn = new StringReturn()
if(add(2, 3, sRtn)){
System.out.println("Value greater than zero");
}
public boolean add(final int a, final int b, final StringReturn sRtn){
int rtn = a + b;
sRtn.val = "" + rtn;
return rtn > 0; // Just something to use the return for.
}
I also really don't like using a method call to set or get an internal value from a class.
If your information is being transferred as 'immutable', then the new Java record could be a solution. However, it still uses the setter/getter methodology, just without the set/get prefixes.