Java字节码重构：实现组件兼容性的类型验证

{|}理论计算机科学电子笔记264（4）（2011）3-18www.elsevier.com/locate/entcs从Java字节码重构类型信息以实现组件兼容性1Jaroslav Bauml，Premek Bradajbauml kiv.zcu.cz西波希米亚Universzitni 8，30614，比尔森，捷克摘要Java类型系统由JVM的编译器和运行时字节码解释器严格检查。这些机制共同保证了类实例的正确使用。然而，使用现代组件系统可以绕过这些静态检查，因为在组件安装或更新期间，类的不兼容版本可以绑定在一起。 这种有问题的绑定会导致ClassCastException或NoSuchMethodException运行时错误。 在本文中，我们描述了一种表示的Java语言类型适合检查组件的兼容性。所提出的方法适用于各种字节码处理技术，以重建一个组件实现中包含的Java类型的表示，使用不同的类数据源。然后在构建和运行时使用该表示类型系统验证的目的是防止这类错误。我们已经成功地应用了这种方法来防止OSGi组件不兼容。关键词：类型重构，反射，字节码分析，子类型，组件兼容性1引言静态类型语言具有明显的优势，因此在大多数软件系统中使用。正如Erik Allen在[1]中清楚描述的那样，静态类型检查通过早期错误检测提高了鲁棒性，通过在最佳时间进行所需的检查来提高编译器对类型一致性的早期检查确保了程序代码的类型安全，并保证了运行时使用的类型是兼容的。然而，这种明显的情况因组件系统而变得复杂。基于一致性的软件工程（CBSE）[20，4]最重要的贡献之一是将应用程序分解为更小的部分-组件。应用程序不是作为一个整体块构建和部署的，而是由1这项工作得到了捷克共和国赠款机构201/08/0266号赠款的支持1571-0661 © 2011由Elsevier B. V.出版，CC BY-NC-ND许可下开放获取。doi：10.1016/j.entcs.2011.02.0024J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）封装其部分功能的组件，可能由独立的供应商开发每个组件都有自己的接口，该接口分为两侧- 所提供的和所需的功能集。通过这些功能，组件根据它们声明的依赖关系连接在一起如今，越来越多的基于Java的系统转向这种模块化或基于组件的架构，并得到OSGi、Netbeans插件或Android应用程序架构等系统的支持。在组件部署时，如果由提供组件导出的类型的结构在其演化过程中发生更改，则可能会发生由类型不匹配引起的问题客户端组件仍然会连接到这样的提供者（因为提供的-所需的特性对中的类型名称匹配），但提供的语言类型现在可能与客户端上的此（引用的）类型的概念不兼容。正如我们在[8]和[5]中所示，这种情况在独立组分进化的情况下是现实的。因此，我们提出了一种方法来决定组件兼容性的基础上的子类型比较的实际结构的引用类型和所描述的客户端的概念，该类型。这种运行时兼容性检查依赖于从组件二进制实现中完全重建类型描述在本文中，我们详细讨论了通过字节码分析和运行时内省来重构Java类型的替代方法。下面的第二部分将用现实生活中的例子深入探讨激励问题。组件依赖中使用的特性实际上取决于所使用的组件模型。由于我们主要使用OSGi组件模型，因此我们将在2.3小节中提供对OSGi的简短描述。在接下来的两个部分中将描述所提出的Java类型重构方法。第3节描述了我们的方法所采用的Java类型系统表示。其设计的通用性允许在其他项目中使用表示，以确保Java语言类型兼容性。第4节描述了决定组件兼容性的方法，该方法使用处理类型系统表示的算法。最后讨论了这些方法的优点。2组件软件在工业界和研究界，有各种各样的组件模型，它们在复杂性、抽象程度、技术成熟度和使用目的方面彼此不同。但是在这些不同的组件模型中，有一个隐含的需求是共享的2.1组件依赖项由于组件的生命周期，组件兼容性是一个至关重要的要求。如图1a所示，当使用标准单片软件时，J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）5在编译器检查其部分（比如类）是否类型兼容时，在构建时创建它们之间的副本。如果编译器发现问题，则不会创建结果代码;当语言类型（类和接口）兼容时，可以构建应用程序并将其部署到生产站点。当开发新版本的软件时，整个单片代码包再次被移动到生产现场进行应用程序升级。(a) 单片软件（b）组件软件图1.软件过程当使用组件软件开发技术时，情况大体相似，但在重要细节上不同。每个组件都有自己的接口，该接口由两个方面组成-提供的和需要的一个。提供的一面由功能（服务，包，事件，. . .），其由组件发布以便可用于组件周围环境。相反，被要求的一面声明了周围环境必须为组件提供的功能通过这些功能，组件被连接在一起，以特定组件模型描述的方式形成依赖关系2.2组件应用程序从图1b中可以看出，组件之间的依赖关系也首先由编译器在组件构建时进行检查。然而，与单片应用程序sce- nario不同的是，每个组件（包括第三方供应商开发的组件在基于组件的应用程序的后续更新期间，组件之间的连接在生产站点处用新版本中的组件重新建立。当新版本不兼容时，应用程序将因某种运行时异常而失败。失败的概率等于调用类型的概率（例如，类），表现出不兼容性。在目前使用的许多组件模型中，没有一种机制来描述组件接口的类型系统。来自供应商组件的提供部分的类型在客户端的源代码中使用，在客户端的实现中创建这些类型的隐式“概念”。客户机代码与提供者类型的绑定6J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）实现-其引用类型的概念基于编译期间使用的特定供应商类型的结构。在编译时，检查供应商导出的实际类型和此概念的一致性。然而，在部署阶段的组件（重新）布线操作期间缺少类似的机制。许多基于Java的组件系统都存在这个普遍问题。从现在开始，我们将在OSGi平台的案例研究中介绍它，OSGi平台非常简单和轻量级，并且越来越受欢迎。为了深入了解进一步处理的问题，需要对OSGi有基本的了解;如果您熟悉这个框架，可以跳过下一小节。2.3OSGi简介开放服务网关计划（Open Services Gateway Initiative，OSGi）平台[18]是一个开放的基于Java的服务部署和管理框架。它的应用范围从嵌入式应用到大规模桌面和企业系统。 OSGi的核心是框架，它创建了一个运行时环境，用于管理称为bundle的组件的部署和生命周期。作为框架分发的一部分，提供了一组由系统包实现的标准化基本服务。bundle可以导出（提供）或导入（需要）Java包和服务，声明使用的本地库，并指定对执行平台和具体bundle的依赖关系。标准的Java清单文件保存指定的Meta数据。包用于访问共享类型和bundle实现，并在bundle之间形成静态绑定。服务由Java接口表示，并允许使用中央框架注册表。默认情况下，服务绑定的责任在bundle实现上，这在处理运行时更改时带来了灵活性如果使用标准化的声明性服务模块，则可以将服务声明和绑定委托给框架。另一方面，包的依赖关系解析总是由框架核心处理，不需要程序员方面的工作2.4真正的Word问题示例在本节中，我们将描述组件兼容性问题的一个具体示例，展示用户如何受到此问题的影响。这是一组运行时故障的一个实例，需要几个小时才能跟踪到。因此，防止这种运行时异常的方法可以节省宝贵的开发时间。为了开发一个研究项目的前端，我们决定扩展Apache Felix Webconsole [2] bundle。这个Webconsole是一个可扩展的网页 为 管理 一 运行OSGi框架它嵌入了一个servlet容器，可以通过注册一个实现接口的服务来扩展该容器org.apache. fashion.webconsole.AbstractWebConsolePlugin.我们的插件包，称为subst-verifier，非常简单。它可以验证捆绑包的新版本是否与旧版本兼容它只有一个HTML表单J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）7图二.现实世界的兼容性问题输入文件。当文件上传到插件时，将执行验证当我们安装subst-verifier并尝试上传文件时，我们得到了如图2所示的错误消息。经过几个小时的问题搜索，我们发现以下问题是其原因：我们在1.2.10版本中使用了org.apache.fashion.webconsolebundle，它需要1.1版本的库commons-fileupload组件的元数据描述不处理此依赖关系，所以不容易观察。然而，我们的子验证器在1.2版中被编译为commons-fileupload由于这两个版本的广泛使用的库是不兼容的，在OSGi组件模型中没有进行兼容性检查，我们得到了一个严重的运行时崩溃的应用程序。3组件类型-级别表示为了比较两个组件并确定它们在运行时（当源文件不可访问时）的兼容性级别，我们需要一个合适的模型来表示这两个组件。我们在本节中描述的表示被设计为捕获组件的公共API上的类型的所有语法更改。它由两层组成（见图3）。对于整个组件的层，我们使用一个简单的OSGi元模型，称为BundleTypes。它表示包的导出和导入特征。第二层只描述组件声明和使用的Java类型由于所有OSGi bundle特性都是作为Java类实现的，或者由Java类组成，因此BundleType层的叶节点使用JavaTypes描述的Java类型表示。JavaTypes层可以独立于Bundle表示使用我们根据Java语言规范第三版[14]设计了这一层。 JavaTypes层非常类似于Java反射API [13]，但更通用，因为内容可以从其他来源获得，而不仅仅是反射。由于下面描述的原因，JavaTypes的独特功能是能够从组件字节码创建类型表示，或者可以通过操作创建不存在的类的表示Java语言类型系统和JVM解释字节码时使用的类型系统因为我们的方法8J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）图三. 构件表示重点是在Java编程元素上重构Java表示和推理，在本文的其余部分，我们将使用Java类型系统。JavaTypes的基本接口如图4所示。JType是Java中特定类型的父接口。这些特定类 型 是 ： JClass ， JTypeVariable ， JParametrizedType ， JWildCardType 和JGenericArrayType。 JClass表示Java语言的基本类型JType的其他子级表示泛型类型。在本文的其余部分，我们将调用JClass表示的类型作为基本类型，其他类型作为泛型类型。图四、JavaTypes表示的基本接口为 了 涵 盖 泛 型 类 型 ， JTypeVariable 表 示 类 或 接 口 定 义 中 的 类 型 变 量 ，JParametrizedType涵盖了定义中带有类型变量的实例的情况，JWildCardType表示带有类型- eg的类型实例。名单？> .最后，JGenericArrayType表示JType- Variable、JParametrizedType或JWildCardType的数组。(The关于泛型的情况实际上更复杂，因为存在它们的表示不可用的情况，例如通过从不包含泛型注释的字节码重构。Java中可用的语言特性的表示方法总结在图中五、JClasses聚合JMember（JFields、JMethods或JConstructors）。 对于所有这些元素，可以获得JModifier，表示它们的访问ModifierJ. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）9public、private、static等。所有可以附加注释的元素都必须实现可以返回JAnnotation对象的JAnnotable接口图五、核心JavaTypes表示层图3.1类型表示源创建组件接口引用的类型的表示是以类似于Java类加载过程的方式设计的。这些类型可以从几个来源获得。每个源都有其JTypeLoader对象，该对象负责读取位于给定源中的类型。当前实现的用于检索JavaTypes表示的源代码是：• 一个加载的程序• 已编译但未加载的文件• 程序化此外，每个JType加载器都有其父JTypeLoader。加载器的树组织以及每个加载器可以从不同的源在获取组件类型表示的过程中带来了可变性。例如，当在组件的字节码中找不到引用的类时，我们可以尝试通过父JType加载器找到它。这可以是一个反射加载器，它与指向类路径（类可用的地方）的类加载器合作创建类表示这些来源可以任意组合在一起。使用Java反射检索表示非常简单，因为JavaTypes和反射API之间有意的相似性。事实上，用于反射的JavaTypes实现是一个在反射API上实现的装饰器设计模式创建JavaType10J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）当从字节码创建表示时，我们使用ASM和BCEL字节码分析框架。ASM [3]提供了访问者模式方法来访问类数据的所有部分。我们已经为特定的JavaTypes类实现了访问器。BCEL [6]的使用是出于历史原因（比ASM更早引入项目）。下面的示例说明如何从字节码创建类表示形式。让我们有一个带有一个方法的Example类公共c l a s s示例{公共虚空打电话给我（i n t我，字符串个）{. . . 个文件夹}方法的字节码方法描述符是：（ILjava / lang / S tr i n g ;）V这个字节码数据由ASM读入我们的JMethodVisitor实现在JTypeLoader中当调用时，访问者创建一个JMethod实例，类型加载器将该实例添加到JClass对象中，该JClass对象在前面以类似的方式创建JavaType的自定义创建在三种情况下很有用。 最简单的一个是测试目的，当我们需要创建人工类型来对表示进行测试时。我们的第二个用例是不存在类型- 这将在下面详细描述。最后，我们可以使用自定义创建的原则，ciple的目的。Stubbing是一种获取我们不能或不想加载的类的替换的技术。这样一个类被一个叫做stub的伪类所取代。在自定义JType加载器中创建存根JClass对象是由一个类名掩码参数化的，该掩码定义存根类的集合（例如，java.lang. *核心Java类）。在通过反射加载的情况下，将为系统类路径上可用的所有类可替代性当组件中没有可用的类时，也会创建存根，我们可以安全地假设它的源代码没有被组件更新更改（即，组件的旧版本和新版本将引用相同的类代码）3.2获得完整的束类型表示为了能够比较bundles，我们必须创建这些bundles的表示。这分三个步骤进行。第一步是读取bundle元数据信息，在第二步和第三步中，我们遵循来自此元数据的指针，并转到bundle实现以获得Java层表示。3.2.1组件元数据Bundle manifest文件作为第一个联系点，在那里可以找到包的名称和其他功能Bundle层表示是根据此信息构建的J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）11mation。这一步很简单，因为它意味着解析一个规范的文本文件（见下面的例子）。捆绑包-名称：日志服务捆绑包-版本：2.3.2Export-Package：cz . zcu。l logging; version =”1 . 3 .第三章。0“导入-Package：org .奥斯吉岛框架接下来的步骤更有趣，因为JavaType表示必须从bundle jar文件中保存的字节码加载3.2.2元件的导出侧组件的所有导出功能的类必须自然包含在内在组件包本身。因此，我们可以直接从相应类型的字节码构造它们的类型重构从束级别开始。对于每个导出的包和服务，我们创建相应的JPackage或JService对象。然后，需要填充其JClass内容。对于只引用一个类（服务接口）的服务案例来说，这种情况是微不足道的对于包，所有包含的类的列表首先通过查询类加载器获得，然后通过使用接收类型加载器创建JClass来接下来，我们必须创建这些类的公共方法或字段引用的所有类型的表示，这个过程是通过将JClass从导出的包和服务添加到knownTypesList队列来引导的。然后开始一个迭代算法来创建接口类型的整个传递闭包。knownTypesList中所有未处理的类型都被连续处理。对于knownType- sList中的每个类型T，检索其成员引用的JType。对于这些引用类型中的每个类型R，以下可能性之一为真：• R包含在组件中，而不是在knownTypesList中-• R包含在组件中，并且已经在knownTypesList中• R不在组件内部，其命名空间列在一个导入包header• R不在组件内部，其命名空间也不在导入包中标题当类型T的所有引用类型都被处理时，T被标记为展开，并且knownTypesList中的下一个类型使用相同的算法处理。异常状态通过抛出适当的异常来处理，以指示分析的bundle无效（在代码中引用一个类型而没有相应的导入包声明意味着bundle无论如何都不会被OSGi框架解析和启动）。因为在类型依赖中存在递归的危险，所以算法必须包括递归检测工具。为此目的，12J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）图第六章导出的包结构，该结构保存当前展开类型的分支序列。在它的底部，有一个直接从导出包组件头引用的JClass。堆栈包含从当前处理的节点到此根的路径。当找到新的引用类型时，将检查堆栈是否包含此类型。如果找到，则检测到递归，类型不会展开，但引用指向堆栈实例。这样，所有JType的整个树就展开了。创建树是因为每个JClass可以引用另一个JClass作为其字段、方法参数或方法返回类型。这个树的叶子节点有以下三种：• 原始类型。在这种简单的情况下，不需要创建子JClass。• 存根类。这意味着该类型包含在另一个包或库中，并且在其位置创建了一个空的存根类• 对递归定义类型的引用。在这种情况下，这个节点不是一个叶子，但是类型的扩展结束了。3.2.3元件的导入侧组件的导入端的情况更加棘手。对于导出端的特性，其类型的具体字节码在组件包中可用，而导入端的情况正好相反。这是应用程序功能的基于组件的分解的明显结果，如第2节所讨论的。我们的解决方案是使用下面的方法来重建导入端。由组件C导入的每个语言类型a（它的功能确实需要）至少被C实现中的一个类型r使用编译器在r的字节码中留下a的印记，包含类的类型签名以及r使用的成员（字段和方法）。当我们在CJ. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）13见图7。 导入的包这个想法可以用来创建导入的包和服务的表示，因为它们是类型的复合。原理如图7所示。在本例中，组件C是导入包com.inv的cz.zcu.translator 这个包包含一个被引用的类com.inv.T，它由组件C中的两种类型（Translator和Dict）使用。从组件的实现重构的类型T的结构由从图中所示的代码片段推导出的两个方法组成。符号any表示任何对象类型、原始类型或void;它充当所有类型的超类型（字节码中的调用约定不包含足够的信息来重建操作签名的精确返回类型）。使用这种字节码分析技术，可以创建与导出包类似的结构但是，表示的根类是通过上一节中描述的自定义创建（创建）来在某些情况下，可以使用另一种方法来重构导入的类型。当bundle的导入包的字节码他们的.jar文件），我们可以从其“类路径”重建表示。 例如，当bundle导入包cz.zcu.example我们将把这个包中的所有类都包含在bundle的导入端的表示中。在下面的第4节中，我们展示了可用“类路径”的假设获取导入类型表示的第一种方法更加费力，但完全符合组件的实际需求。因此，它实际上提供了比通过分析导入的包本身（第二种方法）创建的表示更精确的信息这一优势被一位作者早先提出的上下文兼容性评估[7]所利用。4组件相容性测定我们提出的组件兼容性判定方法是基于评估两个组件之间的子类型关系。简单地说，如果类型A可以在另一个类型的所有可能的上下文中使用，那么A是另一个类型的子类型14J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）在本节中，我们将描述基于组件类型的比较算法。由于本文的重点是类型表示重构，因此只通过一个例子来说明主要原理。我们首先描述一个用于比较类型结构的函数，然后展示这种方法的一些典型用例。4.1组件类型显示器比较两种类型a和b的结果可以用它们之间的变化特征来描述。让我们定义函数Di（a，b）：Type×Type→Di，它计算类型a和b之间的差异。返回的值是以下值之一：• 无：a和b之间无变化。• Specification：Specialization• Gen：泛化• Mut：Mutation见图8。 子类型化示例用于结构化类型的Di（）函数的值是通过组合其组成部分的差异。Di logging（）值确定的精确算法在[5]中发布，并在图8中解释，其中包cz. zcu.logging有两个版本。在第二个版本中，接口Logger中的一个方法（voidsetSize（int））被删除，同时添加了另一个接口LogService的一个方法（void flushAllLoggers（））。 Logger是通用的，而LogService是专用的。 这两个变化在同一个包是contravariant，因此产生的差异是一个突变的类型。4.2差异与兼容性当我们检索Di_n（a，b）函数的值时，我们可以使用它来决定a到b的兼容性。下表（1）显示了规则：J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）15Di（a，b）没有一专业化泛化突变A型与B型是的没有是的没有类型b与a是的是的没有没有表1差异值到兼容性4.3方法的使用案例上面描述的方法是通用的-它在本节中，我们提供了现在使用该方法自动化版本控制正如前面的工作[5]中详细描述的那样，bundle比较方法可以用于组件的自动化版本控制。此过程可以简化为组件及其功能分配版本标识符的易错任务。上面描述的类型标识符可以用作描述组件接口的真实演化的版本标识符的自动创建的输入。例如，在OSGi的情况下，版本编号方案由规则控制当在组件系统中使用这种自动化版本控制时，其管理员可以依赖于版本标识符的可靠性。这个用例在捆绑包发布时应用该方法，此时比较通过对最后两个组件修订版的字节码检查获得的捆绑包类型表示。比较中的第一个捆绑包是最后一个先前发布的具有版本标识符的组件。第二个bundle是下一个候选版本，我们希望确定其版本标识符。通过这种方法，发布的捆绑包携带版本标识符，不仅描述软件本身，还描述它所经历的更改安全更新该方法的另一个用例适用于组件的部署时间。在这种情况下，我们可以使用子类型比较来确保bundle的新版本与前一个版本兼容，而不管分配给两者的版本号如何（采取保守的立场，即它们的可靠性很低，并且需要一种健壮的方法来确保应用程序类型的一致性）。可替代地，该方法可以类似地应用于将新版本与其部署的实际上下文进行在这个用例中，该方法在组件部署时应用。旧的包版本的表示是从反射中获得的，包括导入端（解析到现有的包导出器）。通过字节码分析获得新捆绑包版本16J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）当使用安全更新程序作为更新工具时，我们可以防止第2.4节中的介绍性示例中的情况。安全更新程序递归地搜索提供者和导入者的接口，并验证合约双方引用的类型递归应用的子类型规则保证了这些错误的排除。在这个具体的用例中，我们防止了几乎与JVM链接和验证过程中相同的错误集。与之相反，我们可以按需执行这些检查，而无需将字节码加载到JVM。使用检查我们提到的最后一个应用程序场景是使用额外的子类型检查解析组件的过程。解析，类似于编译过程的链接阶段，用于将导入的包绑定到相应的导出器。这些绑定只在匹配导入和导出的名称上进行附加检查确保组件系统中的所有相互组件接口彼此兼容。在这里，我们的方法在组件安装或更新后的组件框架启动时应用。通过反射加载两个比较接口侧5相关工作在研究和工业界，字节码分析和操作技术都很常见。ASM库[11]可用于修改现有类或动态生成类，它专注于使用和性能的简单性。其他具有类似功能的框架是JMangler [15]或JavaAssist [10]。类由包含给定类的所有符号信息的对象表示：特别是方法，字段和字节码指令这种方法的效率低于ASM访问者设计模式，因此ASM是动态系统的最佳选择。一类独特的框架使用XML进行字节码表示和管理[17，19]。它们在功能上与上述方法相当，并支持包括交叉编译在内的高级操作后一项工作讨论了转换或包装嵌入在字节码中的API调用的需求与JavaTypes不同的是，这些方法都没有处理重构在分析的字节码中找不到的引用类型的问题，这是CBSE上下文中的关键需求。JavaTypes的另一个优点是能够通过子类型规则来组合重构的类型。另一方面，JavaTypes并不打算用于字节码操作，而是有意地只支持Java语言特性的有限子集。关于组件兼容性的评估，有两种通用方法。动态评估通过运行回归测试套件来确定兼容性[12]。与我们的方法更密切相关的是，McCamant等人[16]根据观察到的（未声明的）行为定义兼容性，而Chaki等人[9]验证了全局正确性属性通过组件更新得到保留，应用-J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）17对构件源代码的抽象进行模型检测。这些方法肯定比基于类型重构的兼容性更精确在我们的工作中。另一方面，获得组件所需的行为表示要困难得多。我们的方法可以用作昂贵的模型检查之前进行的第一次检查。6结论执行基于类型的兼容性检查的能力对于增强组件应用程序的本文描述了构成组件接口的Java语言类型的一种我们的系统允许在这些方法中使用一组混合的源，包括使用ASM工具的Refraction API和字节码分析其中的主要挑战，我们的方法地址是（i）需要涵盖组件开发生命周期的各个阶段-构建，部署，以及运行时检查;（ii）有限的访问组件的接口类型引用的一些类;（iii）忠实的重建类型的进口（所需）功能从一个独立的组件包。提出的关键贡献是从组件的字节码实现引用的部分本文所描述的方法已成功地用于处理组件表示和兼容性的几个应用程序。它们为自动化组件版本控制以及为流行的OSGi框架实现的类型安全更新机制奠定了基础引用[1] Allen，E.，诊断Java代码：静态类型的案例（2002）。URLhttp://www.ibm.com/developerworks/java/library/j-diag0625.html[2] Apache fashion web console.URLhttp://felix.apache.org/site/apache-felix-web-console.html[3] Asm网站。网址http://asm.ow2.org/[4] Bachmann，F.例如，第二卷：基于构件的软件工程的技术概念，技术报告CMU/SEI-2000-TR-008，软件工程研究所，卡内基梅隆大学（2000年）。[5] Bauml，J.和P. Brada，OSGi中的自动化版本控制：组件软件一致性保证机制，在：欧洲微电子SEAA（2009年）。[6] Bcel网站。URLhttp://jakarta.apache.org/bcel/[7] Brada，P.，“基于规范的组件可替代性和版本识别”，博士布拉格查尔斯大学论文（2003年）。[8] Brada，P.，增强OSGi bundle更新以防止运行时异常，见：第34届Euromicro SEAA会议论文集（2008）。[9] Chaki，S.，E. Clarke，N. Sharygina和N. Sinha，Veri fication of evolving software via componentsubstitutability analysis，Formal Methods in System Design32（2008）。18J. Bauml，P.Brada/Electronic Notes in Theoretical Computer Science 264（4）（2011）[10] Chiba ， S. 和 M.Nishizawa ， An easy-to-use toolkit for e-quient java bytecode translators ， in ：Proceedings of the 2nd international conference on Generative programming and componentengineering，Springer-Verlag，New York，NY，USA，2003，pp.364-376.[11] 布鲁顿河Lenglet和T. Coupaye，Asm：一种实现自适应系统的代码操作工具，见：自适应和可扩展组件系统，法国格勒诺布尔，2002年。[12] Flores，A.和M. Polo，基于测试的组件可替换性评估过程，载于：第三届复杂架构设计观点国际研讨会论文集（VODCA 2008），2009年，pp.101236.[13] 福尔曼岛R.，N. Forman，D.J. 诉伊姆岛R. Forman和N.Forman，Java recruitment in action（2004）.[14] James Gosling，G.美国，Bill Joy和G. Bracha，Java语言规范，第三版（2005）。[15] G.J.， Costanza和M. Austermann ，Jmangler-Java类文件 ，在 ：IEEE源代码 分析和操 作国际研讨 会（2001年）。[16] McCamant ， S. 和 M.D.Ernst ， Formalizinglightweightverificationofsoftwarecomponentcomposition ， in ： Proceedings of SAVCBS 2004 ： Specification and Verification of convenent-basedSystems，Newport Beach，CA，USA，2004，pp.47比54[17] NoUnit Team，NoUnit（2006），accessed 12/2009.URLhttp://nounit.sourceforge.net/[18] OSGi联盟，www.osgi.org/。[19] Puder，A.和J.Lee，Towards an XML based bytecode level transformation framework，in：E. Albert和S. Genaim，编辑，第四届字节码语义、验证、分析和转换国际研讨会预录，约克，英国，2009年。[20] Szyperski，C.，