… и даже если оно там не лежит на первый взгляд, индексы по таблицам могуть быть бинарными деревьями (да, и их кто-то наверное даже иногда разворачивает, только не на доске).
А. Если нужна прямо официальная поддержка, то пока придётся пользоваться LTS. Даже у самой 13-й версии окно официальной поддержки от разработчиков(!) длится ровно до выхода JDK 14, в отличие от 11, у которой поддержка будет вроде даже немного после выхода JDK 17. Но обратную совместимость между 11, 12 и 13 вроде не ломали, так что разрабатывать вполне можно уже сейчас, а тем временем подтянется и соответствующий релиз Boot.
Java взяла курс на моду и молодёжность, чтобы не выглядеть совсем уж замшело в глазах нынешних программистов, у которых новый любимый фреймворк рождается, делает несколько мажорных релизов без обратной совместимости, и умирает — за время, пока Java всё ещё готовит к релизу очередную версию с кучей плюшек.
Логически не-LTS релизы JDK теперь, видимо, имеют смысл минорных версий — насколько я помню, они даже @Deprecated(forRemove) будут удалять именно в LTS релизах. Плюс Preview Features, да плюс инкубаторы — разумеется, этот зоопарк не для кровавого интерпрайза, а для экспериментов и смузи.
Ну да, на острие придётся быть «на свой страх и риск». А где-то и когда-то это разве было не так?
На нашем родном проекте будут вводить JDK 12/13 из-за внутренних изменений, но вот language target на всём проекте до сих пор 8 (да, кровавый интерпрайз), хотя я бы лично был бы очень рад текстовым блокам, например.
Так ведь и не появилось, по сути, ничего такого ни в 12-й версии, ни в 13-й, что требовалось бы специально поддерживать. Ну что там, улучшенный ZGC? CDS-архивы? Как библиотека сможет это поддержать, а главное — зачем? Опять же, поддерживать preview-фичи — себе дороже, всё равно придётся что-то переделывать в итоге.
Если что-то поддерживает 8 — с этим уже можно удобно работать, если 9 и упаковано в модуль — тем более хорошо. А вот всё остальное это сугубо некритично, в пользовательском коде откликается чем-то вроде мелких улучшений.
И в официальных заявлениях о поддержке всё очень логично. 11-я версия носит метку LTS — её все и будут официально поддерживать, и это правильно. Когда выйдет следующий LTS-релиз — будут официально поддерживать его. Это вовсе не означает, что промежуточные версии никто не поддерживает, это нужно делать хотя бы потому, что иначе прыжки через несколько релизов будут очень тяжелыми.
Вот и Java идёт вперёд — по дорожке, расчищенной более молодыми языками. И при этом имеет возможность тщательно выбрать, какие из модных веяний стоит включить в язык и стандартную библиотеку, а какие — всего лишь веяние, и завтра мода уйдёт, а фича языка останется, и её придётся поддерживать.
Любая фича в языке интерферирует вообще со всеми другими фичами в языке, причём не только уже существующими, но и теми, что вы захотите добавить потом. Посмотрите на C++. Начиная с определённого порога заканчиваются понятные ключевые слова и синтаксис, и приходится начинать использовать непонятные. Или, как Вы выразились — отсекаем лишнее, и ломаем все программы, потому что до версии X оператор <:~: означал выход из корутины, а на момент выхода версии X + 1 корутины перестали быть модными, их сочли лишними и выкинули из языка, зато теперь оператор <:~: освободился, и его приспособили для атомарной записи в файл — разумеется, с ошибкой компиляции если типы не подошли.
Я бы посмотрел на Вашего босса, когда Вы ему сообщите, что ETA перехода на версию X + 1 (где присутствует критическая для него заплатка CVE) составляет год, потому что старый код теперь нужно отсечь, а новый писать заново.
> Тот же Internet Explorer взять.
Этот опыт на самом деле нас учит не тому, что надо брать всё самое современное, а тому, что типичная для Microsoft тактика EEE иногда даёт слабину, и тогда они сокрушительно теряют позиции. Но и при этом в некоторых организациях до сих пор крутится и жрать не просит какая-нибудь внутренняя система, работающая только на IE, и организацию это полностью устраивает.
Можно на это смотреть как на «следование в ж%пе». Но с другой стороны — язык, как и полагается старику с огромным количеством легаси, позволяет юношам с горящими взорами (которым нечего терять) кидаться на минное поле первыми. А потом собирает самые удачные остатки.
На Java по-прежнему работают программы, написанные чуть ни не в самых первых версиях, именно благодаря такому подходу.
Признаюсь, я думал, что речь в целом шла про inline class, а record — это прежнее название того же самого, но в прошлом.
Сейчас перепроверил, и таки нашёл их parent JEP 359 (про который просто преступно мало информации — видимо, все сейчас смотрят на Вальгаллу).
Тем не менее, штука про отсутствие собственного identity (точнее, логическому равенству между state и identity) и «другие значения <==> другая запись» тут ещё более применимы, это проистекает из самого исходного требования о полном соответствии состояния объекта его identity. Словами автора (в весьма вольном переводе):
Аргумент против изменяемости записей более сложен [чем против расширяемости], так как, в теории, вполне можно представить примеры когда возможность мутировать не идёт против основной цели создания подобных типов. Однако, изменяемость мешает соответствию между состоянием объекта и API его типа. Например, как правило, будет ошибкой использовать изменяемое состояние в методах equals() и hashCode(), так как это создаёт возможность для подобных элементов, к примеру, «неожиданно исчезать» из HashSet'ов или словарей HashMap. Иными словами, изменяемые поля записей означают, что мы хотим использовать протокол equals/hashCode, отличный от определения состояния; либо же, мы хотим конструировать подобные объекты по-другому (объекты во многих доменах создаются с использованием конструктора по умолчанию, а затем «заполняются» состоянием посредством вызова сеттеров, либо их конструктор принимает только поля их «натурального ключа».) Такие объекты, теряют одно из основных важных отличительных свойств: мы более не сможем выделить их API только лишь из описания их состояния. (И, как только мы введём в рассмотрение изменяемость, нам придётся также думать о потоко-безопасности, а это будет сложно примирить с основными целями введения записей в язык.)
Весь смысл record Foo {} не в уменьшении boilerplate, а именно в том, что он урезанный. У него не должно быть собственного identity, чтобы не таскать за собой "лишних" данных, заголовков, wait-списков и прочей чепухи, которой никто не пользуется, и иметь возможность инлайнить такие объекты в массив не перемежая их теми самыми заголовками. Именно поэтому они немутабельные — так как нету заголовка, всё состояние описывается значением полей, следовательно "другое значение поля <==> другая запись".
Но работа над этим ведётся так долго именно от того, что все в округе хотят всего и сразу. Насколько я помню, в недавних докладах уже рассказывали, что из-за public demand пришлось чуть ли не повернуться на 180, и какие-то вещи оставить. Но вот точно могу сказать, что чем больше у вас запросов вида "хочу не урезанных" — тем меньше у вас причин пользоваться записями. Если вы хотите только синтаксис — берите Lombok (ну или Kotlin сразу, чего мелочиться), а та фича про оптимизацию памяти.
В большинстве популярных языков оно, насколько я знаю, будет доступно за пределами блока
Да, это потому, что объявление переменных обычно либо вообще не выражение, либо не возвращает ничего полезного. Но говорил я не про популярные языки, а про принцип в целом. И в принципе такая инкапсуляция имеет смысл. А вот переписывать на какой-нибудь итератор — не всегда, так как единственная подобная абстракция, которая решает именно проблему инкапсуляции возвращаемого значения в блоке — это что-то вроде Spliterator<T> в Java, и при этом и там тоже есть "лишние" элементы.
Даже предпочтение someVar = someFunc(); if (someVar) ... перед if (someVar = someFunc()) ... — это выбор в пользу SRP формально: у if только одна ответственность, проверка условия, присвоение переменной вне него.
… Но при этом из соображений некоторой низкоуровневой инкапсуляции (когда значение someVar не должно быть видно или доступно за пределами блока If) имеет смысл предпочесть второй вариант. То есть, это вырожденный случай вот такого кода:
Вообще, как говаривал один индиец, правильно работающий программист должен уменьшать количество кода в приложении, без изменения его функциональности.
Моё "правило буравчика" — в реализации, где-нибудь внутри можно и навернуть абстракций, при условии, что в целом написание наворотов займёт, ну, ~10% от времени написания кода (если где-нибудь есть Future-задача сделать именно расширение, можно поднять планку до 15-20%). Но это в реализации. В интерфейсах всегда стараюсь следовать YAGNI, по умолчанию публикуется только абсолютный минимум. Что-то эдакое опубликовать потом™ всегда успею. Но на любую опубликованную деталь следует смотреть будто прямо в момент коммита какой-нибудь важный модуль начнёт от неё зависеть (что не всегда правда, мягко говоря), и значительно поменять её уже не выйдет. Потому лучше положить всё, что вот прямо сейчас не нужно, под подушку, вдруг во сне придумаю, как сделать лучшее.
На моём компьютере с Windows 10 два монитора, и основным выбран левый. Как результат, модный трей уведомлений (как на Android, да) находится на левом мониторе, в правом нижнем углу. Так вот, если быстро кликать по трею, можно наблюдать, как шторка уведомлений, не сворачиваясь и не уменьшаясь в размерах, уезжает на правый монитор, и только потом что-то "просыпается", и шторка пропадает.
Асинхронный код /s
Так я и сам против каких-либо репрессий. Мне эта относительная свобода в интернете очень по душе, я не хотел бы с ней расставаться только от того, что кто-то не может отделять свою страницу вконтакте от себя как личности.
надеюсь, не доберётся
Я тоже, но придётся иногда в этом направлении поглядывать. До нас такие волны могут дойти хоть и с опозданием, зато в резко искажённом виде, с доведением до абсурда.
Я не зря дал ссылки на два явления в современном интернете. Они характеризуются двумя вещами:
Далеко не всегда участники травли сегодня анонимны. Напротив, они теперь часто имеют очень конкретные имя, фамилию и армию друзей, а значит — влияние. Причём, инициаторы — не они, и с их точки зрения это жертва плохая.
Теперь в интернете могут не только унизить морально, но и добиться увольнения с работы (или иным образом подорвать доход), рассорить с родственниками и друзьями. Был даже случай, когда отказывали во въезде в страну. Опять же, психическое здоровье — это, всё же, не пустой звук.
Я не пытаюсь доказать, что разницы нет. Я пытаюсь сказать, что интернет имеет больше влияния на реальную жизнь, чем вы, похоже, думаете. И что, по моему мнению, может стать значительно хуже, прежде чем станет намного лучше.
Я думаю, многие программы всё же вполне могут обработать OOM собственными силами, (хоть и не на уровне условного f, можно ведь и какой-нибудь LRU-кэш почистить где-нибудь в соседнем модуле). Потому, как раз не надо делать halt если память закончилась, а если и делать, то давать программе возможность это действие обратить и "попытаться снова", и вообще очень много подобных оговорок. Но я не уверен, что такое получится применить в языке без механизма исключений. Разве что не иметь исключений в safe-коде, но иметь его или его аналог в unsafe.
Java взяла курс на моду и молодёжность, чтобы не выглядеть совсем уж замшело в глазах нынешних программистов, у которых новый любимый фреймворк рождается, делает несколько мажорных релизов без обратной совместимости, и умирает — за время, пока Java всё ещё готовит к релизу очередную версию с кучей плюшек.
Логически не-LTS релизы JDK теперь, видимо, имеют смысл минорных версий — насколько я помню, они даже
@Deprecated(forRemove)будут удалять именно в LTS релизах. Плюс Preview Features, да плюс инкубаторы — разумеется, этот зоопарк не для кровавого интерпрайза, а для экспериментов и смузи.Ну да, на острие придётся быть «на свой страх и риск». А где-то и когда-то это разве было не так?
На нашем родном проекте будут вводить JDK 12/13 из-за внутренних изменений, но вот language target на всём проекте до сих пор 8 (да, кровавый интерпрайз), хотя я бы лично был бы очень рад текстовым блокам, например.
docs.spring.io/spring-boot/docs/current/reference/html/getting-started-system-requirements.html
Хотя там контрастным по менее контрастному написано, что Так что непонятно, откуда дровишки.
Вот ContainerTools действительно никто, вроде, не собрал для JDK 12.
Если что-то поддерживает 8 — с этим уже можно удобно работать, если 9 и упаковано в модуль — тем более хорошо. А вот всё остальное это сугубо некритично, в пользовательском коде откликается чем-то вроде мелких улучшений.
И в официальных заявлениях о поддержке всё очень логично. 11-я версия носит метку LTS — её все и будут официально поддерживать, и это правильно. Когда выйдет следующий LTS-релиз — будут официально поддерживать его. Это вовсе не означает, что промежуточные версии никто не поддерживает, это нужно делать хотя бы потому, что иначе прыжки через несколько релизов будут очень тяжелыми.
Любая фича в языке интерферирует вообще со всеми другими фичами в языке, причём не только уже существующими, но и теми, что вы захотите добавить потом. Посмотрите на C++. Начиная с определённого порога заканчиваются понятные ключевые слова и синтаксис, и приходится начинать использовать непонятные. Или, как Вы выразились — отсекаем лишнее, и ломаем все программы, потому что до версии
Xоператор<:~:означал выход из корутины, а на момент выхода версииX + 1корутины перестали быть модными, их сочли лишними и выкинули из языка, зато теперь оператор<:~:освободился, и его приспособили для атомарной записи в файл — разумеется, с ошибкой компиляции если типы не подошли.Я бы посмотрел на Вашего босса, когда Вы ему сообщите, что ETA перехода на версию
X + 1(где присутствует критическая для него заплатка CVE) составляет год, потому что старый код теперь нужно отсечь, а новый писать заново.> Тот же Internet Explorer взять.
Этот опыт на самом деле нас учит не тому, что надо брать всё самое современное, а тому, что типичная для Microsoft тактика EEE иногда даёт слабину, и тогда они сокрушительно теряют позиции. Но и при этом в некоторых организациях до сих пор крутится и жрать не просит какая-нибудь внутренняя система, работающая только на IE, и организацию это полностью устраивает.
На Java по-прежнему работают программы, написанные чуть ни не в самых первых версиях, именно благодаря такому подходу.
inline class, аrecord— это прежнее название того же самого, но в прошлом.Сейчас перепроверил, и таки нашёл их parent JEP 359 (про который просто преступно мало информации — видимо, все сейчас смотрят на Вальгаллу).
Тем не менее, штука про отсутствие собственного identity (точнее, логическому равенству между state и identity) и «другие значения <==> другая запись» тут ещё более применимы, это проистекает из самого исходного требования о полном соответствии состояния объекта его identity. Словами автора (в весьма вольном переводе):
Весь смысл
record Foo {}не в уменьшении boilerplate, а именно в том, что он урезанный. У него не должно быть собственного identity, чтобы не таскать за собой "лишних" данных, заголовков, wait-списков и прочей чепухи, которой никто не пользуется, и иметь возможность инлайнить такие объекты в массив не перемежая их теми самыми заголовками. Именно поэтому они немутабельные — так как нету заголовка, всё состояние описывается значением полей, следовательно "другое значение поля <==> другая запись".Но работа над этим ведётся так долго именно от того, что все в округе хотят всего и сразу. Насколько я помню, в недавних докладах уже рассказывали, что из-за public demand пришлось чуть ли не повернуться на 180, и какие-то вещи оставить. Но вот точно могу сказать, что чем больше у вас запросов вида "хочу не урезанных" — тем меньше у вас причин пользоваться записями. Если вы хотите только синтаксис — берите Lombok (ну или Kotlin сразу, чего мелочиться), а та фича про оптимизацию памяти.
Да, это потому, что объявление переменных обычно либо вообще не выражение, либо не возвращает ничего полезного. Но говорил я не про популярные языки, а про принцип в целом. И в принципе такая инкапсуляция имеет смысл. А вот переписывать на какой-нибудь итератор — не всегда, так как единственная подобная абстракция, которая решает именно проблему инкапсуляции возвращаемого значения в блоке — это что-то вроде
Spliterator<T>в Java, и при этом и там тоже есть "лишние" элементы.А что если?
… Но при этом из соображений некоторой низкоуровневой инкапсуляции (когда значение
someVarне должно быть видно или доступно за пределами блока If) имеет смысл предпочесть второй вариант. То есть, это вырожденный случай вот такого кода:`
Вообще, как говаривал один индиец, правильно работающий программист должен уменьшать количество кода в приложении, без изменения его функциональности.
Моё "правило буравчика" — в реализации, где-нибудь внутри можно и навернуть абстракций, при условии, что в целом написание наворотов займёт, ну, ~10% от времени написания кода (если где-нибудь есть Future-задача сделать именно расширение, можно поднять планку до 15-20%). Но это в реализации. В интерфейсах всегда стараюсь следовать YAGNI, по умолчанию публикуется только абсолютный минимум. Что-то эдакое опубликовать потом™ всегда успею. Но на любую опубликованную деталь следует смотреть будто прямо в момент коммита какой-нибудь важный модуль начнёт от неё зависеть (что не всегда правда, мягко говоря), и значительно поменять её уже не выйдет. Потому лучше положить всё, что вот прямо сейчас не нужно, под подушку, вдруг во сне придумаю, как сделать лучшее.
А API тоже такие от того, что "мне было удобно сделать так". Как ими кто-нибудь будет пользоваться чукчу не волнует.
Да, особенно интересно, почему это — премия по физике?
На стопке глиняных перфокарт.
На моём компьютере с Windows 10 два монитора, и основным выбран левый. Как результат, модный трей уведомлений (как на Android, да) находится на левом мониторе, в правом нижнем углу. Так вот, если быстро кликать по трею, можно наблюдать, как шторка уведомлений, не сворачиваясь и не уменьшаясь в размерах, уезжает на правый монитор, и только потом что-то "просыпается", и шторка пропадает.
Асинхронный код /s
Так я и сам против каких-либо репрессий. Мне эта относительная свобода в интернете очень по душе, я не хотел бы с ней расставаться только от того, что кто-то не может отделять свою страницу вконтакте от себя как личности.
Я тоже, но придётся иногда в этом направлении поглядывать. До нас такие волны могут дойти хоть и с опозданием, зато в резко искажённом виде, с доведением до абсурда.
Я не зря дал ссылки на два явления в современном интернете. Они характеризуются двумя вещами:
Я не пытаюсь доказать, что разницы нет. Я пытаюсь сказать, что интернет имеет больше влияния на реальную жизнь, чем вы, похоже, думаете. И что, по моему мнению, может стать значительно хуже, прежде чем станет намного лучше.
Я думаю, многие программы всё же вполне могут обработать OOM собственными силами, (хоть и не на уровне условного
f, можно ведь и какой-нибудь LRU-кэш почистить где-нибудь в соседнем модуле). Потому, как раз не надо делать halt если память закончилась, а если и делать, то давать программе возможность это действие обратить и "попытаться снова", и вообще очень много подобных оговорок. Но я не уверен, что такое получится применить в языке без механизма исключений. Разве что не иметь исключений в safe-коде, но иметь его или его аналог в unsafe.