А она (Java) точна нужна в БД ? Не жалко памяти и скорость будет JVM отдавать ? Я почему спрашиваю - начиная с 9-ой версии ASA использование Java там разрешается только в качестве расширенных ХП, все остальное обьявленно как Depricated (то есть в будующем не будут поддерживаться Java-классы в таблицах и WatcomSQL скриптах). Так что привязавшись к Java в дальнейшем будет сложно перейти на более современные версии ASA.

P.S. Так же как depricated обьявлены Compressed Database.

Их есть у меняСтранное у них решение, как будто шаг назад - надо
функциональность увеличивать, а не сокращать - кому не
нужны Java-классы - пускай их просто не использует и все.
Ничего странного не вижу. Во первых внешние ХП на Java будут продолжать поддерживаться, их вполне достаточно для регулярных выражений (хотя мне еще ни разу Java здесь не пригодилась), а во вторых держать обьекты Java в таблицах и использовать из в WatcomSQL ХП им просто связывало руки и накладывало определенные ограничения на дальнейшее развитие продукта. Согласитесь, если они исследовавали потребности пользователей и обнаружили малый процент тех, кто использует Java, то смысла ее держать в БД асболютно нет. Тем более что начиная с 9-ой версии у ASA есть прекрасная альтернатива хранения обьектов и их обработки - это поддержка XML и веб-сервисы. И я соглашусь вместе с разработчиками ASA что этого вполне достаточно, с учетом того, что серьезное испльзование Java обычно идет на 3-х звенках в связке с J2EE стандартом и Application серверами и поддержка самопальные решений с собственными интерфейсами и хранением обьектов напрямую в БД немножко вышла из моды.

Информацию на тему Java можно поднять из BOL и их форумов, где тоже одно время шло активное обсуждение, почему с ASA убирают Java.

Их есть у меняASCRUS а по поводу использования Java - есть
надобность работать с сетями, тут без нее никак.
А зачем с сетями из БД работать, почему нельзя отдельно запустить на J2EE модуль, который будет работать с сетями и писать все что нужно в БД ?

J2EE - это Java стандарт для выноса нужной логики приложения на Application Server, где Вы на Java рисуете только нужные модули (Beans) бизнес-логики, а координацию их работы, жизни и общения на себя берет Application Server. Эта технолология довольно обширна и продвинута, имеет собственные механизмы поддержки транзакционной модели для обьектов и используется везде, где необходимо вынести с БД бизнес-логику, не соответствующую прямому назначению работы с данными БД (веб-интерфейсы, обработка и сложные расчеты данных и т.д.). В качестве достоинств таких решений можно еще привести их масштабируемость, где их можно в случае необходимости делать множество и располагать на других серверах, снимая лишние нагрузки по управлению и работе самой СУБД. Думаю работа с сетями как раз относиться к случаям, где в БД должна храниться информация и бизнес-логика касаемо самой информации, а работа с сетью должна быть вынесена в отдельное звено, так как сеть - это уже внешний и независимый от БД источник информации и работы (другое направление).

Их полно, какие то дороже, какие то дешевле. У Borland для JBuilder по моему неплохая связка с Application Server идет. Тут лучше обратиться в форум Java, там народ опытный обитает.