Package Details: jdk7 7u79-4

Git Clone URL: https://aur.archlinux.org/jdk7.git (read-only)
Package Base: jdk7
Description: Oracle Java 7 Development Kit (public release - end of support)
Upstream URL: http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
Keywords: java-environment-jdk java-openjfx java-runtime-headless-jre java-runtime-jre java-web-start-jre
Licenses: custom
Provides: java-environment=7, java-environment-jdk=7, java-openjfx=7, java-runtime=7, java-runtime-headless=7, java-runtime-headless-jre=7, java-runtime-jre=7, java-web-start=7, java-web-start-jre=7
Submitter: joschi
Maintainer: Det
Last Packager: Det
Votes: 133
Popularity: 2.833439
First Submitted: 2013-09-11 18:22
Last Updated: 2016-11-11 16:08

Dependencies (15)

Required by (1000)

Sources (7)

Latest Comments

TomFyuri commented on 2016-05-10 13:01

After installing had to do:
# find /usr/lib/jvm/java-7-jdk -type d -exec chmod o+rx {} \;
# find /usr/lib/jvm/java-7-jdk/ -name "bin" -exec chmod -R o+x {} \;
# chmod -R o+r /usr/lib/jvm/java-7-jdk
Is it intended? Or my makepkg&pacman messed up permissions?

Det commented on 2015-07-18 18:43

Also, you could change the pkgver to the more accurate "7u80" (or 7u79), since there's no more public versions for JDK 7.

Det commented on 2015-07-18 18:42

Please include the Java Cryptography Extension (JCE), which provides access to important ciphers like 256-bit AES that are required by some applications: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

This is already included in OpenJDK by default.

isiachi commented on 2015-04-26 20:11

@BluePeril

Thanks! Updated.

BluePeril commented on 2015-04-26 10:18

You forgot to update the i686 checksum: 9ded1318a7223cf6e09ac4b6ee4db1f4c5d1aef1d3d291f6db8491a32eaa57ba

jfcandidofilho commented on 2015-03-21 00:17

@joschi Oh, it's really OK now. Thanks!

joschi commented on 2015-03-20 08:38

@jfcandidofilho: I have re-downloaded the "jdk-7u76-linux-x64.tar.gz" archive and verified that the checksum is correct. If it fails on your system, check your setup.

jfcandidofilho commented on 2015-03-20 06:19

@joschi,

This proxy-thing (no master here :P) wouldn't be bad in terms of security? Shouldn't it be checked by someone? I'm not amused by the fact the SHA-256 is not correct!

joschi commented on 2015-02-09 20:49

The checksum for jdk-7u76-linux-x64.tar.gz (SHA-256: ce8ff4fed2cd16aea432edf8e94f21ccfe29e9d4a659bbbef3551982769e0c8c) is correct and works for me. You might want to check you downloads. Maybe there's a proxy in between which modifies the archives.

vitoreiji commented on 2015-02-03 17:59

jdk-7u76-linux-x64.tar.gz is not passing the hashsum check, please update.

frederik commented on 2015-01-21 12:02

Please do not update the archlinux-java defaults when upgrading. It should be up to the user to switch the defaults when upgrading.

joschi commented on 2014-12-26 13:41

@Det Thanks! Fixed it.

Det commented on 2014-12-24 15:42

Since makepkg 4.2.0, the DLAGENTS line can't have quotes around "oraclelicense=a":

DLAGENTS=('http::/usr/bin/curl -LC - -b oraclelicense=a -O')

joschi commented on 2014-11-05 21:18

@NullAxis Uninstall any older version of this package (or oracle-java7-jre/oracle-java7-jdk) and then install this package.

Also make sure to read https://www.archlinux.org/news/java-users-manual-intervention-required-before-upgrade/ first if you haven't updated your system in a while.

NullAxis commented on 2014-11-05 21:14

I'm having the same error as @madscience, is there any way to fix this?

joschi commented on 2014-10-20 19:40

@Det Thanks to you. I mostly just copied the jdk PKGBUILD…

I think the line in the jdk7 PKGBUILD is correct (https://github.com/joschi/AUR/blob/e3bae70bc35a9776164bfd2697e3b327be6cfc08/jdk7/PKGBUILD#L125). If the license was linked as /usr/share/licenses/jdk it would lead to conflicts with the jdk PKGBUILD.

Det commented on 2014-10-20 11:42

Great work. However, the second license line should also say $_pkgname, not $pkgname:

ln -sf /usr/share/licenses/java$_major-$_pkgname/ "$pkgdir"/usr/share/licenses/$pkgname

disponiblekonto commented on 2014-10-16 08:25

I managed to update by:

$ pacman -Rdd jdk7
$ packer -S jdk7

wtribe commented on 2014-10-15 19:31

I third the comment. It depends on java-environment-common and java-runtime-common but then conflicts with files in them. Maybe something changed in the two common packages?

Or, am I missing something else?

madscience commented on 2014-10-15 12:19

I second josephgbr's comment. I'm getting this:

error: failed to commit transaction (conflicting files)
java-environment-common: /usr/bin/appletviewer exists in filesystem
java-environment-common: /usr/bin/extcheck exists in filesystem
java-environment-common: /usr/bin/idlj exists in filesystem
java-environment-common: /usr/bin/jar exists in filesystem
java-environment-common: /usr/bin/jarsigner exists in filesystem
java-environment-common: /usr/bin/javac exists in filesystem
java-environment-common: /usr/bin/javadoc exists in filesystem
java-environment-common: /usr/bin/javah exists in filesystem
java-environment-common: /usr/bin/javap exists in filesystem
java-environment-common: /usr/bin/jcmd exists in filesystem
java-environment-common: /usr/bin/jconsole exists in filesystem
java-environment-common: /usr/bin/jdb exists in filesystem
java-environment-common: /usr/bin/jhat exists in filesystem
java-environment-common: /usr/bin/jinfo exists in filesystem
java-environment-common: /usr/bin/jmap exists in filesystem
java-environment-common: /usr/bin/jps exists in filesystem
java-environment-common: /usr/bin/jrunscript exists in filesystem
java-environment-common: /usr/bin/jsadebugd exists in filesystem
java-environment-common: /usr/bin/jstack exists in filesystem
java-environment-common: /usr/bin/jstat exists in filesystem
java-environment-common: /usr/bin/jstatd exists in filesystem
java-environment-common: /usr/bin/native2ascii exists in filesystem
java-environment-common: /usr/bin/rmic exists in filesystem
java-environment-common: /usr/bin/schemagen exists in filesystem
java-environment-common: /usr/bin/serialver exists in filesystem
java-environment-common: /usr/bin/wsgen exists in filesystem
java-environment-common: /usr/bin/wsimport exists in filesystem
java-environment-common: /usr/bin/xjc exists in filesystem
java-runtime-common: /usr/bin/java exists in filesystem
java-runtime-common: /usr/bin/keytool exists in filesystem
java-runtime-common: /usr/bin/orbd exists in filesystem
java-runtime-common: /usr/bin/pack200 exists in filesystem
java-runtime-common: /usr/bin/policytool exists in filesystem
java-runtime-common: /usr/bin/rmid exists in filesystem
java-runtime-common: /usr/bin/rmiregistry exists in filesystem
java-runtime-common: /usr/bin/servertool exists in filesystem
java-runtime-common: /usr/bin/tnameserv exists in filesystem
java-runtime-common: /usr/bin/unpack200 exists in filesystem
Errors occurred, no packages were upgraded.

rafaelff commented on 2014-10-13 15:12

@joschi: please set this package to work with 'java-runtime-common' and 'java-environment-common'

Det commented on 2014-10-13 03:02

You didn't reply to my email sent almost a month ago about cleaning up the Java packages.

Are you still alive?

galaux commented on 2014-10-12 20:00

As previously reported, package "java-common" is now gone in favor of "java-runtime-common" and "java-environment-common".

@users: once this very package is updated, you will be able to build and install it. Please note that a news item was posted (https://www.archlinux.org/news/java-users-manual-intervention-required-before-upgrade/) that provides 3 quick commands to prevent you from getting a "file conflict" error during the next pacman upgrade.

Please see our Java wiki page for info, and forum, IRC, Mailing lists for help.

@maintainer: you will need to:
- change your "java-runtime" providing package dependency from "java-common" to "java-runtime-common"
- add dependency "java-environment-common" to your "java-environment" providing packages

Changelog:
- Links from /usr/bin now belong to one of the mentioned "common" packages (fixes FS#41883)
- Links from /usr/bin point at /usr/lib/jvm/default/bin/* and thus do not use JAVA_HOME nor script /usr/lib/java-common-wrapper (prevents incorrect Java path detection for many build or run scripts). As a side effect, forcing a Java runtime by setting JAVA_HOME is now NOT supported anymore.

This should be all. Please have a look at official OpenJDK packages from extra for reference. "install" scripts for OpenJDK packages have also been revamped for nicer integration but without any consequence on other packages. These could easily be customized (or even taken "as is") for your own "install" scripts.

galaux commented on 2014-10-12 19:59

As previously reported, package "java-common" is now gone in favor of "java-runtime-common" and "java-environment-common".

@users: once this very package is updated, you will be able to build and install it. Please note that a news item was posted (https://www.archlinux.org/news/java-users-manual-intervention-required-before-upgrade/) that provides 3 quick commands to prevent you from getting a "file conflict" error during the next pacman upgrade.

Please see our Java wiki page for info, and forum, IRC, Mailing lists for help.

@maintainer: you will need to:
- change your "java-runtime" providing package dependency from "java-common" to "java-runtime-common"
- add dependency "java-environment-common" to your "java-environment" providing packages

Changelog:
- Links from /usr/bin now belong to one of the mentioned "common" packages (fixes FS#41883)
- Links from /usr/bin point at /usr/lib/jvm/default/bin/* and thus do not use JAVA_HOME nor script /usr/lib/java-common-wrapper (prevents incorrect Java path detection for many build or run scripts). As a side effect, forcing a Java runtime by setting JAVA_HOME is now NOT supported anymore.

This should be all. Please have a look at official OpenJDK packages from extra for reference. "install" scripts for OpenJDK packages have also been revamped for nicer integration but without any consequence on other packages. These could easily be customized (or even taken "as is") for your own "install" scripts.

galaux commented on 2014-10-12 19:59

As previously reported, package "java-common" is now gone in favor of "java-runtime-common" and "java-environment-common".

@users: once this very package is updated, you will be able to build and install it. Please note that a news item was posted (https://www.archlinux.org/news/java-users-manual-intervention-required-before-upgrade/) that provides 3 quick commands to prevent you from getting a "file conflict" error during the next pacman upgrade.

Please see our Java wiki page for info, and forum, IRC, Mailing lists for help.

@maintainer: you will need to:
- change your "java-runtime" providing package dependency from "java-common" to "java-runtime-common"
- add dependency "java-environment-common" to your "java-environment" providing packages

Changelog:
- Links from /usr/bin now belong to one of the mentioned "common" packages (fixes FS#41883)
- Links from /usr/bin point at /usr/lib/jvm/default/bin/* and thus do not use JAVA_HOME nor script /usr/lib/java-common-wrapper (prevents incorrect Java path detection for many build or run scripts). As a side effect, forcing a Java runtime by setting JAVA_HOME is now NOT supported anymore.

This should be all. Please have a look at official OpenJDK packages from extra for reference. "install" scripts for OpenJDK packages have also been revamped for nicer integration but without any consequence on other packages. These could easily be customized (or even taken "as is") for your own "install" scripts.

galaux commented on 2014-10-05 13:16

FYI, current package "java-common" will be split due to https://bugs.archlinux.org/task/41883

The only changes needed will be:
- for java-runtime-headless providing packages to now depend on "java-runtime-common" rather than "java-common"
- for java-environment providing packages to now depend on "java-environment-common"

These new packages are expected to be pushed to extra next week-end.

galaux commented on 2014-10-05 12:17

FYI, chances are current package "java-common" will be split due to https://bugs.archlinux.org/task/41883

tsachev commented on 2014-10-02 16:37

please copy the src.zip file to /usr/lib/jvm/java-7-oracle

tsachev commented on 2014-10-02 16:16

I do not think that (jmc) mission control is included in jdk7. isn't it only in the java 8 package?
And merging with jdk7 will be very good. It is annoying to have jdk for java 8 and jdk7-oracle for java 7.

Det commented on 2014-09-11 15:57

Well, it wasn't chosen, right?

basinilya commented on 2014-09-10 06:39

That post doesn't tell what convention was chosen. In fact, I hardly understand its manner.

Det commented on 2014-09-10 02:27

That's fine. My response: https://mailman.archlinux.org/pipermail/aur-general/2014-September/029499.html

Jristz commented on 2014-09-09 22:23

ok, again this thread is for the naming issue:
https://mailman.archlinux.org/pipermail/aur-general/2014-September/029497.html
Pleas come to a conclission to this nameing differences.

Jristz commented on 2014-09-09 22:22

For the naimg issue I bring this thread: https://mailman.archlinux.org/pipermail/aur-general/2014-September/029497.html

Det commented on 2014-09-09 16:25

So just relaying the same thing here: because the path for OpenJDK 8 was chosen as '/usr/lib/jvm/java-8-openjdk' (java-<major version>-<project name>), I simply preferred making mine 'java-8-jdk' (not 'java-8-oracle'), because the actual name of the project is 'JDK', not 'Oracle JDK', and it also creates consistency with the man pages:

$ man java-openjdk8
$ man java-jdk8

Instead of:

$ man java-openjdk8
$ man java8-oracle

Which also made me change the following dependencies:

- java-runtime-headless-oracle
- java-runtime-oracle
- java-web-start-oracle
- java-environment-oracle

to:

- java-runtime-headless-jre
- java-runtime-jre
- java-web-start-jre
- java-environment-jdk (a JDK component)

Even if all of those end up being '-jdk' for "simplicity", I'd still prefer that setup, than the whole excessive "Oracle" tagging. The 'java8-oracle' (jre8-oracle/jdk8-oracle) package was already replaced with my implementation, so I assume the devs think it's fine as long as it works and doesn't conflict.

However, you're part of the whole Java scheme in Arch also, so I'd like your input on this as well so we can reach a consensus on the standard.

russo79 commented on 2014-09-09 11:28

@Josephgbr

jre8-oracle was recently merged with jre [1].

[1] https://aur.archlinux.org/packages/jre/

rafaelff commented on 2014-09-09 02:48

@joschi:

In the PKGBUILD you disabled JAVA plugin (libnpjp2.so) installation because it "conflicts with jre8-oracle". However I notice jre8-oracle is not in AUR, so I suppose you have it locally. Please install this plugin and later, when you submit jre8-oracle, you re-think this action.

rafaelff commented on 2014-09-09 02:47

@joschi:

In the PKGBUILD you disable JAVA plugin (libnpjp2.so) installation because it conflicts with jre8-oracle. However I notice jre8-oracle is not in AUR. Please install this plugin and later, when you submit jre8-oracle, you re-think this action.

Jristz commented on 2014-09-08 20:56

@joschi the why not ask for a mergin and add the provided to jdk-oracle (proivides=jdk7) to the respective package package_jdk7-oracle(provides=jdk7) or something?

I ask fot the merge but they want you do the fist step.

joschi commented on 2014-09-05 07:00

@Jristz: jdk7-oracle (and jre7-oracle) follow the new package name scheme (just like jdk7-openjdk and jre7-openjdk from the official package repository) and support the new `archlinux-java` conventions.

As a matter of fact *this* very package is likely to be removed in the future.

Jristz commented on 2014-09-05 04:36

@joschi: Well then the package that need to be removed is jdk7-oracle because the common schene is use only jdk{number if apply} fot the package, and unles jdk7-oracle provide something different that jdk7 not have I think is better remove jdk7-oracle.

joschi commented on 2014-09-03 16:58

@Jristz: Please see https://aur.archlinux.org/packages/jdk7-oracle/

Nowaker commented on 2014-09-03 15:38

jdk7-compat will be removed soon. Please use jdk7 package - jdk7 no longer conflicts with other Javas. See https://wiki.archlinux.org/index.php/Java#Switching_between_JVM.

Jristz commented on 2014-09-03 15:26

Since the java-common now is out in extra is more than recommended update to the new javva guidelines since you know "packages not follow the guideliness will be removed" -AUR home

rafaelff commented on 2014-09-03 12:45

Would you please set the jre7-oracle's and jdk7-oracle's dependencies as 'makedepends' of the package base?

Currently the package base 'java7-oracle' has no dependency, only the packages have it. So, when I was building these two packages using yaourt, Yaourt correctly added 'java-common' to the list of packages to be installed, but in the wrong precedence order: 'jre7-oracle' and 'jdk7-oracle' were installed before 'java-common'. Consequence: 'java-default-runtime' was no found when installed both packages.

While this is not exactly your fault, I believe that by adding the dependencies to pkgbase's "makedepends" you will make sure that the required dependencies of each package built are already installed and available.

justin8 commented on 2014-09-01 15:15

What is the difference between this and the jre7 package?

joschi commented on 2014-09-01 07:14

@frownlee: Argh! Thanks, I've fixed it!

frownlee commented on 2014-09-01 03:10

Small thing - the jre7 install script calls itself java-9-oracle rather than java-7-oracle.

Thanks for making this package!

joschi commented on 2014-08-31 13:03

@russo79: Please see https://aur.archlinux.org/packages/jdk7-oracle/

russo79 commented on 2014-08-25 08:26

Would be nice if this package was updated according to the new Arch Java guidelines: https://wiki.archlinux.org/index.php/Java

A compatible jdk8 [1] has already been uploaded and can be used as example.

This would remove the need for the jdk7-compat [2] package.

[1] https://aur.archlinux.org/packages/jdk8-oracle/
[2] https://aur.archlinux.org/packages/jdk7-compat/

russo79 commented on 2014-08-25 08:26

Would be nice if this package was updated according to the new Arch Java guidelines: https://wiki.archlinux.org/index.php/Java

[1] A compatible jdk8 has already been uploaded and can be used as example.

This would remove the need for the jdk7-compat [2] package.

[1] https://aur.archlinux.org/packages/jdk8-oracle/
[2] https://aur.archlinux.org/packages/jdk7-compat/

russo79 commented on 2014-08-25 08:24

Would be nice if this package was updated according to the new Arch Java guidelines: https://wiki.archlinux.org/index.php/Java

This would remove the need for the jdk7-compat [1] package.

[1] https://aur.archlinux.org/packages/jdk7-compat/

Nowaker commented on 2014-08-14 19:32

Thanks for marking out-of-date. I'm very short on time this week. Can you please update and send the pull request? I'll merge and reupload ASAP. Thanks for your understanding. https://github.com/Nowaker/aur-packages

disponiblekonto commented on 2014-08-06 13:20

7u67-b01 is out.

MD5 for 64bit tar.gz = 81e3e2df33e13781e5fac5756ed90e67

disponiblekonto commented on 2014-08-06 13:07

7u67-b01

md5sum 81e3e2df33e13781e5fac5756ed90e67

Nowaker commented on 2014-07-16 12:54

The package is updated thanks to @joschi, who submitted a pull request.

The repo is here: https://github.com/Nowaker/aur-packages

joschi commented on 2014-07-16 09:14

Updated PKGBUILD for Java 7u65: https://github.com/joschi/AUR/blob/c05e500bdf661a43273c7bd11e0edd8cc827f776/jdk7-compat/PKGBUILD

Nowaker commented on 2014-07-15 22:46

Thanks for letting me know. I will try to do it ASAP.

vitoreiji commented on 2014-07-15 22:46

I see someone has already flagged this as out of date.
I just wanted to add that 7.65 is a rather important update, security-wise.
See what Brian Krebs has to say about it:
http://krebsonsecurity.com/2014/07/java-update-patch-it-or-pitch-it/

Please update ASAP.
Thanks!

Nowaker commented on 2014-06-11 20:40

Oh I see, since /top is tmpfs, it makes sense. I will remove PKGEXT. Thanks for explanation.

ypoluektovich commented on 2014-06-11 20:32

My main intent is development, which I do on a laptop :) But thanks for the suggestion anyway.

As for PKGEXT — I personally believe that it's the user's choice to make, not package maintainer's, and so should be set in the system-wide configuration file (/etc/makepkg.conf) and not in a PKGBUILD. Besides, even for those two minutes, the package file ends up on disk (or in /tmp), where saving those megabytes might make the difference between a successful update and a crash.

Nowaker commented on 2014-06-11 20:22

Thanks for suggestions, I will check the pkgbuild when I am at my desktop. (re: curly braces)

However, I won't change PKGEXT. It's there for a reason - xz compression is damn slow, and it really makes no sense to xz compress a package just to install it two minutes later. That's how 95% of AUR users do it.

BTW, have a look at oraclejdk* packages, you might find them useful if you main intent is servers.

Have a great day.

ypoluektovich commented on 2014-06-11 19:54

Oh, and also please don't set PKGEXT (line 55).

ypoluektovich commented on 2014-06-11 19:52

On line 68 of the PKGBUILD there are curly braces that shouldn't be there.

joschi commented on 2014-06-10 12:06

@ypoluektovich I've removed the setting. Thanks for mentioning!

ypoluektovich commented on 2014-06-07 14:59

Why does the PKGBUILD set PKGEXT='.pkg.tar'?

Nowaker commented on 2014-06-05 20:21

@russo, This is a non-conflicting Java package. Adding provides= makes it conflict with other JDKs. Therefore, I didn't add it.

@joschi, Thanks! You can even submit a pull request next time. :) https://github.com/Nowaker/aur-packages

joschi commented on 2014-06-03 09:12

updated PKGBUILD for Java 7u60: https://github.com/joschi/AUR/blob/73d7b18418efbe3f89d78f26c78fd00115587d4a/jdk7-compat/PKGBUILD

joschi commented on 2014-06-03 09:08

Updated PKGBUILD for Java 7u60: https://github.com/joschi/AUR/blob/259907857a1fd535b4bbad5ef17da1f95bb344af/jdk7-compat/PKGBUILD

Nowaker commented on 2014-05-31 16:46

@russo79, thanks for pointing it out. I will add it soon

russo79 commented on 2014-05-30 13:46

Out of curiosity, why doesn't this package provide java-runtime=7, java-environment=7 and java-runtime-headless=7?

frederik commented on 2014-05-29 12:43

I think this package should provide java-runtime-headless=$_major ...?

Nowaker commented on 2014-04-24 00:17

Java version bumped, and paths in jdk.sh fixed. Thanks Slipknot!

waelk10 commented on 2014-04-16 20:02

@joschi thanks, now it is working.

joschi commented on 2014-04-16 18:07

@waelk10 I've just retried installing JDK 7u55 with this PKGBUILD and it worked (x86_64 and i586).

Please post the output when trying to install jdk7 7.55-1 to https://pastebin.com or https://gist.github.com

joschi commented on 2014-04-16 18:04

@waelk10: I've just retried installing JDK 7u55 with this PKGBUILD and it worked fine (i586 and x86_64).

Please post the output you're getting when trying to install jdk7 to https://gist.github.com or https://pastebin.com

waelk10 commented on 2014-04-16 16:36

I've tried to build the latest version (at the time of writing 7.55-1), and the build fails in extracting the tarball, both in yaourt (which uses bsdtar) and with the regular "tar zxvf" command, I hope that this problem gets fixed soon...

denisfalqueto commented on 2014-04-16 03:00

JDK 7u55 is out.

joschi commented on 2014-04-03 20:04

@k2s Thanks, I've updated the PKGBUILD for jdk7 and jre7 accordingly.

Pecto commented on 2014-04-02 08:50

Installs flawlessly on manjaro. Too bad it's 7u51 and not 7u52 making netbeans refuse to compile it.

sl1pkn07 commented on 2014-03-29 01:17

jdk.sh points to /opt/java instead of /opt/java7

please fix it

sl1pkn07 commented on 2014-03-29 01:13

jdk.sh poinst to /opt/java instead of /opt/java7

please fix it

Det commented on 2014-03-28 03:14

"${provides[@]}" _is_ "${provides[@]/${_major}/8}" in jdk/jre.

Nowaker commented on 2014-03-27 12:51

Fixed. Sorry it took so long. I have been extremely busy in the last days.

Nowaker commented on 2014-03-27 11:57

Will get it fixed in a minute.

dreieck commented on 2014-03-27 11:57

@Nowaker: Maybe, if you don't want to deal with it, disown it so that someone willing to deal with it can adopt it (me not).

dreieck commented on 2014-03-27 11:56

@Nowak: Maybe, if you don't want to deal with it, disown it so that someone willing to deal with it can adopt it (me not).

dreieck commented on 2014-03-27 11:55

I disowned the package. Maybe someome willing to deal with it can adopt it.

anpieber commented on 2014-03-27 10:53

with java8 out this package becomes quite important suddenly. Still it fails. Would be quite valuable having this one working again.

k2s commented on 2014-03-25 13:10

Installing of JDK7 package if JDK package is installed doesn't work. I had to fix conflicts property to:

conflicts=("${provides[@]}" "${provides[@]/${_major}/8}")

joschi commented on 2014-03-17 22:06

@Det Thanks! I've updated the PKGBUILD.

Det commented on 2014-03-17 20:57

The download doesn't work anymore. I currently use:

DLAGENTS=('http::/usr/bin/curl -LC - -b "oraclelicense=a" -O')

Det commented on 2014-03-17 20:56

Also, the download doesn't work anymore. I currently use:

DLAGENTS=('http::/usr/bin/curl -LC - -b "oraclelicense=a" -O')

Det commented on 2014-02-09 10:11

FYI, if you're installing the scripts in /etc/profile.d/, then the whole symlinking to /usr/bin/ is unnecessary.

sschober commented on 2013-12-03 17:35

Symlinking is broken for me (cannot find `/opt/java/bin`, if no version of jdk is installed already).

This patch fixes it (though not very elegantly):

https://gist.github.com/sschober/7773626

ryenus commented on 2013-08-26 14:45

Maybe those *.desktop and /etc/profile.d/jdk*.sh stuff should only be relevant to the *current* jdk(or possibly jre?)

I think it's enough for jdk*-compat only provide the /opt/java* stuff.

or maybe the /etc/profile.d/jdk*.sh stuff should only be symbol links pointing to stuff something elsewhere.

The for-now jdk6-compat package is incomplete and depending on jre6-compat which conflicts with other java packages (as it provides java-runtime) is making it useless.

@Nowaker, I wish you fix all these *-compat packages once for all. Thank you!

Det commented on 2013-06-19 09:02

Good luck with that. It was really frustrating to try it out with jre-/jdk-devel.

Nowaker commented on 2013-06-12 00:32

Upgraded to the newest available version without any significant changes to tke PKGBUILD.

I'm currently discussing with Guillaume Alaux how we should rewrite all JRE/JDKs packages (both official and AUR ones) so they never conflict each other, automatically set JAVA_HOME, and Java can be used in systemd services. Please stay tuned. :)

Nowaker commented on 2013-06-09 10:59

Sorry, forgot about the package, give me a few days to fix it.

xgdgsc commented on 2013-06-09 03:03

Why not update it after you take ownership?

dreieck commented on 2013-03-12 08:22

disowned.

Jristz commented on 2013-02-15 04:00

jdk 1u13 is out and fix the 49 critical bugs

vnoel commented on 2013-02-13 17:21

Thx :)

dreieck commented on 2013-02-13 17:00

@vnoel:
Fixed.

vnoel commented on 2013-02-13 14:12

Hi, why is there the two /etc/profile.d/jdk.csh and /etc/profile.d/jdk.sh files in this package?

This is conflicting with jdk7-openjdk!

Isn't that compat package made to be installed along jdk7-openjdk?

Thanks

dreieck commented on 2013-01-14 17:21

jre7-compat no longer needed as dependency, since it is included within this package.

dreieck commented on 2013-01-14 16:44

Updated to jdk version 7u11.

xgdgsc commented on 2013-01-07 03:49

jre7-compat not found.