blocks|key|328684|text|许多库是向后兼容的。但不是全部..|type|unstyled|depth|inlineStyleRanges|entityRanges|data|328685|328686|旧的方法是尝试只依赖于一个版本。|328687|使用相同的版本(最新版本)编译这两个可能会更安全。|328688|至少你得到的是编译时错误，而不是运行时错误。|328689|如果需要，你可以对你的库进行一点修改，使之与旧的依赖关系一起工作……|328690|这将需要访问源代码...|328691|328692|请注意，编译时兼容性也不能保证正确的运行时行为。这是一个步骤，然后您可以：|328693|328694|读取WhatsNew文件中的新版本jar|unordered-list-item|328695|在互联网上查找用户报告的兼容性问题|328696|编写JUnits+|328697|比较两个jar中的代码|328698|<代码>F29|328699|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|15|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|16|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1B|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1D|8|@]|9|@]|A|$]]|$1|T|3|U|5|S|7|1E|8|@]|9|@]|A|$]]|$1|V|3|W|5|S|7|1F|8|@]|9|@]|A|$]]|$1|X|3|Y|5|S|7|1G|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1H|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|12|$]]

Many libraries are backward compatible. But not all..

<hr>

The old way is to try to depend from only one version.

It is probably safer to compile both with the same version (latest). 
At least you get compile-time errors, instead of runtime errors.

If needed, you can modify a little bit your library that works with the old dependency... 
This would require access to the source...

<hr>

Please note that compile-time compatibility will not guarantee correct runtime behavior either. It is one step, then you can:

<ul>
<li>read the WhatsNew file for the new version of the jar</li>
<li>look on the Internet for users reporting compatibility problems</li>
<li>write JUnits </li>
<li>compare the codes in both jars</li>
</ul>

blocks|key|328701|text|OSGi可以解决这个问题。OSGi捆绑包只不过是一个jar，其中包含详细说明版本的附加元数据。包有一个版本号，并将详细说明依赖jars的版本号(或范围)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|328702|有关更多信息，请查看this+introductory+Javaworld+article。|offset|length|328703|要在没有OSGi的情况下解决这个问题，就意味着必须手动确保您使用兼容的jars编译和运行。正如您已经发现的，这不一定是一项微不足道的任务。由于jars不一定标识它们的版本，因此唯一确定的方法是记录/比较校验和或签名。|328704|entityMap|0|LINK|mutability|MUTABLE|url|http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html^0|0|A|Z|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

OSGi can fix this problem. An OSGi bundle is nothing more than a jar with additional metadata detailing versions. A bundle has a version number, and will detail version numbers (or ranges) of dependent jars.

Take a look at <a href="http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html" rel="nofollow noreferrer">this introductory Javaworld article</a> for more information.

To solve this without OSGi means having to ensure manually that you compile and run with compatible jars. As you've discovered that's not necessarily a trivial task. Since jars don't necessarily identify their versions, the only sure way to do this to record/compare checksums or signatures.

blocks|key|3297840|text|正如KLE所提到的，默认方法是依赖于较新的版本。不能保证，但在大多数情况下，这是有效的。也许最好的方法(虽然是一个臃肿的)是使用OSGI来克服它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3297841|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As mentioned by KLE, the default approach is to depend on the newer version. There is no guarantee, but most of the time this works. Probably the best way (while being a bloated one) is using OSGI to get over it.

blocks|key|326100|text|您提到的“老方法”(也是OSGI肯定在幕后使用的方法)是为依赖项的两个分支安装自己的ClassLoader。例如，这就是应用程序服务器能够在同一JVM中运行同一应用程序的旧版本和新版本的原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|326101|阅读有关类加载器层次结构的内容。|326102|在您的设置中，棘手的部分是连接点，即来自两个分支的类相遇的地方。两个分支都不能使用加载到另一个分支中的类。让它工作的方法是确保只有由引导类加载器(JRE类)或MY.jar的类加载器加载的类才会向下传递到两个分支。|326103|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

"Old way" you mentioned (and the one OSGI certainly uses under the hood) is to install your own ClassLoader for both branches of your dependencies. That's how, for instance, application servers are able to run both older and newer versions of the same application inside the same JVM.

Read about classloader hierarchy.

In your setup, the tricky part is the joint point, where classes from both branches meet. Neither branches can use classes loaded into another one. The way to make it work is to make sure only classes loaded by boot classloader (JRE classes) or classloader of MY.jar are passed down to both branches.

blocks|key|326105|text|引用一个基本的"oldway“实现校验https://github.com/atulsm/ElasticsearchClassLoader|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|326106|这提供了一种处理elasticsearch客户端使用的非向后兼容版本的方法。|326107|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/atulsm/ElasticsearchClassLoader^0|J|1E|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

To refer a basic "oldway" implementation checkout <a href="https://github.com/atulsm/ElasticsearchClassLoader" rel="nofollow">https://github.com/atulsm/ElasticsearchClassLoader</a>

This provides an approach to handle non-backward compatible versions of elasticsearch client usage.

This is a common problem. I'm using 2 libraries A.jar and B.jar and these depend on different versions of the same jar. 
Let's say that at runtime I need THIS.x.x.x.jar

<pre><code>MY.jar 
 -&gt; A.jar -&gt; THIS.1.0.0.jar
 -&gt; B.jar -&gt; C.jar -&gt; THIS.5.0.0.jar
</code></pre>

I can compile the specific jar (A.jar/B.jar) against its dependency but at runtime I've to load only 1 version. Which one? 
Loading only 1 dependency (the latest version) means that my code will probably throw runtime exceptions if the libraries are not Backward Compatible (are there Backward Compatible libraries out there?).

Anyway I know that something like OSGi can fix this issue. 
I'm wondering what's the old way to fix this kind of problems...

Thanks a lot

Java Classloader - how to reference different versions of a jar

Elasticsearch 

服务器

这是一个常见的问题。我使用了两个库A.jar和B.jar，它们依赖于同一个jar的不同版本。假设在运行时我需要THIS.x.x.x.jarMY.jar        -> A.jar -> THIS.1.0.0.jar     -> B.jar -> C.jar -> THIS.5.0.0.jar我可以根据依赖项编译特...

问Java Classloader -如何引用不同版本的jar
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java Classloader -如何引用不同版本的jarEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java Classloader -如何引用不同版本的jar
EN