Релиз Java SE 9

тут об этом говорят: https://bugs.openjdk.java.net/browse/JDK-8145568

кроме как распарсить json без использования сторонних библиотек

Джава головного мозга

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

Еще один попался. Вот они пожиратели ваших ресурсов: «Гоните его, насмехайтесь над ним» (c)

Это говорит о высокой востребованности специалистов по Java.

Шарпей хорош под офтопиком.

Тем и хорош, что отбирает на себя посредственность.

То есть - фильтр для HR для отсева серости и «троечников».

«Моня» на GNU/Linux и macOS кроме смеха никаких эмоций не вызывает.

Все эти ZOG мега корпорации добра JPMorgan Chase & Co используют в mission critical applications только Java.

И только по остаточному принципу крупные компании банковского и финансового сектора используют решения (обычно внутренние системы учета офисного планктона) не от IBM и Oracle, а от мелкомягких.

https://www.superjob.ru/research/articles/111800/samye-vysokie-zarplaty-v-sfe...

JavaScript – весьма распространенный язык, но как правило, он является дополнением к другим языка программирования. Поэтому чистые программисты JavaScript нужны редко и ценятся невысоко.

Сегодня это исследование нельзя считать релевантным.

Скриптомакаку порвало.

Или о недостатке специалистов такого уровня.

Ну ладно х86 говно, которому надо консоль через браузер с жабой запускать, но свичи и схд чем провинились? К ним ведь есть нормальный доступ по ssh.

Да нет. Речь про то, что сегодня спрос на «чистых» js-еров есть и достаточно высокий.

Ты хочешь сказать, что больше нельзя запустить AWT и Swing-приложение под голыми X'ами без установленного Gtk2/3?

А я уже лет 10 считал, что оно кануло в Лету. А вот поди ж ты, релизнулось, како такое.

Написал функции, завел переменные, а промежуточную часть засосал как js script (на каждый проект свой), работающий с этими переменными и, если надо, функциями.

Для такого я у себя jython пользую, не любитель js. Они щас же вынесут это в отдельный модуль, и теперь никто не будет этим пользоваться совсем.

Я не знаю

Почему ты думаешь, что на C# пишут троечники, это личный опыт?

поставил на убунту 16.04, прогнал и оракловский и опендждк, даже проверил AOT, оверхед на запуск по сравнению с восьмой версией вырос в два раза и не меняется от того, прекомпиленый код или нет :( как была жаба непригодна для дестопа, так и осталась. И с модулями игрался, всё равно медленно. Что интересно, моно стартует заметно быстрее...

Java проиграла в войне по завоеванию десктопов. Но и dotNet также «не осилил» десктопную сферу, хоть он стоит на всех поддерживаемых Windows. Это самый большой парадокс в истории IT. Причём и способ интерпретации программ на переносимом байт-коде (JIT и AOT, соответственно) не имеет принципиального значения. Разработчики просто не хотят писать на Java и C# что-то сложное, навроде web-браузера и офисных приложений, а почему-то используют для этого связку с C++ и ECMAScript - налицо разделение труда программистов на back-end и front-end, на движки и визуальную часть. То есть сама среда настольных приложений диктует это разделение на красивый внешний вид и достаточно эффективный движок, чтобы не ощущать проблем. Универсальные переносимые среды не справились с этим. Проблема входа? «Дизайнерам» слишком сложно, а «движочникам» слишком примитивно?

Проверь сам.

Переименуй GTK-либы и попробуй позапускать Java-аппликухи.

Зачем так сложно? Во FreeBSD на время эксперимента достаточно переименовать /usr/local и /var/db/pkg, создать новые каталоги и накатить из ранее собранных пакетов X'ы, OpenJDK и JEdit, например, чтобы проверить запускаемость. Но чё-та лень.

Вы это в Jetbrains расскажите.

Весьма возможно.

Сравните уровень зарплат джавистов и шарпеев.

Естественно.

На обширном семействе различных фреймворков Spring работать - тут долго учиться надобно.

Это не под мелкософт поделием антипаттерн «волшебная кнопка»(С) в ГУЕ лабать.

Учите матчасть - GWT, GXT, Vaadin.

Скорее всего он может использоваться для пользовательских DSL.

Никогда не видел, тяжело даже представить, а вот groovy прекрасно справляется, вспомнить хотя бы gradle.

Он уже аж 2 версии. Это аж эквивалентно дот нету 4.6.1ДД

1) потребление увеличится

2) производительность не изменится

3) «разработчики» хрюкают у корыта и возбуждённо нахваливают всё, что им туда нальют из нововведений.

Никто ничего никогда не знает на достаточном уровне. А рефлексы у не совсем уж имбецилов за месяц на любом стеке вырабатываются.

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

В нормальном интерфейсе никаких реализаций «по умолчанию» нет. Потому что 1) требования отличаются. А где не отличаются, там память + цпу (у нормальных людей).

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

Это несерьёзно, их использование может позволить какой-нибудь монополист типа Гугла, в своих адвордс приложениях. Когда на переключение страниц секундные задержки. Но для стартапа это смерть.

Впрочем спасение будет, работаю над этим )

Никогда такой проблемы реально не было. Этой вознёй с интерфейсами неэффективно решают книжные проблемы.

Если у тебя не было, не значит, что ни у кого не было. Проблема как раз таки абсолютно реальная. Зайди в любую библиотеку на Scala и посмотри, сколько там методов в интерфейсе с реализацией.

Ну и жаба коллекшын АПИ ещё может обновили, вынеся что-то из абстрактных листов и прочей хрени.

Это да, тут проблема самая заметная была.

В нормальном интерфейсе никаких реализаций «по умолчанию» нет. Потому что 1) требования отличаются. А где не отличаются, там память + цпу (у нормальных людей).

Посмотри в Spring. Там на каждый интерфейс с кучей методов идёт какая-нибудь Abstract-реализация с кучей реализованных методов по умолчанию.

Что запускал?

В спринге «абстракт реализация» почти всегда с состоянием.

Обмазываться интерфейсами с «дефолтной» реализацией без состояния почти всегда не имеет практического смысла. А состояние зависит от реализации.

А скалу не пользую. Там знатные ООП наркоманы скалу создавали. Компилятору нужна фича «откинься на спинку кресла да выпей смузи» с экранами новых возможностей в процессе компиляции.

в интерфейсах теперь поддерживаются private-методы.

Жесть какая, они в курсе, что у них абстрактные классы уже есть?

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

Где действительно нужные вещи, где проперти, где алиасы для импортов, где value type?

Сочли не нужным копировать весьма спорные вещи из c#, что бы не захломлять язык.

В спринге «абстракт реализация» почти всегда с состоянием.

Далеко не всегда. Да и состояние проблем не представляет. Делаешь абстрактные getState[/setState] и оперируешь им, наследнику его реализовать тривиально.

Обмазываться интерфейсами с «дефолтной» реализацией без состояния почти всегда не имеет практического смысла. А состояние зависит от реализации.

Если пишешь библиотечный код — такие случаи бывают.

В случаях «Object getState()» это вообще не имеет смысла.

class Hello { public static void main(String [] args) { System.out.println(«Hello, world!»); } }

Никто ничего никогда не знает на достаточном уровне

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

У меня зп больше в пересчёте на ваши вечнодеревянные. И я никогда ничего не знаю из модной Java матчасти на достаточном уровне и открыто это заявляю тем, кто покупает мой труд.

А уроки сделал?

Ага, последние где-то лет 16 назад.

И я никогда ничего не знаю из модной Java

Что там модного-то для тебя? Джава это синоним динозавростроения.

Для меня - ничего. А для авторов кода, который доводится читать и менять - стримы, аннотации, спрингбуты и прочее говно.