Разработчики С#, изучающие Java, каковы самые большие различия, которые можно игнорировать?

Для разработчиков С#, которые ищут возможность изучать Java, существуют ли какие-либо существенные различия между двумя языками, которые должны быть указаны?

Возможно, некоторые люди могут считать вещи одинаковыми, но есть некоторые аспекты импорта, которые нельзя игнорировать? (или вы действительно можете испортить!)

Возможно, с точки зрения конструкций ООП, способ работы GC, ссылки, связанные с развертыванием и т.д.

Ответ 1

Несколько голов от головы:

  • Java не имеет пользовательских типов значений (structs), поэтому не беспокойтесь о них.
  • Перечисления Java очень сильно отличаются от подхода с именами номеров С#; они больше OO. Их можно использовать для большого эффекта, если вы будете осторожны.
  • byte подписан на Java (к сожалению)
  • В С# инициализаторы переменных экземпляра запускаются до конструктора базового класса; в Java они запускаются после его выполнения (т.е. непосредственно перед телом конструктора в классе "this")
  • В С# методы по умолчанию закрыты. В Java они по умолчанию виртуальны.
  • Модификатор доступа по умолчанию в С# всегда "самый ограничительный доступ, доступный в текущем контексте"; в Java это "пакетный" доступ. (Это стоит прочитать на конкретных модификаторах доступа в Java.)
  • Вложенные типы в Java и С# работают несколько иначе; в частности, они имеют разные ограничения доступа, и если вы не объявите вложенный тип static, он будет иметь неявную ссылку на экземпляр содержащего класса.

Ответ 3

Я удивлен, что никто не упомянул свойства, что-то совершенно фундаментальное в С#, но отсутствует в Java. С# 3 и выше также автоматически реализовали свойства. В Java вы должны использовать методы типа GetX/SetX.

Еще одно очевидное отличие - это выражения LINQ и лямбда в С# 3, отсутствующие в Java.

Есть несколько других простых, но полезных вещей, отсутствующих в Java, таких как строки verbatim (@"), перегрузка операторов, итераторы с использованием выходных и предварительных процессоров также отсутствуют на Java.

Один из моих личных фаворитов на С# - это то, что имена пространства имен не должны следовать структуре физического каталога. Мне очень нравится эта гибкость.

Ответ 4

Есть много различий, но они приходят мне в голову:

  • Отсутствие перегрузки оператора в Java. Просмотрите свой экземпляр. Эквалайзер (экземпляр2) по сравнению с экземпляром == instance2 (особенно с строками).
  • Используется для интерфейсов, не имеющих префикса с I. Часто вы видите пространства имен или классы, суффиксы с Impl вместо.
  • Двойная проверка блокировки не работает из-за модели памяти Java.
  • Вы можете импортировать статические методы без их префикса с именем класса, что очень полезно в некоторых случаях (DSL).
  • Операторы Switch в Java не требуют по умолчанию, и вы не можете использовать строки в качестве ярлыков case (IIRC).
  • Генераторы Java будут вас раздражать. Генераторы Java не существуют во время выполнения (по крайней мере, в 1.5), это трюк компилятора, который вызывает проблемы, если вы хотите отразить общие типы.

Ответ 5

.NET обновил дженерики; Java стирает дженерики.

Разница заключается в следующем: если у вас есть объект ArrayList<String>, в .NET вы можете указать (во время выполнения), что объект имеет тип ArrayList<String>, тогда как в Java во время выполнения объект имеет тип ArrayList; часть String теряется. Если вы помещаете объекты String в ArrayList, система не может обеспечить это, и вы узнаете об этом только после того, как попытаетесь извлечь этот элемент из списка, и сбой выполнения.

Ответ 6

Одна вещь, которую я пропускаю на С# с Java, - это принудительная обработка проверенных исключений. В С# это очень распространено, что никто не знает об исключениях, которые может бросить метод, и вы находитесь во власти документации или тестирования, чтобы обнаружить их. Не так в Java с проверенными исключениями.

Ответ 7

Нет делегатов или событий - вам нужно использовать интерфейсы. К счастью, вы можете создавать классы и реализации интерфейса внутри, поэтому это не так уж и важно.

Ответ 8

Java имеет автобоксинг для примитивов, а не типов значений, поэтому, хотя System.Int32[] представляет собой массив значений в С#, Integer[] представляет собой массив ссылок на объекты Integer и, как таковой, не подходит для более высоких вычислений производительности.

Ответ 9

Встроенная функция даты/календаря в Java ужасна по сравнению с System.DateTime. Здесь много информации об этом: Что случилось с API дат и времени Java?

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

  • Класс Java Date изменен, что может привести к тому, что даты возврата и передачи даты будут опасными.
  • Большинство конструкторов java.util.Date устарели. Просто создание экземпляра даты довольно многословно.
  • Я никогда не получал класс java.util.Date, чтобы хорошо взаимодействовать с веб-службами. В большинстве случаев даты с обеих сторон дико трансформировались в другие даты и время.

Кроме того, Java не имеет всех тех же функций, что и GAC и сильно названные сборки. Jar Hell - это термин, который может ошибиться при связывании/ссылках на внешние библиотеки.

Что касается упаковки/развертывания:

  • может быть сложно упаковать веб-приложения в формате EAR/WAR, которые фактически устанавливаются и запускаются на нескольких серверах приложений (Glassfish, Websphere и т.д.).
  • развертывание вашего Java-приложения в качестве службы Windows требует гораздо больших усилий, чем на С#. Большинство рекомендаций, которые я получил для этого, включали несвободную стороннюю библиотеку. Конфигурация приложения
  • не так проста, как включение файла app.config в ваш проект. Существует класс java.util.Properties, но он не такой надежный и нахождение подходящего места для удаления вашего файла .properties может запутать.

Ответ 10

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

Ответ 11

Одна вещь, которая выпрыгивает из b/c в моем списке интервью, заключается в том, что в Java нет "нового" аналога ключевых слов для скрытия метода, и поэтому нет предупреждения о компиляторе "вы должны поместить здесь новое". Случайный метод, скрывающийся, когда вы хотели переопределить, приводит к ошибкам.

(например, редактировать) Пример: B происходит от A (используя синтаксис С#, Java ведет себя так же, как и последний, я проверил, но не выдал предупреждение о компиляторе). Вызывается ли foo или B foo? (A получает вызов, вероятно, удивляет разработчика, который реализовал B).

class A 
{
public void foo() {code}
}

class B:A
{
public void foo() {code}
}    

void SomeMethod()
{
A a = new B(); // variable type is declared as A, but assigned to an object of B.
a.foo();
}

Ответ 12

Java не имеет LINQ, а документация - ад. Пользовательские интерфейсы на Java - это боль, чтобы развиваться, вы теряете все хорошие вещи, которые Microsoft дала нам (WPF, WCF и т.д.), Но получили труднодоступные, едва документированные "API".

Ответ 13

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

Например, вы не можете поймать ошибку из памяти с помощью catch (Исключение e).

Подробнее см. ниже:

why-is-java-lang-outofmemoryerror-java-heap-space-not-caught

Ответ 14

Это было так давно, как я был на Java, но те вещи, которые я сразу заметил с точки зрения разработки приложений, - это модель событий С#, перетаскивание с помощью С# и использование менеджеров макетов в Swing (если вы делаете App dev) и обработки исключений с Java, убедившись, что вы поймаете исключение, а С# не требуется.

Ответ 15

Самая неприятная разница для меня, когда я переключаю на java это объявление строки.

в С# string (большую часть времени) в Java string

Это довольно просто, но поверьте мне, это заставляет вас терять так много времени, когда у вас есть привычка s not s!

Ответ 16

В ответ на ваш очень прямой вопрос в вашем названии:

"Разработчики С#, изучающие Java, какие самые большие различия можно игнорировать?"

A: факт, что Java значительно медленнее в Windows.