C# против дженериков Java

Разница заключается в дизайнерском решении Microsoft и Sun.

Дженерики в Java реализуется компилятором через стирание типа, что означает, что проверка типа происходит во время компиляции, а информация о типе удаляется. Этот подход был использован для сохранения совместимости устаревшего кода с новым кодом, использующим обобщения:

Из Руководства по Java, Обобщения: Стирание типа:

When a generic type is instantiated, the compiler translates those types by a technique called type erasure — a process where the compiler removes all information related to type parameters and type arguments within a class or method. Type erasure enables Java applications that use generics to maintain binary compatibility with Java libraries and applications that were created before generics.

Однако с дженерики в C# (.NET) компилятор не стирает типы, и проверки типов выполняются во время выполнения. Это имеет свои преимущества в том, что информация о типе сохраняется в скомпилированном коде.

Из Википедии:

This design choice is leveraged to provide additional functionality, such as allowing reflection with preservation of generic types, as well as alleviating some of the limitations of erasure (such as being unable to create generic arrays). This also means that there is no performance hit from runtime casts and normally expensive boxing conversions.

Вместо того, чтобы говорить «дженерики .NET лучше, чем дженерики Java», следует изучить разницу в подходах к реализации дженериков. В Java кажется, что сохранение совместимости было высоким приоритетом, тогда как в .NET (когда он был представлен в версии 2.0) реализация всех преимуществ использования дженериков была более приоритетной.

ссылка Стрелокси отлично справляется с устранением различий. Краткое и грязное резюме ...

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

Однако самая большая разница заключается в реализации.

Java использует понятие стирания типов для реализации универсальных шаблонов. Короче говоря, базовые скомпилированные классы на самом деле не являются универсальными. Они компилируются до Object и преобразуются. По сути, универсальные шаблоны Java являются артефактом времени компиляции и могут быть легко разрушены во время выполнения.

C#, с другой стороны, благодаря CLR реализует универсальные шаблоны вплоть до байтового кода. В CLR было внесено несколько критических изменений для поддержки дженериков в 2.0. Преимущества заключаются в улучшении производительности, глубокой проверке безопасности типов и отражении.

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

Также нашел разговор это с Андерсом Хейлсбергом, который тоже может быть интересным. Подытоживая замечания, сделанные Андерсом Хейлсбергом, с некоторыми дополнительными замечаниями: Дженерики Java были созданы для максимальной совместимости с существующей JVM., который привел к нескольким странным вещам по сравнению с реализацией, которую вы видите на C#:

• Стирание типа заставляет реализацию представлять каждое общее параметризованное значение как Object. В то время как компилятор обеспечивает автоматическое преобразование между Object и более конкретным типом, это не снимает негативного влияния типов забросов и бокса на работоспособность (например, Object приводится к конкретному типу MyClass или int должен быть упакован в Integer, что было бы еще более серьезным для C# /. NET, если бы они следовали подходу стирания типов из-за в определяемые пользователем типы значений). Как сказал Андерс: «вы не получаете никакой эффективности выполнения» (в C# включены обобщенные дженерики)

• Стирание типа делает информацию доступной во время компиляции, недоступной во время выполнения. То, что раньше было List<Integer>, становится просто List без возможности восстановления параметра универсального типа во время выполнения. Это затрудняет построение сценариев отражения или динамической генерации кода на основе универсальных шаблонов Java. Более свежий ТАК ответ показывает способ обойти это через анонимные классы. Но без уловок что-то вроде генерации кода во время выполнения через отражение, которое получает элементы из одного экземпляра коллекции и помещает их в другой экземпляр коллекции, может дать сбой во время выполнения во время выполнения динамически сгенерированного кода: отражение не помогает отловить несоответствие в List<Double> по сравнению с List<Integer> в эти ситуации.

Но +1 за ответ со ссылкой на Сообщение блога Джонатана Прайора.