• Кто создал Java: главное про Джеймса Гослинга
    +2

    По легендам корень из двух — первое число, иррациональность которого была доказана (ещё во времена Пифагора). В некотором смысле первое иррациональное число знакомое людям. Поэтому оно вполне заслуживает особой любви.

  • Уберите ваших детей от наших голубых экранов, или почему нельзя покупать Яндекс.Станцию для ребёнка
    0

    Видал кружки и группы раннего развития, в том числе пресловутого Зайцева, но не видел в них ни одного ребёнка младше четырёх лет, который бы прилично читал. В четыре нормально читают единицы, несмотря ни на какие занятия. Из группы раннего развития с уклоном в чтение к пяти годам хорошо если 10% умеют бегло читать. Поэтому ваши слова для меня звучат неубедительно.


    Не понял как второй абзац вашего сообщения относится к моему сообщению. Видимо, никак?

  • JEP 360: Sealed Types (Preview)
    +1

    Вообще-то это фича JVM. Её и Котлин может использовать, если захочет. Проблема с продвинутыми уровнями доступа в Котлине и других JVM-языках в том, что рантайм про них ничего не знает и никак не помешает вам нарушить этот уровень при использовании смеси языков или раздельной компиляции.

  • JEP 360: Sealed Types (Preview)
    +2

    Почему это оформлено как перевод? Брайан ничего не писал про размножение бельгийцев.

  • JEP 360: Sealed Types (Preview)
    +1

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

  • Уберите ваших детей от наших голубых экранов, или почему нельзя покупать Яндекс.Станцию для ребёнка
    0

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

  • Спор о первом языке программирования: окончательное решение
    0

    Запросы Sun Microsystems, конечно, порадовали.

  • Спор о первом языке программирования: окончательное решение
    +3

    Слабоватый разброс. Предлагаю Idris и VHDL.

  • Спор о первом языке программирования: окончательное решение
    0

    В наши дни почти для любого языка достаточно браузера. Смотрите https://ideone.com/ или https://try.kotlinlang.org/ и т. д.

  • В Microsoft модель машинного обучения выявляет 99% ошибок безопасности
    +2

    Это мешает привести пример?

  • В Microsoft модель машинного обучения выявляет 99% ошибок безопасности
    +3

    Что-то хоть бы один пример уязвимости, который ML-робот смог найти, а традиционные инструменты не могут. Интересно же. Без примеров статья совсем ни о чём.

  • Java-чемпион или Java-лузер: тест для разработчиков
    0

    О, надо же, я этого не знал. Спасибо! Добавишь так в HashMap объект, а потом biased locking на нём сломается =)

  • Java 14: Record, более лаконичный instanceof, упаковщик jpackage, switch-лямбды и текстовые блоки
    0
    Объекту в данном случае вообще пофиг — его никто и никак не изменяет и уж точно объекту никто ничего не присваивает.

    В принципе valery1707 всё правильно сказал, незачем повторяться. "Присвоить объекту что-то" означает что объект будет этим владеть, обладать, либо это станет свойством объекта. Можно присвоить значение переменной, здесь всё нормально: переменную как раз можно представлять как контейнер со значением, и значение является её свойством.


    но зачем заниматься буквоедством?

    Ну извините, у слов в языке есть смысл. Если вы используете слова произвольно, не так как принято в языке, то будьте готовы к претензиям. Я всё-таки считаю, что пост на Хабре должен быть поприличнее качеством чем рандомное высказывание в чате (пусть злые языки говорят, что Хабр не торт). Если у вас другое мнение, то в принципе ладно, мы можем остаться при своём и не вдаваться в дальнейшую дискуссию.


    большинство постов на Хабре пишутся для широкой публики, максимально просто и понятно.

    Использование слов не в общепринятом значении не способствует простоте и понятности.

  • Java-чемпион или Java-лузер: тест для разработчиков
    +7

    На седьмой вопрос мой ответ: у меня глаза текут от этого ужасного кода. Используйте неизменяемые кортежи, лесом синхронизацию.


    На восьмой вопрос мой ответ: не мучайте киску. Если вам нужен putIfAbsent, берите CopyOnWriteArraySet и радуйтесь. Если вы по несчастью застряли с synchronizedList, рефакторьте код, это в любом случае опасная фигня (например, стримы от неё небезопасны, я дописал это в документации). Если уж совсем припёрло, почитайте документацию, там написано, что надо использовать в качестве монитора для синхронизации дополнительных операций. Помнить это наизусть необязательно. Про synchronizedList надо помнить одну вещь: что его лучше избегать и использовать крайне осторожно.


    На девятый вопрос мой ответ: используйте SynchronousQueue из стандартной библиотеки. Вы всё равно не сделаете лучше. Все четыре предложенные реализации неустойчивы против повторного вызова producer. В этом плане смешно видеть умные слова в ответе "что позволяет потоку писать данные достаточно быстро". Как он может писать достаточно быстро, если дизайн класса не предполагает перекачки более одного значения? Такой код в серьёзном продакшне недопустим. Не надо изобретать велосипеды.


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

  • Java-чемпион или Java-лузер: тест для разработчиков
    +7
    Ты разрабатываешь часть системы, которая выполняет различные финансовые операции. Какие типы могут подойти для выполнения таких операций?

    И к этому вопросу много вопросов. Типа Int в стандартной библиотеке Java вообще нет, но допустим это особенность формы опроса и имелся в виду примитивный int. Почему можно его использовать? Человек, у которого больше двух миллиардов рублей на счету, будет очень недоволен. Деление двух интов всегда округляется вниз, хотя вы пишете, что округлений нет. Наконец, любое число, представимое в int, представимо и в double с той же самой точностью. То есть любую операцию, которую вы можете сделать на int, вы можете сделать на double с не меньшей точностью. Причём у вас будет более точный результат деления и меньше рисков переполнения. Почему int считается правильным ответом, а double нет — совершенно неясно.


    Нет, я понимаю стандартную мантру "используйте BigDecimal", но блин, вопрос-то надо правильно формулировать.

  • Java-чемпион или Java-лузер: тест для разработчиков
    +3
    Должен ли класс, который планируется использовать в качестве ключа HashMap, быть полностью immutable?

    Тут очень много вопросов. Начиная с того что понимать под immutable класс. Можете дать определение? Я знаю, что лучшие умы OpenJDK обсуждали этот термин долго и горячо, когда ввели вот эти все List.of и собирались их описать в документации. В итоге вообще отказались от слова immutable. Вот к примеру java.lang.String immutable или нет?


    Также в "правильном" ответе ничего не написано про контракт Comparable. А если ключ реализует Comparable, но после изменения объекта результат сравнения получается другой? HashMap может сломаться.


    Я бы ответил, что для любого объекта, используемого в качестве ключа (в том числе необязательно помещённого в Map, но и переданного в containsKey и т. д.), результат hashCode должен сохраняться на протяжении использования, а также для любой пары объектов, используемых в качестве ключа, результат equals и compareTo (при наличии) должен тоже сохраняться на протяжении использования. А что означает слово immutable — наплевать.

  • Java-чемпион или Java-лузер: тест для разработчиков
    +1
    К сожалению, разработчики написали плохую хеш-функцию, и наблюдается значительная коллизия ключей. Метод equals() переопределен корректно. Какую алгоритмическую сложность поиска значения по ключу стоит ожидать?

    Вы, конечно, ожидаете, что с Java 8 будет O(log n). Но это возможно только в том случае, если разработчики сделали свои объекты Comparable и корректно реализовали compareTo. Что было бы наивно ожидать от разработчиков, которые реализовали плохую хэш-функцию. Ни разу в жизни не видел объекта с плохой (но корректной) хэш-функцией и правильным compareTo одновременно. Вы видели?

  • Что не так с коллекциями в Java и почему Guava не поможет
    0

    Vavr невозможно использовать в реальных проектах. Вам нужен интероп с кучей других библиотек, которые про Vavr ни сном ни духом. А у вас и там, и сям простые имена классов называются одинаково со стандартными. В итоге ваш код превратится просто в ад. Хорошо и красиво для маленьких учебных проектов. Для кровавого продакшна — извините.

  • Оптимизации в JIT-компиляторе для .NET 5
    0

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

  • Java 14: Record, более лаконичный instanceof, упаковщик jpackage, switch-лямбды и текстовые блоки
    +1

    Изложение слабовато, конечно. "Присвоение ссылки объекту" — что это вообще за жесть? Как объекту можно присвоить ссылку?

  • Java 14: Record, более лаконичный instanceof, упаковщик jpackage, switch-лямбды и текстовые блоки
    +1

    Вы совершенно неправы. Все фичи продуманные. Над некоторыми думали годами и продолжают думать. И то что завезли — switch, instanceof, record — это маленькие куски более общей картины, которая соберётся позднее. Критика на уровне "фу, бяка" без конструктива не делает чести никому.

  • Java 14: Record, более лаконичный instanceof, упаковщик jpackage, switch-лямбды и текстовые блоки
    +1

    Вы жалуетесь что чего-то нету, когда оно на самом деле есть? Оригинально.


    И если вам кажется, что фичи несвязанные и висящие в воздухе, попробуйте подумать с другой стороны. А может вам это только кажется? Может, вы чего-то не знаете? Может, всё-таки это делали люди не глупее вас?

  • Java 14: Record, более лаконичный instanceof, упаковщик jpackage, switch-лямбды и текстовые блоки
    0

    Закройте кавычку левее. Положением закрывающей кавычки можно регулировать положение отступа.

  • Java 14: Record, более лаконичный instanceof, упаковщик jpackage, switch-лямбды и текстовые блоки
    0

    Деструктуризация рекордов планируется в Java 15 в виде превью-фичи. Уже JEP завели.


    Не понял пассаж про лень и не осилили. К чему это? Кому лень? Кто не осилил?

  • Java-дайджест за 6 марта
    +1

    Ещё такой момент. Компоненты рекорда — абсолютно важная часть его интерфейса, важнее всего остального. Поэтому они сверху, чтобы глядя на определение рекорда было ясно, что к чему. Поля же можно объявлять в любом месте класса, хоть после методов. Но они и не так важны.

  • Java-дайджест за 6 марта
    +3

    Потому что это не поля, а компоненты рекорда. Поля генерируются по ним. Ещё по ним генерируются, например, параметры конструктора и геттеры. У компонентов могут быть особые аннотации, доступные через reflection. В общем, это новая конструкция языка. Странно делать её синтаксически такой же как другая конструкция. А разве большая разница как скобки ставить?

  • Java-дайджест за 6 марта
    +1

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

  • Кто умнее чем IDEA?
    0

    Возможно, из-за неблагоприятной эпидемиологической обстановки. Но точно не знаю.

  • Ужасы Set.removeAll
    +1

    Мы, кстати, обсуждаем реализацию из AbstractSet, а не возможную специализацию в HashSet. Конечно, когда мы больше знаем хотя бы про свой Set, нам будет проще выделить fast-path.

  • Ужасы Set.removeAll
    +1
    Возможно, метода retainAll вообще не должно было быть.

    Вот это зря, очень полезный метод. Понимаю желание убрать всё, что не вписывается в красивую картину мира, которую мы себе рисуем в голове, но надо не забывать про то что API должно быть практичным.


    Зато сейчас у removeAll вообще не определена семантика

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


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

    Вариант всегда использовать contains целевой коллекции настолько же предсказуем. Ты вот делаешь неявное предположение, что у переданной коллекции iterator.next() быстрый, а это может быть и не так. К примеру, коллекция может быть фильтруемой на лету вьюшкой над большим сетом. Степень предсказуемости абсолютно одинаковая, она в любом случае зависит от устройства переданной коллекции, и с этим ничего не сделаешь.


    Библиотека Guava могла бы и предоставить свою реализацию removeAll, принимающую MultiSet, в статическом хелпере.

    Во-первых, это не нужно, потому что достаточно сделать mySet.removeAll(multiSet.toElementSet()) (подразумевая твою реализацию). Во-вторых, речь о неожиданных перформансных эффектах. Как ты обучишь каждого пользователя не использовать стандартный метод (или использовать его нестандартно) там, где он работает, выдаёт правильный результат и выполняется быстро на небольших тестовых данных? Либо ждать пока обожжётся (что мы, кстати, имеем в обсуждаемом примере), либо ожидать, что каждый пользователь прочитает и запомнит всю документацию от корки до корки (глупо), либо прокачивать статический анализ (вариант хороший, но ненадёжно).

  • Ужасы Set.removeAll
    +1

    Ладно, но есть метод retainAll, который реализован через обход нашей коллекции. Причём его реализовать через обход переданной коллекции невозможно без использования O(N) дополнительной памяти. Выходит, у removeAll по твоему предложению будет contains-семантика текущей коллекции, а у retainAll будет contains-семантика переданной коллекции. Она может отличаться. Например, нам передан TreeSet с компаратором.


    Далее, кто сказал, что известная асимптотика лучше? Например, моя задача требует передавать параметром Guava Multiset. Я знаю, что contains в нём очень быстрый. Мне может интуитивно кажется, что обойти его тоже быстро, даже если там элементы с огромным количеством повторов. По факту же обход будет включать в себя все повторы, и я также получу провал в производительности на ровном месте.

  • Ужасы Set.removeAll
    +1

    Почему?

  • Ужасы Set.removeAll
    +1

    А какую ветку из исходного кода оставить, если убрать проверку?

  • Ужасы Set.removeAll
    +4
    Похоже, в JDK выбран довольно убогий способ справиться с задачей

    Все мы любим покритиковать код, который был написан, когда мы ещё ходили под стол пешком. Но вопрос не в этом. Как правильно-то надо было сделать, расскажи нам :-)

  • Кто умнее чем IDEA?
    0

    Нет, не может быть. Это совсем бесполезно.

  • Кто умнее чем IDEA?
    0

    Метод и переменная очевидно не могут называться одними цифрами. Придумывать для типов и для переменных разный набор допустимых символов? Ради чего?

  • Кто умнее чем IDEA?
    +2

    Простите, не мы, а вы.

  • Кто умнее чем IDEA?
    0

    Ты действительно хочешь жить в мире, где возможен подобный код? :-) Опасайтесь своих желаний!

  • Кто умнее чем IDEA?
    0

    Да, есть инспекции, а есть аннотаторы, и в некоторых языках почему-то используют аннотаторы, к которым по умолчанию нет механизма саппресса. Почему это так — для меня загадка. В джаве мы всё делаем инспекциями. Но если вы считаете, что у вас что-то подсвечивается неправильно, всегда можно написать баг-репорт или проголосовать за существующих. Про вашу проблему есть репорт?

  • Кто умнее чем IDEA?
    +6

    В джаве return; посреди метода — это не предупреждение, а ошибка компиляции. Если вы совсем не хотите никаких ошибок видеть, а только подсветку синтаксиса, можно отключить гектора в статусной строке:



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


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


    Кстати, вот вы написали if (true && ...), а ведь это бесполезно. Вы хотели сделать ветку всегда истинной, но в итоге не сделали ничего. Надо было написать if (true || ...). Если вы эту ошибку сделали в редакторе Хабра, вы могли её сделать и в редакторе кода без встроенного статического анализатора. А анализатор подсветит по-разному: в первом случае выделит только true, а во втором — всё условие. Опытный пользователь сразу заметит ошибку, даже если использует подобные условия для прототипирования. В любом случае это полезная визуальная напоминалка, что эта ветка выполнится всегда. Она пригодится при отладке.


    Ещё кстати в отладчике можно менять значения переменных, форсируя выполнение определённой ветки. Часто это гораздо удобнее, чем модифицировать код.