Конвертер Delphi -> Java

← →
Юрий Зотов © (2008-06-19 22:18) [0]

Есть здоровеннейший проектище. Первоначально был сделан, как двузвенка (Oracle + BDE + Delphi), затем был переведен на трехзвенку (Oracle + WebSphere + Delphi). Для перевода была написана библиотека компонентов, которая на стороне клиента эмулирует компоненты BDE, а с Oracle общается через WebSphere.

Все это сделано и работает. Теперь встала другая задача - уйти от Delphi совсем и перевести весь проект на Java. Из-за большого объема кода переписывать его ручками малореально, в связи с чем и возник следующий вопрос:

Не встречал ли кто любых инструментов, которые могли бы этот процесс автоматизировать? Хоть частично, хоть еще как угодно.

Заранее благодарен за любую информацию по сабжу.

← →
Игорь Шевченко © (2008-06-19 22:21) [1]

Если встретишь, дай знать. Только на C#

← →
Игорь Шевченко © (2008-06-19 22:22) [2]

максимум, что я встречал - это неплохой парсер - генератор абстрактного синтаксического дерева из исходников delphi. С исходниками и работающий

← →
Тимохов (2008-06-20 00:23) [3]

большой дядя, а в существование чуда верит :)
не может быть такого средства перевода, если только Дельфи проект не тривилен (по сути, а не объему).

извините уж за оффтоп.

← →
Тимохов (2008-06-20 00:25) [4]

Кстати, если такая тулза все же есть. Было бы интересно посмотреть.

Юра, скинь, пожалуйста информацию, если сам найдешь.

← →
Petr V. Abramov © (2008-06-20 00:57) [5]

> Игорь Шевченко © (19.06.08 22:21) [1]

а нафига те дельфийский код, написанный на C#?
увидеть те же глюки?
вот если б была тулза bpl -> assembly....
:)

← →
DrPass © (2008-06-20 01:56) [6]

> Не встречал ли кто любых инструментов, которые могли бы
> этот процесс автоматизировать? Хоть частично, хоть еще как
> угодно.

Не встречал, и не представляю как такой конвертер мог бы помочь. Ведь в вашем случае надо архитектуру клиента полностью переделывать, а не просто код на Java транслировать.
Кстати, а зачем делался посредник в виде мимулятора BDE? Почему не общаться с WAS напрямую, через SOAP? Это очень удобная схема. Например, она позволит реализовать Single Sign-on - никаких паролей при входе в приложение. Легко регулировать "толщину" клиента - хочешь, помещай в него бизнес-логику. Не хочешь, сделай из него просто тупое окошко. И т.д.

← →
Юрий Зотов © (2008-06-20 02:07) [7]

http://www.re-coding.com//root.php?t=root&g=delphi2java%20overview

http://www.javadelphi.com/Delphi_To_Java.cfm?pt=2&sp=2&ycs=%2BqWEgB7wUAc%3D&qs=06oENya4ZGJbKUjvjwGtnG1Ko75B9lZM-bGtVy92ltDe8vsUSPwdCe364Lp3b0L1DEbnh__PZe4OuVILD7CgR39xudoVZuBR7k5pUObck5TDs0Lvd zUaU9s4BlzcrWVhGI2Q-RmbIy37l6ApGhLk71-e8L5DWLCF30YNb-smQYqAtUk7uAH7StCr-_BzDKMzzPceZTgQcNzGaTpJ8nYv5r432fKA7gQp0OSTkhfEsiA6KRFY4DGfn8AZCitw..,YT0z&vid=1 213912172_2X01X931224165&rpt=2&kt=4&kp=8

← →
Юрий Зотов © (2008-06-20 02:14) [8]

> DrPass © (20.06.08 01:56) [6]

> как такой конвертер мог бы помочь.

Сам не очень представляю. Наверное, он мог бы создать хотя бы заготовки кода.

> зачем делался посредник

Чтобы не перепахивать огромный код ручками. Например, написали мы TMyQuery - эмулятор TQuery. Далее просто делаем поиск и замену текста (имени класса) по всем файлам pas и dfm - и все сразу работает (uses правятся аналогично - поиском и заменой текста).

← →
MBo © (2008-06-20 05:16) [9]

>Игорь Шевченко
Встречал название delphi2cs, но что и как делает - не знаю

← →
Simpson © (2008-06-20 11:17) [10]

а если все что зделано в Ole закинуть и использовать через Ole?

← →
Mystic © (2008-06-20 12:53) [11]

Как идея можно посмотреть в сторону откомпилять под .NET, а потом код отрешарпить под J#. Это можно было бы рекомендовать, но под Delphi наверняка используется куча внутренних библиотек, которые будет тяжело перевести 1-1 под Java (тот же VCL)

← →
Simpson © (2008-06-20 12:57) [12]

Mystic © (20.06.08 12:53) [11]
Есть библиотека которая позволяет использовать через Native функции Оле интерфейсы, у .Net ИМХО с Оле вообще не должно быть проблем.

← →
Mystic © (2008-06-20 13:05) [13]

> Есть библиотека которая позволяет использовать через Native
> функции Оле интерфейсы

Надо смотреть на зависимость кода. Например, от чего наследуется TMyQuery. В этом случае придется переводить и TDataSet и TField и все-все-все... Может оказаться намного проще самому реализовать TMyQuery.

← →
Simpson © (2008-06-20 13:11) [14]

Mystic © (20.06.08 13:05) [13]
Зачем? В Оле можно публиковать интерфейсы тех классов которые тебе нужны что делает на самом деле класс на который ссылается интерфейс и кого он создает это уже проблемы класса, а не интерфейса.
// Проблемы индейцев шерифа не касаются )) Кто то из модераторов.

← →
Mystic © (2008-06-20 13:15) [15]

> Simpson © (20.06.08 13:11) [14]

Т. е. ты предлагаешь создать на Delphi Ole объекты и их использовать из Java? А как кроссплатформенность? Как это будет работать не под Windows?

← →
Mystic © (2008-06-20 13:23) [16]

Еще Oberon умеет компилировать в JVM код. Может и FreePascal тоже?

← →
Simpson © (2008-06-20 13:26) [17]

Mystic © (20.06.08 13:15) [15]
>>Т. е. ты предлагаешь создать на Delphi Ole объекты и их использовать из Java?
Да, к сожелению не помню название библиотеки которая это делает.

>>А как кроссплатформенность?
D"oh, только в условиях ничего не было про кроссплатформенность.

>>Как это будет работать не под Windows?
Никак. Native функции не предпологают кроссплатформенности.

зы
На Windows влет будет работать в свое время была задача в Java вытащить Ole интерфейсы которые писались на ForPro все на ура прошло.

← →
iZEN (2008-06-20 18:44) [18]

> Simpson © (20.06.08 13:26) [17]
> >>Как это будет работать не под Windows?
> Никак. Native функции не предпологают кроссплатформенности.

Содержимое нативных функций нужно писать и компилировать для каждой платформы отдельно — получается соответствующие .DLL- или .SO-файлы библиотек.
А Java-классы с нативными вызовами компилируются раз и навсегда. Потом нативную библиотеку нужную подцепить для них — не проблема.

← →
iZEN (2008-06-20 18:46) [19]

> Юрий Зотов © (19.06.08 22:18)
>
> Есть здоровеннейший проектище. Первоначально был сделан,
> как двузвенка (Oracle + BDE + Delphi), затем был переведен
> на трехзвенку (Oracle + WebSphere + Delphi). Для перевода
> была написана библиотека компонентов, которая на стороне
> клиента эмулирует компоненты BDE, а с Oracle общается через
> WebSphere.

Для Java это будет долгоиграющий костыль, который убъёт и/или замучает несколько разработчиков. Лучше перепроектировать и переписать всё на Java, используя соответствующие технологии.

← →
tesseract © (2008-06-20 18:46) [20]

Могу только посоветовать попробовать перебросить в UML, оттуда на java. Хотя бы структура сохраниться должна.

← →
Simpson © (2008-06-20 19:59) [21]

iZEN (20.06.08 18:44) [18]
Речь идет не про нативные функции в чистом виде, а про то чтобы перегнать проект в Оле и из Оле уже иметь доступ к функционалу через нестандартную библиотеку. Поэтому я и написал никак.

Вообще конечно можно перегнать и в DLL/SO, тогда уже операционка не играет роли.

← →
iZEN (2008-06-22 03:21) [22]

> tesseract © (20.06.08 18:46) [20]
>
> Могу только посоветовать попробовать перебросить в UML,
> оттуда на java. Хотя бы структура сохраниться должна.

А как быть с завязками на VCL? Ведь просто так структуру кода, связанного с вызовами VCL-компонентов, не перенесёшь 1-в-1 на структуру, опирающуюся на Swing или SWT. Хотя со старой микрософтовской/хайлсберговской библиотекой WFC можно попытать счастья (там, кстати, и OLE есть). Но всё равно костыли будут заложены и для граблей места найдётся.

← →
ZeroDivide © (2008-06-22 11:23) [23]

> максимум, что я встречал - это неплохой парсер - генератор
> абстрактного синтаксического дерева из исходников delphi.
> С исходниками и работающий

Дай.

← →
Пробегал2.... (2008-06-22 14:15) [24]

я вообще не понимаю также чем это может помочь.

Ведь наверняка в дельфи усердно используется VCL, да? Хотя бы тот же наследник TQuery, это значит этот переводчик должен еще и VCL библиотеки перевести на Java?!?!

С грехом пополам заголовочные файлы из C в Delphi переводятся и то править нужно иногда по-моему... А тут код...

← →
Пробегал2.... (2008-06-22 14:16) [25]

вопрос к Юрию - а ведь Дельфи так хороша, и по вашим же словам Java отстой несусветный. Так зачем же проект переводить на java?!?!

Чтобы он как вы говорите начал тормозить в 30 раз больше, памяти кушать в 20 раз больше?

← →
VirEx © (2008-06-22 14:19) [26]

> [25] Пробегал2.... (22.06.08 14:16)

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

← →
iZEN (2008-06-22 14:34) [27]

> Пробегал2.... (22.06.08 14:16) [25]
> Так зачем же проект переводить на java?!?!
>
> Чтобы он как вы говорите начал тормозить в 30 раз больше,
> памяти кушать в 20 раз больше?

Тоже поддерживаю вопрошающего.

При переводе проекта конвертором (если такой найдётся) с Delphi на Java с большой долей вероятности приложения будут "тормозить в 30 раз больше, памяти кушать в 20 раз больше", чем если бы всё было написано с нуля на Java. ;)

← →
VirEx © (2008-06-22 14:38) [28]

> [27] iZEN (22.06.08 14:34)

"джависты" держат оборону :-D

> VirEx (22.06.2008 14:38:28) [28]

Просто заметил тонкое место и очень точно :-)

Anatoly Podgoretsky

ну это то и так понятно, как грубый пример: игрушка заточенная для консоли, портированная на PC будет выглядеть не как задумывалось, да часто такие игрушки "тормозят"

> VirEx (22.06.2008 15:08:30) [30]

Да он просто Юрия подколол :-)

> Пробегал2.... (22.06.08 14:16) [25]

> вопрос к Юрию - а ведь Дельфи так хороша, и по вашим же словам Java
> отстой несусветный. Так зачем же проект переводить на java?!?!

Увы, этот вопрос даже не ко мне. На фига козе баян - мне тоже совершенно непонятно. Но в этом проекте не я архитектор и не я определяю политику. Более того, на текущей стадии я в нем даже и не участвую (пока, во всяком случае), а сабж - это типа "в консультативном порядке".

← →
int64 (2008-06-22 15:52) [33]

Можно выгрузить все юниты в диаграмму классов, если ее еще нет. Через что-то типа ModelMaker-а. Туда можно и "визуальные" юниты впихнуть. К тому же будет видно, как лучше рефакторить исходники, чтобы отвязаться от Delphi штучек. А потом по этой диаграмме автоматом сгенерить джава код. Главное, чтобы конвертеры-генераторы понимали общий формат UML.
От похожей процедуры всеравно не уйти.

Anatoly Podgoretsky © (22.06.08 14:55) [29]
Просто не надо верить в сказки про добрый сборщик мусора, и удалять обьекты сразу после использования.

> Просто не надо верить в сказки про добрый сборщик мусора,
> и удалять обьекты сразу после использования.

Во-первых, это не сказки, сборщик мусора действительно добрый, во-вторых, программируя на delphi ты же не присваиваешь каждой строке пустое значение, после того, как строка станет не нужна - за тебя это делает добрый Delphi-йский сборщик мусора, освобождая память, занимаемую строкой. И с интерфейсами тоже самое...

Игорь Шевченко © (23.06.08 01:16) [36]

>>Во-первых, это не сказки, сборщик мусора действительно добрый
Ну хорошо пусть будет добрый, но беспомощный он

>>программируя на delphi ты же не присваиваешь каждой строке пустое значение
Не много не правильный пример, если создал класс будь добр его уничтожить
>>И с интерфейсами тоже самое

Сборщик мусора не удаляет классы/интерфейсы на которые есть ссылки, если у двух обьектов по выходу из области видимости ссылки друг на друга, он(сборщик мусора) ничего не удалит.

На этот счет есть утилитка yourKit она показывает что не удалил сборщик.

> Не много не правильный пример, если создал класс будь добр
> его уничтожить
>

Почему, создал класс - забрал ресурсы, хотя бы память, вырастил динмассив - ту же память покушал. И счетчик ссылок у нее есть, как для GC.

> Сборщик мусора не удаляет классы/интерфейсы на которые есть
> ссылки, если у двух обьектов по выходу из области видимости
> ссылки друг на друга, он(сборщик мусора) ничего не удалит.
>

примерчик приветствуется

TUser © (23.06.08 09:38) [38]
Потому что Java обьектный язык и все там обьекты, простые типы это проклятый пережиток прошлого от которого так и не смогли избавиться, поскольку GC шуршит в поисках все время, он удаляет не все что ушло за область видимости, а только тех на кого нету ссылок. Естейственно если ты определиш

public void Foo(){
int a=0,b=765765765,c=1234567,d=3456778,e=2,f=2434564,h=11111;
}

то по выходу из зоны видимости GC шустро их удалит. Все обьекты(классы, интерфейсы) за тебя удалять он будет очень долго. Поэтому надо GC явно скзать: -"обьекты не нужны потри плзс". Иначе ты рискуеш забить память в течении 5 минут.

Конвертер Delphi -> Java Найти похожие ветки