JDK 12

Ты не должен хотеть скачать jar. Ты должен хотеть скачать дистрибутив программы.

Ты не должен хотеть скачать jar. Ты должен хотеть скачать дистрибутив программы.

С какой «радости»?

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

Открой в IDE интерфейс java.util.List и там посмотри классы которые его реализуют. Там будет длинный список реализаций List, из самых разных пакетов включая spring, hibernate и netty. А теперь добавь декларацию нового метода forEach в List специально для лямбд. Вот тебе и поломка всех реализаций. Хочешь всех заставить переписывать существующий код чтоб они обязательно расширяли класс AbstractList (на случай добавления новых методов в List и их реализаций в AbstractList)? А если их реализация уже наследуются от другого класса, что делать? Переписывать, делегировать вызовы? Публиковать несколько версий библиотек для разных версий Java?

Это сделали для миграционной совместимости. Обновляешь java8 и ничего не ломается, старые либы работают, да и тебе срочно фиксить код ненужно, при этом инчего не мешает начать использовать лямбды, даже против коллекций из либ которые были созданы до java8, лябды будут работать через fallback реализации методов, aka дефолтные методы.

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

Не стоит впадать в крайности.

Что ты понимаешь под «оптимально»?

Умение выжать из железа, для пользовательского кода, всю мощь, оставаясь при этом незаметным.

Java-подобный язык работает на сим-картах

Мне не нужен язык. Я говорю о рантайме. Синтаксис джавы более-менее оптимален. Достаточно посмотреть на современные поделки, чтобы понять, что синтаксис джавы вполне оптимален и все к нему приходят рано или поздно.

Оптимально и C не умеет

Так и его тогда на свалку истории.

На практике качество кода у JVM достаточно хорошее.

И как мне запустить JVM на современных микроконтроллерах с 512 КБ памяти? Я не спорю, что JVM оптимальна на бекенд решениях. Но у неё даже с десктопом куча проблемы, я уже не говорю о других кейсах.

А что ты ожидаешь увидеть?

Удобное АПИ для интрисиков, простой доступ к Си библиотекам, существенное снижение потребления памяти. В общем, я хочу тоньше управлять рантаймом, но при этом не хочу получить кресты.

С какой «радости»?

Потому, что jar это компонент приложения, а не полное приложение.

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

Потому, что jar это компонент приложения, а не полное приложение.

jar - это архив с классами, а компонент приложения постольку-поскольку. Так с какой «радости» мне качать весь пакет, если нужен всего один архив?

Умение выжать из железа, для пользовательского кода, всю мощь, оставаясь при этом незаметным.

Любая удобная абстракция это чаще всего компромисс с производительностью. Чудес не бывает.

И как мне запустить JVM на современных микроконтроллерах с 512 КБ памяти? Я не спорю, что JVM оптимальна на бекенд решениях. Но у неё даже с десктопом куча проблемы, я уже не говорю о других кейсах.

Ну минимальные требования по памяти у JVM есть, на 512 КБ не запустишь. Но у тебя очень узкое требование, подавляющее большинство компьютеров мощней, делать сложную JVM ради такого требования вряд ли имеет смысл. Под самые узкие ниши можно и специализированные языки применять.

Удобное АПИ для интрисиков, простой доступ к Си библиотекам, существенное снижение потребления памяти. В общем, я хочу тоньше управлять рантаймом, но при этом не хочу получить кресты.

Посмотри на D.

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

Никак. Такое непредусмотрено. Java изначально строилась с ленивой загрузкой классов, всегда была проблема сказать от чего зависит библиотека классов (jar), т.к. для этого нужно было бы каждый класс проанализировать и то не всегда бы сработало (поиск в classpath по имени). Теперь, с появлением java9 и модулей, jar файл может содержать список модулей от которых он зависит.

Не хватает своих на галерах?

Я так-то свободный художник, как там товарищ Бендер пел: «Пусть бесится ветер жестокий. В тумане житейских морей. Белеет мой парус, такой одинокий, На фоне стальных кораблей.»

jar - это архив с классами, а компонент приложения постольку-поскольку. Так с какой «радости» мне качать весь пакет, если нужен всего один архив?

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

Нет никакой практической необходимости хранить информацию о зависимостях

Точно?

Если не хочешь стать рабом жыдбрейнсов, то стоит определённо. Java уже не та, развивается быстро, скоро в неё перетащат плюшки из других JVM-языков и те станут не нужны, кроме от силы одного-двух — как уже было с многочисленными препроцессорными языками для JS.

Это кого? быструю рефлексию, что ли? :D

Мыши плакали, кололись, но продолжали копипастить с Опеннета?

Любая удобная абстракция это чаще всего компромисс с производительностью. Чудес не бывает.

Не бывает. Но всегда можно сделать лучше.

Но у тебя очень узкое требование

Почему узкое? В каждой современной железке эти микроконтроллеры. Огромное количество DIY поделок. И про десктоп ты скромно умолчал. А сколько с андроидом было мучений? Это тоже узкое требование?

делать сложную JVM ради такого требования вряд ли имеет смысл

Зачем делать сложную? Нужно делать простую, модульную, подключающую необходимые вещи под нужное железо. Другой вопрос, что текущую JVM уже не реально переделать под современные требования.

Посмотри на D.

Смотрел и ни один раз. Умных людей я там не наблюдаю.

И верню поню на аватарку, даже курносые недолошади смотрятся лучше, чем этот трап низшей расы.

кривой реализации стандартной библиотеки.

Как можно было во времена java 1.6 (2006 год) догадаться что через 10 лет будет хайп на лямбды?

-- Лямбды, лямбды, лямбды — кричала недовольная толпа.
-- Мы сделаем лямбды! — сказали девелоперы java.
-- А кому они нужны без коллекций? — кто-то спросил выглянув из кустов.

Повисла тишина...

-- Мы добавим методы в коллекции для лямбд.
-- Но вы же все поломаете и создадите фрагментацию.
-- Тогда.. тогда... тогда мы добавим методы которые не обязательно реализовывать.

Пагади. Ты два поста назад сказал что дженерики гадость

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

u wot m8? Стримы делались ради parallelStream? Ты серьёзно? Это просто сахар поверх коллекций, достаточно удобный насколько вообще могут быть удобными лямбды в явке

у JVM есть LTS релизы

Да, только последний LTS ломает совместимость и с восьмерки на него просто так не перейдешь. Ну, либо надо отключать фичи, эту вашу модульность. Ну и нахрена это надо? Ради нового GC и ключевого слова var? Я за форк восьмерки и продолжения нормального развития, а не вот этой всей хипсторни

Пусть лучше жаба, чем жс повсюду.

А что с жс не так?

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

Дофига кодирования просто ради кодирования.

Нет параллелизма, потребление памяти не лучше жабьего, а тормоз как бы не хлеще жабы.

Не бывает. Но всегда можно сделать лучше.

Ну как сделают, так приходите :) А пока JVM это довольно крутая штука. Хотя на .NET надо будет посмотреть.

Почему узкое? В каждой современной железке эти микроконтроллеры.

Вопрос не в числе микроконтролеров а в числе строк кода в них.

Огромное количество DIY поделок.

Для DIY поделок не проблема поставить 512 мегабайтов и не думать про память.

И про десктоп ты скромно умолчал.

А что о нём говорить? 512 MB у меня в десктопе было 15 лет назад. А в 2019 году память на десктопе это вообще не ресурс.

А сколько с андроидом было мучений?

Сколько? И от чего? На андроиде, кстати, не JVM, гугл слишком жадный. Была бы JVM, глядишь, и мучений было бы меньше.

Это тоже узкое требование?

Это не узкое требование. Но памяти для Java там хватает с большим запасом.

Красавица же.

Ну знаете ли, молодежь уже пристроилась сзади...:)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/node-yarv....

Как можно было во времена java 1.6 (2006 год) догадаться что через 10 лет будет хайп на лямбды?

А при чём тут хайп на лямбды? List раньше был вообще довольно ублюдочным интерфейсом и как его можно было имплементировать без AbstractList я не знаю, какие-то мазохисты видимо это делали. Его изначально сделали криво и лямбды тут не при чём.

Вот полный список методов в List в 1.4, которые предлагается реализовывать (и ещё что-то из Collection лень уже копировать):

    int size();
    boolean isEmpty();
    boolean contains(Object o);
    Iterator iterator();
    Object[] toArray();
    Object[] toArray(Object a[]);
    boolean add(Object o);
    boolean remove(Object o);
    boolean containsAll(Collection c);
    boolean addAll(Collection c);
    boolean addAll(int index, Collection c);
    boolean removeAll(Collection c);
    boolean retainAll(Collection c);
    void clear();
    boolean equals(Object o);
    int hashCode();
    Object get(int index);
    Object set(int index, Object element);
    void add(int index, Object element);
    Object remove(int index);
    int indexOf(Object o);
    int lastIndexOf(Object o);
    ListIterator listIterator();
    ListIterator listIterator(int index);
    List subList(int fromIndex, int toIndex);

хотя реально достаточно реализовать гораздо меньше.

Про разделение списков на ReadOnly и Mutable на уровне типов я даже не говорю, хотя стоило бы. Тоже сложно было догадаться что-ли.

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

Ruby и Scala не согласятся. Но это уже не интерфейсы как их понимали в early Java, а нечто иное.

Ну раз добавили, приходится использовать. Может я когда-нибудь упорюсь и форкну Java и стандартную библиотеку. Но пока пишем на том, что дали.

u wot m8? Стримы делались ради parallelStream?

Если ты откроешь код и посмотришь, как реализованы стримы, потом откроешь Sequence в Kotlin и посмотришь туда, ты поймёшь, что весь этот оверинжиниринг сделан ради parallelStream. На досуге попробуй реализовать свой класс стрима (с нуля, без хелперов), а потом свой класс Sequence-а.

только последний LTS ломает совместимость

Чем? Тем, что иногда печатает warning-и?

Это называется правильная иерархия и разделение ответственности между классами. Ты, конечно, можешь всю программу заинлайнить в static main.

Красавица же.

Ты наркоман чтоле?

Угу, это уже просто классы без полей. Осталось сделать последний шаг, назвать класс без полей implicitly interface и убрать это ключевое слово нафиг из языка :)

А пока JVM это довольно крутая штука

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

Вопрос не в числе микроконтролеров а в числе строк кода в них.

Ну да, можно даже писать на сях. Но, как я говорил выше, всегда ведь можно сделать лучше и удобнее. Работать с объектами, а не указателями. Иметь приятную IDE и т.д.

Для DIY поделок не проблема поставить 512 мегабайтов и не думать про память.

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

А что о нём говорить? 512 MB у меня в десктопе было 15 лет назад.

Вот именно, что не о чем. Прикладуху сегодня не делают на JVM. И тут не только в памяти проблема. Хотя я смотрел ZGC он очень крут. В целом, у JVM появляется шанс занять эту область после реализаций всех задумок из roadmap на ближайшие годы.

Но с другой стороны, они перестают выкатывать решения под Windows, JVM всё больше скатывается на бекенд и отрицает свой изначальный лозунг.

Сколько? И от чего? На андроиде, кстати, не JVM, гугл слишком жадный.

Не считал, но точно хватило, чтобы андроид отказался от JVM из 2007 года. Неспроста какой-то парень пилил далвик. И жадность гугла тут не обязательна. Далвик пилили до всей этой движухи со смартфонами. Будь JVM тогда очень хороша, никто бы далвик не пилил.

Но памяти для Java там хватает с большим запасом.

Это сейчас (да и то, только в последние пару лет). А в 2007 году не было столько памяти. И рынок не заканчивается на хайенд смартфонах, есть огромный рынок, где пользователи страдают из-за существующих, неэффективных рантаймов.

Очень много либ завязанных на 8

Например?

Но с другой стороны, они перестают выкатывать решения под Windows, JVM всё больше скатывается на бекенд и отрицает свой изначальный лозунг.

Вот именно поэтому и не делают. Чтобы написать нормальное графическое приложение, тебе надо написать биндинги на все WinAPI функции и фреймворк поверх них, инкапсулирующий их в объекты. И оно прекрасно будет работать и памяти жрать фиксированно мегабайтов 20 ну и сверху сколько сам сожрёшь. Самому это всё делать муторно и в нормальном виде никто не сделал. Корпорация это сделать может но, опять же, не сделала. Вот и не юзают. Жаваскрипт для десктопа тоже не юзали, пока кто-то не заморочился и не запаковал хром в электрон. Не вижу абсолютно никакой причины, по которой жава работала бы хуже электрона.

Корпорация это сделать может

Не может. Не думай, что они всесильны. Там еще те олухи сидят.

Поля в трейтах вполне могут быть. Но они там строго абстрактные, на уровне контракта типа.

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

Да, только последний LTS ломает совместимость

А когда еще ломать совместимость? Минорным релизам? Как раз самый момент. Одни переходят на новую версию, другие остаются на форке старой LTS, если ее кто-то подерживает, конечно.

Просто пидор, это же очевидно.

Чем? Тем, что иногда печатает warning-и?

Модульной системой. Она, правда, появилась раньше, но кто ж смотрит на не LTS релизы. И ещё они JavaFx выпилили.

Одни переходят на новую версию

В том-то и дело, что почти никто и не переходит. В том числе из-за этой модульной системы. Затраты на миграцию не стоят того.

А можно тут четко и ясно написать какая ЖАВА теперь фрии и что за шум (примерно год назад) когда куча разрабов на всех форумах кричали что ЖАВА теперь платная и нужно валить с нее ...

Так она опциональная и чтобы что-то действительно не заработало, надо передать специальные флаги, разве не так?

Oracle JDK платный, Open JDK - то же самое, но бесплатно, кроме этого есть и сборки от некоторых других компаний. В общем моя рекомендация - либо ставить Open JDK 11 от своего дистрибутива, либо качать здесь.

Тоже самое быть не может. Должна быть какая то разница, или чего то не хватает, или по условиям лицензии нельзя юзать для ...

Или OpenJDK это не Оракла ?

Тоже самое быть не может.

Может. Ну косметические различия есть: exe-инсталлятор для Windows в Oracle JDK, zip-архив в Open JDK, --version другая, ещё какая-то эзотерическая мелочёвка, можешь в интернете поискать список отличий.

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

По условиям лицензии Oracle JDK на халяву юзать коммерчески нельзя, да. Собственно лицензией они и отличаются по сути.

Или OpenJDK это не Оракла ?

Оракла. Собрано ровно с тех же исходников.