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

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

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

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

вот очень полное сравнение 2 языков:

http://www.25hoursaday.com/CsharpVsJava.html

Добавлено: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp

] Прошло столько времени с тех пор, как я работал на Java, но я сразу же заметил в разработке приложений C# event model, C# drag and drop vs using Layout Managers in Swing (если вы делаете App dev), и обработку исключений с помощью Java, чтобы убедиться, что вы поймали исключение и C# не требуется.[

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

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

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

]Смотрите следующие подробности:[

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

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

] [
• ]Отсутствие перегрузки оператора в Java. Смотрите instance.Equals(instance2) против instance== instance2 (особенно w/strings).[
] [
• ]Привыкайте к тому, что интерфейсы НЕ префиксуются с I. Часто вместо этого вы видите пространства имен или классы, суффиксованные с Impl.[
] [
• ]Блокировка двойной проверки не работает из-за модели памяти Java. [
] [
• ]Вы можете импортировать статические методы без префиксации с именем класса, что очень полезно в некоторых случаях (DSL).[
] [
• ]Операторы переключения в Java не требуют умолчаний, и вы не можете использовать строки в качестве регистровых меток (IIRC).[
] [
• ]Java генерики разозлят вас. Java дженериков не существует во время выполнения (по крайней мере, в 1.5), это трюк компилятора, который вызывает проблемы, если Вы хотите сделать размышления о типах дженериков. [
] [

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

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

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

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

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

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

в C# string (в большинстве случаев). на Java String

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

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

Некоторые из них могут быть получены разработчиком на C#:

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

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

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

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

Удивительно, что никто не упомянул свойства, что-то весьма фундаментальное на C#, но отсутствующее на Java. На C# 3 и выше свойства реализованы автоматически. В Java необходимо использовать методы типа GetX/SetX.

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

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

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

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

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

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

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

«Разработчики C #, изучающие Java, какие самые большие различия можно упустить?»

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