Jawa / Говнокод #14510 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
public static String elvis(String value, String ifNull) {
        return value == null ? ifNull : value;
    }

    public static Boolean elvis(Boolean value, Boolean ifNull) {
        return value == null ? ifNull : value;
    }

    public static Object elvis(Object value, Object ifNull) {
        return value == null ? ifNull : value;
    }

- Objects#firstNotNull()?
- нет, не слышал

Запостил: myzone myzone, (Updated )

Комментарии (34) RSS

  • > Objects#firstNotNull()
    Внешняя зависимость же... Не всегда айс. Или там guava/commons уже юзается?
    Ответить
    • Если не стоит ограничение "никаких внешних зависимостей", то отказываться от гуавы бессмысленно. Самая адекватно спроектированная либа для жабы из всех, что я видел.
      Ответить
      • Вот если бы ещё обратносовместимость была на уровне, а то её грамотность привносящая популязиционный фактор, приводит к адовому jar hell от зависимостей в третьем колене.
        Ответить
        • jar hell happends не хороших дипендерсов, так что лишний повод избавиться от аудейтед хлама 😉
          Ответить
              • Не надо паники. Тешит то, что этвсёхерня в сравнении со стыковкой с тем тырпрайзом, который крутится на старопне под мсдосом. А переписывать никто софт не собирается ибо оно "и так хорошо работает".
                Ответить
    • Гуавы там не было, а зря...
      Там люди сделали NativeStringCache, например, кто догадается как он работает?
      Ответить
          • Зато потом через == можно сравнивать 🙂 Темная сторона силы.
            Ответить
              • А в 1.6 и ниже через == разве нельзя сравнивать?

                Или ты о сборке мусора из пула интернированных строк?
                Ответить
                • >о сборке мусора из пула интернированных строк
                  OutOfMemoryError: PermGen space error
                  Это сильно заябывает. А куча больше.
                  Ответить
              • кстати, там в этом коде рефлексией брался филд "offset" из стринга и мутились "указатели" на эти строки, или что-то типа того, я не сильно заморачился логикой, ибо наш проект переехал на последний релиз JDK, а там стринг перепилили 😀
                Ответить
            • Да, если только перед сравнением строки уже не надо интернировать, а то equals поди дешевле будет интернирования.
              Ответить
              • Нихера подобного.
                Интернируем - раз при создании, как и расчёт хеш-кода. А equals нужно много раз на немутабельном объекте (те же мапы, они везде).

                Если конечно строки не одноразовые, типа такого гогна:
                while(it.hasNext()) s+=it.next();

                Короче от контекста зависит.
                Ответить
                  • Спасибо за минус. Я стану стражем твоей тени. (LEXX, надеюсь, смотрели)
                    Ответить
                • Я не понял, что тут нихера. Вот в пример, о чём я выше писал, что менее накладнее, internedString == userString.intern() или internedString.equals(userString)? Контекст тут такой, юзер ввёл своё имя и мы проверяем, не "олень" ли юзер.
                  Ответить
                  • Далее ссылка на строку с именем пользователя может путешествовать по системе и попадать в разные мапы, дабы доставать разную инфу.
                    Ответить
                    • Получается, что например, если путешествие занимает 10 мап в роли ключа, то мы экономим >= 10 полных String.equals, в зависимости от коллизий. Оптимизация, однако!
                      Ответить

Добавить комментарий

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?


    8