а все

оно возвращает же Mountain

http://puu.sh/qd0mX/2fad84717f.png

думал стринг возвращает

оно возвращает же Mountain

стоп, оно ж нулл возвращает

и че?

класс статический

аа

точнее поле

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

Ещё хотите?)

у меня был похожий вопрос на собеседовании в Ламоду

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

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

конечно

че ему не быть доступным? оно же паблик

ну, оно статичное, хз

@DarkCasual , а если не сложно, флотовский нан torawintbytes распечатай?)

как-то не вяжется статичное поле и экземпляр класса в моем понимании

я тебя огорчу

не знаю деталей как классы инициализируются, но обращение к статическому полю идет не к памяти конкретного объекта, а к описанию класса, что-то вроде того

http://puu.sh/qd0yz/1cfcef6629.png

http://puu.sh/qd0DP/0220b70c45.png

"Hel" + "lo" == "Hello"  Чому равно?

в общем

я тут дебагер запустил

http://puu.sh/qd0Lg/2573be58f2.png

не знаю деталей пула стрингов, но вроде как true

как видишь, вот при нане это условие выполняется

и там он как-то хардкордно result приравнивает к 0x7fc0...

"Hello" == "Hello" что Выдаст?

тоже тру

Таже тема, но сложнее: //In File Other.java package other; public class Other { public static String hello = "Hello"; } //In File Test.java package testPackage; import other.*; class Test{   public static void main(String[] args) {     String hello = "Hello", lo = "lo";     System.out.print((testPackage.Other.hello == hello) + " ");     System.out.print((other.Other.hello == hello) + " ");     System.out.print((hello == ("Hel"+"lo")) + " ");     System.out.print((hello == ("Hel"+lo)) + " "); // runtime     System.out.println(hello == ("Hel"+lo).intern());   } } class Other { static String hello = "Hello"; }

Что получим?

Всё тру, кроме hello == "Hel"+lo Итак, 6 малоизвестных фактов о строках в Java: 1. Строковые литералы в одном классе представляют собой ссылки на один и тот же объект.  2. Строковые литералы в разных классах, но в одном пакете представляют собой ссылки на один и тот же объект.  3. Строковые литералы в разных классах и разных пакетах всё равно представляют собой ссылки на один и тот же объект )).  4. Строки, получающиеся сложением констант, вычисляются во время компиляции и далее смотри пункт первый.  5. Строки, создаваемые во время выполнения НЕ ссылаются на один и тот же объект. (поэтому четвертый вывод — false) 6. Метод intern в любом случае возвращает объект из пула, вне зависимости от того, когда создается строка, на этапе компиляции или выполнения. (Поэтому последний вывод — true). Более подробно эта тема описана в пункте 3.10.5 спецификации Java.

норм тема

Всё тру, кроме hello == "Hel"+lo Итак, 6 малоизвестных фактов о строках в Java: 1. Строковые литералы в одном классе представляют собой ссылки на один и тот же объект.  2. Строковые литералы в разных классах, но в одном пакете представляют собой ссылки на один и тот же объект.  3. Строковые литералы в разных классах и разных пакетах всё равно представляют собой ссылки на один и тот же объект )).  4. Строки, получающиеся сложением констант, вычисляются во время компиляции и далее смотри пункт первый.  5. Строки, создаваемые во время выполнения НЕ ссылаются на один и тот же объект. (поэтому четвертый вывод — false) 6. Метод intern в любом случае возвращает объект из пула, вне зависимости от того, когда создается строка, на этапе компиляции или выполнения. (Поэтому последний вывод — true). Более подробно эта тема описана в пункте 3.10.5 спецификации Java.

кинь ссылку, откуда это всё - упражнения и разъяснения

https://m.habrahabr.ru/post/111189/

Хехе, меня расскрыли

https://m.habrahabr.ru/post/111189/

спасибо

Скомпилируется? System.out.println("\uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu2015")

нет

да

"pritln" не скомпилится точно

А это? char ch = '\uuuuuuuuuuuuuuuu2015'; System.out.println(ch);

очевидно что подвох не в этом

Аха, точно

все скомпилилось

в чем суть?

Зачем они так сделали?

В Си одна только u разрешена

Тут - бесконечно

а какие проблемы могут возникнуть?

Зачем они так сделали?

А что тогда на собеседованиях спрашивать?

Никаких, но как-то оно не очень выглядит.

Вроде в спеках написано, что это стандарт.

А в С, C# и остальных, не стандарт что ли?

http://puu.sh/qd2d0/e6a6e3c68d.png

действительно

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

Лол 300 сообщений обсуждали как писать equals. ?

мдемс

а я вместо спринга в чатике сидел

и вот эти задачки смотрел

Эх спринг, one love. Вместо него команда сказала что будем пилить все на finagle / Twitter-server и на скале. И пофигу что займет раза в три больше времени.

ERROR: S client not available

я вот это не понял, кстати

допустим есть у нас формула result = 31*x + y

нужно решить уравнение 31*x + y = 31*y + x

тогда ты получишь значения твоего объекта point когда случится коллизия

кстати

Это вы обсуждали hashcode?

ага

в общем, я посмотрел реализацию hashcode в классе Objects

http://puu.sh/qd3pN/f8d21d397b.png

http://puu.sh/qd3qk/e4fea83029.png

вот он тут норм выглядит, во всяком случае для интов

я вот это не понял, кстати

я там хуйню сказал

Бросай не скины, а код.

как мне форматировать?

просто хотел найти зависимость x от y, когда возникнет коллизия

вот так

или как

public static int hash(Object... values) { return Arrays.hashCode(values); }

public static int hashCode(Object a[]) { if (a == null) return 0; int result = 1; for (Object element : a) result = 31 * result + (element == null ? 0 : element.hashCode()); return result; }

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

ага

вообще

версия хашкода, что я скинул из класса arrays делает точно такой же хэш, что и сгенерила intellij, только в 31 раз больше

так что, это точно такой же алгоритм

я с какого-то перепугу решил что он лучше

А зачем так заморачиваться по поводу хешей то?

Где-то в классическом труде по cs бы описан именно такой способ расчета хеша, вот все его и юзают

жалко что я плохой математик

я понимаю почему используют простое число

но почему такое - хз

Ну главное не путать его с криптографическими хешами.

но почему такое - хз

Потому что 31 * i == (i << 5) - i. Из-за чего такое решение становится очень производительным.