Week 59 — What are libraries in the context of Java and how can they be used in Java programs?

Question of the Week #59
What are libraries in the context of Java and how can they be used in Java programs?
7 Replies
Eric McIntyre
Eric McIntyre10mo ago
Libraries are reusable components of programs. When someone writes code that may be useful to other people, they can package the compiled version of it in a JAR so that other people can import these classes from their code after adding the JAR to the classpath/modulepath. For example, assume the following class:
package com.example.library;

public class LibraryClass {
public static void printHi(){
System.out.println("Hi");
}
}
package com.example.library;

public class LibraryClass {
public static void printHi(){
System.out.println("Hi");
}
}
This class can be compiled to a file LibraryClass.class and included in a JAR as com/example/library/LibraryClass.class. When this JAR file is added to the classpath of another program (if the JAR is called lib.jar, it can be included using the argument --class-path lib.jar to both the java and javac command), it can be imported like other classes:
package com.example.client;

import com.example.library.LibraryClass;

public class LibraryUser {
public static void main(String[] args){
LibraryClass.printHi();
}
}
package com.example.client;

import com.example.library.LibraryClass;

public class LibraryUser {
public static void main(String[] args){
LibraryClass.printHi();
}
}
Eric McIntyre
Eric McIntyre10mo ago
As listing all libraries in the classpath/modulepath and updating them can be cumbersome, one would typically use a build tool in order to manage them. In the context of build tools, libraries are typically called dependencies. (See https://canary.discord.com/channels/648956210850299986/1130182060410159144 for build tools.) Commonly used libraries are typically published to Maven Central or another Maven repository. These can then be specified in the configuration of a build tool and the build tool automatically downloads the dependency as well as dependencies used by the dependency (these are called "transitive" dependencies) and adds them when necessary. With Maven, dependencies can be specified using a <dependency> block in the pom.xml:
<dependencies>
<dependency>
<!-- all artifacts on Maven Central have a unique combination of group ID, artifact ID and version number used for identifying them -->
<groupId>com.example</groupId>
<artifactId>my-library</artifactId>
<version>1.0.0</version>
<dependency>
<dependencies>
<dependencies>
<dependency>
<!-- all artifacts on Maven Central have a unique combination of group ID, artifact ID and version number used for identifying them -->
<groupId>com.example</groupId>
<artifactId>my-library</artifactId>
<version>1.0.0</version>
<dependency>
<dependencies>
📖 Sample answer from dan1st
Eric McIntyre
Eric McIntyre10mo ago
In Java, libraries are collections of precompiled Java classes and methods that provide reusable functionality for developers. They can be used by importing them into Java programs using the import statement, allowing developers to access and utilize their functions and classes to simplify development and add advanced features to their programs. Ex:-
import java.util.*;
import java.util.*;
Submission from ig.imanish
Eric McIntyre
Eric McIntyre10mo ago
libraries are a collection of java classes, methods and variables and you can use them by using the import keyword
Submission from abc8671
Eric McIntyre
Eric McIntyre10mo ago
Libraries are a bunch of pre-made functions they can be used to perform actions that you would usually need to make a function for yourself
Submission from b.o.blox
Eric McIntyre
Eric McIntyre10mo ago
Libraries are collections of class files written by another party, and provide functionality that you yourself would probably skip implementing. The class files are often distributed as jar files, and can be included in the classpath when compiling with javac, and included in the classpath when running with java to use them (on the base level). To that end, they're seen as extra class files of your program, and act just like other class files you yourself might've written. In practise, you probably don't manage javac commands manually, so your build tool takes over the job. With maven, for example, you include libraries by specifying the coordinates in the dependencies section:
<dependency>
<artifactId>someLibrary</artifactId>
<groupId>me.x150</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<artifactId>someLibrary</artifactId>
<groupId>me.x150</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
This tells maven to download the library identified by group id me.x150, artifact id someLibrary at version 1.0-SNAPSHOT from one of the repositories configured in the pom. If it cant find the dependency anywhere, maven fails to build. The maven compiler plugin then uses those dependencies to run javac with the appropiate classpath set. That way you dont have to manage that yourself. Maven also makes managing dependencies easier, since it can easily resolve dependencies of dependencies, and automatically includes them as well. That way, all of the required class files and resources of the library are present. Normally, you'd have to download transitive dependencies yourself. There are several ways to include dependencies when you run your program. You can for example include them directly in your program jar, to be able to distribute a single file for running your program. This means that all your dependencies are in the same package as your main app, which brings some benefits and some downsides: 1. All of the dependencies are already there and will stay where they are, which makes distributing things relatively easy 2. The app is one single jar file, which again improves simplicity 3. You dont have to make a start script to include the required jars when starting your app, a simple java -jar will work. 1. Everything is in one jar, which makes conflicting files an issue. If two dependencies have overlapping files, one version will have to be replaced 2. Strong integrity is no longer easily available, since the module-info pseudoclasses cant all coexist in the same jar This is called "fat jar" packaging, and it's often used with smaller apps. If you're just developing something small, this might be a good choice.
Eric McIntyre
Eric McIntyre10mo ago
You can also put all libraries in their own folder in the distribution package and include them in the classpath when running, which preserves strong integrity and prevents file conflicts. This is more standard with larger applications, and basically flips the pros/cons of fat jar packaging around. Now you have all classes in their separate jars, load all of them onto the classpath and run your main class.
⭐ Submission from 0x150
Want results from more Discord servers?
Add your server