Сугубо IMHO - пока не появится java-ориентированная архитектура и 100% аппаратная реализация JVM, java приложения приличными не будут.

Не соглашусь.

Сам Java-код может быть (и бывает) достаточно шустрым не только сегодня, а еще "вчера".

Лично участвовал в разработке нескольких Java программ, которые в конечном итоге работали в среде z/OS. По сути программы занимались разбором текстовых сообщений (из WebSphere MQ) и раскладыванием их по базе данных.
Работало это все на 9672-R14, OS/390 2.10, JDK 1.3, WebSphere MQ 5.3, DB2 V7.
Эти программы заменили оригинальные программы, которые были написаны на HLASM и работали с собственной файловой базой данных, но исчерпали ресурс по размеру БД.
Скорость работы и потребление CPU были сравнимы уже тогда!
Но, для Java-программы было прилично большее потребление памяти (порядка 4 МБ для оригинальной программы и порядка 80 МБ для Java-программы).

Другое дело, что поверх Java SDK часто накручивают очень много кода для "облегчения" жизни разработчика. Изоляция от SQL-кода (DAO, DAL, Persistance и т.п.), взаимодействие через веб-службы (а это синтез/разбор XML), и еще куча всевозможных "оберток".
В итоге все это быстро работать не сможет в принципе, т.к. большая избыточность кода и куча проверок (внутри каждой обертки).

Т.е. очень часто Java-реализация некоего функционала может быть "тормозной" не по вине самого Java SDK, а по вине технологии разработки приложений для Java/J2EE.

Аппаратная реализация JVM и/или предварительная компиляция байт-кода в платформенный код может помочь, но не радикально, т.к. сложность кода от этого не уменьшится.

PS: IBM не просто так выпустил "облегченную" версию WAS, которая называется Liberty Profile. Полнофункциональный WAS стал слишком перегружен технологиями и совместимостью, а очень немаленькому проценту приложений это вовсе ненужно, поэтому теперь (в версии 8.5) можно использовать Liberty Profile и, при его запуске, подключать только те функции и расширения, которые реально нужны приложению.

поддержу.
во-первых, скорость исполнения, грубо говоря, дважды два, что в яве, что в С.
во-вторых, изложенная ситуация описывается архитектурной парадигмой "нет такой архитектруной проблемы, которую нельзя было бы решить введением дополнительного слоя, и нет такой проблемы производительности, которую было бы нельзя решить убиранием дополнительного слоя".
кроме потребления памяти, платформа исполнения явы отличается ещё и тем, что нельзя выполнить каждую задачу в своём адресном пространстве, что изначально типично для MVS и является её преимуществом by design. Но учитывая, что, к примеру, в CICS это тоже невозможно, то очевидно, что это актуально не для всех задач.
Так что и яве тоже есть место, если есть голова.
Кстати, проблема головы первична, слабое знание платформы, состава, назначения, и взаимодействия основных частей и механизмов, приводит к большим глупостям при портации на платформу. Часто действие идёт по шаблону - если в юникс что-то было сделано в оракл, значит, в z/OS это надо делать в DB2, несмотря на то, что этой задаче база вообще не нужна, поскольку эта часть функционала уже реализована подсистемами MVS, использование этих возможностей позволит ускорить выполнение и снизить потребление ресурсов раза в три. И таких примеров масса.
Низкая техническая грамотность, действия по шаблону.... Бич.

ты про кикс не прав, thread safe можно выполнять не на квази TCB.

Отвечаю
Во-первых. Quasy Reentrant TCB, если полностью. Средство синхронизации нитей (TCB) между собой по доступу к разным ресурсам, кто занимался многонитиевым програмимрованием, тем понятнее. Я не утверждаю, что ВСЕ транзакции будут выполнятся на нём или в другом адресном пространстве. Хотя, это типичная ситуация для кикса, когда ВСЕ транзакции в одном адресном пространстве, MRO было сделано позже (Multiple Region Option, по-моему, расшифровывается), и можно и без него, но можно и с ним. Но бай дизайн КИКС сформировался как все задачи в единственном адресном пространстве с синхронизацией через QR TCB.

Во-вторых. Максимальный уровень изоляции, который теоретически можно достичь в CICS, это выделить под одинаковые экземпляры транзакций адресное пространство. Ещё раз - все экземпляры объявленной транзакции будут исполняться вместе в одном адресном пространстве на разных TCB. То есть, если есть транзакция, объявленная в системе, как TRAN1, то ВСЕ экземпляры этой транзакции, сколько бы их небыло одновременно, будут работать в одном адресном пространстве, на разных TCB (ну это то понятно, что на разных). Если кто знает и может, ткните, где и как сделать, чтобы каждый экземпляр транзакции TRAN1 работал в собственном адресном пространстве. И как правило, в одно адресное пространство напихано разных транзакций.

Такого уровня изоляции как в ИМС, где каждая инстанция задачи(транзакции) выполняется в собственном адресном пространстве, я знаю вот ещё в JES.
Ещё кто назовёт подсистемы схожие по этому признаку?

А ведь кстати да.
ВСЕ не threadsafe транзакции будут исполнятся на ОДНОМ единственном TCB.
Надеюсь, с понятным результатом...
Threadsave писать можно, на любой платформе, просто надо выполнять правила.
Правила надо выполнять....
Дополнительные усилия.
И вообще, это КИКС сосредоточие проблем...
Кто б мог подумать, каких то лет 10 назад это была вершина технологии

Далее следует абсолютнейшее ИМХО.

На Java вполне можно разрабатывать достаточно шустрые приложения, главное не увлекаться многоуровневой архитектурой и уровнями абстракции.
В общем случае Java-программа не получает особых бенефитов от исполнения в среде z/OS.
Какие могут быть основания для переноса Java-нагрузки на платформу System z ?

1. Получить выигрыш от "colocation".
Например, в случае СУБД DB2 использовать не сетевой доступ к базе (Type4), а локальный, через общую память (Type2). Тем самым минимизировать задержки и повысить быстройдейтсвие.
Однако, DB2 сможет использовать zIIP для обработки SQL-запросов только для DDF-соединений (сетевых), т.е. выбирая локальное соединение мы попадаем на увеличенное потребление GCPU со стороны СУБД.
Второй выйгрыш от "соседства" - нет проблем с разрывами сетевых соединений по неизвестным/неподконтрольным причинам.
Бонус: не нужно в программе закладываться на обработку кодов разрыва соединений по сети и их восстановления. Если "упало" локальное соединение - чаще всего нужно просто завершить работу.

2. Повысить отказоустойчиовсть приложения за счет самой архитектуры z/OS. Возможно, но тут нужно вдумчиво считать, а будет ли оно того стоить.

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

x. Больше ничего не придумывается, буду рад услышать дополнения.

Вторая цель присутствия Java в среде z/OS - повышение привлекательности самой платформы z/OS и облегчение процесса миграции.
Java как платформа в настоящий момент очень популярна, есть готовые продукты, есть большое количество специалистов.
Плюс, немалое количетсво Java-программ можно без изменений запустить на платформе System z.
Т.е. можно вполне честно утверждать, что переход на платформу не потянет за собой переписывание прикладного ПО (java-based), что снижает риски и сроки миграции.
С другой стороны - и уйти с платформы z/OS тоже весьма просто, что минус для IBM и плюс для пользователей.

Ухвачена суть.
Добавлю только, что и от использования драйвера тип 4 может быть выигрыш - скорость внутри может быть поболее, наверное, да и как факт сетевого то соединения по всей сетевой инфраструктуре нету, всё внутри, по локальным интерфейсам, хоть на loopback посади.
И хотелось бы дополнить, что особенно это имеет смысл, если уже core systems внутри z/OS, на традиционных приложениях, то размещая рядом новые системы на Java, не только UI, но и, допустим, бизнес-интеграцию, хоть Process Server для управления бизнес-процессами, любую высокоуровневую бизнес-логику, которая склонна к частому изменению, мы можем получить выгоду, от снижения latency хотя бы.
То есть понятно, что основа основ, двойная запись в учёте финансов неизменна и не будет изменена, и перевод денег со счёта на счёт можно смело делать хоть на HLASM, это не будет менятся никогда.
А вот куча правил вокруг этого, куча банковских продуктов, рождающихся чуть не каждую неделю, отличаются как раз правилами, размером процентов, коэффициэнтом, и прочими "мелочами", которые надо часто менять. И вот это вполне можно сажать на Java.
Если есть основа, которая за гарантированный период времени проводит финансовую транзакцию, то мы немного теряем, размещая вычислительную часто изменяемую часть правил в Java, скорее, даже выигрываем иногда, ускоряя вывод продуктов на рынок. Но тут надо учесть наличие BRMS for z/OS for COBOL, бывший iLog, как я понимаю, который транслирует бизнес-правила в COBOL, и их можно слинковать с целевым приложением хоть на HLASM, и тогда даже задержек на вызов правил по вебсервисам не будет.
Art сейчас эту тему ковыряет.
Как закончим - где-то тут на сайте выложим.
Хотя, место для Java всё равно остаётся, как для "обвязки" core system.
Я так думаю.

я тоже похоже думаю, но при условии эффективного RTE для Java, может даже нэйтивного а не основанного на интерпретации.
хотя в последнем сильно сомневаюсь.

и вообще - нельзя купить машину только из спецпрцессоров. есть жесткая зависимость межде количеством одних и других. не весь код на них можно исполнять, нельзя иметь машину только из спецпроцессоров... так что фиг вам, а не быстрая и дешёвая ява!

Ну в частности можно прикручивать Java GUI интерфейс к продуктам. То есть навернуть сверху что-то на более дешевом процессоре.

Переключение контекста будет гораздо больше, потому как ибм не даёт выполнятся всему коду на zaap, точно так же как и на ziip, в результате когда система обнаруживает, что следующий участок кода можно (или нельзя) выполнить на спец процессоре - она переместит задачу с проца на прц. Это очень затратно, и производительность падает, но лицензионные отчисления тоже падают.
Интересно посмотреть, может, скоро ибм доплачивать будет, лиш бы "")это"" кто-нибудь использовал.
Явно хорошая мина при плохой игре. Если бы брали как горячие пирожк, то фиг бы мы увидали  специализированные процесслры. ИБМ не благотворительная контора, а акула капитализма.

Будущее за платформами типа EGL. Вся индустрия движется в этом направлении. 
А ява - всего лишь язык, с достоинствами и недостатками. И пока с паршивыми средами исполнения.
Кстати, характерный пример, где пользователи проголосовали за среды исполнения - в одной очень крупной компании, имеющей старые АРМ реализованные VaGen, и новые, реализованные вебсферой. Статистика использования за рабочий день, старый интерфейс более 3000 раз, новый 3-4 раза!

Ну, тут всё очень просто - сперва посмотрите в сторону Java, если разрабатываете новое приложение под мэйнфрейм, потом боритесь с тем, что она сожрёт все ресурсы, (особенно если это вебсфера), потом подумайте надо добавить ресурсов, поймите, что машину только из ZaaP вам никто не продаст, потом удивитесь наивности liks, потому что переключения контекста будет постоянным - ни в случае с ZaaP, ни в случае с ZiiP, задача не может целиком выполнятся на специализированном процессоре, IBM очень дозировано добавляет функциональность на них, и WebSphere Application Server, и DB2 жрут GPU только так, потом подсчитайте совокупную стоимость, и в конце концов под Java выберите более подходящую платформу.
Это я вообще даже не упоминаю об управляемости и понимаемости кода в среде Java.

Есть подозрение, что производительность еще немного выше из-за меньшего контекст-свитчинга -- процессы, которым нужен CP, не будут туда отправлять свои задачи.

википедия говорит, что "zAAPs are not specifically optimized to run Java faster or better". Так что мне очень интересно про "оптимизированный под Java код". Можно посмотреть где-нибудь что именно там специализированно?

там ничо не оптимизировано, мы все это знаем)) это чисто вопрос лицензий и платежей.

ну вот я тоже удивился, может чего поменялось, а я и не в курсе.

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

Кто-то мне говорил, что за счет того что милликод лимитирован под Java, там меньше других проверок, из за чего получается быстрее. На сайте IBM я вижу в лучшем случае сочетание "price performance".

Хохо, Сергей! Эти все соображения - из лагеря покупателей новых машин и лицензирующих все подряд. На рынке секонд-хенд машин любой процессор стоит одинаковых денег. А вот Коболом из этих денег можно вытряхнуть больше транзакций, значит, быть более эффективным.

И еще. При такой постановке Java выгоднее по деньгам не на zAAP, а на быстрых RISC или Intel процессорах. Кому нужны эти мейнфреймы?

Ну не все же живут в нашем секонд мире. В мировом масштабе это тенденция, которая все больше и больше осознается. И да, имеются в виду Java приложения которые обрабатывают данные на мейнфрейме. Перекачка данных по сети на RISK для обработки не эффективна из-за низкой пропускной способности сети. zBX стоит поближе и позиционируется для аналитики, но думаю и это не спасет для больших объемов данных.

Я сейчас страшную вещь скажу. JAVA - нормальный язык, и на нем вполне можно писать что-то приличное. Проблема в среде выполнениея JAVA-кодов. Сделает IBM толковую среду выполнения или компилятор сразу в нормальные машинные коды - и возможно наступление счастья!

Еретик!
А по теме: JIT уже давно на фрейме есть.

а про него плохие отзывы. имеется в виду что-то приличное и шустрое.