Pull to refresh

Comments 30

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

Работает? В прод! ©®™

с переменными такая чехарда начнется... Некоторые до сих пор var не могут переварить

До сих пор не понимаю радости вокруг var.
Имеет смысл разве что тут:

var some = new Some();

В остальных местах теряется читабильность. Экономить время написания? Ну нет, нажмите Ctrl+Alt+V и все будет.
А с _ - раньше было ignore, теперь так.
В pattern matching только и вижу применение, больше нигде.

Что-то ощущение, что новость не из 2024, а из 2014-2015...типо, щас же даже в C++ есть большенство этих вещей

String Templates (Second Preview) (JEP 459)

Их скорее всего очень сильно переделают в следующем релизе, и реализацию, и синтаксис. Пока выглядит что синтаксис будет $"Bla-bla {var}"(вместо STR."Bla-bla {var}"), но это не финальное решение.
Одно из обощающих писем для тех кому интересны детали:
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-March/004062.html

Implicitly Declared Classes and Instance Main Methods (Second Preview) (JEP 463)

Мне ненравится как сделали этот JEP. Есть проблема-многословный синтаксис, лишние абстракции которые как выяснилось не всегда нужны. Что мы сделаем, исправим это в языке? Нет, введем дополнительный граничный случай для начинающих с неявно объявленными классами, которые как потом выснится больше нигде работать небудут.

Одно из обощающих писем для тех кому интересны детали

Автор упомянул об этом:

примечание: сейчас идут обсуждения относительно отказа идеи процессоров и оставления только StringTemplate

Слегка ошибся - по ссылке в статье другое письмо, но по той же теме.

Автор упомянул об этом

Незаvетил примечания

Слегка ошибся - по ссылке в статье другое письмо, но по той же теме.

Да, там несколько обощающих писем, и прямо сейчас идет активное обсуждение, не удивлюсь если уже опять все поменялось

Не нравятся мне Scoped Values. По-сути это глобальные переменные. Применяться они будут только как инструмент для костылестроения, когда неохота добавлять параметры и грамотно рефакторить код при разросшемся количестве параметров. Когда надо пробросить параметр через пять вложенных вызовов и несколько классов параметров.

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

Да и scope'ы в Java EE можно вспомнить - context, session, request... Такая же история по сути.

А как mdc делать например? Таскать все параметры и каждый раз в логер передовать?

Добавление параметров не всегда возможно, как раз в случае, когда в середине вызова - библиотечный код (или наоборот, код приложения, который использует наш как библиотеку), изменить который нельзя. В целом это редкий кейс, но тут без ThreadLocal или аналога не обойтись.

В библиотеку в таких случаях добавляют новый overloading метод с дополнительным параметром.

Это если библиотека своя - конечно. А если это какой-нибудь spring или junit - лучше ThreadLocal, чем форк IMHO

ThreadLocal, синлтоны, public static поля в конце концов - скорее их будут использовать) Хороший кейс для использования как TheradLocal, так и Scoped Values - передача данных между основным кодом и кодом аспекта, вызываемого через аннотацию

Мне тоже не нравится, но по прямо противоположной причине - это полумера, которая способна запутать код, поскольку без привлечения более мощных средств расширения проверок типов, например CheckerFramework'а, трудно будет обеспечить гарантии. Ну вот пишу я метод - как мне сказать компилятору "Проверь обязательно, что бы в ScopedValue при вызове моего метода обязательно по такому-то ключу лежал объект такого-то типа с таким-то дженериком, а при попытке вызова без этого - вали компиляцию"? Никак. И когда это сделают в CheckerFramework'е, и вообще - сделают ли — непонятно...
На мой взгляд, чем такой труднопроверяемый огород городить, нужно было бы просто сделать implicit-параметры, как в Scala - и проблема была бы решена наилучшим образом, а так - это полумера, которая только дополнительную неразбериху создаёт и вынуждает перекладывать ответственность на сторонние инструменты, типа того же CheckerFramework'а...

windowSliding

интересно почему не человекочитаемое slidingWindow или просто window.

Думаю потому что есть windowFixed

А это как? Типа с фиксированным шагом делать? или типа чанками обрабатывать?

В статье есть пример

jshell> Stream.of(1,2,3,4,5,6).gather(Gatherers.windowSliding(3)).toList()
$4 ==> [[1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5, 6]]

Хотя насколько часто такое надо я не знаю.

Так про этот пример и возник вопрос - оно использует скользящее окно. Вы заявили, что есть ещё некий windowFixed, но не пояснили, что тот должен делать. Функции, которые используют последовательные окна вместо скользящих обычно зовутся chunk или bulk и их вариации.

windowFixed

jshell> Stream.of(1,2,3,4,5,6,7,8).gather(Gatherers.windowFixed(3)).toList()
$3 ==> [[1, 2, 3], [4, 5, 6], [7, 8]]

А есть API чтобы он то же самое делал, но без хвостов?

Нет. А что вы бы хотели сделать, отобросить последний массив [7,8]?

Да. У раста они соотвественно chunks и chunk_exact: первый нарезает на размеры и остаток прилетит из итератора в дальнейшую функцию, второй отдаст из итераторов только целые части, а остаток если надо можно взять по .remainder(). Ну, а скользящее окно просто window. Похожие имена API знаю были и в OCaml.

Java как язык догоняет C#. A .NET как рантайм пытается догнать Java.

Так и есть 😁

Вопрос про JEP-330. Выходит, что классическое разделение JDK/JRE больше не актуально и теперь всё в одном?

Актуально. JRE не может запускать нескомпилированные программы, потому что у него нет модуля jdk.compiler. Так что JDK всё ещё необходим для этого.

Sign up to leave a comment.

Articles