As an addition the META-INF folder is now also used for multi-release jars. This is a feature which allows to package classes which are meant for different Java version in one jar, e.g. include a class for Java 11 with new features offered by Java 11 in a jar also working for Java 8, where a different class for Java 8 with less features in contained. E.g this can be useful if a newer Java version is offering enhanced, different or new API methods which would not work in earlier version due to API violations. One will see a sub folder versions then.

如果您使用的是JPA1，则可能必须在其中放入一个persistence.xml文件，该文件指定您可能想要使用的持久化单元的名称。持久化单元提供了一种方便的方式，可以指定一组元数据文件、类和包含分组中要持久化的所有类的jar。

import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

点击这里查看更多信息: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

你有舱单。MF文件在你的META-INF文件夹。您可以定义必须访问的可选或外部依赖项。

例子:

假设你已经部署了你的应用程序，你的容器(在运行时)发现你的应用程序需要一个不在lib文件夹内的库的新版本，在这种情况下，如果你在MANIFEST中定义了可选的新版本。MF，那么你的应用程序将从那里引用依赖(不会崩溃)。

来源:Head First Jsp & Servlet

我最近一直在思考这个问题。对于META-INF的使用似乎真的没有任何限制。当然，有一些限制，关于把舱单放在那里的必要性，但似乎没有任何禁止把其他东西放在那里。

为什么会这样呢?

cxf案例可能是合法的。这里是建议使用非标准的另一个地方，它可以绕过JBoss-ws中防止针对wsdl模式进行服务器端验证的严重错误。

http://community.jboss.org/message/570377#570377

但似乎真的没有什么标准，没有什么千言万语。通常这些事情都有非常严格的定义，但出于某种原因，这里似乎没有标准。奇数。META-INF似乎已经成为了一个无所不包的地方，任何所需的配置都无法通过其他方式轻松处理。

Maven中的META-INF

在Maven中，META-INF文件夹被理解是因为标准目录布局，根据名称约定将您的项目资源打包到JAR中:放置在${basedir}/src/main/resources目录中的任何目录或文件都以完全相同的结构打包到JAR中，从JAR的底部开始。

文件夹${basedir}/src/main/resources/META-INF通常包含。properties文件，而在jar中包含一个生成的MANIFEST。MF,砰的一声。属性，pom.xml，以及其他文件。同样，像Spring这样的框架使用classpath:/META-INF/resources/来提供web资源。

有关更多信息，请参阅如何向Maven项目添加资源。

来自官方JAR文件规范(链接到Java 7版本，但文本至少从v1.3开始就没有改变):

The META-INF directory The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services: MANIFEST.MF The manifest file that is used to define extension and package related data. INDEX.LIST This file is generated by the new "-i" option of the jar tool, which contains location information for packages defined in an application or extension. It is part of the JarIndex implementation and used by class loaders to speed up their class loading process. x.SF The signature file for the JAR file. 'x' stands for the base file name. x.DSA The signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file. services/ This directory stores all the service provider configuration files.

自Java 9实现JEP 238以来新增了多版本jar。一个会看到子文件夹的版本。这个特性允许将不同Java版本的类打包到一个jar中。