Package Base Details: java7-openjdk

Git Clone URL: (read-only, click to copy)
Keywords: infinality java jdk jre
Submitter: trollixx
Maintainer: trollixx
Last Packager: trollixx
Votes: 27
Popularity: 0.000000
First Submitted: 2014-07-22 00:55
Last Updated: 2018-04-13 22:32

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 ... Next › Last »

Rhinoceros commented on 2014-09-14 12:12

@chrbayer I'd definitely be keen. I imagine that most v7 users would be keen to at least test v8, even if they eventually move back. How complicated is it? An AUR package is definitely preferred in terms of ease of installation.

chrbayer commented on 2014-09-14 12:07

I did some more investigations on building an infinality enhanced version of OpenJDK 8 and I think, that it should be possible even if there is not only an option to activate. Is anybody else interested? Should I just prepare a patch or should I try to submit a AUR package? At least if there is some interest...

Rhinoceros commented on 2014-09-10 23:17

@chrbayer I had a quick look the other day at the PKGBUILD for openjdk-8, but I'm not sure how to enable infinality. In openjdk-7, it's as easy as changing a switch from off to on. There is no pre-existing switch in the openjdk-8 PKGBUILD, so it's not obvious to me how to do this.

chrbayer commented on 2014-09-10 12:26

Is somebody already working on a patched version of openjdk-8? I would volunteer to build the this on my machine regularly :-)
I am using the great Android Studio but can't stand the font rendering of the original openjdk-8 any more...

phant0m commented on 2014-09-09 17:29

I fixed my issue with the following command: sudo archlinux-java fix

phant0m commented on 2014-09-08 18:48

I got an error at configure stage:
error: "A Java header generator was not found."

Rhinoceros commented on 2014-08-27 12:44

Nice one. However, you have to add in `conflicts` with upstream packages. Otherwise, when you attempt to install over upstream, it fails. Also, it'd probably be a good idea to add `provides` upstream packages, so you could have (e.g.) jre7-openjdk-infinality with jdk7-openjdk. Also, then you wouldn't need to modify the `depends` from upstream at all.

Also, I also noticed that you didn't duplicate some files from upstream, specifically jdk7-openjdk.profile, jdk7-openjdk.profile.csh, jre7-openjdk.profile and jre7-openjdk.profile.csh. I can't exactly work out what these files do, but did you remove them for a specific reason?

trollixx commented on 2014-08-27 04:56

Now there are three packages, so it should not cause any problems with updates anymore.

Rhinoceros commented on 2014-08-25 23:38

@trollixx Assuming this is not in contradiction to Arch policy, I can't think of a negative, really. You'd have to rename the other parts of this split package to (e.g.) jre7-openjdk-infinality and jdk7-openjdk-infinality. These can then "provide" the upstream package, similar to how jre7-openjdk-headless-infinality's "provides". Then, users can choose to install the precompiled upstream jre7-openjdk and jdk7-openjdk, which is how it is done currently, or move to the (slightly lagging) versions from this split package. The former means they don't have to compile it themselves. The latter means they won't have system updates blocked.

trollixx commented on 2014-08-25 18:44

@Rhinoceros, that might be an option. The current scheme worked well when no exact version was required. But now it's really annoying to break all updates. I think I would prefer some duplication rather than broken updates.

I would like to hear objections as well if anyone has them.