только взял боец гитару — сразу видно гармонист.

There are good reasons that Java excluded the idea of pass-by-reference from its language design, and when writing Java applications it's best to do as Java does. There are elegant solutions to all common problems that may be solved with pass-by-reference in other languages. Before I get there, though, let's look at some of the problems of pass by reference.

Pass by reference mixes inputs and outputs of code. This is the fundamental problem with the technique. In Java, a programmer can assume that variables will not change their value when passed as parameters to a method. In languages with pass by reference semantics, this basic assumption cannot be made.

Pass by reference confuses the interface to a method. Methods written using pass-by-reference semantics can have extremely complex interfaces that are difficult for client programmers to learn and understand. That said, you may be left with a situation where you feel the need to use pass-by-reference in an application. There are two major reasons to use pass by reference, and each has its own solution:

First, pass by reference is used in many languages to reduce the costs of a method call, preventing the copying of large amounts of data. This is a non-issue in Java. The problem is solved by simply realizing that in Java, the values passed to a method are either primitive data or object references, which cannot be large enough to make this a real issue. Objects themselves can be very large, but are never passed to methods.

Second, pass by reference allows the variable to be changed, and the changed value can be seen in client code. The solution here is to refactor the application to use the return value for this purpose. If a parameter is an "in-out" parameter, then its original value should be passed into the method and its result moved to the return value.

Object a = new Object;
Object b = new Object;
// вместо Swap(ref a, ref b)
Object temp = a;
a = b;
b = temp;

package ru.rsdn.test;

public class Searcher {
    private int min;

    private int max;

    private int[] array;

    public Searcher(int[] _array) {
        array = _array;
    }

    public void eval() {
        for (int i = 0; i < array.length; i++) {
            if (min > array[i])
                min = array[i];
            if (max < array[i])
                max = array[i];
        }
    }

    public int getMax() {
        return max;
    }

    public int getMin() {
        return min;
    }
}

package ru.rsdn.test;

public class Test {
    public static void main(String[] args) {
        int[] a = { 2, 1, 5, 1, -1 };
        Searcher searcher = new Searcher(a);
        searcher.eval();
        System.out.println("min = " + searcher.getMin());
        System.out.println("max = " + searcher.getMax());
    }
}

public class Holder<T>
{
    T var;
    Holder(){}
    Holder(T var){this.var=var;}
    T get(){return var;}
    void set(T var){this.var=var;}
}

...
public void getMinMaxValues(int []values,Holder<int> min, Holder<int> max)
...

public static class MinMaxRes
{
    int min,max;
};
public MinMaxRes getMinMaxValues(int []values)

• почему Ваше желание неправильно я не знаю
  
• есть примитивные типы, а есть классы-обёртки примитивных типов
  
• в Java есть передача параметров только по значению
  
• отсюда вытекает, что если использовать примитивный тип как параметр, то внутри него используется его локальная копия.
  
• а вот если передавать ссылку (копия ссылки!) на объект с полем типа int это пожалуйста
  
• как я узнал от fellow.sufferer с обёртками примитивных типов фича с передачей ссылки не прокатит

public class MyIntWrapper
{
    private int intTypeField;

    public MyIntWrapper() {}

    public MyIntWrapper(int intTypeParam)
    {
        this.intTypeField = intTypeParam;
    }

    public void setInt(int intTypeParam)
    {
        this.intTypeField = intTypeParam;
    }

    public int getInt()
    {
        return this.intTypeField;
    }
}

public class Test1
{
    public static void change(MyIntWrapper n)
    {
        n.setInt(5);
    }

    public static void main(String[] args)
    {
        MyIntWrapper n = new MyIntWrapper();
        System.out.println(n.getInt());
        change(n);
        System.out.println(n.getInt());
    }
}

Т> откуда такое определение?

class New 
{
    int n = 0;
    public static void change(int m)
    {
        n = m;
    }
    
    public static void main(String[]args)
    {

        change(m);
        System.out.print(n);
    }
}

package ru.rsdn.test;

class New {
  int n;

  void change(int m) {
    n = m;
  }

  public static void main(String[] args) {
    New _new = new New();
    _new.change(1);
    System.out.println(_new.n);
  }
}

... а если бы он вез патроны.....

 private static void change(Integer ch) // ch содержит ссылку на объект Integer со значением 0
 {
  // при этом ch находится в контексте функции change и имеет совсем разное значение, нежели n внутри main.
    // то есть по сути это две разные ссылки, указывающие на один объект на данном этапе
    ch = new Integer(6); // ch теперь содержит ссылку на объект Integer со значением 6, а n внутри main продолжает содержать ссылку на объект Integer со значением 0
 }
 
 public static void main(String[] args)
 {
    Integer n = new Integer(0); // переменной n устанавливается ссылка на объект Integer со значением 0
    change(n);
    System.out.println(n);
 }

void set(int&n);

class New 
{
    public static void change(int n)
    {
        n = 5;
    }
    
    public static void main(String[]args)
    {
        int n = 0;
        change(n);
        System.out.print(n);
    }
}

double radians = 1.2345;
System.out.println("Sine of " + radians + " = " + Math.sin(radians));

public void bumper(int bumpMe) {
bumpMe += 15;
}

int xx = 12345;
bumper(xx);
System.out.println(“Now xx is “ + xx);

1. Button btn;
2. btn = new Button("Ok");

В данном же контексте метод (method) определяется как процедура или функция, которая изменяет состояние объекта или заставляет объект отправить сообщение.

public class Test
{
    public static void change(Integer n)
    {
        n = 5;
    }

    public static void main(String[] args)
    {
        Integer n = 0;        
        change(n);
        System.out.print(n);
    }
}

public class Test
{

    public static void main(String[] args)
    {
        T t = new T();
        System.out.println("s in main = " + t.s);
        
        t.s = "2";
        System.out.println("s in main = " + t.s);
    }
}

class T
{
    public String s = "1";
}

public class ObjectTest {

    public static void byValue(Test t) {
        Test anotherT = new Test();
        anotherT.i = 2;
        t = anotherT;
        System.out.println("anotherT.i in byValue = " + anotherT.i);
        System.out.println("t.i in byValue = " + t.i);
    }
    public static void main(String[] args) {
        Test t = new Test();
        t.i = 1;
        System.out.println("t.i in main = " + t.i);
        byValue(t);
        System.out.println("t.i in main = " + t.i);
    }
}

class Test {
    public int i;
}

    MyObject obj = new MyObject();
    obj = new MyObject();

public String convert(final String source)
{
    String dest = new String(source);
    ...
    return dest;
}

   Integer obj = new Integer(1);
   Integer obj2 = new Integer(1);
   if (obj == obj2) {
         
   }

A>блин, чего вот в жаве нет, так это старого доброго const )

MyInterface {

Object getValue();

}

MyImpl implements MyInterface {

Object getValue() {...}

setValue(Object obj)

}

...
method(MyInterface obj) {

...

}

T>Буду рад если вы приведете кусочек кода, после которого у меня наступит прозрение чтобы понять, что я теряю сейчас.

   public static void Swap(ref Object a, ref Object b)
    {
        Object temp = a;
        a = b;
        b = temp;
    }
.......

// использование...где то в коде
Object a=new Object;
Object b=new Object;

Swap(ref a, ref b)

К>Но это уже какой-то глупый флейм выходит

rsn81> В ООП по определению метод должен осуществлять обработку самого объекта, а не передаваемого ему.

R>Железный аргумент, чтобы сделать людям жизнь посложнее.

Скажу твердо: RTFM!

т.е. ссылку как некий объект

Не бывает локальных объектов, бывают только локальные ссылки.
У ссылок есть "границы видимости", а у объектов их нет.
В Java программист не может управлять временем жизни объектов.
В Java нет средств (таких, как константы) для защиты объекта от изменений (например для защиты от негативных последствий использования дублирующих ссылок).

In Java, Objects are passed by reference, and primitives are passed by value.
This is half incorrect. Everyone can easily agree that primitives are passed by value; there's no such thing in Java as a pointer/reference to a primitive.
However, Objects are not passed by reference. A correct statement would be Object references are passed by value.

The use of the word "reference" in Java was an incredibly poor choice (in my not-so-humble opinion...) Java has pointers, plain and simple. The designers of Java wanted to try to make a distinction between C/C++ pointers and Java pointers, so they picked another term. Under the covers, pointers are implemented very differently in Java and C/C++, and Java protects the pointer values, disallowing operations such as pointer arithmetic and invalid runtime casting.

Традиционная компьютерная система, основанная на так называемой аппаратной архитектуре фон Неймана (Von Neumann architecture), может рассматриваться как множество функций или процессов, работающих с набором данных, хранимых либо в памяти, либо на диске — это не принципиально. Эта статическая архитектурная модель показана на рис. 1.1. Из рисунка видно, что в процессе работы системы динамика состоит в вызове некоторой функции f(1), которая считывает соответствующие данные A, преобразовывает их и записывает в B. Потом вызывается некоторая другая функция f(2), которая тоже считывает некоторые данные (возможно, те же), использует их по назначению и записывает в C. Подобный перекрывающийся доступ к данным порождает проблемы параллельной обработки и целостности, которые могут быть разрешены с помощью систем управлениябазами данных. Перед тем как двигаться дальше, стоит рассмотреть вопрос, что нужно сделать, чтобы изменить часть структуры данных.

Рассматривая это с точки зрения специалиста по поддержке программы, можно сделать единственный вывод: необходимо проверить, затрагивают ли эти изменения каждую отдельную функцию. В этом вопросе может помочь качественная документация, но на практике она доступна редко. Отчасти это объясняется тем, что хорошая документация сама должна состоять из объектноориентированного описания системы, и ее невозможно представить в отрыве от объектноориентированной реализации или, по крайней мере, проектного решения. Кроме того, изменение каждой функции в соответствии с новыми структурами данных может иметь побочный эффект в других частях системы. Возможно, это объясняет необычайно высокую стоимость поддержки программных систем.

На рис. 1.2 показан совершенно иной архитектурный подход к системам. Все данные, доступ к которым нужен функции, инкапсулируются в один пакет с этой функцией — так называемый объект (object) — таким образом, чтобы другой объект не имел доступа к этим данным. Используя аналогию, предложенную Стивом Куком (Steve Cook), можно рассматривать эти объекты как яйца. Желток — это структура данных, белки состоят из функций, которые имеют доступ к этим данным, а скорлупа представляет сигнатуру общедоступных операций. Оболочка интерфейса скрывает реализацию и самих функций, и структур данных. Предположим, что в яйце, изображенном “в разрезе” на рис. 1.2, изменилась структура данных. Тогда специалисты по сопровождению должны проверить только факт влияния изменений на белок этого яйца; сфера вмешательства локализована. Изменение реализации одного объекта не может затронуть “внутренность” другого. В этом и состоит инкапсуляция: данные и процессы объединяются и скрываются за интерфейсом.

по другому не могут

static void set(int[] nByRef)
{
    nByRef[0] = 5;
}

public static void main(String[] args)
{
    int[] nRef = { 1 };
    System.out.print(nRef[0]);
    set(nRef);
    System.out.print(nRef[0]);
}

class Ref<T> {
    public T v;

    Ref(T v) {
        this.v = v;
    }
}

public class Main {
    static void main(String[] args) {
        Ref<String> ref = new Ref<String>("1");
        System.out.print(ref.v);
        set(ref);
        System.out.print(ref.v);
    }

    static void set(Ref<String> ref) {
        ref.v = "5";
    }
    
}

_>void set(int&n);
_>

/**
 * Calculation example
 */
public class Calculation {
    public static class Result {
       int foo;
       double bar;
    }

    public Result calculate(double[] values, int magicParam) {
        Result result = new Result();
        // put calculation results in result object
        result.foo = magicParam + values.length;
        result.bar = average(values);
        return result;
    }
}

/**
 * The contributors enhance the model creation process by adding plug-in specific information to the model.
 */
public interface Contributor {
     void contribute(Model model);
}

/**
 * This contributor adds ConcreteExtension to the model.
 */
public class ConcreteContributor implements Contributor {
    public void contribute(Model model) {
        model.addExtension(new ConcreteExtension("foo"));
        model.addMetadata(new ConcreteMetadata("alice","bob",1));
    }
}

/**
 * The builder collects contributors from application plug-ins and creates the model with all available extensions.
 */
public class Builder {
    public Model createModel() {
          Model model = new Model();
          for (Contributor contributor : contributors) {
             contributor.contribute(model);
          }
    }
}