Manage dependencies, compile, test, and package your app into a runnable JAR using Maven or Gradle instead of raw javac.
Why: running javac by hand breaks down fast — real projects pull in dozens of libraries and need a repeatable way to compile, test, and package. Maven and Gradle download dependencies, run your build in standard steps, and produce a JAR. Most teams use one or the other.
Why: Maven describes a project in an XML file called pom.xml — its name, Java version, and dependencies. Maven reads it, fetches the listed libraries, and builds in a fixed sequence (compile, test, package).
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>my-app</artifactId>
<version>1.0.0</version>
<properties>
<maven.compiler.release>21</maven.compiler.release>
</properties>
<dependencies>
<!-- libraries go here -->
</dependencies>
</project>When: run these from the project root (where pom.xml lives). Each phase runs the ones before it — package compiles and tests first. The result lands in the target/ folder.
Compile, run tests, and build the JAR:
mvn compilemvn testmvn packageThen run the produced JAR:
java -jar target/my-app-1.0.0.jarWhy: Gradle does the same job with a concise script instead of XML, and caches work so rebuilds are fast. Dependencies use a short "group:name:version" notation.
plugins {
id 'application'
}
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
}
application {
mainClass = 'com.example.Main'
}When: use the bundled wrapper (./gradlew on Mac/Linux, gradlew.bat on Windows) so everyone uses the same Gradle version. build compiles and tests; run launches your application.
Build and test, then run the app:
./gradlew build./gradlew test./gradlew run