Комментарии 12
Меня в java все время смущало "high performance". При этом я привык под этим словом подразумевать возможность выжимать максимум из железа, Например, сделать вычисления на GPU или сделать невыгружаемую в своп всегда доступную страницу памяти, чтобы обращение к ней всегда было максимально быстрым.
Просто, раз уж тут базы данных упомянуты — у меня был опыт, когда некое построение бухгалтерских отчетов типа P&L было сделано изначально на языке типа PL/SQL (T/SQL) внутри СУБД, а потом перенесено на Java в небольшой кластер. Ускорение было на несколько порядков (пять минут вместо нескольких часов, причем эти минуты были заняты вводом-выводом).
А GPU кстати из Java давно можно, чего тут такого-то?
a little high )))
До сих пор не пойму сколько тактов требуется на самую частую операцию -- на адресацию объекта. Изза того, что объект может перемещаться по памяти, то могут быть дополнительные расходы. Джависты даже вопроса не понимают к сожалению.
Ну… для языка (с другой архитектурой команд), который транслируется в выполняемые команды реального процессора в рантайме, т.е. на лету, вы хотите слишком многого. Тут может быть куча дополнительных расходов, начиная с того же GC, и кончая JIT, который само собой тоже процессор кушает, кудаж он денется? О тактах тут можно говорить разве что в среднем.
А у меня в Связьинвест был опыт переработки бухгалтерского отчета написанного на PL/SQL - он работал более 12 часов и падал с segmentation fault. Отчет должен был получить из базы данные и построить в зависимости от параметров отчета по тому или иному региону в формате Excel. То есть падал на одном филиале. Хорошо что был документ с изначальными требованиями, и я не "исправил", а написал заново этот отчет. В итоге он работал 3 минуты по всем регионам, если регион не был выбран, формировал Excel-файл с содержимом на первом листе и кучей листов с данными по каждому из регионов и если на этих листах кликнуть в ячейку A1, то попадал на первую страницу с содержимым. Также можно было запустить на печать весь файл по всем регионам вместо формирования файла по каждому региону и его отдельного запуска. К чему это я? К тому, что многое зависит не от языка программирования, а от того как его применяют. Потому что быстрее SQL для работы с данными реляционных баз еще ничего не придумано. А Java - хороший язык и особенно технология, на котором много написано легаси и работы хватит всем. Но все же лучше смотреть на Kotlin и Scala.
Параметры передаются по ссылке
Параметры в java всегда передаются по значению. Просто не стоит забывать, что значением объектных типов является ссылка.
Как человек, который не так давно работает с платформой (Java), считаю нужным добавить информацию о следующих возможностях JVM, которая нужна для реальной разработки (а не просто для выполнения учебных проектов), и которую почему-то не сразу рассказывают "новичкам", возможно, считая, что для них это будет "слишком сложно":
remote debugging, когда JVM запускается не на той машине, на которой ведется разработка
hot code reload (с помощью jdb redefine), что позволяет заменить часть байт-кода (обычно класс или несколько классов) без остановки JVM
возможность дропнуть фрейм в отладчике, что позволяет многократно возвращаться на одну и ту же точку останова без перезапуска всего отладочного сценария
Все это, может быть, не требуется для выполнения простых задач или учебных проектов, но в системах промышленного размера без использования этих возможностей разрабатывать будет очень тяжело.
IntelliJ Idea поддерживает эти возможности прекрасно, и подсказывает, что для запуска JVM в режиме, когда к ней можно подключаться для удаленной отладки, надо добавить в командную строку для ее запуска что-то вроде
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777
Собственно, после подключения к remote JVM отладчик и hot code reload (он срабатывает по команде Build project, Ctrl-F9) начинают работать автоматически.
Кроме того, в стандартной JVM возможности по горячей замене ограничены: можно поменять лишь реализацию метода. Если использовать модифицированную JVM из проекта DCEVM, то можно еще "на горячую" заменять и удалять методы, и вроде бы даже модифицировать интерфейсы.
В самом же языке мне кажутся сравнительно сложными области, связанные с дженериками (по ним есть мега-FAQ от Ангелики Лангер), и еще с помощью аннотаций+рефлексии можно нагородить непонятных конструкций. Наличие же лямбд считаю однозначным плюсом.
Ещё есть отличная книга, которая помогла мне намного лучше понять дженерики:
Java Generics and Collections / Maurice Naftalin and Philip Wadler;
Всё о чём вы написали есть как в Delphi так и в самой среде. Всё целиком. И атрибуты и ОРМки и дженерики. Только что простые типы - это простые типы, а не классы.
В остальном в Delphi всё то же ООП с максимальным его покрытием (по мимо множественного наследования, что решается интерфейсами).
Так что отличия тут лишь в некоторых специфических принципах (например, типах) и в синтаксисе. Ну и конечно синтаксическом сахаре, который лего можно повторить и в делфи.
Ни в коей мере не хотел сказать, что Delphi чем-то плох. Мой опыт работы на Delphi заканчивается где-то в начале нулевых. Тогда мы не знали ни про ОРМ ни про дженерики. Во всех проектах, с которыми я сталкивался, ООП использовалось только потому что оно должно было использоваться. Например, чтоб создать объект. Никто не писал бизнес-логику с использованием ООП. Для этого замечательно подходил процедурный подход.
Но, прогресс не стоит на месте. Вполне допускаю, что Delphi развился достаточно хорошо с того времени, и разработчики поменяли свое мировоззрение.
Из Oracle в Java. Личный опыт