Есть ли оправданная причина использовать new и конструктор для числового класса в Java?

Question

Есть ли какая-либо оправданная причина, чтобы в Java что-то вроде

Long l = new Long(SOME_CONSTANT)

Это создает дополнительный объект и помечается FindBugs, и это явно плохая практика. У меня вопрос, есть ли когда-нибудь веская причина для этого?

Ранее я спрашивал об конструкторах String и получил хороший ответ , но этот ответ, похоже, не относится к числам.

Answer 1

Только если вы хотите убедиться, что получили уникальный экземпляр, поэтому _{практически} никогда.

Некоторые номера могут кэшироваться при автоматической упаковке (хотя Longs не гарантированно равно ), что может вызвать проблемы. Но любой код, который может сломаться из-за кэширования, вероятно, имеет более глубокие проблемы. Прямо сейчас я не могу придумать ни одного действительного случая для этого.

Answer 2

Мой вопрос: есть ли когда-нибудь веская причина для этого?

Вы все еще можете использовать его, если хотите написать код, совместимый с более старыми JRE. valueOf (long) был представлен только в Java 1.5, поэтому в Java 1.4 и до того, как конструктор был единственным способом перейти непосредственно от long к Long . Я ожидаю, что это не считается устаревшим, потому что конструктор все еще используется внутри.

Answer 3

Единственное, о чем я могу думать, это сделать бокс явным, хотя эквивалентный автоматически упакованный код фактически скомпилирован в Long.valueOf (SOME_CONSTANT), который может кэшировать небольшие значения: (из jvm src)

   public static Long valueOf(long l) {
    final int offset = 128;
    if (l >= -128 && l <= 127) { // will cache
        return LongCache.cache[(int)l + offset];
    }
        return new Long(l);
  }

. Ничего страшного, но мне не нравится видеть код, который постоянно упаковывает и распаковывает, не обращая внимания на тип, что может привести к небрежности.

Функционально, однако, я не вижу разницы так или иначе. Новый long будет по-прежнему вычисляться как равный, а хэш-код будет равен автоматически упакованному, поэтому я не вижу, как вы могли бы даже сделать функциональное различие, если бы захотели.