Java на португальском, например

Серьёзная история в сообществе Scala. Спустя три года, молодая Scala-энтузиастка объявила о домогательствах со стороны Джона Претти, одного из центральных фигур Scala-сообщества.

UPD: другая участница сообщества подтверждает историю Ифань и описывает похожий опыт.

35+ членов Scala-сообщества подписали открытое письмо, где объявили, что:
• Будут бойкотировать компании, которые предоставляют услуги Претти, не посещая их мероприятия и не пользуясь их продуктами и услугами
• Не будут принимать участия в конференциях, в которых участвует Претти
• Не будут принимать участия в других конференциях, где нет работающего code of conduct
• Не будут использовать и продвигать программные артефакты, которые поддерживаются Претти

Вот и всё. Менее чем за час человека отменили. Полностью.
#scala

В проекте Lilliput (попытки сжать заголовки объектов до 32/64 бит вместо 96/128) помаленьку начинает происходить активность. Вот уже отключён Biased Locking и identity hash code уменьшен с 31 до 25 бит.

Много лет использую схему именования переменных типа Map в Java. Схема очень простая: xToYMap. То есть что (X) мапится во что (Y). Например:

Map<String, Point> locations;

или

Map<String, Point> idToLocationMap;

Какой вариант понятнее читателю? Вопрос риторический. Особенно это стало критичным, когда появились var'ы:

var locations = getLocations();

или

var idToLocationMap = getIdToLocationMap();

Тут первый вариант уж совсем плох.

Entry по такой схеме логично именуются как xToY:

for (var idToLocation : idToLocationMap.entrySet()) {
    ...
}

Тут немедленно понятно, что такое idToLocation.

Ещё пример: Map<String, Integer> personNameToAgeMap;

Если в примере выше там был Point, и из типа Value худо-бедно можно было понять, что он означает, то здесь Integer может означать что угодно (возраст? вес? зарплата?).

В общем, рекомендую такую схему. Использую много лет.

Мда, ребят, половина не читала про concurrency. Как вас вообще допустили к написанию кода? Как прошли собеседование? Ну-ка бегом читать! :)
Книга, кстати, несмотря на то, что вышла в 2006, не устарела вообще нисколько, так что страх, что вы прочитаете и усвоите неактуальные вещи, беспочвенен. Книга про фундаментальные концепции, которые будут актуальны всегда.

Вот такой стих я сочинил в 2013 году, когда ещё не вышла Java 8:

Scala, JRuby или Jython
Kotlin, Fantom или, может, Ceylon?
Дайте хоть что-то, хотя бы Lua
Лямбд до сих пор у нас нет ни**
#юмор

«Не нанимайте токсичных людей» – постоянно я вижу в советах по рекрутингу. А, собственно, почему?

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

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

Если человек крутой спец, то почему бы не дать ему хотя бы шанс? Нанять в штат психолога, и пусть он работает с такими людьми. Большинство крупных и даже средних контор может себе это позволить. У каждой психологической травмы есть причина, и, выяснив её, человека можно вылечить. А потом получить крутого человека в команде. И просто хорошего человека в обществе. Конечно, не все будут проходить испытательный срок, и если у человека не будет никакой положительной тенденции, то тут уж сорян: мы сделали всё, что смогли. Тут всё так же как и с хард-скиллами: человек должен сам хотеть идти навстречу и прокачивать свои навыки.

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

Кстати, пользуясь случаем, рекомендую посмотреть шикарный сериал "Триггер". Конечно, он имеет мало общего с реальными ("научными") методами лечения психическим болезней, но я из него почерпнул одну важную идею. А именно тому, что даже если человек абсолютная мразь, то не надо преждевременно ставить на нём крест. Возможно если попытаться разобраться, почему он стал мразью, то может получится его исправить. Меня, например, очень сильно поразила сцена, где ФСИНовец жестоко и по беспределу избивал в тюрьме главного героя, но тот не только не затаил на него злобу, а пригласил его на сеанс и смог помочь ему, разобравшись в его психологической проблеме.

В общем, этого я и боялся. Я ожидал, что тот факт, что Java 17 будет LTS, будет сдерживающим фактором не пихать туда preview-фичи, но нет. Они всё-таки хотят засунуть JEP 406 в релиз.
Чем это плохо? Это значит, что IDE будут обязаны поддерживать вот эту предварительную версию Pattern Matching for switch много лет. И при этом одновременно поддерживать стабильную версию, которая выйдет где-то в районе Java 19. Поддерживать две версии одной фичи много лет – прям совсем плохо. Дай бог, если они не будут сильно отличаться.
#Java17

Вы знали, что для любого non-generic метода в Java можно указать типы-параметры? Любое количество. Причём даже для конструктора.

Кто-нибудь ещё так делает? 😄

У вас есть в проекте какие-нибудь утилитные методы, которых вам не хватает в стандартной библиотеке? Меня вот задалбливает каждый раз писать:

for (int i = 0; i < list.size(); i++) {
// action using i and list
}

Поэтому я завёл себе метод:

public static <A> void forEachWithIndex(Iterable<A> iterable, ObjIntConsumer<A> consumer) {
int i = 0;
for (A value : iterable) {
consumer.accept(value, i++);
}
}

Теперь можно писать так:

forEachWithIndex(list, <action>);

К тому же работает не только со списками, а с любым Iterable.

Ещё несколько методов:

public static <A, B> List<B> mapList(List<A> list, Function<A, B> f);

public static <A, B> List<B> mapListWithIndex(List<A> list, ObjIntBiFunction<A, B> f); // Пришлось завести ObjIntBiFunction

public static <T> List<T> flattenList(List<? extends List<T>> list);

А у вас есть что-то подобное? Пишите примеры в комментариях.

А javac это дебаггер и jar это статический анализатор

Сегодня узнал забавный факт, что Comparator.comparing(String::toLowerCase) не компилируется, в то время как Comparator.comparing((String s) -> s.toLowerCase()) прекрасно работает. Проблема в том, что у String.toLowerCase() есть две перегрузки: одна без аргументов, а другая - с Locale. При чём здесь вторая перегрузка, которая вообще не приминима здесь по сигнатуре Function? А пёс его знает. Вот так работает компилятор.
Чуть больше про это можно прочитать здесь.

Копец. В книги Кея Хорстманна написано, что hashCode образуется из адреса памяти 🤦‍♂️
И это последнее, 11-е издание книги.

Тестовое задание от кандидата

А вот это прикольно. Оказывается, почти все классы в java.util.concurrent являются общественным достоянием. Например, AtomicReference, ConcurrentHashMap, Semaphore, CountDownLatch, ReentrantLock, ForkJoinPool и т.д. Единственное исключение – CopyOnWriteArrayList 😀 (Наверное потому, что когда писался, многие куски были скопированы из ArrayList, а тот не является public domain).
Что значит общественное достояние? Значит, что Sun отказался от авторских прав на эти классы, это собственность всего общества. То есть исходный код классов можно копировать, изменять, распространять, продавать без разрешения.
#concurrency