Ошибка запуска java

Пытаешься запустить 64 битный JDK на 32 битном дистрибутиве?

Сообщение об ошибке самообъясняющееся, хотя непонятно, как вы смогли установить это Java. Удалить и переустановить, если нужна эта версия. Если ставили не из хранилища, а загрузили дистрибутив, то его списать заново на случай если его архив дефектный.

Что говорит

file `which java`

Ну и выложи еще

uname -a

миллиардный раз объясняю. Пакеты java в дистрибутивах создают обычно шизики.

способ установки человека, котоырй не хочет потом бегать с голой жопой:

1) Качаем JDK с официального сайта. JDK, а не JRE! Распаковываем в папочку.

2) Прописываем переменную export $JAVA_HOME=, указывающую на то место, куда распаковали.

3) Добавляем export PATH=$JAVA_HOME/bin:$PATH

Если джава планируется запускаться от пользователя - то распаковывать в его домашнюю папку и прописывать экспорты в ~/.bash_profile (или ~/.bashrc)

Если джава планируется запускаться системно - то распаковываем куда-нибудь в корень (например, в /opt/jdk), переменные прописываем в /etc/profile.

Зачем заниматься этим рукоблудием, когда есть официальный rpm-пакет?

потому что описанное выше решение работает в 146% случаев, а практически любое другое (включая «официальный» rpm-пакет) - нет

JDK 8 же от Оракла будет в EOL для незаплативших очень очень скоро. JDK 11 еще даже не зарелизилось. Бета-версии 9 и 10 не предлагать. Какой из сайтов теперь официальным для JDK 8 (такой себе жабааналог Python 2.7) будет?

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

потому что описанное выше решение работает в 146% случаев

146 лет в арче ставлю из репы, все работает на ура.

Arch Linux не предназначен для работы, поэтому эта делёжка опытом не актуальна. Но я как-то был на компьютерных курсах, где изучалась одна программа на Java. Преподаватель был слабый - знал ненамного больше, чем рассказывал. и излагал так, что я ничего бы не понял, если бы и без того это не знал. Неудивительно, что он поставил на учебные компьютеры Arch Linux, и совсем не удивительно, что программа зависала. Я проверил её в Debian и Fedora - как я и ожидал, работала нормально. JDK может понадобиться до двух версий- 10 и (для старых программ) 8. Сам он бывает двух видов - OpenJDK (этот входит в хранилища) и Oracle JDK (этот списывается с сайта Oracle). Иногда энтузиасты предоставляют свои PPA архивы со стандартным JDK.Но это не основной способ установки.В общем, стандартный JDK от Oracle лучше тем, что больше проверен, и производители некоторых важных программ тестируют их на совместимость с ним. Но может устроить и OpenJDK. У автора вопроса проблема в том, что он поставил JDK неправильно. Из его описания не видно, как. Может, архив битый или он запускает 64 битный JDK в 32 битной ОС. В общем, убрать этот ущербный JDK и установить заново, ознакомившись с инструкцией, как это делать.

именно так ставится оракловая java из ppa на дебиан-бубунту.

Судя по всему у тс проблемы как раз от того что он руками её ставил. Ну или рач какой-нить.

новые сборки джавы будут раз в полгода. Рекомендую обновляться раз в полгода. Это новая политика Партии, от нее никуда не деться. Все кто будут пытаться делать вид, что ничего не произошло - будут жутко мучиться, и решения этому нет никакого. Комьюнити _специально_ позаботилось, чтобы этому не было никакого решения.

для легаси проектов, которые на JDK11 не запускаются, можешь использовать сборки от Азула, они обещали патчить беслпатно: https://www.azul.com/downloads/zulu/

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

Откуда инфа?

Я лично остаюсь на восьмёрке и просто не буду обновляться, если не найдётся серьёзный вендор. Мне нужна 32-битная джава, которая нормально работает на XP. Про обновляться раз в полгода это вообще несерьёзно.

Таких людей про «обновляться несерьезно» оказалось исчезающе малое количество. Проще на них забить.

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

Если джава планируется запускаться от пользователя - то распаковывать в его домашнюю папку и прописывать экспорты в ~/.bash_profile (или ~/.bashrc)

Если джава планируется запускаться системно - то распаковываем куда-нибудь в корень (например, в /opt/jdk), переменные прописываем в /etc/profile.

За такой способ прописывания переменных в приличном обществе бьют по лицу. Особенно, если это сервак. Нормальные люди пишут wrapper script и кладут его в /usr/local/bin или в $HOME/.local/bin.

да неважно как $PATH записывать. Важно чтобы все зависело от тебя, а не от админа сервера (который может и не дать тебе права на bin), и не от создателя дистрибутива

более лучший вариант - Docker. Стараюсь теперь совершенно все запускать в нем.

Пакетики восьмерки в шапке/бубунте по крайней мере еще долго будут поддерживать.

Откуда инфа?

Тынц - https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_v...

Вроде October 2020 для jdk8 это не очень уж и долго, всего на полтора года дольше чем Oracle Java 8. Но внимание, тынц на предыдущую версию этой страницы:

http://web.archive.org/web/20160616025330/https://access.redhat.com/articles/...

Срок поддержки для jdk7 продлили на 2 года, а для jdk8 оставили таким же, что есть очень нелогично, так как переход jdk7 -> jdk8 гораздо менее болезненный чем jdk8 -> jdk11. Отсюда логично предположить, что поддержку jdk8 тоже продлят года на 2. Шапка продает саппорт на ЖиБосс, и покупатели очевидно будут хотеть поддержку jdk8 на все время пока ЖиБосс не научится в jdk11 и пока все бузинесс-критикал приложения на jdk11 переведут (т.е. - никогда).

Пакетики в CentOS 7 == пакетики в шапке 7 (тупая пересборка). Пакетики в бубунте - ну очень похожи на пакетики из шапки помимо именования.

Рекомендую обновляться раз в полгода.

Ах-ха-ха, ну конечно, все жабаынтырпрайзы сразу запишутся в бета-тестеры. LTS версии есть для юзеров же. А у jdk8 есть все шансы стать «супер-LTS» по примеру Python 2.7.

более лучший вариант - Docker

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

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

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

Я лично остаюсь на восьмёрке и просто не буду обновляться

+1, как и руководства многих разумных ынтерпрайзных предприятий.

Про обновляться раз в полгода это вообще несерьёзно.

+2, если Партия будет заставлять обновляться каждые полгода на новую мажорную версию, то обновления будут происходить «на другой язык».

Мне нужна 32-битная джава, которая нормально работает на XP

Рекомендую мониторить следующие места на предмет jdk8-32-bit-оффтоп:

https://adoptopenjdk.net/ https://www.azul.com/downloads/zulu/zulu-windows/ https://github.com/ojdkbuild/ojdkbuild#other-downloads https://developers.redhat.com/products/openjdk/download/

Из них AdoptOpenJDK - самое официальное место, там правда вроде нет сейчас 32-битных сборок, но они известные слоупоки и вполне могут добавить 32-бит позднее.

Спасибо, понятно.

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

никаких left-pad, если ты об этом

На компьютере, с которого сейчас пишу, JDK 10.0.1 apt-get'ом нормально установился.

А вот Eclipse Photon я ставил в /opt ручками.

Mint 19.

На работе в «продакшене» JRE и JDK ставлю только ручками.

PS. Еще ANT_HOME и M2_HOME тоже желательно указать.

В enterpriZe никакого «бардака» нет.

А есть Oracle и IBM.

Бардак - это LAMP - пых-пых, гвидопых и прочие кустарные поделия от кульхацкеров-одиночек.

этот входит в хранилища

этот списывается с сайта Oracle

Это ты сейчас на каком языке пишешь?

А есть какие-нибудь доки или мини-книжки/статьи про новые «фишки» в 9-10-11 java для тех, кто на ней редко пишет? Так сказать, понять, что нового по сравнению с 8-кой.

Real World Java 9

Java 10 and IntelliJ IDEA

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

там везде есть раздел Features, где приведен список JEP, в которых четко и конкретно, грамотными людьми, описано - что это такое, зачем нужно, как посмотреть

http://openjdk.java.net/projects/jdk/11/

http://openjdk.java.net/projects/jdk/10/

http://openjdk.java.net/projects/jdk/9/

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

А в 10 и 11 там по сути, всякая минорщина. Не факт что на ЛОРе бы про такое разрешили писать мини-новость.

Нет в этом ничего жуткого, необычного. Чего-то такого, что разработчики на почти любых других технологиях не видели бы при самых обычных обновлениях

Как обычно, истерят в основном белки-истерички

Ну, а как вообще, сообщество/опенсорс, пишет под 9-10-11 или всё медленно движется?

Если ты об backward compatibility, то все основные вещи давным-давно совместимы вплоть до 11. Специально собиралась статистика, были какие-то тэги в твиттере, но это уже не актуально. Всё просто работает. За исключением вещей вроде JavaEE и Nashorn.js, которых просто выбросили из JDK на мороз.

Основной дизастер был за пару месяцев до и после выхода 9 в прошлом году. После этого уже не было ченжей, чтобы что-то там поломалось. Ченжи вроде добавления Shenandoah GC приносят новые крутые фичи и не способны что-то поломать на уровне пользовательского API

Если ты о версии кода, то понятия не имею. Скорей всего, внедрение идет только на уровне совсем новых с смелых проектов, в том же Spring. Проблема в том, что forward compatibility нет, собранное под 11 не запустится на 8, и соответственно возникает вопрос - готовы ли проекты потерять всякий совсем кровавый ынтерпрайз из своих клиентов. Думаю что до выхода JDK 11 и сбора реальной статистики - сколько больших компаний перекатились с 8 на 11 - охотников будет немного.

Прямо сейчас охотники будут в end-user продуктах. Охотники среди системных либ подтянутся где-то через год, когда до значительной части сообщества дойдет озвученная выше мысль: обновляться можно и нужно, а сидеть на LTS - это удел совсем кровавых ынтерпрайзов с кромешным говнокодом. Сейчас вам это кажется дичью, но как говорится - «запомните этот твит» (с)

Кишори Шаран «Java 9. Полный обзор нововведений» для быстрого ознакомления и миграции. ДМК Пресс, 2018. ISBN 978-5-97060-575-2

Есть и не мини-книжки. Наиболее важное нововведение в Java 9 - система модулей. Надо ознакомиться с ней, чтобы решить, как использовать в своих разработках. Остальное больше относится к удобству. Но JDK 9, хоть он и новый, не имеет особого смысла использовать ввиду наличия JDK 10. В котором однако изменения в самом языке незначительны. Так что изучать нововведения можно по литературе о JDK 9, а пользоваться JDK 10. JDK 8 оставить для программ, которые ещё не проверены на совместимость с JDK 10.