blocks|key|3439662|text|解决这个问题的办法似乎是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3439663|将相同的工件名称与新的(不同的)模块名称不间断地使用的一种方法是，使用属性Automatic-Module-Name打包工件的META-INF/MANIFEST.MF，该属性控制转换为自动模块时由模块描述符使用的模块的名称。|offset|length|style|BOLD|3439664|或|3439665|3439666|工件所有者可以使用module-info.java将模块声明添加到其JAR中。(这可能导致缓慢的自下而上迁移)|unordered-list-item|CODE|3439667|3439668|3439669|由于module+declaration在规范中定义为：|3439670|3439671|模块声明引入了可以在其他模块声明中使用的模块名称，以表达模块之间的关系。模块名称由一个或多个组成，以".“分隔。代币。|blockquote|3439672|3439673|3439674|3439675|有趣的是，declarations建议-|3439676|3439677|在某些情况下，互联网域名可能不是有效的包名。以下是处理这些情况的一些建议约定：|3439678|3439679|3439680|3439681|如果域名包含连字符或标识符中不允许的任何其他特殊字符(§3.8)，请将其转换为下划线。|3439682|3439683|3439684|如果生成的包名称部分中有任何是关键字(§3.9)，请在它们后面加上下划线。|3439685|3439686|3439687|如果任何生成的包名称组件以数字或不允许作为标识符的起始字符的任何其他字符开头，则该组件前应带有下划线。|3439688|3439689|但请记住，在这样做时，Underscore+is+a+keyword+in+Java9|3439690|​|3439691|📷|atomic|3439692|3439693|int+_;++//+is+would+throw+an+error+on+javac+based+out+of+JDK9
int+_native;+//+works+fine|code-block|syntax|javascript|3439694|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/specs/jls/se9/html/jls-7.html#jls-7.7|1|https://docs.oracle.com/javase/specs/jls/se9/html/jls-6.html#jls-6.1|2|https://blogs.oracle.com/sundararajan/underscore-is-a-keyword-in-java-9,-use-this-script-to-check-your-code|3|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/e491344b2ee58f94c815ebdb12088615.png|imageAlt^0|0|11|L|1R|K|0|0|1|0|0|9|G|0|0|0|2|I|0|0|0|0|0|0|0|5|C|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|B|W|2|0|0|0|1|3|0|0|0^^$0|@$1|2|3|4|5|6|7|2D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2E|8|@$D|2F|E|2G|F|G]|$D|2H|E|2I|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|2J|8|@$D|2K|E|2L|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|2N|8|@$D|2O|E|2P|F|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|2S|8|@]|9|@$D|2T|E|2U|1|2V]]|A|$]]|$1|S|3|-4|5|6|7|2W|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|2X|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|30|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|31|8|@]|9|@$D|32|E|33|1|34]]|A|$]]|$1|11|3|-4|5|6|7|35|8|@]|9|@]|A|$]]|$1|12|3|13|5|V|7|36|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|37|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|38|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|39|8|@]|9|@]|A|$]]|$1|17|3|18|5|M|7|3A|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|3B|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|3C|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|M|7|3D|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|3E|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|3F|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|M|7|3G|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|3H|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|3I|8|@]|9|@$D|3J|E|3K|1|3L]]|A|$]]|$1|1K|3|1L|5|6|7|3M|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|1O|7|3N|8|@]|9|@$D|3O|E|3P|1|3Q]]|A|$]]|$1|1P|3|1L|5|6|7|3R|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|1S|7|3S|8|@]|9|@]|A|$1T|1U]]|$1|1V|3|-4|5|6|7|3T|8|@]|9|@]|A|$]]]|1W|$1X|$5|1Y|1Z|20|A|$21|22]]|23|$5|1Y|1Z|20|A|$21|24]]|25|$5|1Y|1Z|20|A|$21|26]]|27|$5|28|1Z|29|A|$2A|2B|2C|-4]]]]

The solution to this seems to be:-
<ul>
<li>A way possible to uninterruptedly using the same artifact name with a new(different) module name could be by packaging META-INF/MANIFEST.MF of the artifact with an attribute Automatic-Module-Name which governs the name of the module to be used by the module descriptor when converted as an automatic module.</li>
</ul>
OR
<ul>
<li>Artifact owners can add module declarations using <code>module-info.java</code> to their JAR. (this could result in a slow bottom-up migration)</li>
</ul>
<hr />
Since the <a href="https://docs.oracle.com/javase/specs/jls/se9/html/jls-7.html#jls-7.7" rel="nofollow noreferrer">module declaration</a> defined in the specs as:
<blockquote>
A module declaration introduces a module name that can be used in
other module declarations to express relationships between modules. A
module name consists of one or more <a href="https://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.8" rel="nofollow noreferrer">Java identifiers (§3.8)</a> separated
by &quot;.&quot; tokens.
</blockquote>
<hr />
Intersetingly the <a href="https://docs.oracle.com/javase/specs/jls/se9/html/jls-6.html#jls-6.1" rel="nofollow noreferrer">declarations</a> suggests -
<blockquote>
In some cases, the Internet domain name may not be a valid package
name. Here are some suggested conventions for dealing with these
situations:
<ul>
<li>If the domain name contains a hyphen, or any other special character
not allowed in an identifier (§3.8), convert it into an underscore.
</li>
<li>If any of the resulting package name components are keywords (§3.9),
append an underscore to them.
</li>
<li>If any of the resulting package name components start with a digit, or
any other character that is not allowed as an initial character of an
identifier, have an underscore prefixed to the component.
</li>
</ul>
</blockquote>
But keep in mind as you do so that <a href="https://blogs.oracle.com/sundararajan/underscore-is-a-keyword-in-java-9,-use-this-script-to-check-your-code" rel="nofollow noreferrer">Underscore is a keyword in Java9</a>
<a href="https://i.stack.imgur.com/wURRf.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/wURRf.png" alt="enter image description here" /></a>
<pre><code>int _; // is would throw an error on javac based out of JDK9
int _native; // works fine
</code></pre>

blocks|key|3439790|text|从现在开始，您还可以使用这个小的Maven插件自动修改本地Maven存储库中的Scala+jar中的清单文件：https://github.com/makingthematrix/scala-suffix|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3439791|在链接下面，你会发现整个问题的概述，以及你需要添加到你的pom.xml中的东西，但我被要求在这里解释，所以它是这样的：|style|CODE|3439792|如前所述，Java不会将_2.13等模块名称中的后缀识别为版本号，并将其视为模块名称的组成部分。因此，当您的项目尝试使用Scala依赖项中的类时，它将查找your.scala.dependency.2.13，而不仅仅是your.scala.dependency，它将无法做到这一点，并且会崩溃。|3439793|要在您的一侧修复此问题(即不需要库创建者的任何操作)，请将此代码添加到pom.xml的<plugins>部分|3439794|<plugin>
++<groupId>io.github.makingthematrix</groupId>
++<artifactId>scala-suffix-maven-plugin</artifactId>
++<version>0.1.0</version>
++<configuration>
++++<libraries>
++++++<param>your-scala-dependency</param>
++++</libraries>
++</configuration>
++<executions>
++++<execution>
++++++<goals>
++++++++<goal>suffix</goal>
++++++</goals>
++++</execution>
++</executions>
</plugin>|code-block|syntax|javascript|3439795|其中your-scala-dependency是您的Scala依赖项的名称，不带版本后缀(如果有多个，只需添加更多的<param>标记)。这应该与<dependency>部分中的artifactId相同。|3439796|该插件修改本地Maven存储库中的依赖项的JAR文件。它打开jar，读取META-INF/MANIFEST.MF并添加一行：|3439797|Automatic-Module-Name:+your-scala-dependency|3439798|如果属性Automatic-Module-Name已经存在，插件什么也不做--我们假设在这种情况下，依赖项应该已经起作用了。这可以防止插件多次修改相同的JAR文件。|3439799|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/makingthematrix/scala-suffix^0|1J|1B|0|0|S|7|0|C|5|25|Q|0|Z|7|17|9|0|0|2|L|1M|7|21|C|2H|A|0|10|K|0|0|4|L|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]]|C|$]]|$1|D|3|E|5|6|7|1A|8|@$A|1B|B|1C|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|1D|8|@$A|1E|B|1F|F|G]|$A|1G|B|1H|F|G]]|9|@]|C|$]]|$1|J|3|K|5|6|7|1I|8|@$A|1J|B|1K|F|G]|$A|1L|B|1M|F|G]]|9|@]|C|$]]|$1|L|3|M|5|N|7|1N|8|@]|9|@]|C|$O|P]]|$1|Q|3|R|5|6|7|1O|8|@$A|1P|B|1Q|F|G]|$A|1R|B|1S|F|G]|$A|1T|B|1U|F|G]|$A|1V|B|1W|F|G]]|9|@]|C|$]]|$1|S|3|T|5|6|7|1X|8|@$A|1Y|B|1Z|F|G]]|9|@]|C|$]]|$1|U|3|V|5|N|7|20|8|@]|9|@]|C|$O|P]]|$1|W|3|X|5|6|7|21|8|@$A|22|B|23|F|G]]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|24|8|@]|9|@]|C|$]]]|Z|$10|$5|11|12|13|C|$14|15]]]]

From now on you can also use this small Maven plugin to automatically modify the manifest file in a Scala jar in your local Maven repo: <a href="https://github.com/makingthematrix/scala-suffix" rel="nofollow noreferrer">https://github.com/makingthematrix/scala-suffix</a>
Under the link you will find the overview of the whole issue and what you need to add to you <code>pom.xml</code>, but I was asked to also explain here, so here it goes:
As it was mentioned already, Java does not recognize suffixes in modules names like <code>_2.13</code> as version numbers and treat them as integral parts of modules names. So, when your project tries to use a class from the Scala dependency, it will look for <code>your.scala.dependency.2.13</code> instead of just your.scala.dependency, it will fail to do it, and it will crash.
To fix this on your side (i.e. without any action from the library's creator) add this to the <code>&lt;plugins&gt;</code> section of your <code>pom.xml</code>:
<pre><code>&lt;plugin&gt;
 &lt;groupId&gt;io.github.makingthematrix&lt;/groupId&gt;
 &lt;artifactId&gt;scala-suffix-maven-plugin&lt;/artifactId&gt;
 &lt;version&gt;0.1.0&lt;/version&gt;
 &lt;configuration&gt;
 &lt;libraries&gt;
 &lt;param&gt;your-scala-dependency&lt;/param&gt;
 &lt;/libraries&gt;
 &lt;/configuration&gt;
 &lt;executions&gt;
 &lt;execution&gt;
 &lt;goals&gt;
 &lt;goal&gt;suffix&lt;/goal&gt;
 &lt;/goals&gt;
 &lt;/execution&gt;
 &lt;/executions&gt;
&lt;/plugin&gt;
</code></pre>
where <code>your-scala-dependency</code> is a name of your Scala dependency without the version suffix (if there are more than one, just add them with more <code>&lt;param&gt;</code> tags). This should be the same as <code>artifactId</code> in your <code>&lt;dependency&gt;</code> section.
The plugin modifies the dependency's JAR file in your local Maven repository. It opens the jar, reads <code>META-INF/MANIFEST.MF</code> and adds to it a line:
<pre><code>Automatic-Module-Name: your-scala-dependency
</code></pre>
If the property <code>Automatic-Module-Name</code> already exists, the plugin does nothing - we assume that in that case the dependency should already work. This prevents the plugin from modifying the same JAR file more than once.

My project depends on Netty Epoll transport. Here is dependency:

<pre><code>&lt;dependency&gt;
 &lt;groupId&gt;io.netty&lt;/groupId&gt;
 &lt;artifactId&gt;netty-transport-native-epoll&lt;/artifactId&gt;
 &lt;version&gt;${netty.version}&lt;/version&gt;
 &lt;classifier&gt;${epoll.os}&lt;/classifier&gt;
&lt;/dependency&gt;
</code></pre>

The auto-generated module name for this dependency is:

<pre><code>netty.transport.native.epoll
</code></pre>

And as the <code>native</code> keyword is reserved in Java 9 I can't add this module as a dependency to my project:

<pre><code>module core {
 requires netty.transport.native.epoll;
}
</code></pre>

Due to:

<pre><code>module not found: netty.transport.&lt;error&gt;
</code></pre>

Additionally the jar tool <code>--describe-module</code> reports the following:

<blockquote>
 Unable to derive module descriptor for:
 netty-transport-native-epoll-4.1.17.Final-SNAPSHOT-linux-x86‌_64.jar
 netty.transport.native.epoll: Invalid module name: 'native' is not a
 Java identifier
</blockquote>

Are there any workarounds? (except "release correct netty artifact", of course).

<a href="https://stackoverflow.com/a/46501811/1746118">EDIT</a>:

As the quick fix for maintainers - you can add next line to build:

<pre><code>&lt;manifestEntries&gt;
 &lt;Automatic-Module-Name&gt;netty.transport.epoll&lt;/Automatic-Module-Name&gt;
&lt;/manifestEntries&gt;
</code></pre>

Unable to derive module descriptor for auto generated module names in Java 9?

Java

我的项目依赖于Netty Epoll传输。下面是依赖关系：<dependency> <groupId>io.netty</groupId> <artifactId>netty-transport-native-epoll</artifactId> <version>${netty.version}</...

问无法为Java 9中自动生成的模块名称派生模块描述符？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问无法为Java 9中自动生成的模块名称派生模块描述符？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问无法为Java 9中自动生成的模块名称派生模块描述符？
EN