问题描述
我的问题是关于编写 JAXB 插件，特别是 JAXB 代码模型.
My question concerns writing JAXB plugins, in particular JAXB codemodel.
ClassOutline 的作用是什么(它是 companions) 和 JClass(和 companions) 和 CClass(和 companions)?查看相应包中的类列表时，不清楚什么是鸡，什么是蛋.
What is the role of ClassOutline (and it's companions) and JClass (and companions) and CClass (and companions)? When looking at the list of classes in corresponding packages it is not clear what is chicken and what is egg.
我的解释是 CClass (CPropertyInfo, CEnumConstant, ...) 是 XJC 在解析 XSD 的初稿时创建的.然后一些神奇的事情发生了，这个模型被转换成 JClass (JFieldVar, JEnumConstant, ...) 并在这个转换过程中应用自定义.然后调用插件.ClassOutline 被用作这两个模型之间的桥梁.整体看起来很复杂.
My interpretation is that CClass (CPropertyInfo, CEnumConstant, ...) are created by XJC at first draft parsing of XSD. Then some magic happens and this model is transformed into JClass (JFieldVar, JEnumConstant, ...) and during this transformation customizations are applied. Afterwards plugins are invoked. ClassOutline is used as a bridge between these two models. Altogether looks very complicated.
通过这些并行模型，我相信可以通过多种方式获得相同的信息.例如，类字段类型:
With these parallel models I believe that the same information can be derived in several ways. For example, class field type:
JClass#fields()→JFieldVar#type→JTypeCClassInfo#getProperties()→CPropertyInfo#baseType→JType
JClass#fields()→JFieldVar#type→JTypeCClassInfo#getProperties()→CPropertyInfo#baseType→JType
我正在寻找上述模型生命周期的详细解释.谢谢.
I am looking for verbose explanation of the lifecycle of above mentioned models. Thanks.
推荐答案
哦，哦，有人对 XJC 内部结构感兴趣.我可能会有所帮助，因为我开发的 JAXB 插件可能比其他任何人都多(请参阅 JAXB2 基础知识 例如)
Oh, oh, someone is interested in XJC internals. I might be of some help since I've probably developed more JAXB plugins than anyone else (see JAXB2 Basics for instance)
好的，让我们开始吧.在 XJC 中，模式编译器大致如下
Ok, let's start. In XJC the schema compiler does approximately following
- 解析架构
- 创建架构模型(CClass、CPropertyInfo 等)
- 创建大纲(ClassOutline、FieldOutline 等)
- 呈现代码模型(JClass、JDefinedClass、JMethod 等)
- 写入物理代码(例如磁盘上的 Java 文件)
让我们从最后两个开始.
Let's start with the last two.
Java 文件不需要解释，我希望.
Java files don't need explanation, I hope.
代码模型也是相对容易的事情.它是一个 API，可用于以编程方式构建 Java 代码.您可以只使用字符串连接，但它更容易出错.使用 CodeModel，您几乎可以保证至少获得语法正确的 Java 代码.所以我希望这部分也很清楚.(顺便说一句，我非常喜欢 CodeModel.我最近根据想法写了JavaScript Code Model来自 CodeModel.)
Code model is also a relativesly easy thing. It is an API which can be used to construct Java code programmatically. You could just use string concatination instead, but it's much more error-prone. With CodeModel you're almost guaranteed to get at least grammatically correct Java code. So I hope this part is also clear. (By the way, I like CodeModel very much. I recently wrote JavaScript Code Model based on ideas from the CodeModel.)
现在让我们看看模型"和轮廓".模型是解析传入模式的结果.它对传入模式的构造进行建模，主要根据对应于复杂类型的类"和对应于元素、属性和值的属性"(例如，当您拥有具有简单内容的复杂类型时).
Let's now look at the "model" and the "outline".Model is the result of parsing the incoming schema. It models the constructs of the incoming schema, mainly in terms of "classes" which corresponds to complex types and "properties" which corresponds to elements, attributes and values (ex. when you have a complex type with simple content).
应该将模型理解为接近 XML 和模式的逻辑建模构造.因此，它只描述了它们具有的类型和属性.它肯定比我描述的要复杂得多，有各种各样的例外和警告——从通配符类型 (xsd:any)、替换组、枚举、内置类型等开始.
The model should be understand as a logical modelling construct close to XML and schema. As such, it just describes types and properties that they have. It's surely much more complex that how I'm describing it, there's all sorts of exceptions and caveats - starting from wilcard types (xsd:any), substitution groups, enums, built-in types and so on.
非常有趣的是，Model 的兄弟是 RuntimeTypeInfoSetImpl，JAXB 在运行时使用它.所以它也是一种模型 - 然而它不是从 XML Schema 解析的，而是从类中的 JAXB 注释解析的.这个概念是一样的.Model 和 RuntimeTypeInfoSetImpl 都实现了 TypeInfoSet 接口，它是一个超级结构.检查像 ClassInfo 和 PropertyInfo 这样的接口 - 它们在编译时都有实现(XJC 中的 CClassInfo 和 CPropertyInfo)和运行时(RuntimeClassInfoImpl 等，用于 JAXB RI).
Quite interestingly, a sibling of Model is RuntimeTypeInfoSetImpl which is used by JAXB in the runtime. So it's also a type of model - which is however not parsed from the XML Schema but rather from JAXB annotations in classes. The concept is the same. Both Model and RuntimeTypeInfoSetImpl implement the TypeInfoSet interface which is a super-construct. Check interfaces like ClassInfo and PropertyInfo - they have implementation both for compile-time (CClassInfo and CPropertyInfo in XJC) and run-time (RuntimeClassInfoImpl etc. for JAXB RI).
好的，所以当 XJC 解析和分析模式时，您已经获得了 Model.这个 Model 还不能生成代码.实际上，生成代码有不同的策略.您可以只生成带注释的类，也可以像 JAXB 1 一样生成接口/实现类对.整个代码生成实际上并不是模型的任务.此外，有许多方面与 Java 代码的物理性质相关，但与模型并不真正相关.例如，您必须将类分组到包中.这是由 Java 的打包系统驱动的，而不是由模型本身的属性驱动的.
Ok, so when XJC parsed and analysed the schema, you've got the Model. This Model can't produce the code yet. There are, indeed, different strategies of producing the code. You can generate just annotated classes or you can generate interface/implementing class pair like in JAXB 1. The whole code generation thing isn't actually the task of the model. Moreover, there is a number of aspects that are relevant to the physical nature of the Java code, but aren't really relevant for the model. For instance, you have to group classes into packages. This is driven by the packing system of Java, not by the properties of the model itself.
这就是大纲发挥作用的地方.您可以将轮廓视为模式模型和代码模型之间的步骤.您可以将大纲视为负责组织代码和从 CClassInfo 生成 JDefinedClass 的代码模型元素的工厂.
And this is where outlines come into play. You can see outlines as step between the schema model and the code model. You can view outlines as factories for code model elements responsible for organization of the code and generation of JDefinedClasses from CClassInfos.
所以你是对的，它确实非常复杂.我不是 Sun/Oracle 的员工，我没有设计它(我认识设计它的人，但非常尊重他).我可以猜测某些设计决策的几个原因，例如:
So you're right, it is indeed very complicated. I am not a Sun/Oracle employee, I did not design it (I know the person who did it, though and respect him very much).I can guess a couple of reasons for certain design decisions, for instance:
- 对编译时和运行时模型使用相同的接口
- 允许不同的代码生成策略
- 允许插件操作创建的模型
我同意这个设计非常复杂，但它有它的原因.一个证明是，实际上可以为 XML 到 JavaScript 的映射构建一个映射生成器——基本上是在相同的模型上.我只需要替换代码生成，让模式分析保持完整.(请参阅 Jsonix.)
I agree that this design is very complicated, but it has its reasons. One proof for that is that it was actually possible to build a mapping generator for XML-to-JavaScript mappings - basically on the same models. I just had to replace the code generation leaving schema analysis intact. (See Jsonix for that.)
好的，希望我能解释为什么 XJC 中的事情是这样的.祝这些 API 好运，它们并不直接.随意检查现有的开源代码，有很多示例可用.
Ok, hopefully I shed some light on why things in XJC are how they are. Good luck with these APIs, they're not straghtforward. Feel free to check existing open-source code, there's a lot of examples available.
ps.一直很想写这个.:)
ps. Really always wanted to write this. :)
这篇关于ClassOutline/JClass/CClass 在 CodeModel 中的作用是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！