Каким станет Java в 1998 году?

Совершенствование Java оказалась делом куда более сложным, чем первоначально предполагалось.

Не становится ли Java слишком "неподъемным" для JavaSoft? Сложность и объем стандартных API JDK 1.2 непрерывно растут по мере приближения срока выпуска продукта, намеченного на второго квартал нынешнего года.

Между тем, несмотря на выпуск пяти усовершенствованных подверсий JDK 1.1, ошибки по-прежнему остаются, причем довольно серьезные и требующие от разработчиков обходных решений. Не произойдет ли то же самое и с JDK 1.2? Боюсь, что так оно и будет, если вместо "гонки" за немыслимыми сроками JavaSoft не сосредоточится на обеспечении качества своего продукта.

Новые Java-технологии появляются слишком быстро и, как правило, отличаются нестабильностью. Замедление темпов их выпуска принесло бы облегчение многим, особенно если принять во внимание, что обучение разработчиков до сих пор почти повсеместно ведется на базе пакета JDK 1.1.

Сейчас на то, чтобы обучить знающего Си программиста языку Java и "перспективным Java-технологиям" - Remote Method Invocation, Java Database Connectivity и JavaBeans, - уходит почти две недели. С выходом JDK время обучения удвоится, если не утроится, в связи с появлением Java Foundation Classes, новой модели защиты данных и Enterprise JavaBeans.

Благодаря новым технологиям мы сможем создавать полезные и простые в использовании распределенные приложения. Но чтобы добиться их стабильной работы на различных платформах, вполне можно было бы отодвинуть сроки выпуска на несколько месяцев вперед.

Давайте теперь рассмотрим обратное предположение - не слишком ли JavaSoft велика для Java? Судя по двум недавним событиям, и такое возможно.

В ноябре прошлого года ISO присвоила Sun статус уполномоченного издателя открытой спецификации (PAS). Это означает, что все предложения о внесении изменений в спецификацию Java должны быть представлены Sun, и только она вправе решать, передавать их на рассмотрение ISO или нет.

Затем в декабре JavaSoft объявила, что не намерена включать модуль HotSpot в состав JDK, как планировалось изначально, а собирается продавать его в качестве самостоятельного продукта. HotSpot представляет собой технологию компиляции, благодаря которой Java-приложения будут работать не медленнее, чем программы, написанные на Си.

Я не имею ничего против того, чтобы JavaSoft зарабатывала деньги, но только не таким способом. Основной недостаток Java, по мнению многих, заключается в его медлительности по сравнению с Си++, а значит, HotSpot необходим всем. Однако заставляя платить за него, JavaSoft увеличивает общую стоимость внедрения Java, что не может не повлечь за собой негативных последствий.

Беспокоит также тот факт, что решение JavaSoft стало неожиданностью для всех, включая владельцев лицензии на Java. Если бы компания в самом начале заявила, что собирается сделать HotSpot платным дополнением, то другие производители смогли бы начать разработку конкурирующих продуктов.

Не думаю, что JavaSoft ввела сообщество Java в заблуждение намеренно. Однако на будущее компании следует запомнить, что ей как законодателю стандартов следует сообщать о своих планах заранее, дабы другие могли подготовиться. В противном случае разработчики будут относиться к Sun как к очередному монополисту, который уверен, будто может делать все, что ему вздумается.

Если вас прельщает перспектива вступления в Java Lobby (группу защитников Java) или Java Developer's Alliance (союз разработчиков Java-приложений), посетите страницы www.javalobby.org и www-b.developer.com/jda/.