выбор openjdk в idea

file что говорит?

Оказывается, можно проще.

$ ls -lA /usr/lib/jvm/

total 8

lrwxrwxrwx 1 root root   20 Aug  8 12:32 java-1.8.0-openjdk-amd64 -> java-8-openjdk-amd64

-rw-r--r-- 1 root root 2600 Aug  8 12:32 .java-1.8.0-openjdk-amd64.jinfo

drwxr-xr-x 7 root root 4096 Sep 28 08:38 java-8-openjdk-amd64

Поверь человеку, который пишет на Java уже более 10 лет.

Никогда, никогда не используй JDK из дистрибутива!

Идешь на сайт Оракла, или Азула, и качаешь сборку. Кладешь куда хочешь и прописываешь в PATH. Вот так - правильно.

Идешь на сайт Оракла, или Азула, и качаешь сборку.

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

Кладешь куда хочешь и прописываешь в PATH. Вот так - правильно.

Вот так - неправильно, как раз таки. Пакетов с проприетарной Оракловской жабой, пруд пруди. Почти во всех дистрибутивах. И оно как правило, прописывает себя в alternatives.

Поверь человеку, который уже больше 10 лет наблюдает на ЛОРе за теми, кто пишет на Java. Java повреждает мозг, подтверждением чего будет чувак с 5 звёздами выше. Не трогай каку.

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

Если боишься злого оракла и очень не лень, можно пойти и скачать исходники openjdk и собрать их самостоятельно. Я так и делаю (по той причине что хачу исходники openjdk). Еще вроде как где-то в недрах java.net была репа с готовыми сборками именно openjdk, но я к стыду не могу нагуглить этот урл

Самое главное в этом - никогда, никогда не связываться с мантейнерами дистрибутивов, которые выполняют эту работу. Что Debian/Ubuntu, что ArchLinux, что куча других дистрибов - они ничего не понимают в Java. Например, они пытаются паковать джарки в отдельные гну-линукс-пакеты и потом переиспользовать их. Очевидно, они тронулись умом, и я бы не стал надеяться на качество работы поехавших :)))

В alternatives лучше тоже не прописывать. Самый лучший, проверенный годами метод - в /etc/profile или ~/.profile ипрочие ~/.bashrc прописать две вещи: переменную $JAVA_HOME, и export PATH=$JAVA_HOME/bin:$PATH. Если хочется переключать версию джавы (например, для разработки), в профиль добавляешь функции типа:

export JAVA8_HOME=/opt/java8
export JAVA9_HOME=/opt/java9

function java8() {
  export JAVA_HOME=$JAVA8_HOME
  export PATH=$JAVA_HOME/bin:$PATH
}

В alternatives нужно прописывать на проде, но это гемор и к обычному пользователю или разработчику никак не относится

Но для написания простых программ, с целью обучения, и минесруфта - зачем?

для того чтобы не греть мозг идиотскими проблемами, которыми переполнен ЛОР по тэгу Java.

Большинство этих проблем решаются одним простым алгоритмом: а) скачать сборку, которую собрали профессионалы, а не кто попало. В данном случае это или официальный сайт openjdk, или oracle, или azul. б) и прописываешь её вручную самым простым и действенным способом: переменная JAVA_HOME и PATH. Любых хитрых утилит избегаешь любой ценой.

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

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

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

Спасибо за ответы. Я не компетентен в проблемах java сборок; инфу про официальные сборки openjdk учту.

Есть ещё несколько вопросов,

1) oracle jdk и openjdk - не одно и то же( первая - проприетарная сборка, вторая - собранная с открытых исходников)?

2) сейчас у меня (debian 8, idea) используется декомпилятор при открытии сорцов класса. Есть ли способ заставить её открывать исходники?

1) oracle jdk и openjdk - не одно и то же( первая - проприетарная сборка, вторая - собранная с открытых исходников)?

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

сейчас у меня (debian 8, idea) используется декомпилятор при открытии сорцов класса. Есть ли способ заставить её открывать исходники?

при открытии сорцов какого именно класса, откуда он берется?

если ты имеешь в виду какие-то библиотеки, которые ты используешь в своем проекте, то тут всё просто. Сейчас все современные джава-проекты собираются с помощью Maven (ну или Gradle) - на первое время можно думать о нем как о пакетном менеджере типа pacman/apt/yum/etc, но специально для джавы. Зависимости на внешние библиотеки указываются в настройке dependencies в Maven. Переведи свой проект на Maven - после этого Идея начнет выкачивать из репозитория не только джарки библиотек, но и их исходники. И переход совершенно автоматически будет происходить не в декомпилятор, а в настоящие исходники.

инфу про официальные сборки openjdk учту.

думаю что пакетам в операционных системах Red Hat Enterprise Linux и Oracle Linux можно таки относительно доверять. Ибо бизнес этих компаний напрямую зависит от того, чтобы с джавой в их дистрибутивах всё было идеально.

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

да ;)

ну или как вариант - школьники отупели настолько окончательно, что могут зафакапить даже простейшую процедуру сборки

Мне кажется, что проблемы не столько в Java (у меня опенсорсная Java без проблем работает и проги под неё собираются как положено), сколько в недодистрибутивах и кривых руках (если дистрибутив - Gentoo).

ну или как вариант - школьники отупели настолько окончательно, что могут зафакапить даже простейшую процедуру сборки

Яхз какие у тебя там школьники, но в моей уютной генте oracle-jdk-bin без проблем ставится из портажа.

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

gentoo - недодистрибутив?

Если в строчке

import java.util.Arrays;

нажать f4 - запускается декомпилятор, вместо открытия сорцов.

требует прямых рук, спокойствия и времени

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

С флагами чего? У меня с firefox была проблема только с custom-cflags: он падал иногда. Но firefox - тот ещё монстр.

Можно подумать, что Java не монстр.

хачу исходники openjdk

Лада седан баклажан?

Присмотрись внимательно - наверху должно быть предложение скачать сорцы либо указать их расположение.

Неужели $JAVA_HOME где-то ещё нужно прописывать/использовать? Во FreeBSD с OpenJDK6 это уже не нужно было.

я не нашел спеки, но «интуитивно»(с) понятно следующее: java из alternatives (/bin/java, /usr/bin/java) - это джава для запуска софта из дистрибутива. $JAVA_HOME - это то место, откуда в первую очередь пытается подхватить её всякие Томкаты (см. catalina.sh). Или например Идея - она берет в качестве джавы то, что записано в IDEA_JDK, если нет - JAVA_HOME или JDK_HOME, если нет - то что в path, если нет - ошибка. Также из $JAVA_HOME ынтерпрайзный софт берет путь до javac чтобы чегой-то там отконпелировать, или например используется в качестве пути по умолчанию в говноинсталляторах (первым на ум пришло КриптоПро).

То есть на уровне самого JDK эта переменная не нужна, но на уровне ынтерпрайзного софта продолжается политика недоверия к тому, что создатели дистрибутива засунули в PATH.

import java.util.Arrays;
нажать f4 - запускается декомпилятор, вместо открытия сорцов.

што, опять?! :))) ar u fucking jocking?

наверное, в твоей сборке openjdk нет сорцов. Скорей всего там есть какой-то отдельный пакет типа pacman -S openjdk8-src (циферку поменять, в зависимости от версии жабы).

необходимость знать такие подробности нейтрализуется простейшим алгоритмом:
а) скачать JDK с сайта Oracle
...
и дальше по тексту :)))

важно понимать, что Идея берет для проекта JDK не из PATH, а из того, что ты сам туда настроил. То есть нужно пойти в File -> Project Structure -> Project, нажать кнопку New напротив Project JDK и указать нужное. Это совершенно необходимый шаг, т.к. обычно при разработке у тебя на жестком лежит куча разных версий JDK, и для IDE не имеет особого смысла угадывать её из PATH.

решением проблемы была установка пакета openjdk-8-source, и в настройке проекта в sourcepath указать на src.zip. Теперь все ок.

Сборки оракла и азула почти полностью совпадают с openjdk

У оракла жаба мало что с закрытыми добавками, так еще и нет unlimited crypto по дефолту. Это просто срамота, в 2016 году ковыряться с policy файликами после установки.

И не путай мейнтейнеров пакетов в арче и в RHEL/CentOS. Первым эта жаба куда шла туда и ехала. А вторые продают JBOSS поддержку со своими сборками OpenJDK и помимо плюшек вроде приложенных сорцов JSSE и интеграции с системной tzdata, тестируют эти сборке на той самой версии RHEL, а не на говне мамонта в котором оракул вынужден свои бинарники собирать для «совместимости с разными линуксами». А еще судя по недавней Jocker conf, производительностью сборок в RHEL теперь занимается известный в узких кругах Л. Шипилев.