Убедить клиентов перейти на Java 5

Мы продаем пакетные веб-приложения Java некоторым из наших клиентов. Это в основном набор сервлетов, некоторый веб-сервис SOAP и некоторые статические ресурсы. Мы не занимаемся EJB и другими интересными материалами Java Enterprise.

Некоторые из наших клиентов работают под управлением IBM WebSphere Application Server v5.1, поэтому мы ограничены Java 1.4 для времени выполнения и разработки. Конечно, мы хотели бы сделать наше развитие с помощью Java 5 (или даже лучше Java 6). Для выполнения SOAP в 1.4 требуется внешняя библиотека (мы используем AXIS, но она стареет). Мы не можем использовать перечисление, бокс, дженерики... Становится труднее найти совместимые со сторонними библиотеками 1.4.

Клиенты в настоящее время довольны этой настройкой старой, но работоспособной. Мы хотели бы, чтобы они обновили время выполнения Java. В этом случае это означает переход на IBM WAS 6.1 или 7.0?

Что мы можем сказать им? Что в них для них?

До сих пор я получил:

  • Лучшая производительность, поскольку JVM намного эффективнее в Java 5 (еще лучше с Java 6). Однако я не могу нарисовать цифры. Не уверен, что IBM VM значительно улучшилась (один из наших клиентов работает в AIX).
  • Поддержка. IBM WAS 5.1 может поддерживаться только через специальные расширенные программы поддержки.

Это крупные корпорации, поэтому они планируют свои решения более чем за год вперед. Сегодня они выбирают зрелый продукт, и они развертывают его спустя годы. Затем продукт за несколько месяцев до истечения срока службы.

См. Сравнение IBM WebSphere Application Server

ОТВЕТЫ

Ответ 1

Прежде всего, единственным SDK, поддерживаемым данной версией WAS, является SDK, который фактически поставляется с продуктом (другими словами, IBM не будет поддерживать запуск WAS на другом JDK, если это имеет значение).

Во-вторых, WAS может даже не начать с более новой версии SDK (WAS 6.1 не будет запускаться с IBM JDK 1.6, например).

  • WAS 5.1: J2EE 1.3, JDK 1.4.2
  • WAS 6.0: J2EE 1.4, JDK 1.4.2
  • WAS 6.1: J2EE 1.4, JDK 1.5
  • WAS 7.0: J2EE 1.5, JDK 1.6

Поэтому для более позднего времени выполнения, вероятно, будет синоним большой миграции: квалификация сервера JDK и приложений, обучение админов, миграция платформ, миграция приложений, обновление мониторинга, инструменты развертывания, регрессионное тестирование и т.д. Это как правило, сложный и чрезвычайно медленный процесс с крупными консервативными компаниями.

В вашем случае вы можете подумать о разветвлении своего программного обеспечения и предложить разные версии и:

  • только обслуживание в старой версии
    • и определить дату EOL для старых версий (вы не можете поддерживать ее Ad Vitam Aeternam)
  • предлагает новые функции только в новой версии
  • предлагают более агрессивную ценовую политику в новой версии

Должна быть веская причина для того, чтобы ваши клиенты могли использовать более новую версию, и это должно привести к снижению стоимости миграции.

Ответ 2

Java 1.5 достигла конца жизни 3 ноября 2009 года.

Таким образом, ни 1,4, ни 1.5 не поддерживаются больше, что означает отсутствие исправлений безопасности.

Таким образом, в настоящее время единственной поддерживаемой платформой Java в настоящее время является Java6 (aka Java 1.6)

Ответ 3

Вы могли бы рассказать им о расходах на их решение.

Если они продолжат выбирать Java 1.4, то добавление новой функции будет стоить $yyy. Если они будут обновлены, то добавление этой же функции обойдется в $xxx. Предположительно, они также имеют затраты на модернизацию своих систем. Если вы можете показать им, что сбережения на более новой версии Java превышают затраты на модернизацию их системы, тогда они могут видеть, что они сэкономят деньги, если они будут обновлены.

Очевидно, трудно дать точные значения затрат на разработку, но если вы можете оценить, что разработка, например, будет примерно на 30% быстрее (и, следовательно, на 30% дешевле) на более новой версии Java, тогда вы можете получить по крайней мере, приблизительный.

Ответ 4

Вы находитесь в бизнесе, чтобы удовлетворить ваших клиентов. У них есть потребность (будь то реальная или воспринимаемая) придерживаться устаревшей платформы.

Итак, скажите "да", но сообщите им, что вы планируете увеличить свое обслуживание и повысить цены на старую платформу на определенную дату. Это абсолютно оправданное повышение цен; вам необходимо поддерживать опыт и оборудование, чтобы убедиться, что ваш код работает на старой, неподдерживаемой и предположительно небезопасной платформе. Вы предоставляете им реальную ценность, поддерживая их текущую инфраструктуру.

И будьте счастливы, что вы не в бизнесе дизельных двигателей. Если бы вы были, у вас было бы много клиентов с технологией эпохи мировой войны.

Ответ 5

Был там... Клиенты могут быть упрямыми. Я использовал RetroTranslator (http://retrotranslator.sourceforge.net/) и Retroweaver (http://retroweaver.sourceforge.net/), чтобы иметь возможности Java 5. Однако на стороне производительности ничего не может быть сделано.

Что касается Java 1.5/1.4 EOL, для Java-приложений есть программа Java for Business - они не EOL, если вы платите за них...

Ответ 6

Расскажите им о безопасности. Я не уверен, что солнце по-прежнему доставляет исправления для более старых версий (ответ pavanlimo).

Ответ 7

В то время как я согласен с другими приведенными вами ответами, другое соображение заключается в том, что вы рассматривали ситуацию там? Вы пишете приложение таким образом, чтобы оно хорошо сочеталось с другими? Некоторое время я был системным администратором, и одним из моих самых больших проблем является количество домов разработчиков, которые думают, что мы должны изменить нашу ИТ-среду, когда они будут готовы. И, конечно, если есть 2 или более таких домов развития, поставляющих продукты на мой сайт, тогда возникает конфликт.

Написал ли вы свое приложение таким образом, чтобы я мог использовать ваш вариант Java-версии и (выберите свой номер, но его, вероятно, больше 2) другие версии Java, которые мне нужны, как правило, на том же сервере, для поддержки других не менее важных приложений? И предложение обратной совместимости не имеет значения - другой поставщик не поддержит меня, если я не нахожусь на их выбранной версии.

Ответ 8

Возможно, потому, что Java 1.4 достигла EOL 30 октября 2008 года. И поэтому их безопасность может быть скомпрометирована!.

Покажите несколько примеров, где безопасность действительно была скомпрометирована из-за Java 1.4.

Они будут достаточно страшно ИМО.

Ответ 9

Почему бы не пойти в java 6? И java 1.4, и java 5 достигли конца жизни.