На десктопе оправданный подход. В энтерпрайз среде — нет. Когда приложение должно расширяться и поддерживаться десятки лет. Причем не переписыванием на новую платформу, когда она выйдет. Конечно, многие стремятся к SOA, чтобы интегрировать гетерогенные системы, но и всякие WS-* не недавно появились. Тот же SOAP появился 1998.
Hadoop запущенный на win остается java-приложением и к экосистеме .net не относится. В текущий момент он поддерживает win только как dev-платформу. То, что MS делает шаги в направлении запуска hadoop всего лишь означает, что она востребована.
С оптимизацией в java становится получше. Так что в некоторых областях она даже обгоняет плюсы. В частности засчёт того, что не гонится за оптимизацией всего. Тот же jit работает на тех функциях, которые вызываются чаще. И измерения производятся непрерывно при работе jvm.
Например, тот же lucene — это поисковые индексы. Штука довольно низкоуровневая (куча битовых операций, математики), высокопроизводительный поиск, чувствительная к io. Развивается, имеет большое сообщество. А стоит глянуть в сторону плюсов — глухо.
Так что в некоторой области java, c++ и с конкурентоспособны. В том числе, в области бэкендов. Особенно приятен управляемый код, когда надо мигрировать код и данные между различными нодами. Скорость разработки выше и сложность поддержки кода ниже на java чем на плюсах. И вместо дорогостоящего написания кода на c++ выбирают большее количество ресурсов. А при некоторых условиях на java горизонтальное масштабирование становится довольно дешевым.
В Java для приведения к более «узкому» типу необходимо явное приведение на этапе компиляции.
В случае type erasure проверка происходит на раннем этапе, при компиляции. Основные проблемы с generic-типами в этом случае при смешивании legacy кода (написанного под 1.4 или более раннюю jvm). Если я правильно помню, в JLS3 описаны причины такого решения при проектировании generic'ов. Такой вариант позволяет старому коду прозрачно взаимодействовать с новым (при условии, что старый код аккуратно работает с обновленными частями JRE).
То есть, если в legacy-код передать List<String>, а он запихает туда значение иного типа, то ошибка произойдет в рантайме. И это лучше, чем невозможность взаимодействовать со старым кодом вообще. Но приведение List к List<String> является небезопасной операцией, поэтому требует явного приведения типов и генерирует предпреждение, если не поставить аннотацию @SuppressWarnings(«unchecked»).
Бытует распространенное мнение, что generic'ов в рантайме нет. Это не так. Reflection позволяет вытащить некоторую информацию. Примеры можно смотреть в CDI-библиотеках.
Для REST-сервисов сейчас принято использовать аннотации JAX-RS, которым глубоко не важно, что Вы используете: Resteasy, Jersey, CXF или ещё что-либо. Struts, Spring, Seam и прочее даёт инфраструктуру (те же tx, security, persistence и т. д.).
Java будет жить ещё долго, особенно консервативная энтерпрайз среда. И переход с одной платформы может быть неоправдан (в смысле затрат времени, например). Особенно, если у Вас большой опыт на одной из них.
Очень важно среди рядовых работников иметь поддержку внедрения. Если довести работника до понимания того, что ваша система упростит ему жизнь, заинтересовать его, то будет:
а) Свой человек, который сможет дать быстрый фидбек до окончания внедрения (а ему дальше с этим работать, он заинтересован в улучшении и «допилке» системы). Это позволит сильно снизить сопротивление внедрению, т. к. конечные пользователи будут видеть, что работа ведется не ради красивых графиков руководства, но и ради повышения их производительности. А увеличение вовлечения пользователей очень полезно.
б) «Первая линия» техподдержки средствами заказчика. Пользователям зачастую проще спросить своего коллегу, чем использовать формальную процедуру взаимодействия с техподдержкой или разбираться с документацией.
Там по крайней мере, в презентацию прописываются относительные пути, рядом складываются медиа-файлы, ембидятся шрифты и проч. А просмотрщиком может выступать LO/OO.
Например, тот же lucene — это поисковые индексы. Штука довольно низкоуровневая (куча битовых операций, математики), высокопроизводительный поиск, чувствительная к io. Развивается, имеет большое сообщество. А стоит глянуть в сторону плюсов — глухо.
Так что в некоторой области java, c++ и с конкурентоспособны. В том числе, в области бэкендов. Особенно приятен управляемый код, когда надо мигрировать код и данные между различными нодами. Скорость разработки выше и сложность поддержки кода ниже на java чем на плюсах. И вместо дорогостоящего написания кода на c++ выбирают большее количество ресурсов. А при некоторых условиях на java горизонтальное масштабирование становится довольно дешевым.
В случае type erasure проверка происходит на раннем этапе, при компиляции. Основные проблемы с generic-типами в этом случае при смешивании legacy кода (написанного под 1.4 или более раннюю jvm). Если я правильно помню, в JLS3 описаны причины такого решения при проектировании generic'ов. Такой вариант позволяет старому коду прозрачно взаимодействовать с новым (при условии, что старый код аккуратно работает с обновленными частями JRE).
То есть, если в legacy-код передать List<String>, а он запихает туда значение иного типа, то ошибка произойдет в рантайме. И это лучше, чем невозможность взаимодействовать со старым кодом вообще. Но приведение List к List<String> является небезопасной операцией, поэтому требует явного приведения типов и генерирует предпреждение, если не поставить аннотацию @SuppressWarnings(«unchecked»).
Бытует распространенное мнение, что generic'ов в рантайме нет. Это не так. Reflection позволяет вытащить некоторую информацию. Примеры можно смотреть в CDI-библиотеках.
Очень важно среди рядовых работников иметь поддержку внедрения. Если довести работника до понимания того, что ваша система упростит ему жизнь, заинтересовать его, то будет:
а) Свой человек, который сможет дать быстрый фидбек до окончания внедрения (а ему дальше с этим работать, он заинтересован в улучшении и «допилке» системы). Это позволит сильно снизить сопротивление внедрению, т. к. конечные пользователи будут видеть, что работа ведется не ради красивых графиков руководства, но и ради повышения их производительности. А увеличение вовлечения пользователей очень полезно.
б) «Первая линия» техподдержки средствами заказчика. Пользователям зачастую проще спросить своего коллегу, чем использовать формальную процедуру взаимодействия с техподдержкой или разбираться с документацией.