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

StackOverflow https://stackoverflow.com/questions/1009087

  •  06-07-2019
  •  | 
  •  

Вопрос

Есть ли уважительная причина использовать в Java что-то вроде 

Long l = new Long(SOME_CONSTANT)

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

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

Это было полезно?

Решение

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

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

Другие советы

  

У меня вопрос, есть ли когда-нибудь веская причина для этого?

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

Единственное, о чем я могу думать, это сделать бокс явным, хотя эквивалентный код автобокса фактически компилируется в 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);
  }

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top