OpenJDK 8 met Webstart in Ubuntu 20.04 mogelijk?

[Josefien]

Mijn vraag
...
Ik zit te testen met Ubuntu 20.04 met het oog op dat ik misschien ooit van 16.04 moet upgraden. Maar ik loop nu al in de problemen met Java.

Er zijn 2 Java-programma's die ik regelmatig gebruik (en voor zover ik weet geen goede vervanger met GUI hebben):
- Geotag (http://geotag.sourceforge.net)
- BT747 (https://www.bt747.org/webinstall)

Geotag wordt zowel in .jnlp (Webstart) als in .jar aangeboden. BT747 heeft alleen een .jnlp.

Ubuntu heeft openjdk-8-jre en openjdk-11-jre in de repositories. En icedtea-netx voor de Webstart om die .jnlp bestanden te kunnen gebruiken.

Nu het probleem: Geotag in .jar variant werkt alleen met openjdk-8-jre. Maar die is niet installeerbaar samen met icedtea-netx. Die laatste wil per se samen met openjdk-11-jre geïnstalleerd worden en dan stopt Geotag ermee

Maar icedtea-netx heb ik wel nodig, omdat ik BT747 anders niet kan starten/gebruiken

Geotag .jar weigert te werken met openjdk-11-jre als in dat hij dan bij de eerste start eeuwig blijft hangen bij het start-logo. Pas bij nog een keer starten werkt hij, maar die 1e instantie blijft op de achtergrond hangen met logo, ook als die 2e instantie is afgesloten, hij moet uiteindelijk gekilled worden met een task manager. En de .jnlp is nog gekker: start wel, maar alle functies doen het niet... zelfs afsluiten niet en moet gekilled worden om van af te komen.


De situatie die ik moet hebben is dus openjdk-8-jre i.c.m. die Webstart-functionaliteit (icedtea-netx). Zeg maar de situatie zoals in Ubuntu 16.04 waar het perfect werkt.

Alleen, hoe voorkom ik dat icedtea-netx per se die versie 11 van OpenJDK meeneemt bij het installeren?


Relevante software en hardware die ik gebruik
...
Ubuntu MATE 20.04


Wat ik al gevonden of geprobeerd heb
...
Eerst openjdk-8-jre installeren en dan icedtea-netx samen met openjdk-11-jre. Ze lijken dan selecteerbaar bij het openen van een .jar, maar het werkt niet, uiteindelijk wordt toch 11 gebruik.

Ik heb ook Oracle Java 14 geprobeerd, maar ook geen werkt Geotag niet en die mist ook de Webstart-functionaliteit.

[Hero of Time]

Je kan niet voorkomen dat OpenJDK 11 er op komt. Dat is gewoon een harde dependency. Wat je wél kan doen, is de java die wordt aangeroepen door icedtea aanpassen. Op kantoor ben ik ook verplicht om Java te hebben om een stuk admin te kunnen doen. En de ontwikkelaars eisen keihard java 8, nieuwer jankt het en weigert het te starten.

Dus, wat had ik gevonden/gedaan? Kijk in /usr/lib/jvm. Daar zal je een symbolic link vinden met de naam 'default-java' of iets in die geest. Deze wijst naar de map voor openjdk-11. Verander die naar de map van openjdk-8 en het gaat miraculeus werken.

[Josefien]

Maar het probleem is nu niet zozeer dat Icedtea Java 11 oproept, maar dat Java 8 blijkbaar überhaupt niet meer gebruikt kan worden.

De .jar van Geotag gebruik namelijk geen Icedtea, maar wordt als je 'm dubbelklik gewoon direct met Java geopend. Echter, met rechtermuisknop kan je kiezen tussen 8 en 11... maar die 8 heeft hetzelfde probleem zodra 11 geïnstalleerd is... terwijl met alleen 8 geïnstalleerd er geen enkel probleem is.

[begintmeta]

Kan je niet via de shell/terminal of eventueel via een script (dat je ook via de grafische interface zou kunnen laten starten) de juiste java_home instellen en dan met javaws de betreffende jnlp opstarten? (Of java voor de jar)

[ Voor 5% gewijzigd door begintmeta op 17-06-2020 23:40 ]

[NESFreak]

Vroeger kon je vanaf de command line switchen tussen geïnstalleerde Java versies met

code:

sudo update-alternatives --config java

Misschien dat dat werkt

[Snake]

begintmeta schreef op woensdag 17 juni 2020 @ 23:39:
Kan je niet via de shell/terminal of eventueel via een script (dat je ook via de grafische interface zou kunnen laten starten) de juiste java_home instellen en dan met javaws de betreffende jnlp opstarten? (Of java voor de jar)

Dit is de betere oplossing.

Niet met PATH gaan spelen, maar een .sh maken die het PATH aanpast voor de huidige context en dan de .jar aanroept.

[Hero of Time]

@Josefien, je had het er toch over dat iets via java webstart niet werkt omdat het klaagt over java 11 en juist java 8 nodig heeft?

Als de versie niets uitmaakt voor webstart/icedtea, dan is de oplossing wat @NESFreak zegt, of je gebruikt het volledige pad van de java 8 executable: /usr/lib/jvm/openjdk-8-amd64/bin/java.

[Josefien]

Nee, er is een programma wat alleen als .jnlp (Webstart) beschikbaar is en die werkt wel met Java 11. Mat 8 niet geprobeerd, maar hij deed het onder de 8 van Ubuntu 16.04 wel.

Een ander programma wat een .jar is (maar ook beschikbaar als .jnlp als het moet) werkt alleen met Java 8.

Ik ben nu niet in de buurt van dat testsysteem, als ik er ben ga ik eens kijken of die Java 8 er überhaupt nog wel is nadat 11 is geïnstalleerd en niet stiekem is overschreven...

[Hero of Time]

Die is niet zomaar verwijdert. Dankzij het alternatives systeem kan je java 8, 11, 12, 13, 14 én 15 installeren als je zou willen.

Of Ubuntu moet iets idioots doen met dependencies en conflicts gaan opwerpen die nergens op slaan. Debian doet er iig niet moeilijk over.

[Josefien]

Hero of Time schreef op donderdag 18 juni 2020 @ 20:19:
@Josefien, je had het er toch over dat iets via java webstart niet werkt omdat het klaagt over java 11 en juist java 8 nodig heeft?

Als de versie niets uitmaakt voor webstart/icedtea, dan is de oplossing wat @NESFreak zegt, of je gebruikt het volledige pad van de java 8 executable: /usr/lib/jvm/openjdk-8-amd64/bin/java.

Die Geotag .jar lijkt het vooralsnog weer te doen door die Java 8 handmatig op te roepen met "/usr/lib/jvm/java-8-openjdk-amd64/bin/java -jar geotag-0.103.jar".

Maar nu is Java Webstart voor BT747 kapot blijkbaar, door eerder proberen met Oracle Java. Die had ik geïnstalleerd met een PPA: https://www.linuxuprising...cle-java-14-jdk14-on.html

Werkte niet voor Geotag dus ook weer verwijderd met apt remove. Echter, nu is Java Webstart kapot omdat 'ie nog steeds ergens verwijst naar die van Oracle:

code:

josefien@ws20:~/Downloads$ javaws BT747_J2SE.jnlp
selected jre: /usr/lib/jvm/java-14-oracle
thread 'main' panicked at 'Error spawning JVM process, java executable: [/usr/lib/jvm/java-14-oracle], arguments: [["-splash:/usr/share/icedtea-web/javaws_splash.png", "-Xbootclasspath/a:/usr/share/icedtea-web/javaws.jar:/usr/share/java/js.jar:/usr/share/java/tagsoup.jar:/usr/lib/jvm/java-14-oracle/lib/ext/nashorn.jar:", "-classpath", "/usr/lib/jvm/java-14-oracle/lib/rt.jar:/usr/lib/jvm/java-14-oracle/lib/ext/jfxrt.jar:", "-Dicedtea-web.bin.name=javaws", "-Dicedtea-web.bin.location=/usr/lib/icedtea-web/bin/javaws", "net.sourceforge.jnlp.runtime.Boot", "BT747_J2SE.jnlp"]]', src/os_access.rs:36:19
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Ik heb met "apt remove --purge icedtea-netx" hem verwijderd en weer opnieuw geïnstalleerd, maar Icedtea blijft naar Oracle verwijzen. Terwijl is hele /usr/lib/jvm/java-14-oracle al niet meer bestaat.


De eerder genoemde "update-alternatives --config java" doet wel de 8 zo instellen dat .jar dubbelklikken in de GUI ook wordt geopend met 8. Maar het verhelpt die kapotte Icedtea niet

[ Voor 4% gewijzigd door Josefien op 18-06-2020 23:43 ]

[Josefien]

Java Webstart is volgens mij kapot omdat "echo $JAVA_HOME" nog steeds verwijst naar die /usr/lib/jvm/java-14-oracle.

Alleen, ik weet niet hoe ik dat gewijzigd krijg. Er is geen enkel pakket van Oracle Java meer geïnstalleerd.

[imp-]

Uit interesse eens naar de oracle java 14 installer package uit die ppa gekeken, daar word ik niet echt gelukkig van

Ter zake:

Josefien schreef op vrijdag 19 juni 2020 @ 00:11:
Java Webstart is volgens mij kapot omdat "echo $JAVA_HOME" nog steeds verwijst naar die /usr/lib/jvm/java-14-oracle.

Alleen, ik weet niet hoe ik dat gewijzigd krijg. Er is geen enkel pakket van Oracle Java meer geïnstalleerd.

Waarschijnlijk heb je nog de oracle-java14-set-default package uit die ppa geïnstalleerd, deze installeert namelijk files in /etc/profile.d waardoor o.a. de JAVA_HOME variable in je shell nog deze waarde heeft.
Als dat het geval is, snel opgelost door de package te verwijderen dus.

[Josefien]

Met "update-alternatives --config java" kan ik de standaard Java-versie selecteren en dat heeft invloed op hoe .jar bestanden worden geopend in de GUI.

Dit heeft echter geen betrekking op Icedtea (.jnlp), die pakt altijd default-java en die blijft java 11, wat er ook met "update-alternatives --config java" is geselecteerd:

code:

root@ws20:/usr/lib/jvm# update-alternatives --config java
Er zijn 2 beschikbare keuzemogelijkheden voor het alternatief java (dat voorziet in /usr/bin/java).

  Keuze        Pad                                             Prioriteit Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      automatische modus
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      handmatige modus
* 2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      handmatige modus

Druk <enter> om de huidige keuze[*] te behouden, of typ een keuzenummer in: 2
update-alternatives: /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java wordt gebruikt om in de handmatige modus in /usr/bin/java (java) te voorzien.
root@ws20:/usr/lib/jvm# ls -l
totaal 8
lrwxrwxrwx 1 root root   25 jul 17  2019 default-java -> java-1.11.0-openjdk-amd64
lrwxrwxrwx 1 root root   21 apr 16 14:54 java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
drwxr-xr-x 7 root root 4096 jun 17 14:00 java-11-openjdk-amd64
lrwxrwxrwx 1 root root   20 apr 16 10:47 java-1.8.0-openjdk-amd64 -> java-8-openjdk-amd64
drwxr-xr-x 5 root root 4096 jun 18 23:12 java-8-openjdk-amd64
root@ws20:/usr/lib/jvm#

De link default-java gaat nog steeds naar 11 Is dat ook nog in te stellen naar 8 of moet de link handmatig aangepast worden?


En dit is ook raar: als ik in de GUI met rechts klik op een .jar kan ik kiezen uit Java 8 of 11. Maar in werkelijkheid is het geen keuze en pakt hij alleen hetgeen wat is ingesteld met "update-alternatives --config java". Dus als 8 is ingesteld resulteren beide keuzes in 8 en als 11 is ingesteld resulteren ze beide in 11. Waarom wordt er een keuze geboden als dat er eigenlijk niet is?

imp- schreef op vrijdag 19 juni 2020 @ 02:57:
Uit interesse eens naar de oracle java 14 installer package uit die ppa gekeken, daar word ik niet echt gelukkig van

Ter zake:

[...]


Waarschijnlijk heb je nog de oracle-java14-set-default package uit die ppa geïnstalleerd, deze installeert namelijk files in /etc/profile.d waardoor o.a. de JAVA_HOME variable in je shell nog deze waarde heeft.
Als dat het geval is, snel opgelost door de package te verwijderen dus.

Oh, dit doet 't hem Na verwijderen van dit pakket is $JAVA_HOME leeg en pakt Icedtea de /usr/lib/jvm/default-java en dat is Java 11.

Hoe kan ik zien op er nog andere Oracle Java spullen zijn achtergebleven? apt search laat niks meer zien, maar ik heb de PPA ook al lang verwijderd.

[Hero of Time]

@Josefien, die default-java is dus waar ik het over had die je met de hand moet aanpassen. Het is een symlink naar de java die in het package default-jre wordt toegekend. Dat is idd openjdk 11. Maar niets weerhoud je ervan om de link in /usr/lib/jvm te veranderen zoals ik heb gedaan. Die link wordt hooguit opnieuw gemaakt als er een update is van de default-jre package om een nieuwe versie (bijvoorbeeld 12) als standaard aan te wijzen.

Voor wat betreft zien wat er nog over is gebleven aan packages kan je met Synaptic kijken (als dat erop staat) onder de groep 'obsolete and local packages'