CodeOutline / JClass / CClass在CodeModel中的作用是什么？ [英] What is the role of ClassOutline / JClass / CClass in CodeModel?

问题描述

我的问题是关于编写JAXB插件，特别是JAXB代码模型。

My question concerns writing JAXB plugins, in particular JAXB codemodel.

ClassOutline 的作用是什么（它是同伴 ）和 JClass （以及同伴）和 CClass （以及同伴）？当查看相应包中的类列表时，不清楚什么是鸡，什么是鸡蛋。

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 → JType


• CClassInfo＃getProperties（ ）→ CPropertyInfo #baseType → JType

• JClass#fields() → JFieldVar#type → JType
• CClassInfo#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等） 。）


• 写入物理代码（磁盘上的ex.Java文件）

• Parses the schema
• Creates the model of the schema (CClass, CPropertyInfo etc.)
• Creates the outline (ClassOutline, FieldOutline etc.)
• Renders the code model (JClass, JDefinedClass, JMethod etc.)
• Writes the physical code (ex.Java files on the disk)

让我们从最后两个开始。

Let's start with the last two.

我希望Java文件不需要解释。

Java files don't need explanation, I hope.

代码模型是也是一件相对简单的事情。它是一个可用于以编程方式构造Java代码的API。你可以只使用字符串连接，但它更容易出错。使用CodeModel，您几乎可以保证获得至少语法正确的Java代码。所以我希望这一部分也很清楚。 （顺便说一下，我非常喜欢CodeModel。我最近根据想法写了 JavaScript代码模型来自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和模式的逻辑建模构造。因此，它只描述了它们具有的类型和属性。我描述它的方式肯定要复杂得多，有各种各样的例外和警告 - 从wilcard类型（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 等接口 - 它们都是编译时实现的（ CClassInfo 和XJC中的 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 。此模型无法生成代码。实际上，有不同的生成代码的策略。您可以生成带注释的类，也可以像在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 s生成 JDefinedClass es 。

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. :)

这篇关于CodeOutline / JClass / CClass在CodeModel中的作用是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！