int vs Integer vs a user made class to achieve effective pass by reference behavior in Java

Question

Let's say you have a class of object with three integer fields that you want to possibly change, all in the same way, with one method.

Let's keep it simple and say all that the method does is add 1 to the parameter passed to it.

That is to say, the desired behavior is that by the time the method has completed, the relevant field has increased by 1.

This is impossible to achieve in Java using the primitive type "int" for those fields.
I know about how Java is "always" pass by value, and not pass by reference, - and - i've heard whisperings on the internet that this is one reason that the Integer class exists, along with other object "wrapper" classes for ordinarily primitive types such as int and double.

Sending an object as an argument to a method should, in theory, provide a way to [effectively, if not technically] pass by reference, since the value that is passed, is supposedly the value of the reference to the object. Very tricky. BUT - and this is where my annoyance comes in - I've tried achieving this very simple task by passing an Integer argument instead of an int, and the desired behavior was still not accomplished. 1 was not added to the relevant field.

And yet, when I made my very own object, which consisted of just one field, an int value, and passed an instance of this object as an argument to an appropriate method which would simply add 1 to the passed parameter, the desired behavior was in fact accomplished. 1 was added to the relevant field.

So the questions orbiting around this query are - Is it really going to be necessary to craft my own homemade class just to carry a simple integer value every time I want to achieve this desired behavior? Can the existing tool provided by Java, Integer, really not perform this simple task?

Instead of having one nice, neat method to handle all three of the hypothetical integer fields i mentioned in the beginning, I felt compelled (in a separate, similar project that ultimately provoked this line of thinking) to make a separate method corresponding to each of the three fields, with essentially the same exact code in each one. This seems very inefficient.

It may not seem like a big deal, on the surface, to write three similar methods instead of one, but to clarify why this dismays me - imagine instead of an object with three integer fields as I stated, there are say, i don't know, four thousand. It would be so much better to write just one thing to perform the same kind of behavior, instead of copying and pasting (and changing whatever little bits necessary) four thousand times.

So I suppose the ultimate question is, Why doesn't Integer function in a reasonable way? What's the point of wrapping a primitive in an Object at all, if it doesn't even help perform something this simple? Am I missing something simple about how to get Integer to function in the desired way? (Hopefully so) The answer seems close yet infuriatingly out of reach since "RInteger" produces the desired behavior, yet "Integer" doesn't.

The entire source code I used while trying to figure out how to construct this painstaking question is below.

package r9mp;

import javax.swing.SwingUtilities;

public class RefTest2 {
//[main m]
public static void main(String[] args){
    SwingUtilities.invokeLater(new Runnable(){
        public void run(){
            new RefTest2();
        }
    });
}
//[fields]
int i;
Integer I;
RInteger RI;

//[constr]
public RefTest2(){
    intTest();
    IntegerTest();
    RIntegerTest();

    display();
}

//[methods]
private void intTest(){
    i = 100;
    intMethod(i);
}
private void IntegerTest(){
    I = 100;  //boxing? auto?
    IntegerMethod(I);
    I = 100; //just in case.
    IntegerMethod2(I);
}
private void RIntegerTest(){
    RI = new RInteger(100);
    RIntegerMethod(RI);
}

private void intMethod(int ipar){
    ipar = ipar + 1;//no change. expected.
}
private void IntegerMethod(Integer IPar){
    IPar = IPar + 1;//no change. frustrating.
    pln("From inside IntegerMethod: IPar = " + IPar );
    pln("From inside IntegerMethod: I = " + I );
}
private void IntegerMethod2(Integer IPar){
    IPar = new Integer(IPar+1);//still no change.  there are no set methods for Integer, or I'd try them.
}
private void RIntegerMethod(RInteger riPar){
    riPar.value = riPar.value + 1;
}

private void display(){
    pln(
            "Display...    \n" +
            "i: "  + i  + "\n" +
            "I: "  + I  + "\n" +
            "RI: " + RI + "\n" +
            "--------"
            );
}

private void pln(){
    pln("");
}
private void pln(String s){
    System.out.println(s);
}

//[internal class]
private class RInteger{
    int value;
    public RInteger(int v){
        value = v;
    }
    public String toString(){
        return ""+value;

    }
}

}

And, here is the output...

Answer 1

First of all, you need to read up on immutability to find out why it is a very good thing to have. There even exist entire languages (functional, mostly) that capitalize on it.

Once you have read about that, then read Eric Lippert's series of articles on immutability. Start here: https://blogs.msdn.microsoft.com/ericlippert/2007/11/13/immutability-in-c-part-one-kinds-of-immutability/ Mind = blown.

But to give you a quick hint as to why primitive wrappers like Integer are immutable, let me just say that these classes are often used as keys in Hash Maps, and a key must be immutable, so that its hashCode will never change, otherwise the hash map will fail with very difficult to track down behaviour. Mutable keys in hashmaps are nasty bugs.

You can achieve what you want with a class of your own devise which plays the role of a reference, or by simply passing an array and modifying the element at array[0].

My personal preferences are as follows:

• I would try to do as much as possible with return values.
• When return values are inapplicable, (as the case is with invokeLater,) then inner/nested/anonymous classes that have access to the fields of the enclosing class are my next preference.
• When that's not an option either, then special classes crafted precisely for the application at hand are my next option. (MyMutableNumberWrapper.)
• And when I just want something quick and dirty, then general-purpose classes like Ref<T> (or even single-element arrays) would be my final option.

Answer 2

How about one method for primitives and their wrappers?

private int incInteger(int value)
{
    return value + 1;       
}

and call for it:

int intVal = 100;
intVal = incInteger(intVal);

Integer integerVal = 200;
integerVal = incInteger(integerVal);