CN106605212A - 在动态链接的运行时环境中的模块化共同版本管理 - Google Patents

Abstract

模块化共同版本管理可以包括创建可以包括类的多个版本的多版本库。根据各种实施例，多版本库可以包括基础版本和一个或多个其他版本，其他版本中的每一个可以对应于软件开发包、运行时环境或者软件平台的特定相应版本。在运行时，可以搜索多版本库以便加载类的与当前执行的运行时环境的版本对应的版本。如果多版本库不包括类的与环境或平台的当前执行版本对应的版本，如果在多版本库中找到类的与环境的先前版本对应的版本，则可以加载类的与环境的先前版本对应的版本。作为替代，如果没有找到该类的其他版本，则可以从多版本库中加载该类的基础版本。

Description

在动态链接的运行时环境中的模块化共同版本管理

背景技术

第三方库和框架一般需要支持一定范围的软件平台版本，通常向前追溯若干个版本。这往往意味着开发者常常并没有利用软件平台的较新版本中可用的特征，因为常常难以表达条件化的平台依赖性(即，反映性地测验和激活可能并没有出现在所有支持的平台版本中的方法)。作为替代，为了支持不同的底层平台版本而分发多个库版本可能是昂贵的(例如，在开发时间和分发媒介方面)。这会为库和框架开发者使用新特征带来阻碍，进而可能成为用户升级到新平台版本的阻碍，这本身又为开发者支持较新平台版本的特征带来阻碍——从而形成了可能妨碍新特征的采用和改进的循环。

软件平台一般以向后兼容的方式进行版本管理，使得较旧的应用能在较新的平台版本上运行。但是，软件库常常依赖于底层平台的某个版本。因此，库开发者一方面可能希望让库在较旧的平台版本上运行，另一方面可能也希望使用来自较新的平台版本的特征。因此，软件库开发者经常延迟使用较新的平台特征，直到他们能要求较新的平台版本(并且因此可能没有向后兼容较旧的平台版本)。此外，软件库开发者可能分发库的多个版本，以便既对一些用户向后兼容，又对其它用户支持较新的平台特征。

发明内容

本文描述的是用于动态链接(例如运行时可链接)的运行时环境中的模块化共同版本管理(modular co-versioning)的系统和方法的各种实施例。根据本文所描述的模块化共同版本管理，可以创建包括类的多个版本的多版本库。根据各种实施例，多版本库可以包括基本版本和一个或多个其它版本，其中每一个版本可以对应于软件开发包、运行时环境或软件平台的特定相应版本。因此，根据一些实施例，本文所描述的多版本库可以是在一个分发单元内的能利用底层运行时的多个版本的版本的库。

在运行时，多版本库可以被搜索，以加载类的与当前执行的运行时环境或平台的版本或者与被用来开发当前执行的环境/平台的软件开发包的版本对应的版本。如果多版本库不包括类的与环境/平台的当前执行版本对应的版本，则可以在该多版本库中找到该类的与环境/平台(和/或软件开发包)的先前版本对应的版本并加载。作为替代，如果在该多版本库中没有找到该类的后续版本，则可以从该多版本库中加载该类的基础版本。

因此，本文描述的模块化共同版本管理可以让库开发者提供类的多个版本，以便支持运行时环境、软件平台或者软件开发包的多个版本，而不用维护多个不同的库和/或交付物。

附图说明

图1是示出了根据一个实施例的利用本文描述的模块化共同版本管理实现的多版本库的逻辑框图。

图2是示出了在一个实施例中的被配置为从根据模块化共同版本管理的多版本库中加载类的类加载器的逻辑框图。

图3是示出了如本文描述的用于从根据模块化共同版本管理的多版本库中加载类的方法的一个实施例的流程图。

图4是示出了在一个实施例中的根据模块化共同版本管理实现的基于Java的多版本库的逻辑框图。

图5是示出了如本文描述的根据模块化共同版本管理的多版本库的一个实施例的逻辑框图，该多版本库没有在每个文件夹都包括每个类的版本。

图6是示出了根据一个实施例的被配置为实现模块化共同版本管理的软件开发系统的逻辑框图。

图7是示出了如本文描述的生成多版本库的软件开发系统的一个实施例的流程图。

图8是示出了根据一个实施例的适合实现模块化共同版本管理的示例计算机系统的逻辑框图。

具体实施方式

本文描述的用于实现模块化共同版本管理的系统和方法的各种实施例。例如，库经常依赖于底层平台的某个版本，比如需要软件平台或者运行时环境的特定(或较新)版本。库开发者可能希望具有在较旧的平台版本上运行的库，但是也可能希望使用来自较新的平台版本的特征。本文描述的模块化共同版本管理可以提供开发和/或软件封装方法，以便使动态链接的平台(例如，运行时可链接的平台)允许多版本库的创建和分发。

本文描述的模块化共同版本管理可以被视为打破了利用来自较新的平台版本的特征的能力和由于要求所有用户升级到较新的版本而造成向后兼容性的丢失之间的耦合。库和框架研发者可以维护和分发单个多版本产品(例如，软件库)，该多版本产品能够在较新的底层平台上被执行时利用新特征(或者应付已移除特征的缺失)，而不要求所有用户进行升级(这将减少他们的库的潜在用户，并且因此减小库的市场)。

在一些实施例中，模块化共同版本管理包括多版本库的创建。例如，在基于Java的系统中，模块化共同版本管理可以利用用Java软件开发包(JDK)开发的多版本Java归档(JAR)格式，其中JAR文件可以对较旧的运行时环境(例如，较旧的JRE)表现为普通(例如单一版本的)JAR文件，但是还可以包括较旧的运行时环境可能忽略的额外的“隐藏”文件夹(例如，在META-INF/模块文件夹中)。

但是，被配置为支持模块化共同版本管理的运行时环境或者软件开发工具可以利用多版本Java(JAR)文件中的额外信息来支持模块化共同版本管理。图1是示出根据一个实施例利用如本文描述的模块化共同版本管理实现的多版本库的逻辑框图。

如图1所示，多版本库100可以包括类的多个版本。例如，类110可能表示类的通用、基础或者根版本(例如，可以被软件开发包和/或运行时环境的多个受支持的版本使用的类的版本)。此外，类120A、120B和120C可以表示类(例如，由类110表示的相同的类中的一些或全部)的被软件开发包和/或运行时环境的相应版本支持的不同版本。在一些实施例中，多版本库100可以包括元数据130，该元数据130指示并描述根据模块化共同版本管理实现的类的多个版本的存在，这将在下面更详细地描述。

例如，在一个基于Java的例子里，多版本JAR文件可以包括具有类的额外的目录，如下所示：

JAR文件

如上所示，示例JAR文件可以包括相同类的针对运行时环境的不同版本的多个版本，该运行时环境由诸如Java开发包(JDK)的软件开发包的特定版本支持。例如，如图1所示，多版本库100可以表示基于Java的多版本JAR文件，根据一个示例实施例，该JAR文件可以在目录根部分中包括诸如类110的类的基础版本，而同时在JDK 8、JDK 9和JDK 10部分中包括分别由类120A、120B和120C表示的类的其他版本。在一些实施例中，特定类的所有版本可以有相同的类签名。也即，特定类的所有版本都将被认为是二进制兼容的，而且可以对应于相同的类签名。因此，在一些系统中，加载相同类的两个不同版本会是错误的或者不可能的。

大体上，类可以被认为是用户定义的类型或数据结构，其可以包括数据、变量、函数、方法和/或其它属性作为成员，并且表示用于创建特定类型的编程对象的定义、设计或模板。类可以为数据成员提供初始值，并且为成员函数和方法提供实现方式。类经常被包括在库里。库可被认为是被软件程序或应用使用的资源的集合。根据一些实施例，库可以包括任何各种类型的资源，包括但不限于：数据、文档、类、子例程和/或类型规格。库可以被组织得以便被多于一个应用(可能在同一时间)使用，并且可以通过提供资源使得应用可以不必实现(或重新实现)同样的行为而提升可重用性。

当运行在不同的运行时环境上(例如，与软件开发包的不同版本对应的运行时环境)时，可以从多版本库100(例如，以上示例中的多版本JAR)中加载类的不同版本。例如，如图1所示，类110可以对应于软件开发包140(例如，软件开发包的特定版本)(并且支持其特征)，而类120A、120B和120C可以分别对应于软件开发包150A、150B和150C(例如，软件开发包的相应版本)(并支持其特征)。

应当注意，虽然本文描述的主要是基于Java的系统方面，但是根据不同的实施例，模块共同版本管理也可以针对不是(或者不是专门)基于Java的软件开发(和执行)系统被应用和/或使用。此外，在一些实施例中，多版本库100可以表示运行时可链接的库，比如JAR或动态链接的库(DLL)。

在运行时，运行时环境(或运行时环境的类加载器模块)可以通过首先确定多版本库100是否包括类的与运行时环境的版本(例如，正在执行的版本)对应的版本，来从多版本库100(例如，多版本JAR)文件中加载类。如果多版本库100包括该版本，则运行时环境可以加载类的该特定版本(例如，运行时环境的类加载器可以加载该类)。在以上的基于Java的示例中，基于JDK版本10的运行时环境可以(例如，从类120B中)加载类的一个版本，而基于JDK版本9的运行时环境可以(例如，从类120C中)加载类的不同版本。

因此，多版本库(例如，多版本JAR)可以被认为是包括总体组成(amount to)类路径的内容。图2是示出在一个实施例中被配置为从根据模块化共同版本管理的多版本库中加载类的类加载器的逻辑框图。例如，在一个实施例中，在运行时环境200内执行的类加载器210可以通过首先从多版本库100的类120C中搜索类来加载类，如箭头220所示。如果没有在类120C内找到类的合适版本，则类加载器210可以被配置为然后在类120B内搜索该类的版本，如箭头230所示。类似地，如果没有在类120B中找到类的合适的版本，则类加载器210可以被配置为在类120A中搜索该类，如箭头240所示。如果，类加载器210不能在多版本库100的任何特定于版本的区域(例如类120A，120B和120C)中找到该类的合适版本，则类加载器210可以被配置为从类110中加载该类的基础版本，如箭头250和260所示。

在基于Java的例子中，在运行时，被配置为实现模块化共同版本管理并运行在JDK版本10上的类加载器，诸如类加载器210，可以搜索总体组成类路径的内容，包括特定于版本10的类(例如，类120C)，然后是特定于版本9的类(例如类120B)，然后是特定于版本8的类(例如类120A)，然后是在目录根中的类(例如类110)。相似地，在JDK版本9上执行的类加载器可以首先搜索特定于版本9的类(例如类120B)，然后是特定于版本8的类(例如类120A)，并且然后是目录根类(例如类110)，而不用搜索特定于版本10的类(因为在本例中版本10晚于当前执行的版本9)。此外，根据一些实施例，未配置成利用模块化共同版本管理的类加载器可以只看到目录根类(例如类100)(并且因而只能从该目录根类中加载类)。因此，举一个例子，如果JDK版本8、9和10都支持模块化共同版本管理而JDK版本7不支持，则单个多版本库可以支持JDK版本7至10(例如，版本7的类加载器可以读取类的基础版本，而版本8至10的类加载器可以分别利用他们的相应的特定于版本的类)。

图3是示出如本文所描述的用于从根据模块化共同版本管理的多版本库中加载类的方法的一个实施例的流程图。如图3所示，在运行时环境内执行的类加载器(诸如在运行时环境200内执行的类加载器210)可以在运行时从运行时可链接的多版本库(诸如多版本库100)中加载类，该如块300所示，该多版本库被配置为根据模块化共同版本管理而包括类的多个版本。如上所述且如块310所示，类加载器可以确定该多版本库是否包括该类的与软件开发包的当前版本对应的版本，软件开发包的当前版本用于实现能够在运行时环境的相应当前版本内执行的软件。例如，根据一个实施例，类加载器210可以确定多版本库100是否包括类的与软件开发包的一版本对应的版本，软件开发包的该版本被用于为相同版本的运行时环境200开发软件，其中类加载器当前正在该相同版本的运行时环境200上执行。在一些实施例中，类加载器210可以不搜索所需类(例如，将被加载的类)的与软件开发包的“最新”版本对应的版本，因为类加载器210可能不在与“最新”版本对应的运行时环境中被开发或者不在与“最新”版本对应的运行时环境内执行。相反，根据一些实施例，类加载器210可以开始在多版本库100的一区域中搜索该类，多版本库的该区域包括与软件开发包的与类加载器当前正在执行(或者过去利用其开发)的版本相同的版本对应的类。

响应于确定多版本库包含类的与软件开发包的当前版本相关联的版本，如判定块320的肯定输出所示，类加载器可以从多版本库中加载类的与软件开发包的当前版本相关联的版本，如块330所示。例如，如以上所述，如果类加载器210在类120C中找到了类的合适版本，则类加载器210然后可以从多版本库100中加载类的这个版本。

但是，响应于确定多版本库不包含该类的与软件开发包的当前版本相关联的版本，如判定块320中的否定输出所示，类加载器可以确定多版本库是否包含类的与软件开发包的先前版本对应的版本，如块340所示。例如，类加载器210可以被配置为响应于确定多版本库100在类120C中不包括该类的版本而在类120B中搜索该类的版本。在一个基于Java的例子中，根据一个实施例，对应于JDK 9的类加载器可以响应于确定多版本JAR不包括特定类的JDK 9版本而确定多版本JAR是否包含该类的JDK 8版本。

响应于确定多版本库包含该类的与软件开发包的先前版本对应的版本，如判定块350的肯定输出所示，类加载器可以从多版本库中加载该类的与软件开发包的先前版本对应的版本，如块360所示。例如，根据一个实施例，类加载器210可以被配置为响应于确定多版本库100在类120A中包括所需类的版本而从类120A中加载类。在基于Java的例子中，对应于JDK 9的类加载器可以响应于确定多版本JAR不包含特定类的JDK 9版本且响应于确定多版本JAR包括类的JDK 8版本而加载该类的JDK 8版本。

类似地，响应于确定多版本库不包括类的与软件开发包的先前版本对应的版本，如判定块350的否定输出所示，类加载器可以被配置成从多版本库中加载该类的基础版本，如块370所示。例如，根据一个实施例，类加载器210可以被配置成响应于确定多版本库100在类120C、120B或120A的任何一个中都不包括所需类的版本而从类110中加载类。在基于Java的例子中，对应于JDK 9的类加载器可以响应于确定多版本JAR不包括特定类的对应于JDK版本8、9、10的版本而加载类的基础版本。

因此，在一些实施例中，模块化共同版本管理可以让库开发者创建并分发这样的单个库：该库既能够向后兼容较旧的运行时环境版本又能够支持在运行时环境的较新版本中提供的后续特征。执行运行时环境的较旧版本的用户可以与执行运行时环境的较新版本的用户一样使用相同的库。因此，库开发者可以不必分发多个版本，因此潜在地防止了使用户困惑(例如，用户不会意外地下载并安装库的错误版本)。此外，库开发者可以不必要求所有用户升级到运行时环境的较新版本。

另外，多版本库可以不包括每个类的多个版本。相反，多版本库可以包括一些类的多个版本而并不包括其他类的多个版本。另外，多版本的库可以包括每个类的相同数量的版本。例如，根据一些实施例，多版本库可以包括一个类的版本数量少于另一个类的版本数量。

根据各种实施例，模块化共同版本管理可以以不同方式实现，并且用于不同的系统。例如，模块化共同版本管理的基于Java的例子可以包括多版本JAR文件(例如，多版本库100)，该文件可以包括：包含类和/或资源的基础版本的目录根文件夹(或区域，或部分)，以及包括关于JAR的元数据的META-INF文件夹(或区域，或部分)，该元数据包括有关类和/或资源的附加版本的信息。例如，根据一个实施例，多版本库100可以包括表示目录根文件夹的类110和表示META-INF文件夹的元数据130。在其他实施例中，多版本库100可以用非Java的软件编程语言(例如，诸如C、C++等)来实现。

通过包括有关特定文件组的版本管理元数据，支持模块化共同版本管理的多版本库可以兼容地编码(例如，包括)库的用于不同底层平台版本的多个版本(例如，与软件开发包的多个版本兼容)。

如上所述，多版本库可以包括用于特定于软件开发包(和/或运行时环境)的具体版本的代码(例如，类和/或资源)的附加文件夹。例如，在一个基于Java的例子中，多版本JAR(MVJAR)可以包括用于特定于具体Java开发包(JDK)版本的代码的附加文件夹。因此，用于典型的库的一个示例JAR可能看起来如下(例如，不支持多个版本)：

此外，根据一个示例实施例，如果存在类A和类B的替代版本(例如，该替代版本利用版本8的特征，并且类A的另外一个版本利用了9的特征)，他们可以被包括在多版本JAR中，如下所示：

图4是示出在一个实施例中的多版本库的基于Java的例子的逻辑框图，该多版本库是根据上述例子用模块化共同版本管理实现的。如图4所示，多版本库100可以在一个实施例中表示基于Java的多版本JAR，该多版本库100可以包括包含类的基础版本的根区域或文件夹400以及包含有关类的附加版本的信息的META-INF区域或文件夹410。例如，根文件夹400可以包括类A、类B、类C和类D的基础版本，如块440A、450A、460和470所示。此外，META-INF文件夹410可以包括例如420和430两个文件夹，它们分别包括特定于JDK的版本8和版本9的类，如块440B、450B和440C所示。因此，在图4中，根据以上基于Java的例子，块440A、440B和440C可以表示类A的三个不同版本，块450A和450B可以表示类B的两个不同版本。

根据一些实施例，根文件夹400中的类可以是对未被配置为支持模块化共同版本管理的传统运行时环境唯一可见(或者可用的)——由此有可能使得多版本库100对于传统运行时环境而言不能与传统库区分开——除了META-INF文件夹410，该META-INF文件夹410可以被传统运行时环境忽略。

此外，在一些实施例中，对于支持模块化共同版本管理的运行时环境，与高于当前执行的软件开发包版本的软件开发包版本对应的类可以被忽略。例如，利用上述的基于Java的例子，在运行时，文件夹430可以被对应于JDK版本8的运行时环境(例如在运行时环境内执行的类加载器)忽略。因此，基于版本8的类加载器可以在文件夹420(例如，对应于当前执行的版本)中搜索类。根据一些实施例，如果没有找到合适的类，如果在多版本JAR中存在JDK的任何先前(例如，较低)版本，则类加载器可以在对应于该先前版本的文件夹中搜索该相同的类，并且如果在任何特定于版本的区域中没有找到该类的合适版本，则类加载器可以搜索JAR目录根文件夹。

也就是说，根据一些实施例，对应于JDK版本9的类加载器，运行时环境可以在多版本JAR文件中搜索类，就好像存在这样的特定于JAR的类路径：该类路径先包括版本9的文件，然后包括版本8的文件，再然后包括JAR根。但是，在版本8的JDK上，这个类路径可以只包括版本8的文件和JAR根(例如，它可以忽略版本9的类，因为版本9的类与晚于当前执行版本的版本对应)。

通过利用模块化共同版本管理，有可能让类的为后续软件开发包版本设计的版本“覆盖”该同一类的为较早版本设计的版本。在上述基于Java的例子中，当运行在被配置为支持模块化共同版本管理的版本8JDK上时，类A和类B的特定于JDK8的版本(例如块440B和450B)以及类C和类D的通用(例如，基础或者目录根)版本(块460和块470)可以是可见的(和/或可用的)。但是，当运行被配置为支持模块化共同版本管理的JDK版本9，类A的特定于JDK 9的版本(例如块440C)、类B的特定于JDK 8的版本(例如块450B)和类C和类D的通用版本(例如块460和470)可以是可见的。当运行JDK的较旧版本或者在未被配置为支持模块化共同版本管理的JDK上运行时，所有类仅有基础版本(例如块440A、450A、460和470)可见。

虽然本文描述的主要是类和类文件方面，在一些实施例中，当实现模块化共同版本管理时，资源文件可以和类文件用相同的方式处理。也就是说，根据一些实施例，资源的多个版本可以包括在单个文件，而且不同版本可以利用软件开发包或运行时环境的不同版本一起被使用。此外，在一些实施例中，本文描述的不可见的类和/或资源可以对于类加载器或者运行时环境可见，但是类加载器或者运行时环境可以被配置成忽略或者不利用这些类和/或资源。

此外，当实现模块化共同版本管理，可以修改传统的版本控制(例如作为软件开发工具的一部分)以便正确处理类和/或资源的多个版本。例如，根据一个实施例，在基于Java的系统中，版本控制可能不适用于多版本JAR文件中的元数据(例如，诸如对于主要应用类和服务的声明)。

在一些实施例中，诸如基于Java的多版本JAR的多版本库可以被认为是具有其自己的版本的单个发行单元，尽管它可以在内部表示用于在不同平台(例如，运行时环境)版本上使用的库的多个版本的实现。因此，多版本库的实现的每个版本可以针对于公共API是相同的，以此来保证严格的API兼容性。在一些实施例中，这可以意味着在特定于版本的文件夹中存在的公共类应该在根文件夹中有对应的版本。但是，类并不是必须在每个特定于版本的文件夹中具有一个版本。

例如，如本文所述，图5是示出根据模块化共同版本管理的、没有在每个文件夹中包括每个类的版本的多版本库的一个实施例的逻辑图。图5中的多版本库和以上讨论的图4中的多版本库很相似。但是，根据一个实施例，图5示出了附加的类E的版本，由块500和500A表示。因此，在基于Java的例子中，多版本库100可以在JAR根文件夹400中包括类E的基础版本(例如块500A)，以及在版本9文件夹430中包括类E的版本9版本(例如块500B)，而不在版本8文件夹420中包括类E的版本8版本。根据一个实施例，当加载类E时，对应于版本9JDK的类加载器可以被配置为找到该类在版本9文件夹430中的版本(例如块500B)并加载，而对应于版本8JDK的类加载器可以被配置为忽略该类在版本9文件夹430中的版本，而加载该类的基础版本(例如块500A)，因为版本8文件夹420没有类E的版本。

根据一些实施例，模块化共同版本管理可以使库和框架开发者解开使用来自特定软件开发包(和/或运行时环境/平台)版本中的特征与使所有用户迁移到那个特定版本的要求之间的耦合。取而代之，库和框架维护者可以通过使用单个可交付的库(例如，多版本库)逐步迁移到(和/或)支持新特征，同时仍然提供对旧特征的支持。

实现模块化共同版本管理可以包括一个或多个开发和/或运行时部件。例如，诸如编译器、链接器和其他库工具的软件开发工具可以被被配置成能够创建多版本库。例如在基于Java的示例实施例中，以下部件可以被配置为实现本文描述的模块化共同版本管理的某个部分(或者全部)：

·JAR规格

·类加载器实现

·JAR创建工具和JAR签名工具

·编译器

·一个或多个测试工具

·部件扫描库

·以及调试工具。

例如，图6是示出根据一个实施例被配置为实现模块化共同版本管理的软件开发系统的逻辑框图。如图6所示，根据一个实施例，编译器600可以被配置为和库创建工具640一起工作来生成多版本库100。编译器600可以作为单个建立函数的一部分或者分开地编译源代码610、620和630，以便编译类的多个版本。例如，根据各种实施例，源代码610可以包括一组类的基础版本，而源代码620和630可以包括该相同类的被配置为支持软件开发包或运行时环境平台的相应版本的版本。

如箭头615、625和635所示，根据本文所述的模块化共同版本管理，编译器600可以提供类的编译后的版本给库创建工具640，库创建工具640进而可以被配置为生成多版本库100，使得多版本库100可以包括类的多个版本。因此，图6中所示出的软件开发系统可以被配置为编译类的多个版本(例如在源代码610、620和/或630中)，并且在多版本库100中包括这多个版本，使得在运行时，与软件开发包的不同版本对应的运行时环境/平台可以加载该类的不同版本。

尽管没有在图6中阐述，附加的软件开发工具和/或部件也可以被使用或者被配置来实现(或帮助实现)如本文所述的模块化共同版本管理。此外，编译器600和/或库创建工具640可以被配置为对于类的不同版本利用软件开发包、库、建立选项和/或其他部件的不同版本。例如，根据各种实施例，在一个实施例中，源代码610可以用软件开发包的采用一组建立选项的一个版本来被编译，而源代码620可以用软件开发包的采用不同的一组建立选项的不同版本来被编译。

图7是示出用于创建根据如本文所述的模块化共同版本管理的多版本库的方法的一个实施例的流程图。如块700所示，软件开发系统可以被配置为建立运行时可链接的包括类的多个版本的多版本库。在一些实施例中，如以上所述，类的多个版本可以全部对应于相同的类签名。例如，在一个实施例中，软件开发系统可以被配置为用Java编程语言(和利用其他合适的软件开发库和/或工具)创建和/或生成多版本Java归档。在另一实施例中，诸如图6中所示出的软件开发系统可以被配置为用任何诸如C、C++或Java的各种编程语言创建和/或生成多版本的动态链接库。

如块710所示，作为建立多版本库的一部分，软件开发系统可以被配置为在多版本库中存储类的基础版本，该基础版本并不对应于用于开发多版本库的软件开发包的任何特定版本。如上所述，类的基础版本可以被软件开发包、运行时环境或者平台的多个版本支持或者支持软件开发包、运行时环境或者平台的多个版本。在一个基于Java的例子中，多版本JAR可以包括类的基础版本(例如，在根目录区域中)，该基础版本支持Java开发包的版本7、8、9，并且因此并不对应于Java开发包的任何特定版本。也即，类的基础版本可以使用软件开发包的特定版本被编译，但是在模块化共同版本管理方面，可以不对应于软件开发包的任何特定版本(以用于确定在运行时加载类的哪个版本)。

此外，在一些实施例中，存储类的基础版本可以包括将类的基础版本存储在多版本库的根文件夹或者基础文件夹(部分或其他区域)中，其中基础文件夹被配置为存储多个类的基础版本，且并不对应于该软件开发包(或者运行时环境或平台)的任何特定版本。

如图7所示的方法还可以包括在多版本库中存储类的一个或多个其他版本，每个版本都对应于软件开发包的相应版本，如块720所示。例如，如上所述，多版本库100可以包括类的基础版本以及同一类的多个其他版本(这些都可以对应于相同的类签名)。例如，多版本库100可以包括Java类的支持Java开发包(JDK)的多个版本的基础版本以及该类的与JDK的版本8对应的版本和该类的与JDK的版本9对应的另一版本。

在一些实施例中，存储类的一个或多个其他版本可以包括将其他版本存储在多版本库的相应的、特定于版本的文件夹(部分或者其他区域)中。如上所述，根据一些实施例，类的基础版本可以被存储在基础文件夹或者根文件夹(例如，图4中的项400)中，而每个其他版本可以被存储在特定于版本的文件夹(例如，图4中的项420和430)中。在一个实施例中，存储其他版本还可以包括存储元数据(例如，图1和图2中的元数据130)，该元数据包括识别其他版本以及其他版本所对应的具体软件开发包版本的信息。

此外，根据一些实施例，库开发者可以修改其源布局，以便为基础版本和特定于版本的覆盖版本具备分开的源根(source root)。例如，库开发者可能需要修改软件建立过程来编译在不同语言级别的不同的特定于版本的根，并且也可能需要创建多版本库(例如使用更新的开发工具)。另外，开发者可能会在不同平台(例如运行时环境的多个版本)上测试，比如对可能在不同平台上运行的代码的不同版本进行测试。

此外，在某个实施例中，取代基于当前执行的运行时环境、当前执行的软件平台和/或软件开发包来加载类的版本，类的特定版本可以基于用户(例如开发者)的偏好而被加载。例如，根据一些实施例，库开发者可以生成并分发诸如多版本库100的多版本库，而多版本库100的用户(例如开发者或者程序员)可以指示运行时环境忽略类的一个或多个版本的偏好。

例如，在一个实施例中，用户可以指示从不使用类的最新版本的偏好，即使是在对应于该最新版本的运行时环境上执行时。例如，尽管在多版本库中的类可以支持运行时环境的最新版本，但是该多版本库的终端用户(例如，使用该库的程序员)的代码可能并不支持。

此外，用户可以指示运行时环境仅使用类的特定版本的偏好。例如，在一个实施例中，用户可以指示仅使用多版本库中的一个或多个类的基础版本的偏好。

根据各种实施例，有关多版本库中的类的哪些版本的用户偏好可以以任何各种方式被指示。例如，在一个实施例中，用户可以编程地指示有关使用或忽略多版本库中的类的一个或多个版本的偏好，比如通过调用API的一个或多个方法。在另一实施例中，用户可以使用一个或多个全局、系统和/或环境变量来指示有关使用或者忽略多版本库中的类的一个或多个版本的偏好。

在一些实施例中，用户可能基于逐个类来指示有关使用或忽略多版本库中的类的版本的偏好，而在另一些实施例中，这种偏好可以仅仅是基于逐个版本进行的应允。例如，返回到参考图4，在一个实施例中，用户可以有能力指示忽略(例如，从不使用)对应于版本9的类(例如，在文件夹430中存储的类)的偏好，而在另一实施例中，用户可以有能力指示不使用类B的版本8版本(例如，由块450B表示的)但是仍然使用类的其它版本8版本(例，由块440B表示的类A)的偏好。根据一些实施例，基于逐个类来指示版本可能涉及有关兼容性的附加风险，该兼容性来自于执行可能无法在一起正确执行的类的混合版本(例如，一个类的一个版本和不同的类的另一版本)。

至少在一些实施例中，实现部分或者全部本文所描述技术的计算机系统可以包括包含一个或多个计算机可读介质或者被配置为访问一个或多个计算机可读介质的通用计算机系统。图8示出了适合于实现本文描述的方法、特征和改进的这样的通用计算设备3000。在所示出的实施例中，计算设备3000包括通过输入/输出(I/O)接口3030耦接到系统存储器3020的一个或多个处理器3010。计算设备3000还包括耦接到I/O接口3030的网络接口3040。

在各种实施例中，计算设备3000可以是包括一个处理器3010的单处理器系统或者包括若干个处理器3010(例如，两个、四个、八个或者其他适合数目)的多处理器系统。处理器3010可以包括能够执行指令的任何合适的处理器。例如，在各种实施例中，处理器3010可以是实现诸如x86、PowerPC、SPARC或者MIPS指令集架构(ISA)或其他任何合适的ISA的任何各种ISA的通用或者嵌入式处理器。在多处理器系统中，每个处理器3010可以通常但并非一定地实现相同的ISA。

系统存储器3020可以被配置为存储能被处理器3010访问的程序指令和数据。在各种实施例中，系统存储器3020可以使用任何合适的存储器技术来实现，该适合的存储器技术诸如静态随机访问存储器(SRAM)、同步动态随机访问存储器(SDRAM)、非易失或者闪存类型的存储器或任何其他类型的存储器。在所示出的实施例中，实现诸如以上描述的那些方法、技术和数据的一个或多个所需功能的程序指令和数据被示为作为代码(即，程序指令)3025和数据3026存储在系统存储器3020内。例如，在一个实施例中，存储器3020以及代码3025和数据3026可以存储用于实现模块化共同版本管理的程序指令和数据，包括例如上述多版本库100、运行时环境200、类加载器210、编译器600和/或库创建工具640。

在各种实施例中，被配置为实现模块化共同版本管理的一个或多个部件，比如运行时环境200、编译器600和/或库创建工具640(和/或者其中的任何单独的子模块)，可以分别用任何各种编程语言或者方法实现。例如，在一个实施例中，运行时环境200、编译器600和/或库创建工具640可以用JAVA、C、C++、汇编或者其他通用编程语言中的任何一种来编写，而在另一实施例中，运行时环境200、编译器600和/或库创建工具640中的一个或多个可以由不同的更加专用的编程语言来编写。此外，在一些实施例中，运行时环境200、类加载器210、编译器600或库创建工具640(和/或其中的各种子模块)可以不使用相同的编程语言来实现。

在一个实施例中，I/O接口3030可以被配置为协调设备中处理器3010、系统存储器3020和设备中包括网路接口3040或其它外围接口的任何外围设备之间的I/O流量。在一些实施例中，I/O接口3030可以执行任何必要的协议、时序或其他数据转换来将数据信号从一个部件(例如系统存储器3020)转化成适合由其他部件(例如处理器3010)使用的格式。在一些实施例中，I/O接口3030可以支持通过各种类型的外围总线连接的设备，例如，各种类型的外围总线诸如外围部件互连(PCI)总线标准或通用串行总线(USB)标准的变型。而且，在一些实施例中，诸如对于系统存储器3020的接口的I/O接口3030的部分或者全部功能可以直接整合在处理器3010内部。

网络接口3040可以被配置为允许在计算设备3000和连接到一个或多个网络3050的其他设备3060之间交换数据。在各种实施例中，网络接口3040可以支持通过诸如各种类型的因特网的任何合适的有线或者无线通用数据网络进行的通信。

在一些实施例中，系统存储器3020可以是被配置为存储如以上关于图1-7描述的用于实现对应方法和装置的实施例的程序指令和数据的计算机可读(例如计算机可访问)介质的一个实施例。但是，在其他的实施例中，程序指令和/或数据可以被接收、发送或存储在不同类型的计算机可读介质上。大体上说，计算机可读介质可以包括非瞬时存储介质或存储器介质，诸如磁介质或者光介质，例如经由I/O接口3030耦接在计算设备3000上的盘或者DVD/CD。非瞬时计算机可读存储介质可以还包括任何易失或者非易失介质，诸如RAM(例如SDRAM、DDR SDRAM、RDRAM、SRAM等)、ROM等，在计算设备3000的一些实施例中可以包括该易失或者非易失介质被作为系统存储器3020或者其他类型的存储器。

此外，计算机可读介质可以包括传输介质或者诸如电信号、电磁信号或者数字信号的信号，该信号通过诸如网络和/或无线链路的通信介质传送，该通信介质诸如可以通过网络接口3040实现。在各种实施例中，诸如在图8中示出的多个计算设备中的部分或全部可以用来在各种实施例中实现所述功能；例如，运行在各种不同设备和服务器上的软件部件可以协作提供该功能。在一些实施例中，部分所述功能在使用通用计算机系统来实现之外或者作为替代还可以使用存储设备、网络设备或者专用计算机系统来实现。本文使用的术语“计算设备”至少指所有这些类型的设备，但不限于这些类型的设备。

各种实施例可以还包括接收、发送或者存储根据之前的描述在计算机可读介质上实现的指令和/或数据。通常来说，计算机可读介质可以包括存储介质或存储器介质，诸如磁介质或者光介质，例如盘或者DVD/CD-ROM，诸如RAM(例如，SDRAM、DDR、RDRAM、SRAM等)、ROM等的易失或者非易失介质。在一些实施例中，计算机可读介质还可以包括经由诸如网络和/或无线链路的通信介质传送的传输介质或信号，诸如电信号、电磁信号或者数字信号。

在附图中示出或者在本文中描述的各种方法表示方法的示例性实施例。这些方法可以以软件、硬件或者其结合来实现。在各种方法中，步骤的顺序可以被改变，而且各种元素可以被添加、重排、组合、省略或者修改等。各种步骤可以自动被执行(例如，无需通过用户输入进行直接提示)和/或按程序执行(例如，根据程序指令)。

虽然在本文中参照特定实施例并在特定实施例的上下文中描述了各种系统和方法，但是将理解到，这些实施例是示意性的，而且本公开的范围并不局限于这些特定实施例。许多变型、修改、添加和改善是可能的。例如，在说明书中标识的块和逻辑单元用于理解所描述的实施例，但不意在限制本公开。例如，在一些实施例中，本文描述的被诸如运行时环境200、类加载器210、编译器600和/或库创建工具640的特定部件执行的动作、程序、方法、任务或者函数可以由不同的部件来执行，反之亦然。此外，在本文描述的系统和方法的各种实现中，功能可以有差异地分开或者组合在块里，或者用不同的术语描述。

这些实施例旨在是说明性的而非限制性的。相应地，用于本文描述的部件的多个实例可以作为单个实例而被提供。各种部件、操作和数据存储之间的界限在某种程度上是任意的，而且具体的操作是在特定的描述性配置的上下文中阐释的。其他的功能分配也被设想到了，而且可以落入相应例子的范围内。最后，在示例性配置中作为分离的部件呈现的结构和功能可以作为组合的结构或者部件而被实现。

尽管以上实施例已经被详细地描述了，但是一旦完全理解了以上公开，众多变型和修改将变得明显。接下来的权利要求意在被解释为包括所有这样的变型和修改。

Claims (20)

1.一种存储程序指令的非瞬时计算机可读存储介质，所述程序指令当在计算设备上被执行时使所述计算设备执行：

由在运行时环境内执行的运行时模块，在运行时，加载来自运行时可链接的多版本库中的类，所述多版本库被配置为包括类的多个版本，其中相应类的所有版本对应于用于所述相应类的相同的类签名；

其中所述加载包括：

确定所述多版本库是否包括所述类的与软件开发包的当前版本相关联的版本，所述软件开发包的当前版本用于实现能够在所述运行时环境的相应当前版本内执行的软件；以及

响应于确定所述多版本库包括所述类的与所述软件开发包的所述当前版本相关联的所述版本，从所述多版本库中加载所述类的与所述软件开发包的所述当前版本相关联的所述版本。

2.如权利要求1所述的非瞬时计算机可读存储介质，其中为了加载所述类的与所述软件开发包的所述当前版本相关联的所述版本，所述程序指令还使得所述计算设备执行：

从所述多版本库中与所述软件开发包的所述当前版本相关联的文件夹中加载所述类的所述版本，其中所述文件夹被配置为存储多个类的版本，每个版本与所述软件开发包的所述当前版本相关联。

3.如权利要求1所述的非瞬时计算机可读存储介质，其中所述程序指令还使得所述计算设备执行：

响应于确定所述多版本库不包括所述类的与所述软件开发包的所述当前版本相关联的所述版本：

确定所述多版本库是否包括所述类的与所述软件开发包的特定先前版本相关联的版本，其中所述软件开发包的所述特定先前版本按照软件开发包版本的已限定的顺序发生在所述软件开发包的所述当前版本之前；以及

响应于确定所述多版本库包括所述类的与所述软件开发包的所述特定先前版本相关联的所述版本，从所述多版本库中加载所述类的与所述软件开发包的特定先前版本相关联的所述版本。

4.如权利要求3所述的非瞬时计算机可读存储介质，所述程序指令还使得所述计算设备执行：

响应于确定所述多版本库不包括所述类的与所述软件开发包的特定先前版本相关联的所述版本，从所述多版本库中加载所述类的基础版本，其中所述类的所述基础版本不与所述软件开发包的任何特定版本相关联。

5.如权利要求3所述的非瞬时计算机可读存储介质，其中为了从所述多版本库中加载所述类的与所述软件开发包的特定先前版本相关联的所述版本，所述程序指令还使得所述计算设备执行：

从所述多版本库中与所述软件开发包的所述特定先前版本相关联的文件夹中加载所述类的与所述软件开发包的所述特定先前版本相关联的所述版本，其中所述文件夹被配置为存储多个类的版本，每个版本与所述软件开发包的所述特定先前版本相关联。

6.如权利要求1所述的非瞬时计算机可读存储介质，其中所述确定所述多版本库是否包括所述类的与软件开发包的当前版本相关联的版本是在没有考虑所述多版本库中所述类的与所述软件开发的后续版本相关联的版本的存在的情况下执行的，其中所述软件开发包的所述后续版本按照软件开发包版本的已限定的顺序发生在所述软件开发包的所述当前版本之后。

7.如权利要求1所述的非瞬时计算机可读存储介质，其中所述多版本库是用Java编程语言实现的多版本Java归档。

8.一种计算设备，包括：

处理器；以及

存储器，所述存储器耦接到所述处理器，其中所述存储器包括程序指令，所述程序指令当被所述处理器执行时使得所述处理器执行：

执行运行时环境内的类加载；

由所述类加载器在运行时从运行时可链接的多版本库中加载类，所述多版本库被配置为包括类的多个版本，其中，相应类的所有版本对应于用于所述相应类的相同的类签名；

其中所述加载包括：

确定所述多版本库是否包括所述类的与软件开发包的当前版本相关联的版本，所述软件开发包的当前版本用于实现能够在所述运行时环境的相应当前版本内执行的软件，其中所述类加载器在所述运行时环境内执行；以及

响应于确定所述多版本库包括所述类的与所述软件开发包的所述当前版本相关联的所述版本，从所述多版本库中加载所述类的与所述软件开发包的所述当前版本相关联的所述版本。

9.如权利要求8所述的计算设备，其中为了加载所述类的与所述软件开发包的所述当前版本相关联的所述版本，所述程序指令还使得所述计算设备执行：

从所述多版本库中与所述软件开发包的所述当前版本相关联的文件夹中加载所述类的所述版本，其中所述文件夹被配置为存储多个类的版本，每个版本与所述软件开发包的所述当前版本相关联。

10.如权利要求8所述的计算设备，其中所述程序指令还使得所述处理器执行：

响应于确定所述多版本库不包括所述类的与所述软件开发包的所述当前版本相关联的所述版本：

确定所述多版本库是否包括所述类的与所述软件开发包的特定先前版本相关联的版本，其中所述软件开发包的所述特定先前版本按照用于软件开发包版本的顺序发生在所述软件开发包的所述当前版本之前；以及

响应于确定所述多版本库包括所述类的与所述软件开发包的所述特定先前版本相关联的所述版本，从所述多版本库中加载所述类的与所述软件开发包的所述特定先前版本先关联的所述版本。

11.如权利要求10所述的计算设备，所述程序指令还使得所述处理器执行：

响应于确定所述多版本库不包括所述类的与所述软件开发包的所述特定先前版本先关联的所述版本，从所述多版本库中加载所述类的基础版本，其中所述基础版本不与所述软件开发包的任何特定版本相关联。

12.如权利要求10所述的计算设备，其中为了从所述多版本库中加载所述类的与所述软件开发包的所述特定先前版本先关联的所述版本，所述程序指令还使得所述处理器执行：

从所述多版本库中与所述软件开发包的所述特定先前版本相关联的文件夹中加载所述类的与所述软件开发包的所述特定先前版本先关联的所述版本，其中所述文件夹被配置为存储多个类的版本，每个版本与所述软件开发包的所述特定先前版本相关联。

13.如权利要求8所述的计算设备，

其中，与按照软件开发包版本的已限定的顺序的所述软件开发包的最新版本相比，所述运行时环境的相应当前版本与所述软件开发包的较早版本相关联；

其中，所述多版本库包括类的与所述软件开发包的所述最新版本相关联的或多个版本；以及

其中所述确定所述多版本库是否包括所述类的与所述软件开发包的所述当前版本相关联的版本包括：确定所述多版本库是否包括所述类的与所述软件开发包的所述较早版本相关联的版本，而不确定所述多版本库是否包括所述类的与所述软件开发包的所述最新版本相关联的版本。

14.如权利要求8所述的计算设备，所述多版本库是用Java编程语言实现的多版本Java归档，而且其中所述从运行时可链接的多版本库中加载类包括由在所述计算设备上执行的类加载器从所述多版本Java归档中加载所述类。

15.一种计算机实现的方法，包括：

由包括硬件处理器的计算设备建立运行时可链接的多版本库，所述多版本库包括类的多个版本，其中所述多个版本全部对应于相同的类签名；其中所述建立包括：

在所述多版本库中存储所述类的所述多个版本中的基础版本，其中所述类的所述基础版本不对应于软件开发包的任何特定版本；以及

在所述多版本库中存储所述类的所述多个版本中的一个或多个其他版本，其中所述一个或多个其他版本中的每个版本对应于所述软件开发包的相应版本。

16.如权利要求15所述的计算机实现的方法，其中所述存储所述类的所述一个或多个其他版本包括在所述多版本库中存储元数据，所述元数据指示所述其他版本中的每一个对应于所述软件开发包的相应版本。

17.如权利要求15所述的计算机实现的方法，其中所述存储所述类的所述基础版本包括在所述多版本库的基础文件夹中存储所述类的所述基础版本，其中所述文件夹被配置为存储或多个类中的每类的相应基础版本，其中所述基础文件夹不对应于所述软件开发包的任何特定版本。

18.如权利要求15所述的计算机实现的方法，其中所述存储所述类的所述一个或多个其他版本包括在所述多版本库的相应文件夹中存储所述或多个其他版本中的每，其中每个相应文件夹与所述软件开发包的相应版本相关联。

19.如权利要求15所述的计算机实现的方法，其中所述多版本库是用Java编程语言实现的多版本Java归档；并且其中所述软件开发包是Java开发包。

20.如权利要求15所述的计算机实现的方法，其中所述多版本库是用以下的一种或者多种实现的动态链接的库：

C编程语言；

C++编程语言；或

Java编程语言。