Tomcat отстой … Apache несовершенен?

В моем списке блогов по Java находится книга Хани Сулеймана « The BileBlog» , в которой он дает непримиримые абразивные обзоры популярных проектов Java и людей, стоящих за ними. В прошлом он был менее чем комплиментарен для различных предложений Java от Apache Project с открытым исходным кодом («opensores»), таких как Maven и Struts . Сегодня он взял Tomcat на задание .

Разумеется, Tomcat предоставляет эталонные реализации для спецификаций Servlet и JSP, но благодаря тому, что он бесплатный, он также является предпочтительным сервером для многих малых и средних предприятий. Некоторое время назад я критически посмотрел на Tomcat , ища удобный для Java сервер веб-приложений (я все еще ищу).

Критика Сулеймана в отношении Tomcat основывается несколько освежающе (он часто прибегает к неубедительным, если не интересным, личным атакам на разработчиков) на качество кода проекта или, скорее, его отсутствие. Выбрав основной, но относительно несложный класс ( DefaultServlet , который отвечает за обслуживание статических ресурсов, таких как файлы и изображения HTML / CSS / JavaScript), он указывает на множество примеров ужасной практики кодирования, из которых это только выборка:

Код инициализации, который лениво ловит Throwable

  // Set our properties from the initialization parameters String value = null; try { value = getServletConfig().getInitParameter("debug"); debug = Integer.parseInt(value); } catch (Throwable t) { ; } try { value = getServletConfig().getInitParameter("input"); input = Integer.parseInt(value); } catch (Throwable t) { ; } 

  Throwable является базовым интерфейсом для всех исключений Java - ошибок, многие из которых не имеют никакого отношения к такому коду, не говоря уже о том, что этот код будет игнорироваться.  Например, если серверу не хватает памяти во время инициализации DefaultServlet , этот код будет игнорировать полученную ошибку и попытаться продолжить работу. 

Попытки идентифицировать конкретные исключения по частям их строк сообщений

  try { serveResource(request, response, true); } catch( IOException ex ) { // we probably have this check somewhere else too. if( ex.getMessage() != null && ex.getMessage().indexOf("Broken pipe") >= 0 ) { // ignore it. } throw ex; } 

К счастью, рассматриваемое утверждение if (которое, как следует из комментария, кажется, разработчик был довольно неуверенным) на самом деле не приводит к игнорированию исключений, которые оно идентифицирует (как говорится во втором комментарии), так что этот запутанный поворот плохое программирование на самом деле бесполезно в любом случае.

Метод, который возвращает исключение вместо его выброса

  protected IOException copyRange(InputStream istream, ServletOutputStream ostream) { // Copy the input stream to the output stream IOException exception = null; ... try { ... } catch (IOException e) { exception = e; ... } ... return exception; } 

Как сторонник разработки с открытым исходным кодом, я смотрел на все проблемы, на которые он указывал, чтобы получить пользу от сомнений. «Хорошо, это выглядит глупо, но должна быть веская причина, по которой они это сделали». Конечно, не было, если только вы не считаете лень или невежество веской причиной.

Для проекта, созданного под пристальным вниманием общественности к разработке с открытым исходным кодом, это действительно тревожно фундаментальные проблемы. Для меня самый важный вопрос заключается не в том, является ли Tomcat отстойным, а в том, является ли этот уровень качества кода исключением или нормой в лагере Apache.

Я точно знаю, что в дикой природе есть много Java-кода с открытым исходным кодом хорошего качества. Например, я пробовал код Jetty несколько раз и был приятно удивлен тем, что там нашел. Я также знаю, что плохой открытый исходный код — это не просто проблема, с которой сталкивается Java . Но Апач должен быть лидером в этой области.

Если неоднократные осуждения The BileBlog указывают на то, что большая часть Интернета могла бы работать с программным обеспечением, подобным этому — код, который выглядит так, как будто он был написан в отчаянном стремлении уложиться в срок с чем-то, что работает … большую часть времени … едва.