Форум

Reshetov 02.04.2007 11:21 

Слухи про MQL5 уже распущены. Возникает естественный вопрос: а почему бы вместо того, чтобы изобретать велосипед, не сделать клиентскую часть MT на Java?

1. Java язык С подобный
2. Готовая реализация объектно-ориентированного программирования, а следовательно там будут и классы, события, обработчики исключительных ситуаций и прочие вкусности
   
3. Советники можно было бы сделать в виде подгружаемых модулей, написанный на Java
4. У Java богатые библиотеки готовых классов
5. Меньше будет глюков в билдах, ведь за Java следит консорциум разработчиков, и глюки фиксят намного быстрее.
6. Платформенная независимость. Многим, например, хотелось бы иметь торговый терминал под Linux.
7. Меньше было бы проблем с обращениями к разработчикам по поводу того, что сделайте то или сделайте это. Я бы, например, основную часть того, чего мне не хватает в торговой терминале, давно бы уже сделал сам. Например, удаленное управление советниками. Или событие по формированию нового бара.
   
8. Высокая скорость исполнения. JVM от Sun MicroSystems и IBM исполняют код гораздо быстрее, нежели если он был скомпилирован на C за счет JIT компиляции. Правда при этом запуск приложений длится дольше, поскольку перед ним весь Java перекомпилируется в код платформы на которой все будет исполняться.
9. Меньше было бы головной боли у разработчиков насчет распределения памяти, а особенно ее утечки. В Java память выделяется автоматически, как только создана переменная или объект. Зато обратный процесс, т.е. освобождение неиспользуемой памяти уже выполняется так называемым мусорщиком по мере необходимости или в фоновом режиме. Т.е. если переменные или объекты не используются и на них нет ни одной ссылки, то мусорщик автоматом все подчистит
10. Меньше проблем было бы с редактором советников и индикаторов. Например, я давно уже приспособил для MQL4 редактор JBuilder компании Borland. Ведь советники и индикаторы очень схожи с Java апплетами, т.е. имеют те же самые события init(), start() и deinit(). Алгоритмическая часть та же самая. Единственное различие лишь в том, что в Java переменные действительны в блоке, а в MQL в функции.
    

Могут возникнуть вопросы, относительно защиты программ, ведь Java очень запросто декомпилируется. Да в принципе и MQL тоже декомпилируется, насколько я убедился. Любой хакер скажет, что обход защиты - дело времени. Но обфускаторы для защиты кода от изучения в Java есть. Если необходимо будет защитить сам терминал от кражи интеллектуальной собственности другими разработчиками терминалов, то часть кода можно будет написать, например, на C и скомпилировать в native методы. Тогда появление такого кода в клиентской части конкурентов можно будет легко доказать, как кражу.

Renat 02.04.2007 15:14 

Пункт 8 убивает все. Имея скорость практически (не нужно теоретических тестов от производителей) в десяток раз медленнее нативного кода (С++) и потребление ресурсов практически также в десяток раз больше С++ можно ставить крест на любом коммерческом проекте. Ибо он безбожно проиграет конкуренту, написанном на нативном коде. К тому же, речь идет о серьезных вычислительных задачах с огромным потреблением ресурсов даже с С++. Речь о практических вещах, а не теоретических рассуждениях.

Чтобы убить коммерческий проект, достаточно перейти на Яву или .NET. Лучше такой совет дать нашим конкурентам.

alexjou 02.04.2007 15:43 

<<Чтобы убить коммерческий проект, достаточно перейти на Яву или .NET.>>
++
"Чтобы убить любой проект, ... "

Mathemat 02.04.2007 16:22 

Юрий, а ты видел софтину от Доктора Дука (dukascopy.com) где-нибудь с год-полтора назад? Одной из причин, по которой я игрался с ней в общей сложности не более двух недель, а потом забросил, стала именно ее тормознутость. А реализована она как раз на Java. Может быть, за это время что-то поменялось, но тогда скорость ее выполнения была крайне низкой в сравнении с продуктом от MQ.

KimIV 02.04.2007 19:11 

Ваще, не представляю, как на яве можно было бы реализовать тестер с потиковым моделированием или визуальный режим тестирования. Этот был бы, наверно, какой-нить тихий ужас! Нет, мне не надо ни яву, ни .net, MQL4 вполне устраивает. Очень нравится возможность подключения внешних DLL.

bstone 02.04.2007 21:15 

Ко всем негативным отзывам добавлю еще тот факт, что перевод клиента на яву повлек бы за собой убийственное требование к его пользователям: наличие установленной JVM. А это сразу куча проблем: добавление ее к дистрибутиву клиента утяжелит последний где-то на 25Мб; распространение клиента без JVM породит проблемы со скачиванием и установкой JVM по отдельности; усложнится процедура Live Update и т.д и т.п.

С таким же успехом можно было бы предложить перевести клиента с C++ на Smalltalk или Ruby - вот уж где есть разгуляться ООП; и библиотек тоже достаточно :)

Пишите свои вещи на Яве, никто вроде не мешает. Потом подключайте как внешнюю DLL и будет "счастье" :)

Кстати вот это утверждение:

Reshetov:
JVM от Sun MicroSystems и IBM исполняют код гораздо быстрее, нежели если он был скомпилирован на C за счет JIT компиляции

в корне неверно. Никакая JIT компиляция не может быть "гораздо быстрее" откомпилированного С/С++ кода. В лучшем (но очень маловероятном случае) такой код будет приближаться к производительности С/С++ кода. А косяки автоматической сборки "мусора" уж точно не следует выдавать за преимущества платформы. Для такой системы как MT прямое управление памятью настолько же важно, насколько и скорость обработки графической составляющей.