CodeModel中ClassOutline/JClass/CClass的作用是什么? [英] What is the role of ClassOutline / JClass / CClass in CodeModel?
问题描述
我的问题是关于编写 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 Basics 例如)
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)和运行时(JAXB RI 的 RuntimeClassInfoImpl 等).
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.
这就是轮廓发挥作用的地方.您可以将大纲视为模式模型和代码模型之间的步骤.您可以将大纲视为代码模型元素的工厂，这些元素负责组织代码并从 CClassInfos 生成 JDefinedClasses.
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. :)
这篇关于CodeModel中ClassOutline/JClass/CClass的作用是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
