Хочу я тут передать в качестве параметра в метод интежер и получить его изменённое значение

Не делай так. Выводи измененный вариант на выход метода.

Число изменить тоже невозможно. Можно только заменить его на другое число.

+[хочется странного]

если сильно хочется то все можно

на практике как то приходилось иметь дело с таким кодом (портированое строчка в строчку чи из плюсов чи еще откуда), видел вот такое решение:

int [] x = new int[] { 1 };

передаешь куда надо массив и там меняешь сколько угодно нулевой елемент, вариант конечно говно, но если уж очень надо

Не делай так

Очень похоже на догму. Я не к тому, что это не правильно, а к тому, что это технический ресурс, и надо было расписать почему твой вариант лучше с технической точки зрения.

Такой вариант лучше с точки зрения читабельности. Потому что при передаче параметра в функцию человек предполагает, что с ним там ничего делать не будут, а результат он получит на выходе. Это не си, где куча способов передать параметр.

Исключение составляют методы вроде fillЧегоТоТам(Список).

ненадо так делать)

но если надо - use AtomicInteger

А final variables тогда зачем?

Это всё фигня. Почему они не сделали арифметические операции с BigInteger/BigDecimal через символы?

Чтобы явно указать компилятору, что эту переменную нельзя менять и нельзя переопределять это имя, дабы избежать ошибок.

Не вижу как из этого следует, что:

Такой вариант лучше с точки зрения читабельности.

ИМХО просто нагромождение костылей и исключений из правил.

Видимо, по той же причиние, что и == - через .equals();

Не, с == и equals всё ясно и воспринимается нормально

воспринимается нормально

если честно, не понимаю как это может нормально восприниматься (%

У тебя ещё маленький мозг, когда он немного подрастет, тогда, возможно, начнешь понимать, какая перелесть в неизменяемых типах и как они сильно упрощают внутренние реализации всякого разного базового. Нужна изменяемость бери тип который изменяемый - Atomic... или рисуй свою реализацию.

Почему это не делать так? От объекта, переданного в качестве аргумента ожидаешь возможности его изменения, а тут такая засада.

З.Ы. Спасибо за идею, переписал с выводом

Потому что 5 не может просто так превратиться в 11. Это разные числа.

От объекта, переданного в качестве аргумента ожидаешь возможности его изменения, а тут такая засада.

А ты не ожидай, а почитай маны по джаве :)

Но вообще возможность переопределять имя аргумента конечно приводит к путанице. При рефакторинге рекомендуют исправлять такие места.

Это не си, где куча способов передать параметр

В си в общем-то можно передавать параметры только по значению, только этим значением (явно) может быть указатель.

В commons lang3 есть мутабельные обертки над примитивами в пакете mutable (surprise-surprise).

Но ты что-то делаешь не так)

http://stackoverflow.com/questions/5614562/how-to-pass-by-reference-in-java

И эти люди потом хают .net

Только, конечно

final int[] i = {0};

Тогда оно ещё и в inner-классы отлично просовывается, и значение в массиве можно менять.

P.S. Да, я знаю, что подобным стилем нельзя злоупотреблять, но иногда он является единственным способом побороться с коллбэками в яве.

Ну так то же самое написано выше по треду

Это сделано в угоду безопасности, как и неизменяемые строки (java.lang.String).

Так тред не читай, сразу отвечай.

Ещё какой изменяемый

public void changeInteger(Integer i) throws Exception {
    Field value = i.getClass().getDeclaredField("value");
    value.setAccessible(true);
    value.set(i, 1024);
}

Я где-то слышал, что мутабельные числа на рефлекшене особо годны для числодробилок, правда же?

А спеки джавы гарантируют, что у этого класса есть поле value? А то есть шанс, что этот код в новой версии или просто другой реализации работать не будет :)

А спеки джавы гарантируют, что у этого класса есть поле value?

Не знаю :) Но с вероятностью, близкой к 100% все JDK тупо скопировали этот код друг у друга.

А то есть шанс, что этот код в новой версии или просто другой реализации работать не будет :)

У этого кода есть много других куда более важных проблем.

Например

changeInteger(1);
...
System.out.println((Integer) 1); // wtf

Нет завязки на название, однако есть предположение на наличие только одного элемента со значением эквивалентным передаваемому. :D

public static void main(String [] args) throws IOException {
        Integer i = 98;
        changeValue(i, 1024);
        System.out.println(i);

    }
    public static <T> void changeValue(T i, T newValue) {
        try {
            for (Field f : i.getClass().getDeclaredFields()) {
                final boolean save = f.isAccessible();
                if (!save)
                    f.setAccessible(true);
                if (i.equals(f.get(i))) {
                    f.set(i, newValue);
                    f.setAccessible(save);
                    break;
                }
                f.setAccessible(save);
            }
        } catch (IllegalAccessException e) {
            //
        }
    }

Это предположение. Я бы не стал на него опираться. Может, завтра я захочу сделать свою джаву, в которой integer хранит количество экземпляров класса :)

Ещё есть org.omg.CORBA.IntHolder у которого обёрнутый int является публичным полем.

Правильно сделали. Неправильно, что большая часть всего остального по умолчанию мутабельная.

Ява-неудачники должны страдать.

Мимошарпер

Например

жесть, же, такой занятный способ отстрелить себе ногу 8)

Как тогда считать что-то в цепочке хуков, городить свой класс-обёртку?

Нет, для цепочни надо заводить ChainContext в котором будет и твои int и место для тех параметров о которых ты еще не задумывался. А вот что будет если через полгода тебе потребуется добавить парметр для пары хуков?

ууух шайтан! https://gist.github.com/cdshines/7777073