Package Details: jre8 8u341-1

Git Clone URL: (read-only, click to copy)
Package Base: jre8
Description: Oracle Java 8 Runtime Environment LTS
Upstream URL:
Keywords: java-openjfx java-runtime-headless-jre java-runtime-jre java-web-start-jre
Licenses: custom:Oracle
Provides: java-openjfx, java-runtime, java-runtime-headless, java-runtime-headless-jre, java-runtime-jre, java-web-start, java-web-start-jre
Submitter: Det
Maintainer: severach
Last Packager: severach
Votes: 42
Popularity: 0.070301
First Submitted: 2017-09-21 22:18 (UTC)
Last Updated: 2022-08-08 02:44 (UTC)

Required by (1525)

Sources (2)

Latest Comments

severach commented on 2021-02-09 03:58 (UTC) (edited on 2021-02-09 04:00 (UTC) by severach)

I see two types of missing libs. libavcodec and libavformat have many versions and use the one that matches the libs on your system. The versions I don't have all show errors and the version I do have (58) shows no errors. libawt, libjvm, and others are Java internals. Because you can have multiple versions of the jvm installed, these libs can't be placed where ldd can find them. Java must resolve these at runtime to the correct version. This looks like a bug in rebuild-detector for jre8 jdk8 because manually checking jdk8-openjdk jdk11 jre11 libs shows all the same missing libs but are not listed. A quick check with strace shows that libjvm is found just fine.

bartus commented on 2021-01-24 13:49 (UTC) (edited on 2021-01-24 13:55 (UTC) by bartus)

I've tested jre8 with modified rebuild-detector and there are some dangling symbols and missing shared object. This could be a source of problem whit one of my packages (openboard)

Could this missing stuff be fixed by including some extra deps?

jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/
unresolved symbols: jws_g_list_length jws_g_list_nth_data native_trace
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/
unresolved shared objects:
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/
unresolved shared objects:
jdk8: /usr/lib/jvm/java-8-jdk/jre/lib/amd64/
jdk8: /usr/lib/jvm/java-8-jdk/lib/amd64/
unresolved shared objects:

Google only finds single reference to jws_g_list_length referencing oracle community post suggesting archives for old java are corrupted...

Erus_Iluvatar commented on 2020-12-18 17:00 (UTC)

Hi, please don't set PKGEXT in you PKGBUILD : this overrides makepkg.conf in which I don't compress packages.

severach commented on 2020-07-08 16:10 (UTC) (edited on 2020-07-08 16:11 (UTC) by severach)

Bumping pkgrel will make everyone upgrade. No need to upgrade when all current installs are just fine. Also, if dropping JCE causes a problem I'd rather hear about it from new users than long time users who's everything suddenly breaks. The drawback of not changing pkgrel is that users who were having a problem won't get a version change to show that their problem is fixed.

aminvakil commented on 2020-07-08 07:07 (UTC)

Just out of curiosity and to be sure, you haven't bumped pkgrel in two latest changes becuase the final package hasn't changed and you have just changed how it downloads and stuff, am I right or was it because of something else?

kristianjgs commented on 2020-07-07 22:21 (UTC)

==> Validating source files with md5sums... ... FAILED jre-8u251-linux-x64.tar.gz ... Passed policytool-jre8.desktop ... Passed ==> ERROR: One or more files did not pass the validity check!

teafix commented on 2020-02-09 23:37 (UTC)


I've tried installing this both using pikaur and manually. The symlink is not made during the install, when adding it from the CL it doesn't appear in Firefdox and when trying to insert it manually in Firefox ESR the response is "This addon could not be installed because it appears to be corrupt". This happens whether adding the symlink from /usr/lib/mozilla/plugins or from /usr/lib/firefox/plugins when trying from CL.

For clarity, this is a first installation not an update. I am trying to install FF-ESR with JRE on a laptop.

dmftradutor commented on 2019-11-03 02:16 (UTC)


I was getting the error below while trying to update ($ pamac update --aur). FALHOU = FAILED I solved this by downloading the file from Oracle website and pasting it over the corrupted one in /var/tmp/pamac-build-{username}/jre8

Now update is working again.

Construindo jre8... ==> Criando o pacote: jre8 8u231-1 (sáb 02 nov 2019 22:57:54 -03) ==> Verificando as dependências de tempo de execução... ==> Verificando as dependências de tempo de compilação... ==> Obtendo fontes... -> Encontrado -> Encontrado jre-8u231-linux-x64.tar.gz -> Encontrado policytool-jre8.desktop ==> Validando source arquivos com md5sums... ... FALHOU jre-8u231-linux-x64.tar.gz ... Passou policytool-jre8.desktop ... Passou ==> ERRO: Um ou mais arquivos não passaram na verificação de validade!

Link to file:

Kastilo commented on 2019-07-09 00:47 (UTC) (edited on 2019-07-09 00:59 (UTC) by Kastilo)

I'm getting a checksum error in downloading jre-8u211-linux-x64.tar.gz

File provided here has a hash of MD5: E7A6B33DEB17C66D46BEB42F1B8CF3BC SHA-1: 5CDF22F3835DB4719DE221E6F9BD52AD1D73D0FC SHA-256: DB3BA91C78B950269380D8F6872BEFED94176F619CEFBCD7877E3624512E0218

File downloaded by AUR package is MD5:90E2DE207EB73255D2B3C75C790C1883 SHA-1: 568A324A5B65DE11C9BC76942A19D6BCE41863E4 SHA-256 E6599E6AC633B00CED6EB16533735A9E344CCA2A268F2DAEFC3546FA47D63DE0

Any recommendations on to proceed or not?

EDIT: Bypassed by replacing server downloaded file located in /var/pacmac-build-$username with file downloaded from link in sources description and building, bypassing differently hashed file

commented on 2019-04-22 18:43 (UTC)

In fact, the downloaded file (with aria2c) is an HTML file with title "Unauthorized Request" that also appears when I request the URL in my browser and with wget. It says it needs some cookies set... To be clear, this seems to be the URL:

severach commented on 2019-04-18 20:18 (UTC)

@biosin: I rm the file and makepkg -sCo. The checksums are fine.

commented on 2019-04-18 20:10 (UTC)

I'm getting a checksum error

==> Validating source files with md5sums... ... FAILED

severach commented on 2019-01-21 18:34 (UTC) (edited on 2019-01-21 18:35 (UTC) by severach)

I fixed the msg2 lines to handle makepkg --nocolor.

petaramesh commented on 2019-01-21 15:23 (UTC)

Hi, Package build fails here with : /usr/share/makepkg/util/ ligne 58: BLUE : variable sans liaison

Det commented on 2018-10-24 17:14 (UTC)

Can't repro?

renatocan commented on 2018-10-22 17:32 (UTC)

I've tried to install and got an error: "rename: error: unrecognized arguments: lib/desktop/mime/packages/x-java-archive.xml"

Det commented on 2018-07-19 17:11 (UTC) (edited on 2018-07-19 17:15 (UTC) by Det)

No, you're missing the point :D.

Please read, eg. here:

Or my question (less technical):

Or the old Wiki entry (even less technical):

MarcinWieczorek commented on 2018-07-19 16:47 (UTC)

Okay then, let's extend the scope of the article:

The checksum type and values should always be those provided by upstream, such as in release announcements. When multiple types are available, the strongest checksum is to be preferred: sha256 over sha1, and sha1 over md5.


Det commented on 2018-07-19 16:30 (UTC)

You linked a section of the Wiki that actually had a pretty good chart about the differences between MD5, SHA-1, preimage and collision resistances.

It didn't fit the scope of the article tho, so it was removed. The only reasoning left there is literally "When multiple types are available, the strongest checksum is to be preferred".

Reason I was asking is because I don't think you know the aforementioned terms and differences.

MarcinWieczorek commented on 2018-07-19 16:26 (UTC)

I just did.

Det commented on 2018-07-19 16:25 (UTC)

Name one?

MarcinWieczorek commented on 2018-07-19 16:23 (UTC)

There are thousands of reasons why md5 should be avoided.

When multiple types are available, the strongest checksum is to be preferred: sha256 over sha1, and sha1 over md5.

Det commented on 2018-07-19 14:59 (UTC)


MarcinWieczorek commented on 2018-07-19 14:04 (UTC)

Please stop using md5 for checksums. Thanks!

Det commented on 2018-03-24 10:52 (UTC)

waddon1 flagged jre8 out-of-date on 2018-03-24 for the following reason:

The download page ( has encountered an issue due to oracle changing the download process

All the downloads are down:

Stop flagging.