Arch linux and java

How to Install Java on Arch Linux

Java is undoubtedly one of the most popular programming languages ever to grace the face of the planet, powering millions of applications both on Linux and Windows platforms.

Java comprises of JRE (Java Runtime Environment) and JDK (Java Development Toolkit). JRE is a set of software applications that help in the deployment of Java applications. JDK is a development environment necessary for the building and compilation of Java applications.

In this tutorial, we are going to take you through a step by step of how you can install Java on Arch Linux.

Step 1: Check If Java is Installed

To begin with, let’s check if Java is installed in the Arch Linux using the following command.

$ java -version OR $ which java

From the output above, it evident that Java is missing. Let’s now proceed and install both JRE and JDK which both constitute JAVA.

Step 2: Install JRE in Arch Linux

To install JRE (Java Runtime Environment), a first search which versions are available for download using the command.

$ sudo pacman -sS java | grep jre

To install the latest version of JRE, run the command.

Press Y and hit ENTER to proceed with the installation of JRE and other dependencies.

Step 3: Install JDK in Arch Linux

With JRE installed, we can proceed to install JDK on our Arch Linux system. Once again, let’s search for the versions of JDK that are available for download.

$ sudo pacman -sS java | grep jdk

The first option is usually the latest version, so to install the latest JDK, run the command.

As shown before, press Y when prompted and hit ENTER to continue with the installation process. This will take a bit more of your time, so some patience will do.

At this point, we have successfully installed JAVA on our Arch Linux system.

To verify that JAVA has indeed been installed, run.

Conclusion

In this article, we demonstrated how you can install Java on Arch Linux. You can now proceed and install applications such as Apache Tomcat, Maven, Jenkins, and Gradle.

Источник

Java package guidelines

This document defines a proposed standard for packaging Java programs under Arch Linux. Java programs are notoriously difficult to package cleanly without overlapping dependencies. This document describes a way to remedy this situation. These guidelines are flexible in order to cover the many different scenarios that arise when dealing with Java applications.

Introduction

Arch Linux packagers cannot seem to agree on how to handle Java packages. Various methods are used in PKGBUILDs across the official and unofficial repositories and in the AUR. These solutions include placing the whole mess in /opt with shell scripts in /usr/bin or profiles placed in /etc/profile . Others are placed in directories in /usr/share with scripts placed in /usr/bin . Many add unnecessary files to the system CLASSPATH and PATH .

Structure of a typical Java application

Most Desktop Java applications have a similar structure. They are installed from a system-independent (but package dependent!) installer. This usually installs everything in a single directory with subdirectories called bin , lib , jar , conf , etc. There is usually a main jar file containing the main executable classes. A shell script is usually provided to run the main class so users do not have to invoke the Java interpreter directly. This shell script is usually quite complex, as it is generic across distributions and often includes special cases for different systems (e.g., Cygwin).

The lib directory often contains bundled jar files that satisfy dependencies of the Java application. This makes it simple for a user to install the program (all dependencies included), but is a package developer’s nightmare. It is a waste of space when several packages bundle the same dependency. This was not a big issue in the past when there were fewer desktop Java applications and libraries, and those that existed tended to be very large anyway. Things are different now.

Other files necessary to run the program are usually stored in the same folder as the main jar file, or a subdirectory thereof. Since Java programs do not know where their classes were loaded from, they usually need to be run from within this directory (i.e. the shell script should cd into the directory), or an environment variable is set to indicate the directory’s location.

Java packaging on Arch Linux

Packaging Java applications in Arch is going to take quite a bit more work for packagers than it currently does. The effort will be worth it, however, resulting in a cleaner filesystem and fewer bundled dependencies (as more and more Java libraries are refactored into their own packages, packaging will become easier). The following guidelines should be followed in creating an Arch Linux Java package:

• If a Java library has a generic name, the package name should be prepended with the title java- to help distinguish it from other libraries. This is not necessary with uniquely named packages (like JUnit), end-user programs (like Eclipse), or libraries that can be uniquely described with another prefix (like jakarta-commons-collections or apache-ant).

• Place all jar files (and no other files) distributed with the program in a /usr/share/java/myprogram directory. This includes all dependency jar files distributed with the application. However, effort should be made to place common or large dependency libraries into their own packages. This can only happen if the program does not depend on a specific version of a dependency library.

• If the program is meant to be run by the user, write a custom shell script that runs the main jar file. This script should be placed in /usr/bin . Libraries generally do not require shell scripts. Write the shell script from scratch, rather than using one that is bundled with the program. Remove code that tests for custom environments (like Cygwin), and code that tries to determine if JAVA_HOME has been set (Arch does not use JAVA_HOME , it uses archlinux-java to set the /usr/bin/java symlink).

#!/bin/sh exec /usr/bin/java -jar '/usr/share/java/myprogram/myprogram.jar' "$@"

#!/bin/sh exec /usr/bin/java '/usr/share/java/myprogram/myprogramclassname' "$@"

• Set the CLASSPATH using the -cp option to the Java interpreter unless there is an explicit reason not to (ie: the CLASSPATH is used as a plugin mechanism). The CLASSPATH should include all jar files in the /usr/share/java/myprogram direcory, as well as jar files that are from dependency libraries that have been refactored to other directories. You can use something like the following code:

for name in /usr/share/java/myprogram/*.jar ; do CP=$CP:$name done CP=$CP:/usr/share/java/dep1/dep1.jar java -cp $CP myprogram.java.MainClass

• Make sure the shell script is executable!

• Other files distributed with the package should be stored in a directory named after the package under /usr/share . You may need to set the location of this directory in a variable like MYPROJECT_HOME inside the shell script. This guideline assumes that the program expects all files to be in the same directory (as is standard with Java packages). If it seems more natural to put a configuration file elsewhere (for example, logs in /var/log ), then feel free to do so.

• As is standard with Arch Linux packages, if the above standards cannot be adhered to without a serious amount of work, the package should be installed in its preferred manner, with the resulting directory located in /opt . This is useful for programs that bundle JREs or include customized versions of dependencies, or do other strange or painful tasks.

Multiple API implementations

If your package distributes commonly used API implementation(like jdbc driver) you should place the library under /usr/share/java/apiname . So that applications that allow user to select from various implementations will know where to look for them. Use this location only for raw library packages. If such a implementation is part of distribution of application, do not place this jar file under common location but use ordinary package structure.

Example directory structure

To clarify, here is an example directory structure for a hypothetical program called foo . Since foo is a common name, the package is named java-foo , but notice this is not reflected in the directory structure:

• /usr/share/java/foo/
• /usr/share/java/foo/foo.jar
• /usr/share/java/foo/bar.jar (included dependency of java-foo )
• /usr/share/foo/
• /usr/share/foo/*.* (some general files required by java-foo )
• /usr/bin/foo (executable shell script)

Dependencies

Java packages might specify java-runtime or java-environment as dependency, based on what they need.

For most packages, java-runtime is what is needed to simply run software written in Java.

java-environment (e.g. JDK) is needed by packages that will need to compile Java source code into bytecode.

See Java for more information.

Источник

Arch Linux User Repository

@azzbcc @valsaven Package updated. Fix applied, thanks for noticing.

valsaven commented on 2023-06-19 06:48 (UTC)

@dbermond Could you fix the paths, please? This is easy to change by hand, but not everyone reads the comments and will notice it.

azzbcc commented on 2023-05-13 06:29 (UTC)

wrong path in java.desktop and jconsole.desktop

hugegameartgd commented on 2022-05-06 22:43 (UTC) (edited on 2022-05-06 22:44 (UTC) by hugegameartgd)

Maybe upgrading would work with provides = jre18-jdk=18.0.1 instead of 18.0.1-1 in .SRCINFO?

dbermond commented on 2022-05-05 20:38 (UTC)

@MidnightStarSign Sorry, but distributions other than Arch Linux are not supported here. Please seek help on your distribution support channels.

MidnightStarSign commented on 2022-05-05 19:30 (UTC)

I’m encountering an issue where I upgrade this using pamac, but the update is still available despite it being successful.

I found this from another forum regarding the issue: «The maintainer changed the package versioning pattern and did not adopt .SRCINFO, hence AUR helpers interpret that in a way that there is a new update available although there isn’t».

Not sure if that is what’s going on here.

Checking keyring. [1/1] Checking integrity. [1/1] Loading package files. [1/1] Checking file conflicts. [1/1] Checking available disc space. [1/1] Reinstalling jre (17.0.1-1). [1/1] Transaction successfully finished. 

dbermond commented on 2022-03-24 13:51 (UTC)

For users wanting the Oracle Java LTS release, there are now lts packages for convenience: jdk-lts, jre-lts and jdk-lts-doc.

dimich commented on 2022-01-20 15:40 (UTC) (edited on 2022-01-20 16:59 (UTC) by dimich)

UPD: Hm, nevermind. Now downloaded successfully without any changes. Maybe some malfunction of the server.

Seems Oracle doesn’t allow to download jdk-14.0.2_linux-x64_bin.tar.gz directly from script any more:

Sorry! In order to download products from Oracle Technology Network you must agree to the OTN license terms. Be sure that. Your browser has "cookies" and JavaScript enabled. You clicked on "Accept License" for the product you wish to download. You attempt the download within 30 minutes of accepting the license. 

drslmr commented on 2021-11-22 14:00 (UTC)

Update to my last comment:

My issue was, that I get this «undefined symbol: ipv6_available» when executing jar and other jdk executables.

Now I see that un-setting LD_LIBRARY_PATH in the bash shell fixes the problem too.

I tried to find who (which service/program) sets LD_LIBRARY_PATH , in my case to /usr/lib:/usr/lib:/usr/lib:/usr/lib , but I could not find it, neither in my user resource file nor in the system resource files I know off.

drslmr commented on 2021-11-12 09:20 (UTC)

I needed to add the server path to the LD_LIBRARY_PATH.

Источник