Embedded SQL на языках OO как Java

Одна из вещей, которая раздражает меня работающий с SQL на языках OO, должна определить SQL-операторы в строках.

Когда я раньше работал над универсальными компьютерами типа IBM, языки использовали препроцессор SQL для парсинга SQL-операторов из собственного кода, таким образом, операторы могли быть записаны в открытом тексте SQL без путаницы строк, например, в Коболе существует ДОЛЖНОСТНОЕ ЛИЦО SQL.... Конструкция синтаксиса ДОЛЖНОСТНОГО ЛИЦА КОНЦА, которая позволяет чистым SQL-операторам быть встроенными в код Кобола.

<pure cobol code, including assignment of value
 to local variable HOSTVARIABLE>    

EXEC SQL
       SELECT COL_A, COL_B, COL_C
       INTO :COLA, :COLB, :COLC
       FROM TAB_A
       WHERE COL_D = :HOSTVARIABLE
END_EXEC

<more cobol code, variables COLA, COLB, COLC have been set>

... это делает SQL-оператор действительно легким читать и проверить ошибки. Между ДОЛЖНОСТНЫМ ЛИЦОМ SQL.... Маркеры ДОЛЖНОСТНОГО ЛИЦА КОНЦА там не являются никакими ограничениями на добавление отступа, linebreaking и т.д., таким образом, можно отформатировать SQL-оператор согласно вкусу.

Обратите внимание, что этот пример для выбора одной строки, когда набор результатов нескольких-строк ожидается, кодирование отличается (но все еще v. легкий читать).

Так, беря Java в качестве примера

1. Что заставило "старый КОБОЛ" приблизиться к нежелательному? Не только SQL, но и системные вызовы могли быть сделаны намного более читаемыми с тем подходом. Давайте назовем это встроенным подходом препроцессора иностранного языка.

2. Был бы встроенный препроцессор иностранного языка для SQL быть полезным для реализации? Вы видели бы преимущество в способности записать собственные SQL-операторы в коде Java?

Править

Я действительно спрашиваю, думаете ли Вы, что SQL на языках OO является возвратом, и если не затем, что могло бы быть сделано для создания его лучше.