XSLT в java без использования утилит JRE XML
Похоже, что JDK предоставляет собственную закрашенную версию apache xalan.
Я обнаружил ошибку при создании XML с помощью XSLT (ошибка - это новая строка, а в некоторых разделах cdata добавлен отступ). Это исправлено в невыпущенном jdk12. Я бы хотел избежать этой ситуации, в которой мне нужно ждать, пока Oracle исправит проблему, а также обновить используемую JRE.
Я рассмотрел включение xalan в качестве зависимости через maven. Это работает и, похоже, решает проблему, однако, похоже, что последний раз xalan обновлялся 24 июля 2014 г. Это прошло более 4 лет с момента последнего обновления.
Я хотел бы иметь возможность полагаться на xalan или что-то еще, что поддерживает XSLT, без этой зависимости, исходящей от JRE.
- Поддерживает ли Oracle собственную версию xalan для JRE независимо от apache?
- Почему xalan не обновлялся с июля 2014 года на maven?
- Будет ли в зависимости от xalan возникать всевозможные проблемы? Я действительно видел в Имеете дело с "адом Xerces" в Java / Maven?, что xml-apis был исключен, чтобы попытаться избежать некоторых проблем.
- Было бы лучше использовать другую библиотеку XML, которая с меньшей вероятностью также будет использоваться JVM? Какую библиотеку стоит изучить.
# 4: Ознакомьтесь с Саксонский, который также поддерживает XSLT 3.0, ответив на следующие вопросы: Как использовать XSLT 3.0 из приложения Java? и Как я могу использовать XSLT 2.0 и XSLT 3.0 в Java?
Ответы 1
Пытаюсь ответить как можно лучше (но некоторые из ваших вопросов требуют внутренних знаний):
Насколько я могу судить, JRE-версии Xerces и Xalan представляют собой модифицированные версии Apache Xerces и Xalan, но не сильно модифицированы, и есть некоторые усилия по переносу исправлений ошибок из версии Apache.
Ксалан не был изменен, потому что над ним никто не работает. Его первоначальными спонсорами были IBM и Sun (частично он является производным от IBM LotusXSL, частично - от Sun XSLTC). Разработчики Sun ушли после приобретения Oracle; IBM вложила свои средства в коммерческий процессор Websphere XSLT 2.0 и механизм Datapower. Таким образом, Xalan остался процессором XSLT 1.0, что означает, что спецификация не менялась за 19 лет, и код стал, соответственно, стабильным, поэтому необходимость в исправлении ошибок была незначительной. Пользователи, которым требуется больше функциональных возможностей, чем предлагает Xalan, обычно переходят в Saxon, если только у них нет такого бюджета, который делает Websphere или Datapower доступными.
Нет, вполне возможно, чтобы приложение использовало версии Xalan и / или Xerces для Apache без каких-либо технических проблем.
(У меня здесь есть интерес) Переход на Saxon дает вам все функциональные и производительные преимущества XSLT 2.0 и XSLT 3.0; продукт постоянно развивается, поддерживается и хорошо поддерживается; в некоторых случаях вы можете увидеть существенное улучшение производительности; и за прошедшие годы произошло множество постепенных улучшений в таких областях, как диагностика, настраиваемость и инструментарий. Но преимущества не имеют ничего общего с тем, используется ли код также в JVM.
Спасибо за ответ! Saxon выглядит аккуратно, я заметил, что когда я зависел от него, он был немедленно использован с кодом вроде <pre> TransformerFactory.newInstance () </pre> Я думаю, это хорошо, потому что в большинстве мест следует просто использовать Saxon, хотя я беспокоюсь что JVM ожидает какой-то другой реализации XML и не будет работать правильно. Возможно, мне не стоит об этом беспокоиться.
Это серьезное беспокойство. Если ваше приложение полагается на TransformerFactory.newInstance(), то оно говорит, что готово использовать любой механизм XSLT, найденный в пути к классам, и опасно говорить, если XSLT не был написан и не протестирован на переносимость.
Я думаю, по крайней мере, теперь я контролирую, какой XML-парсер используется, и если что-то не так, у меня, вероятно, больше шансов исправить это, даже если мне нужно исправить это сам. Надеюсь, это просто импортировать код в eclipse.
Java 12 выйдет в марте. Может быть, будет проще подождать до тех пор.