Все не-$MS-направления САПа сейчас держаться на энтузиазме и, ИМХО, они (MS&SAP) уже спелись в одну супермегамонополию ((, что не есть хорошо. Будем кушать MSAPбургеры и петь что лучше на свете и быть не может.

можете привести пример подобных направлений? и отличных от них?

Плодятся ФМ под WinAPI.
Аннонсировали BW - "BEx Analyzer is Microsoft Excel with a BW add-in".
Linuxlab что-то давно ничего не выпускает.
Cравните - как прогрессировали SAPGUI и PlatinGui за несколько лет.

Skif
Привязка BeX к эксель - мелочь какая-то
SAPGUI - тоже

лучше рассмотреть Нетвивер, мне кается. Он пока больше на жабе (J2EE Engine) и на других открытых стандартах (XML, BPEL, WebServices и др.)
.Net там сбоку привязан , вернее, не привязан, а просто не может не работать, если всякие вебсервисы есть. (к RFC протоколу тока привязали дополнительно)

ну, вообще-то, такие штуки как регистрация сервисов для каждой конкретной ОС - это неотъемлемая часть, от них не уйти (автостарт). Понятно, что если бы J2EE Engine бы использовался для SAPGUI for Java, то нуна было бы тока его привязывать к конкретной ОС (чтоб стартовал при загрузке машины), а все остальные приложения не нуна.
Ну а различия типа именования файлов (/usr/... или C:/program/...) обычно все могут легко и корректно обходить.
Понятно, что если прилада использует нативные части (для ускорения графики, например, и прочего), то это типа фича, а не недостатки поделия на жаве.
Все определяет конкретный случай.

посмотрю - после НГ - как можно работать из-под солярного десктопа.

Насчёт того, что джава всех убьёт. Джава уже 10 лет всех убивает и кого она убила? Говорят, что вот-вот щас ещё выпустим новую крутотень и точно всех в следущем году закопает. Написать универсальный код, который работает на мобилке и сервере можно. Верю. Только кому он нужен? Где тут печка? Мы же пляшем от задач, а мобилка и сервер решают разные задачи. Универсальность не даётся просто так, надо чем-то жертвовать. Абсолютная универсальность означает абсолютную неприменимость к конкретно вашей задаче.
Джава на мой взгляд лучше бы шла если бы не пыталась объять необъятное. А сконцентрировалась на своих преимуществах. Пока у нас не будут универсальные задачи как мейнстрим, говорить что джава мейнстрим это глупо.

москвич

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

На самом деле java не кого не собиралась убивать мало того она сама года 2 назад чуть не умерла ... так как JVM - работает медленно код условно платформонезависимый...все таки кое что менять надо в коде.. а например такие языки как Perl, Python, Ruby, PHP переносимы полностью хоть на MAC хоть на Sun OS или Windows, но несколько упешных проектов от таких монстров как IBM + расцвет мобильных технологий т.е. JME и java снова на плаву...
Сам я полтора года назад писал на ней ... и очень хорошо помню какой в Sun был перепалох с появлением Дот НЕТ сразу зашевелились и выпусти java 5.0 хотя предыдущая была 1.4 ) На рекламу угрохали если мне не изменяет память 500млн ... думаю ABAP она не вытеснет .... может быть сделают возможность выбрать на чем писать ... ИМХО на АБАПЕ все-таки лучше... заточен он под это дело...
а на java мы устанем писать ... хотя конечно на ней попроиятнее

ине кажется что всетаки надо понимать что abap - это не собственно универсальный язык разработки, а более всего язык для sap. конечно в нем нет многих красивых и вкусных вещей реализованых на java или c#, да в специализированых sql будь то oracall или ms можно делать значительно больше.
но! abap = sap. и если подумать то его ограничения - это вообщем то защита от дурака. (недавно у нас один абапер хотел вставить в запрос на выборку из базы where like '%[0-9]A'. и очень растраивался что работа с регулярными выражениями невозможна. остается спросить парня: сколько бы работал этот запрос?).
а после введения abap objects можно писать вполне таки красиво и на абапе. имхо.

Ich Will

Ни на каком перле нету сервера приложений. Это языки для небольших сайтов.
Java - это платформа. Большая платформа.
Abap - продвинутый аналог pl/sql. Из этой своей области он не вытеснится по определению.

это сервер приложений должен быть написан на perl?


а какие тогда сайты считать большими? Видимо, их совсем мало, если, например, Amazon.com тоже "небольшой" - http://www.masonhq.com/?AmazonDotCom

Кроме того, может удалим все perl скрипты из solaris- и unix- систем? (зачем на серьезном сервере нужен какой-то "язык для небольших сайтов"?)



даже докладчик от SUN сказал, что первоначально Java была платформой для встроенных систем;
только потом было принято решение "позаимствовать" много всего разного от других решений и добавить решение для "больших" систем;

ну а разговоры про мультиплатформенность java всегда мне напоминают высказывание о том, на что это похоже

Perl'у это не нужно там и так все хорошо работает....
для не больших сайтов - - таких как: Yahoo, Ebay наши Yandex и
Рамблер на нем работают... (это я точно знаю ) и проекты программыне там очень сложные...




Вы мне по секрету скажите писали в на ней ? На платформе ???




АБАП был пораньше PL/SQL'я. АБАП - ведет корни от Пролога.

эх..как это давно было...пролог...4GL..абап... ))
pl/sql..isql..esqlc..

От кобола. Даже многие ключевые слова одни и те же (data, perform), точка эта гадка то же оттуда.

http://www.csis.ul.ie/COBOL/examples/Pe ... rform1.htm

С прологом увы у абапа общего -- только OpenSQL как исчисление предикатов первого уровня.