Med Java

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Types of jars in java ======

  - **Regular (or Non-Uber) JARs**: These JAR files contain only the .class files (compiled Java bytecode) of your application. They do not include the .class files for any libraries your application uses. This requires that all libraries used by your application are available on the classpath when your JAR is run.
  - **Thin JARs**: In a thin JAR, dependencies are not packaged inside the JAR. Instead, a lib directory is usually provided alongside the JAR, containing all necessary dependencies. The JAR file includes a Class-Path entry in the manifest file, which references the dependent JARs.
  - **Uber (or Fat) JARs**: These JARs contain not only the .class files for your application, but also the .class files for all libraries your application depends on. This creates a self-contained JAR that can be run without requiring any additional libraries on the classpath. This can be useful for distributing an application or for deploying it in a containerized environment, for example.
  - **War JARs (Web application Archive)**: These JAR files are used for the distribution of a collection of JavaServer Pages, Java Servlets, Java classes, XML files, tag libraries, static web pages (HTML and related files) and other resources that together constitute a web application.
  - **Spring Boot JARs**: A Spring Boot Uber JAR, also known as a Spring Boot Executable JAR, packages the application, all its dependencies, and the embedded server (like Tomcat or Jetty) into a single, runnable JAR file.

<note>The difference between a regular (or non-uber) JAR (#1) and a thin JAR (#2) lies in the way dependencies are managed and distributed:
  - **Regular (or Non-Uber) JARs**: In this case, the JAR file only contains the compiled .class files of your application, without any of its dependencies. When running an application from a regular JAR, it's required that all of the application's dependencies are separately available on the classpath. This means that you have to separately manage and distribute all the dependencies that your application needs to run. This can be more complex and error-prone, especially when dealing with a large number of dependencies or when deploying the application to a new environment.
  - **Thin JARs**: A thin JAR also doesn't include its dependencies within the JAR file itself, but it typically includes a mechanism for automatically resolving and loading those dependencies when the application is run. This often involves a lib directory that contains all the dependencies, and a Class-Path entry in the manifest file of the JAR that references these dependencies. This provides a more self-contained and easy-to-distribute package compared to a regular JAR, since it includes all the dependencies the application needs to run.

So, the main difference between these two approaches is the method of handling dependencies. A regular JAR leaves the responsibility of managing dependencies to the user, while a thin JAR includes a mechanism for managing them as part of the application package itself.
</note>

<note>
All jars can be made executable by including a Main-Class entry in its manifest file (META-INF/MANIFEST.MF):
<code>Main-Class: com.mycompany.MyMainClass</code>
Then can be executed with:
<code>java -jar myapplication.jar</code>

Normally, a WAR file is not executable on its own and must be deployed to a web server or application server, like Apache Tomcat or Jetty. However, Spring Boot allows you to create a standalone Spring application with an embedded server, which can be run as an executable WAR file. This is done by setting up a specific Spring Boot class as a bootstrapping class in the WAR's manifest file.

</note>