LINUX.ORG.RU
Новости — GNU's Not Unix  

JDK 12

 , , , ,


1

2

Стала публично доступной образцовая реализация Java 12 — JDK 12. С момента выпуска сборки №33 (три недели назад) не замечено ошибок уровня P1; таким образом, она становится официальным публичным выпуском, готовым к промышленному использованию.

Сборки OpenJDK от Oracle с лицензией GPL доступны здесь. Скоро, несомненно, появятся сборки других реализаций.

В этот выпуск включено 8 предложений по улучшению (JEP):

  1. 189: Shenandoah: экспериментальный сборщик мусора с малым временем прерывания;
  2. 230: набор миниатюрных эталонных тестов.
  3. 325: switch-выражения (предварительно);
  4. 334: API констант JVM;
  5. 340: один порт на AArch64 вместо двух;
  6. 341: архив обмена данными классов (CDS) из классов по умолчанию;
  7. 344: прерываемые смешанные сборки мусора в G1;
  8. 346: быстрый возврат неиспользуемой памяти операционной системе в G1.

А также, как обычно — сотни мелких улучшений и тысячи исправлений.

>>> Источник



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

 ← 1 2 3 4 5 6 →
Ответ на: комментарий от bbk123

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

Не должны, но встречаются. Ничего не мешает библиотеке возвращать объект класса, загруженного из зависимости. Тем более, если она возвращает интерфейс. А разруливать такие баги ой как невесело.

В любом случае версии модулей были отменены вовсе не из-за проблем с разными класслоадерами.

И так на 9+ никто не хочет переходить, чтобы не париться с этими модулями. А ты предлагаешь ещё больше людей запугать.

Legioner ★★★★★
()
Ответ на: комментарий от foror

Новая Java будет не на JVM

Чиво?

Эта платформа по сути легаси

И что же в ней несовременного?

тот кто изобретает на ней новый ЯП для 21 века сам себя загоняет в ловушку.

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

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Генерики в таком виде не нужны. Аннотации тем более. Лямбды тоже не нужны, анонимных классов прекрасно хватало. Дефолтные методы в интерфейсах это вообще нарушение ООП, в интерфейсах не должно быть реализации. Хочешь реализацию - сделай интерфейс, потом сделай абстрактный класс, в котором дефолтную реализацию для каких-то методов.

Legioner ★★★★★
()
Ответ на: комментарий от foror

Kotlin еще может в Javascript, WebAssembly и нативный код процессора - это вам к сведению.

Судьба Kotlin - полностью в руках JetBrains.

anonymous
()
Ответ на: комментарий от Legioner

Чиво?

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

И что же в ней несовременного?

Не умеет оптимально использовать ресурсы современного железа от микроконтроллеров до суперкомпьютеров.

тот, кто пишет компилятор с llvm загоняет себя в ловушку.

Отчасти, да. Но llvm это всё таки более низкоуровневое решение, поэтому прототип можно сделать и на нём. А еще лучше (для первого прототипа) тупо в Си конвертировать код...

JVM это качественная платформа с множеством библиотек

Нууу, скажем приемлемая, лучшая их худших.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от foror

Запихивание котлина в менюшки IDEA их не спасёт. Новая Java будет не на JVM.

Kotlin/Native умеет в LLVM. Так пойдёт?

DarkAmateur ★★★★
()
Ответ на: комментарий от anonymous

Kotlin еще может в Javascript, WebAssembly и нативный код процессора - это вам к сведению.

Ничоси! А я то пару лет пытаюсь придумать как джаву оптимально в жскрип конвертнуть. А они запили. И как, пол интернета на их решении сидит? Кто там из заметных главную страницу на котлине переписал?

Судьба Kotlin - полностью в руках JetBrains.

Всё верно, как наиграются ему хана.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от Legioner

Да и вообще со времён 1.4 ничего интересного в джаве не появилось. 

Optional, G1, функциональные интерфейсы и стримы с лямбдами (хоть и сомнительного качества). Кстати, дженерики вроде как в java 1.5 появились (хотя там тоже есть много острых углов)

upcFrost ★★★★★
()
Ответ на: комментарий от foror

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

Serbis ★
()
Ответ на: комментарий от anonymous

Binary tree

Node js 45.89

Java 8.32

Ну так, скорее плетётся а не пристраивается

upcFrost ★★★★★
()
Ответ на: комментарий от Legioner

Генерики в таком виде не нужны.

Лол, я видел легаси проект на java 1.4 , знаешь как там писали код? 

List /* AppUser */ loggedinUsers = credentialProvider.getLoggedin()
...
for (int i; i < selected.size(); i++) {
    AppUser user = (AppUser) selected.get(i)
    ...
}
Обрати внимание на коммент перед List

Аннотации тем более.

Добро пожаловать в мир без аннотаций: 

public interface MyService extends RemoteService {
  /**
   *
   * @gwt.typeArgs c <java.lang.Integer>
   * @gwt.typeArgs <java.lang.String>
   */
  List reverseListAndConvertToStrings(List c);
}
Это пример из GWT 2007-2010 годов, написание заглушки для Remote Procedure Call. Где @gwt.typeArgs это то что будет вытащено из javadoc перед компиляцией для генерации классов и всего прочего.

Лямбды тоже не нужны, анонимных классов прекрасно хватало.

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

Дефолтные методы в интерфейсах это вообще нарушение ООП

Интерфейсы не хранят состояний, потому дефолтные методы не проблема. И их ввод следствие введения лямбд. Кому нужны лямбды если их нельзя использовать против существующих реализаций коллекций?

anonymous
()
Ответ на: комментарий от Legioner

Хочешь реализацию - сделай интерфейс, потом сделай абстрактный класс, в котором дефолтную реализацию для каких-то методов.

Ага, под ним 10 сабклассов с максимум 1 оверрайдом, ещё фасад чтоб их выбирать и над фасадом фасадфактори чтоб делать фасад без передачи 100500 аргументов в конструктор. Ничего не забыл?

upcFrost ★★★★★
()
Ответ на: комментарий от anonymous

Но использование лябд делает код не только понятнее но и быстрее.

снимают метрику на холодной jvm

upcFrost ★★★★★
()
Ответ на: комментарий от anonymous

Ну кстати дженерики в яве правда шлак. Вот на днях было прям. Есть класс, есть билдер. Есть сабкласс, как сделать для него билдер? Делать getThis? Делать касты? Делать отдельный билдер без наследования и пытаться сделать чтоб они не разошлись при добавлении полей?

Ещё хуже когда есть конструкция для работы с интерфейсами типа <? super <T extends Model>>. Пытаться выкрутить к ней что-то новое значит пройти N+1 кругов ада.

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

Вылезай их крестопещеры, они во всех языках уже давно есть

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

Вылезай их крестопещеры

Не могу. Не понимаю я, как по-человечески определить зависимости скачанного jar-файла. Хоть убейся. Как?

Deleted
()
Ответ на: комментарий от foror

А я то пару лет пытаюсь придумать как джаву оптимально в жскрип конвертнуть.

Есть GWT, точнее было, его уже закопали, почти...

А вообще для жабоделевопера ничего не стоит освоить TypeScript, это фактически жаба без анонимных классов но с лябдами. Т.е. новых абстракций практически нет, кроме destructuring и более прокаченных дженериков, вот на последнем можно споткнутся если пытаться сделать совсем строгие гарантии по типам. А так очень легко осваивается, проще чем EcmaScript3. Я это говорю как жабокодер.

anonymous
()
Ответ на: комментарий от upcFrost

. Есть класс, есть билдер. Есть сабкласс, как сделать для него билдер?

Делать по билдеру на каждый класс.

и пытаться сделать чтоб они не разошлись при добавлении полей

Так билдеры либо расширяют абстрактный билдер, либо реализуют интерфейсы билдера. Потому они не разойдутся.

anonymous
()
Ответ на: комментарий от loz

Можешь подробнее?

На данный момент нет. Квалификации хватает только не хейтинг текущего развития ЯП (как разносторонний пользователь). Тот, кто сможет поподробнее должен разбираться в современном железе, ОСи строении и разработке прикладного ПО. Короче таких людей сейчас нет на планете (скорее всего) или единицы.

foror ★★★★★
()
Ответ на: комментарий от anonymous

А вообще для жабоделевопера ничего не стоит освоить TypeScript

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

foror ★★★★★
()
Ответ на: комментарий от foror

Короче таких людей сейчас нет на планете (скорее всего) или единицы.

Окей я понял)

loz ★★★★★
()
Ответ на: комментарий от foror

Новая Java будет не на JVM.

«Нормальные» языки весь рантайм несут с собой? JS + Electron/Node, GO, c# + .net core? Какой из них окажется в будущем? Кстати, так с рантаймом решили и для Java из-за чего jre уже легаси, вместо нее jlink который может из подмножества модулей jdk построить рантайм под приложение. Говорят получается 40 метров для Hello World с GUI.

anonymous
()
Ответ на: комментарий от foror

я не простой разраб на галерах

Да, по аве сразу видно, о солнцеликий!

Как же Вас такого непростого сюда то занесло?

anonymous
()
Ответ на: комментарий от anonymous

Обрати внимание на коммент перед List

Заставь дурака богу молиться, так он лоб себе расшибёт.

Добро пожаловать в мир без аннотаций:

Это аннотации, пусть и в комментариях.

использование лябд делает код не только понятнее но и быстрее.

На специально подобранном примере разница меньше 10%. При том, что я не вижу ни одной причины не компилировать анонимные классы так же, как лямбды, если уж хочется производительности. Т.е. то, что должно оптимизироваться прозрачно для программиста, зачем-то вынесли в фичи языка. Любой код с лямбдой это плохой код. С анонимными классами это хорошо видно, т.к. развесистая байда в глаза бросается и возникает подспудное желание от неё избавиться. От лямбды подспудного желания избавиться не возникает и в этом её проблема, она маскирует плохой код под хороший, хотя лямбда это тот же класс, тот же объект где-то в хипе, те же виртуальные вызовы, в общем куча просранных циклов процессора и байтов памяти.

Интерфейсы не хранят состояний, потому дефолтные методы не проблема.

Ну вон скала с трейтами и состояние может хранить. Описываем абстрактные get/set, класс-реализатор их неявно имплементирует, вот тебе и фактическое состояние в интерфейсе. Выкрутасов можно много придумать. Только концептуально это неправильно. Пускай тогда вводят множественное наследование и голову не дурят.

И их ввод следствие введения лямбд. Кому нужны лямбды если их нельзя использовать против существующих реализаций коллекций?

List интерфейс, в AbstractList добавить все нужные методы, всё, какие проблемы? Изначально надо было сделать IList < List, конечно, но и сейчас это не концептуальная проблема.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)

Жабушка, няшечка, ну наконец-то! С этими то фичами мы порвем этих напыщенных пердунов сишников. А к 20 релизу все дрова и ядра будут уже переписаны на жабе111 Век чая не видать!

anonymous
()
Ответ на: комментарий от foror

Нужно делать новый, простой, ООП ЯП, умеющий работать на всех уровнях.

Чем тебе Java 1.4 сложная?

Не умеет оптимально использовать ресурсы современного железа от микроконтроллеров до суперкомпьютеров.

Что ты понимаешь под «оптимально»? Java-подобный язык работает на сим-картах, на миллиардах смартфонов самой разной мощности. Оптимально и C не умеет, только какой-нибудь гуру-машинист, да и то не факт. На практике качество кода у JVM достаточно хорошее.

Впрочем, можно, дождаться валгалы и вот этого всего и смотреть, что из этого выйдет.

Можно. А что ты ожидаешь увидеть? 5% увеличение производительности и 10% снижение потребления памяти на некоторых сценариях? Чудес не будет, всё и так работает очень быстро. Все прорывы это единицы процентов.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Заставь дурака богу молиться, так он лоб себе расшибёт.

Я привел пример, сделай правильное именование переменных, чтоб еще информацию о типах несли. Похожий код был в очень, или даже ооочень, большом приложении. Там иерархий а абстракций было чуть меньше чем в IoC спринга.

Это аннотации, пусть и в комментариях.

Они «ненужны», а их во всю использовали, это было не только в GWT. Значит таки нужны?

развесистая байда в глаза бросается и возникает подспудное желание от неё избавиться

Суждение.

List интерфейс, в AbstractList добавить все нужные методы

Что?

anonymous
()
Ответ на: комментарий от Deleted

Не понимаю я, как по-человечески определить зависимости скачанного jar-файла. Хоть убейся. Как?

У uberjar нет зависимостей. А скачать отдельно jar - ты бинарь крестовый тоже отдельно качать собрался и через ldd ему либо ставить?

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

ты бинарь крестовый тоже отдельно качать собрался и через ldd ему либо ставить?

В определённых случаях приходится делать именно так. Так как зависимости jar определить?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от upcFrost

Ну и какой this у тебя вернёт метод абстрактного билдера?

Ты бы лучше код демонстрирующий проблему привел.

anonymous
()
Ответ на: комментарий от upcFrost

Optional

Не нужно, есть встроенный null.

G1

Деталь реализации. Нужно, но не существенно.

функциональные интерфейсы

Гадость.

стримы

Ужасающая гадость. Наоверинжинирили ради сомнительной фичи автоматического распараллеливания, которой никто не пользуется. В Kotlin вон сделали нормально.

Кстати, дженерики вроде как в java 1.5 появились (хотя там тоже есть много острых углов)

Вот именно. Были бы нормальные дженерики над произвольным типом, включая целочисленные, может быть и было бы нормально. А по факту жутко переусложнили простой и изящный язык ради фичи, которая даже не работает в рантайме.

Legioner ★★★★★
()
Ответ на: комментарий от upcFrost

Хз, о чём ты. Покажи конкретный пример, я тебя не понял.

Legioner ★★★★★
()
Ответ на: комментарий от upcFrost

Ну кстати дженерики в яве правда шлак. Вот на днях было прям. Есть класс, есть билдер. Есть сабкласс, как сделать для него билдер? Делать getThis? Делать касты? Делать отдельный билдер без наследования и пытаться сделать чтоб они не разошлись при добавлении полей?

Добавь класс в генерик-параметр билдера.

class Bla {
}
class BlaBuilder<TBla extends Bla> {
  abstract TBla build();
}

если я тебя правильно понял.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Я привел пример, сделай правильное именование переменных, чтоб еще информацию о типах несли. Похожий код был в очень, или даже ооочень, большом приложении. Там иерархий а абстракций было чуть меньше чем в IoC спринга.

Зачем? Есть комментарии у API, там и описать. Можно сделать статический анализатор, который будет ловить распространённые ошибки и всё это без какого-либо усложнения системы типов.

Они «ненужны», а их во всю использовали, это было не только в GWT. Значит таки нужны?

Ну их и сейчас используют. Просто не надо этого делать. Я не понимаю, для чего используется эта аннотация. Если скажешь, попробую придумать адекватную замену.

Что?

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

Legioner ★★★★★
()
Ответ на: комментарий от Deleted

Не могу. Не понимаю я, как по-человечески определить зависимости скачанного jar-файла. Хоть убейся. Как?

Никак. Точнее запускать и смотреть возникающие стектрейсы с ClassNotFoundException. Потом, по недостающему классу пытаться угадать jar. Но этим никто не занимается, никто не скачивает jar'ы либ вручную.

В стародавние времена, когда проекты строили ANT'ом, без управления зависимостями, тогда скачка jar'ов была. Как сейчас помню, в проектах создавали папку libs и туда клали third-party jar'ы. Это было 10+ лет назад. Теперь все используют билд системы, которые загружают все что нужно, все зависимости перечислены в билд конфигурациях.

Нынче приложения которые распространяются в виде jar файлов, содержат сразу все third-party классы, такие убер jar'ы собирают билд системами с посредством всяких assebly расширений.

anonymous
()
Ответ на: комментарий от Deleted

Не могу. Не понимаю я, как по-человечески определить зависимости скачанного jar-файла. Хоть убейся. Как?

Запустить его, посмотреть, на чём свалится, добавить зависимость, повторять, пока не заработает. По-человечески должен быть дистрибутив со всеми нужными jar-файлами. Ну или можешь написать тулзу, которая проанализирует все .class-файлы и найдёт все классы, на которые есть ссылки, и которых нет в JDK или этой jar-ке. Задача несложная, хотя для сложных приложений может работать не совсем правильно.

Legioner ★★★★★
()
Ответ на: комментарий от upcFrost 
public class Test {
    public static void main(String[] args) throws IOException, SQLException {
        var builder = MyBla.builder();
        builder.setX(1).setY(2);
    }
}

class Bla {
    static BlaBuilder<BlaBuilder> builder() {
        return new BlaBuilder<>();
    }
}

class MyBla {
    static MyBlaBuilder<MyBlaBuilder> builder() {
        return new MyBlaBuilder<>();
    }
}

class BlaBuilder<This extends BlaBuilder> {
    This setX(int x) {
        return (This) this;
    } 
}

class MyBlaBuilder<This extends MyBlaBuilder> extends BlaBuilder<This> {
    This setY(int y) {
        return (This) this;
    }
}
Legioner ★★★★★
()
Ответ на: комментарий от anonymous

«Нормальные» языки весь рантайм несут с собой?

Это как бы переплетающие вещи. Хотя по вашему сравнению jre и jlink, у нас с вами разное представление о рантайме. Я говорю о JVM, а вы о том какие библиотеки будут подключены к JVM.

JS + Electron/Node, GO, c# + .net core? Какой из них окажется в будущем?

Хз, но всё это легаси и одно недоразумение, к которому теперь приделывают костыли.

jre уже легаси, вместо нее jlink который может из подмножества модулей jdk построить рантайм под приложение

JRE и jlink по сути одно и тоже, оба запускаются на JVM, то что вы подключите немного другие библиотеки сути не меняет.

foror ★★★★★
()
Ответ на: комментарий от Deleted

Т.е. ты хочешь скачать jar, запустить его и JVM должна докачать нужные зависимости из интернета? Такого нет. Но зачем это надо? Зависимости описываются при сборке. А при запуске они должны лежать где надо. Проси тех, кто дал тебе эту урезанную jar-ку дать тебе полный дистрибутив. Можешь распаковать и полазить в META-INF, мавен туда любит pom.xml сувать.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

ты хочешь скачать jar, запустить его и JVM должна докачать нужные зависимости из интернета?

Нет. Я хочу «скачать jar и по-человечески узнать его зависимости». Как?

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 →
GNU's Not Unix