Какова роль ClassOutline / JClass / CClass в CodeModel? - PullRequest
8 голосов
/ 12 февраля 2012

Мой вопрос касается написания плагинов JAXB, в частности кодовой модели JAXB.

Какова роль ClassOutline (и это спутников ) и JClass спутников ) и CClass спутников ) ? При просмотре списка классов в соответствующих пакетах не ясно, что такое курица, а что яйцо.

Моя интерпретация заключается в том, что CClass (CPropertyInfo, CEnumConstant, ...) создаются XJC при первом черновом разборе XSD. Затем происходит какое-то волшебство, и эта модель преобразуется в JClass (JFieldVar, JEnumConstant, ...), и во время этого преобразования применяются настройки. После этого плагины запускаются. ClassOutline используется как мост между этими двумя моделями. В целом выглядит очень сложно.

С этими параллельными моделями я считаю, что одну и ту же информацию можно получить несколькими способами. Например, тип поля класса:

  • JClass#fields()JFieldVar#typeJType
  • CClassInfo#getProperties()CPropertyInfo#baseTypeJType

Я ищу подробное объяснение жизненного цикла вышеупомянутых моделей. Спасибо.

Ответы [ 2 ]

18 голосов
/ 23 февраля 2012

О, о, кто-то интересуется внутренностями XJC. Я мог бы быть чем-то полезен, поскольку, вероятно, я разработал больше плагинов JAXB, чем кто-либо другой (см., Например, Основы JAXB2 )

Хорошо, начнем. В XJC компилятор схемы делает примерно следующее

  • Разбирает схему
  • Создает модель схемы (CClass, CPropertyInfo и т. Д.)
  • Создает схему (ClassOutline, FieldOutline и т. Д.)
  • Визуализация модели кода (JClass, JDefinedClass, JMethod и т. Д.)
  • Записывает физический код (например, файлы Java на диске)

Давайте начнем с последних двух.

Java-файлы не нуждаются в объяснении, я надеюсь.

Кодовая модель также очень проста для родственников. Это API, который можно использовать для программного создания кода Java. Вместо этого вы можете использовать конкатенацию строк, но она более подвержена ошибкам. С CodeModel вы почти гарантированно получите хотя бы грамматически правильный Java-код. Поэтому я надеюсь, что эта часть также ясна. (Кстати, мне очень нравится CodeModel. Недавно я написал Модель кода JavaScript на основе идей из CodeModel.)

Давайте теперь посмотрим на «модель» и «контур». Модель является результатом анализа входящей схемы. Он моделирует конструкции входящей схемы, в основном в терминах «классов», которые соответствуют сложным типам, и «свойств», которые соответствуют элементам, атрибутам и значениям (например, когда у вас есть сложный тип с простым содержимым).

Под моделью следует понимать логическую конструкцию, близкую к XML и схеме. Как таковой, он просто описывает типы и свойства, которые они имеют. Это, конечно, намного сложнее, чем то, как я описываю это, есть всевозможные исключения и предостережения - начиная с типов карты (xsd: any), групп подстановок, перечислений, встроенных типов и т. Д.

Довольно интересно, что у брата Model есть RuntimeTypeInfoSetImpl, который используется JAXB во время выполнения. Так что это также тип модели, который, однако, анализируется не по схеме XML, а по аннотациям JAXB в классах. Концепция такая же. И Модель, и RuntimeTypeInfoSetImpl реализуют интерфейс TypeInfoSet, который является суперконструкцией. Проверьте интерфейсы, такие как ClassInfo и PropertyInfo - они имеют реализацию как для времени компиляции (CClassInfo и CPropertyInfo в XJC), так и для времени выполнения (RuntimeClassInfoImpl и т. Д. Для JAXB RI).

Хорошо, поэтому, когда XJC проанализировал и проанализировал схему, вы получили Model. Этот Model пока не может создать код. Есть действительно разные стратегии создания кода. Вы можете сгенерировать только аннотированные классы или вы можете сгенерировать пару классов интерфейс / реализация, как в JAXB 1. На самом деле генерация кода не является задачей модели. Более того, существует ряд аспектов, которые имеют отношение к физической природе кода Java, но не имеют отношения к модели. Например, вы должны сгруппировать классы в пакеты. Это обусловлено системой упаковки Java, а не свойствами самой модели.

И именно здесь в игру вступают контуры. Вы можете видеть контуры как шаг между моделью схемы и моделью кода. Вы можете просмотреть схемы как фабрики для элементов модели кода, отвечающие за организацию кода и генерацию JDefinedClass es из CClassInfo s.

Итак, вы правы, это действительно очень сложно. Я не сотрудник Sun / Oracle, я не проектировал это (я знаю человека, который сделал это, хотя и уважаю его очень). Я могу предположить несколько причин для определенных дизайнерских решений, например:

  • Используйте одни и те же интерфейсы для моделей времени компиляции и исполнения
  • Разрешить разные стратегии генерации кода
  • Разрешить плагинам манипулировать созданной моделью

Я согласен, что этот дизайн очень сложный, но у него есть свои причины. Одним из доказательств этого является то, что на самом деле можно было создать генератор сопоставлений для сопоставлений XML-JavaScript - в основном на тех же моделях. Мне просто пришлось заменить генерацию кода, оставив нетронутым анализ схемы. (См. Jsonix .)

Хорошо, надеюсь, я пролил некоторый свет на то, почему вещи в XJC такие, какие они есть. Удачи с этими API, они не прямолинейны. Не стесняйтесь проверять существующий код с открытым исходным кодом, доступно множество примеров.

пс. На самом деле всегда хотел написать это. :)

2 голосов
/ 28 марта 2012

(Это ответ на ваши дальнейшие вопросы.)

Да, можно проверить настройки. Вот класс, который я использую для доступа к настройкам.

Хитрость в том, что ссылочные свойства не имеют собственных настроек, настройки помещаются в свойства ссылочного элемента.*

Я бы сказал, что users@jaxb.java.net - хорошее место для таких обсуждений.

...