 | Уровень сложности: простой Брэт Маклафлин, автор и редактор, O'Reilly Media Inc.
11.10.2007 Читатели со стажем знают, что Брэтт МакЛафлин любит SAX и не особенно возражает против DOM. Но ему очень не нравится, что Sun отошла от практики создания оболочки для этих API (как это было в ранних версиях пакета JAXP) и почти целиком подменила эти API в последних версиях технологии Java™ и Java 2 Platform, Standard Edition 1.2-1.4 (J2SE).
Воспоминания о JAXP
Программистам, которые только начинают работать с Java и XML (или приходят в XML с опытом использования технологий Sun и J2SE) стоит кратко напомнить историю возникноваения JAXP. Тогда JAXP был третьим API для Java и XML после завоевавших популярность SAX (Simple API for XML) и DOM (Document Object Model). Цель JAXP была проста: облегчить использование SAX и DOM, особенно в плане независимости от производителей.
JAXP был API-оболочкой
Первоначальное предназначение JAXP состояло просто в обеспечении удобства использования и независимости от производителей для SAX и DOM. В свете этого можно сказать, что он никогда не разрабатывался как замена SAX или DOM; фактически, в своих ранних версиях JAXP имел всего несколько методов, двумя из которых были getXMLReader() и getDOMParser(). Эти методы делают довольно очевидным тот факт, что авторы JAXP побуждали разработчиков использовать JAXP для того, чтобы работать с базовыми классами реализации SAX и DOM.
Также важно отметить, что хотя в JAXP за эти годы было добавлено много функциональных возможностей, два вышеназванных метода никогда не менялись. Хотя многие станут утверждать, что целью данного решения была обратная совместимость, на самом деле оно показывает, что JAXP изначально не предназначался для замены SAX или DOM, а служил лишь оболочкой над ними и позволял работать с SAX или DOM без большого количества кода, зависящего от производителей.
JAXP обеспечивал независимость от производителей
На заре программирования на Java и XML существовало множество синтаксических анализаторов XML (Xerces, XML4J в первой версии, Sun Crimson, Oracle XML и несколько других, о которых многие даже не слышали). При написании приложения, работающего и взаимодействующего с XML, необходимо было подключать собственные SAX и DOM API к реализациям этих синтаксических анализаторов, обычно указывая SAX или DOM имя класса анализатора, например:
Parser parser = new org.apache.xercers.parsers.SAXParser();
|
Примечание: Я преднамеренно использовал старый интерфейс SAX Parser; это более старый класс анализатора SAX 1, и именно так все мы работали в то время, когда появился JAXP.
JAXP ввел новое системное свойство javax.xml.parsers.SAXParserFactory, которое позволяло указать реализацию фабрики анализаторов, предоставляющую необходимый анализатор. Можно указать ее через системное свойство, используя System.setProperty(), или через файл jaxp.properties в нескольких местах (по существу, в любом месте в classpath приложения).
Как ни указывай данное свойство (или его DOM-аналог javax.xml.parsers.DocumentBuilderFactory) – в любом случае нет необходимости указывать названия каких-либо классов в анализирующем коде. В этом и состояла основополагающая причина существования JAXP: устранить вероятность попадания подобного рода информации непосредственно в код. Можно легко менять свойства посредством изменения значения этого свойства или даже хранить несколько версий jaxp.properties для разных реализаций синтаксических анализаторов, переключаясь между ними по мере необходимости.
JAXP сегодня
Можно продолжать спорить о том, для чего предназначался JAXP, и даже с чем-то не соглашаться, но это всего лишь разговоры. Дальнейшего обсуждения стоит только то, что представляет из себя JAXP в настоящее время и как его использовать. Поскольку сейчас JAXP входит в каждую версию Java [J2SE и Java Platform, Enterprise Edition 5 (Java EE); Java Platform, Micro Edition (Java ME) - это очевидное исключение], вероятно, его использует 95% всех разработчиков на Java и XML.
JAXP как замена SAX и DOM
JAXP все в большей степени перестает быть оболочкой над SAX и DOM и фактически заменяет их. Но имейте в виду, что JAXP сам по себе не является самостоятельным API для синтаксического анализа, поскольку для его работы необходим анализатор SAX или DOM. Таким образом, JAXP никогда не сможет функционально заменить SAX или DOM; однако он может фактически заменить их, потому что разработчики прекращают использовать методы или классы из пакетов SAX (org.xml.sax) или DOM (org.w3c.dom).
Один из способов удостовериться в этом - спросить разработчиков. Поскольку Sun продвигает (и это понятно) свои собственные API, а JAXP просто "идет в нагрузку" с текущими версиями Java-технологии, многие разработчики знакомятся с XML посредством JAXP. Естественно, они учатся использовать JAXP, хотя для большинства разработчиков полезнее приходить к JAXP после досконального самостоятельного освоения SAX и DOM. Фактически, многие разработчики даже не представляют, что SAX и DOM являются фундаментом JAXP!
Таким образом, JAXP все больше уводит SAX и DOM из поля зрения множества разработчиков. Разговоры о ContentHandler и DOMImplementation в значительной степени дело прошлого или интересны лишь высококлассным программистам на Java и XML. Все очень изменилось даже по сравнению с ситуацией пятилетней давности, когда JAXP все еще имел вес и популярность; тогда существовала гармония в том смысле, что разработчики в основном были удовлетворены SAX или DOM (а во многих случаях обоими) в дополнение к JAXP.
Добавление функциональности или ее удаление?
Но важнее гармонии то, что использование одного лишь JAXP (вместо использования SAX или DOM напрямую, либо использования JAXP вместе с этими API) значительно ограничивает функциональность XML-программирования и синтаксической обработки. Поскольку JAXP на самом деле является просто API-оболочкой (не зависимо от того, как люди его используют), он просто не может поддерживать каждую возможность, предоставляемую SAX и DOM. Хотя при помощи JAXP можно установить свойства анализатора для работы с содержимым и выполнения базовой обработки ошибок, SAX, например, предлагает множество событий, связанных с грамматикой (DTD и схемы), и более сложные лексические события, такие как команды обработки. Единственный способ доступа к этим событиям – непосредственная работа с интерфейсом SAX XMLReader.
Имейте в виду, что я не призываю совершенно отказаться от JAXP. Можно использовать JAXP по его первоначальному назначению (доступ к анализатору без непосредственной работы в коде с классами анализаторов различных производителей), а затем применить метод JAXP getXMLReader() для получения интерфейса SAX XMLReader. Это позволит легко работать с SAX напрямую, но, прежде всего, в предположении, что вы знаете, как работать с интерфейсом XMLReader.
Итак, смысл всего вышесказанного заключается в том, что JAXP, который якобы должен добавлять функциональность (независимость от производителя, а также некоторые удобства и вспомогательные методы), потенциально может эффективно удалять ее. Излишне полагаясь на JAXP (что, вероятно, уже происходит), очень легко забыть или даже не знать о том, что JAXP не реализует многое из того, что есть в SAX и DOM. То есть, хотя цель JAXP состоит в том, чтобы предлагать функциональность, на самом деле он может уменьшать инструментарий Java и XML-программистов.
Проблемы с открытым исходным кодом?
Я оставил этот спорный вопрос напоследок, в основном по соображениям этики, законности и всего того, что большинство программистов считает формальным и скучным, а также, будто этого недостаточно, добавил немного философии открытых исходных кодов. В общем, интересно, не нарушает ли Sun (следуя, конечно, букве закона) дух закона (открытых исходных кодов и сообщества)? Когда они взяли SAX API под свое покровительство, а затем начали добавлять функциональность в JAXP, я удивился, почему они просто не включили эту функциональность непосредственно в SAX? Вполне можно было добавить JAXP-методы, вызывающие эту новую функциональность (то, для чего большинство их API и служит). Нельзя ли вернуться и предоставить все это в SAX API?
Если JAXP так полезен, в чем нас хочет убедить Sun (сразу поясню, что вовсе не оспариваю его полезность), почему они не сделают эту функциональность доступной для тех из вас (нас!), кто изредка предпочитает работать только с SAX, не прибегая к JAXP? Ведь мы все равно используем Java-технологию, значит, делая эту функциональность доступной не только через JAXP, но и через сам SAX, Sun ничего не теряет (это тем более смешно, поскольку Sun не продает Java-технологию). И еще одна мелочь, о которой стоит подумать: если у JAXP столько достоинств, нельзя ли некоторые из них пожертвовать исходному API? JAXP мог бы по-прежнему облегчать трансляцию между SAX и DOM, а XML-сообществу был бы сделан хороший подарок.
В заключение
Я не хочу начинать здесь спор (хотя не возражал бы, если бы некоторые из вас сделали это на дискуссионных форумах), но я действительно исследую JAXP (и другие SUN API, которые следуют тому же стилю) и его эволюцию от API-оболочки до API анализатора "все в одном". Мне кажется, что JAXP затеняет ценность изучения самих SAX и DOM API, на самом деле не предоставляя взамен значительных преимуществ. Я предпочел бы, чтобы Sun сохранила JAXP в качестве облегченного слоя, обеспечивающего независимость от производителя (для тех, кому это надо), и оставила методы и поведение анализатора исключительно в компетенции XML-анализатора и производителей API.
Естественно, Sun не интересовалась моим мнением, а Скотт МакНили (Scott McNealy) наверняка никогда не слышал обо мне, поэтому над Sun никакие тучи не сгущаются. Однако моим намерением было заставить Java- и XML-программистов критически подойти к использованию JAXP. Если бы программисты заново изучили SAX и DOM, то можно было бы снова начать разумно использовать JAXP и на самом деле писать более совершенные приложения, работая с XML-документами на более низком уровне и более компетентно. И тогда Скотт смог бы заметить написанные нами суперприложения, не так ли? Поэтому скажите мне… есть ли во всем этом смысл? Я надеюсь встретиться с вами на форумах developerWorks и узнать ваше мнение.
Ресурсы Научиться
Обсудить
Об авторе | 
| | Брэт Маклафлин работает с компьютерами со времен Logo (помните маленький треугольник?). За последние несколько лет он стал одним из наиболее известных авторов и программистов сообщества по технологиям Java и XML. Он работал в Nextel Communications над реализацией сложных корпоративных систем, в Lutris Technologies, фактически, над созданием сервера приложений, а с недавнего времени - в O'Reilly Media, Inc., где продолжает писать и редактировать книги по данной тематике. Его готовящаяся книга "
Head Rush Ajax
" рассматривает инновационный подход "Вперед головой" к изучению Ajax; она пишется совместно с известными соавторами Эриком и Бет Фримэн. Его недавняя книга "
Java 5.0 Tiger: Заметки разработчика
" является первой доступной книгой по новейшей технологии Java, а его классическая "
Java и XML
" остается одной из наиболее авторитетных работ по использованию технологий XML в языке программирования Java. |
Выскажите мнение об этой странице
| |
