Comments 11
Ещё одна доработка большой фичи, появившейся в Java 9: Multi-Release JARs. Напомню, это возможность в одном JAR-файле иметь несколько версий одного и того же класса или ресурса, соответствующих разной версии Java.
Мне одному кажется, что это заведомо рудиментарная вещь? Она идет вразрез с имеющимися билд тулзами, процессом сборки и выкатывания, и вообще со здравым смыслом. Версионирование должно быть на уровне всей библиотеки, как это делается сейчас, а не отдельных классов. А уже рантайм должен (был) уметь цеплять версию библиотеки, соответствующей релизу, если такая присутствует.
Общее впечатление: я так понимаю, эволюция Java Api остановилась, и будущие изменения будут затрагивать по большей части JVM?
Мне одному кажется, что это заведомо рудиментарная вещь?
Пока неясно, но мне видится польза в том, что у вас один и тот же JAR-файл с разной версией JDK может работать с разной степенью эффективности без приседаний с рефлекшном. Представьте, что в новой версии JDK появился метод, который сделает код вашей библиотеки более быстрым. Однако напрямую использовать вы его не можете, потому что обещаете совместимость с предыдущей версией JDK. Можно собирать два джарика для разных версий JDK, но это очень неудобно и неэффективно. Пользователь не сможет автоматом получить преимущества, просто задеплоив приложение на сервер с более новой JDK: ему придётся иметь опциональные зависимости в проекте и знать при сборке, какая версия JDK будет на целевом сервере. Да и автору библиотеки неудобно поставлять несколько сборок. Если таких отличий немного, обычно втыкают грязный рефлекшн, а не плодят несколько версий библиотеки. С Multi-Release JARs можно обойтись без рефлекшна. Хотя неизвестно что лучше, потому что сборка проекта усложняется и поддержка в IDE далека от идеала. Время покажет.
Общее впечатление: я так понимаю, эволюция Java Api остановилась, и будущие изменения будут затрагивать по большей части JVM?
Вряд ли. Java 10 — это первый полугодовой релиз. До этого все колбасили большие фичи, стараясь изо всех сил их впихнуть в девятку, которую делали три с лишним года. А в эти полгода задела больших фич, которые можно пускать в продакшн, не осталось, поэтому релиз по большей части проходной. Но это не значит, что над большими фичами не работают, просто они будут позже.
Все зависит от глубины изменений. Если речь идет только о новом методе или классе, то самый безболезненный способ — это сделать обычный интерфейс-враппер, а имплементацию подключать динамически через factory или singleton. Уверен, что когда количество изменений вырастет, появятся всякие backport-библиотеки вроде retrolambda. Теперь представьте, что поменялась версия байткода. Тогда по-любому придется делать два билда с разными --target и собирать два разных джарника. Либо если произошла радикальная смена API как в случае с Java8, то вообще придется говорить о двух разных версиях библиотеки, собранной из разных исходников. Multirelease jars же все усложняют: лейаут проекта, компиляцию, сборку и тестирование. Вобщем, поживем-увидим. Пока что пипл не слишком с энтузиазмом относится к фиче.
Честно говоря, чтение это сайта породило еще больше вопросов. Вот это порадовало — "it may want to also remember the user's time zone, ..., smoker/non-smoker preference, meal preference (vegetarian, kosher, and so on), music preference, religion, party affiliation, favorite charity, and so on". Запасаюсь попкорном в ожидании поддержки форматирования в Jave в зависимости от сорта канабиса :)
instanceof всегда было для меня признаком плохого дизайна.static <E> List<E> copyOf(Collection<? extends E> coll) {
if (coll instanceof ImmutableCollections.AbstractImmutableList) {
return (List<E>)coll;
} else {
return (List<E>)List.of(coll.toArray());
}
}
Изменения в стандартной библиотеке Java 10