Los desarrolladores de C # que están aprendiendo Java, ¿cuáles son las mayores diferencias que uno puede pasar por alto? [cerrado]

Para los desarrolladores de C # que quieren aprender Java, ¿hay grandes diferencias subyacentes entre los dos lenguajes que deberían ser señaladas?

Quizás algunas personas asuman que las cosas son iguales, pero ¿hay algunos aspectos importantes que no deben pasarse por alto? (¡O realmente puedes arruinarlo!)

Tal vez en términos de construcciones de OOP, la forma en que funciona GC, referencias, implementación relacionada, etc.

Algunas trampas de mi cabeza:

• Java no tiene tipos de valores personalizados (estructuras), así que no se moleste en buscarlos
• Las enumeraciones de Java son muy diferentes al enfoque de "números con nombre" de C #; son más OO. Pueden usarse con gran efecto, si tiene cuidado.
• byte está firmado en Java (desafortunadamente)
• En C #, los inicializadores de variables de instancia se ejecutan antes que el constructor de la clase base; en Java se ejecutan después (es decir, justo antes del cuerpo del constructor en "esta" clase)
• En C #, los métodos están sellados de forma predeterminada. En Java, son virtuales de forma predeterminada.
• El modificador de acceso predeterminado en C # es siempre "el acceso más restrictivo disponible en el contexto actual"; en Java es el acceso al "paquete". (Vale la pena leer sobre los modificadores de acceso particulares en Java).
• Los tipos anidados en Java y C # funcionan de manera algo diferente; en particular, tienen diferentes restricciones de acceso y, a menos que declare que el tipo anidado static, tendrá una referencia implícita a una instancia de la clase contenedora.

aquí hay una comparación muy completa de los 2 idiomas:

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

Añadido: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp

Me sorprende que nadie haya mencionado propiedades, algo bastante fundamental en C # pero ausente en Java. C # 3 y superior también ha implementado propiedades automáticamente. En Java tienes que usar métodos de tipo GetX / SetX.

Otra diferencia obvia son las expresiones LINQ y lambda en C # 3 ausentes en Java.

Hay algunas otras cosas simples pero útiles que faltan en Java como cadenas textuales (@ ""), sobrecarga de operadores, iteradores que usan rendimiento y preprocesador que también faltan en Java.

Uno de mis favoritos personales en C # es que los nombres de los espacios de nombres no tienen que seguir la estructura del directorio físico. Realmente me gusta esta flexibilidad.

Hay muchas diferencias, pero estas me vienen a la mente:

• Falta de sobrecarga de operadores en Java. Mire su instancia Igual (instancia2) versus instancia == instancia2 (especialmente con cadenas).
• Acostúmbrese a que las interfaces NO tengan el prefijo I. A menudo, verá espacios de nombres o clases con el sufijo Impl.
• El bloqueo comprobado dos veces no funciona debido al modelo de memoria de Java.
• Puede importar métodos estáticos sin prefijarlos con el nombre de la clase, lo cual es muy útil en ciertos casos (DSL).
• Las declaraciones de cambio en Java no requieren un valor predeterminado y no puede usar cadenas como etiquetas de caso (IIRC).
• Los genéricos de Java te enfurecerán. Los genéricos de Java no existen en tiempo de ejecución (al menos en 1.5), son un truco del compilador, lo que causa problemas si desea hacer una reflexión sobre los tipos genéricos.

.NET tiene genéricos reificados; Java ha borrado los genéricos.

La diferencia es la siguiente: si tiene un ArrayList<String>objeto, en .NET, puede decir (en tiempo de ejecución) que el objeto tiene tipo ArrayList<String>, mientras que en Java, en tiempo de ejecución, el objeto es de tipo ArrayList; la Stringparte se pierde. Si ingresa no Stringobjetos en el ArrayList, el sistema no puede hacer cumplir eso, y solo lo sabrá después de que intente extraer el elemento y el lanzamiento falle.

Una cosa que extraño en C # de Java es el manejo forzado de excepciones marcadas. En C #, ¿es demasiado común que uno desconozca las excepciones que puede generar un método y que esté a merced de la documentación o las pruebas para descubrirlas? No es así en Java con excepciones marcadas.

Java tiene autoboxing para primitivas en lugar de tipos de valor, por lo que, aunque System.Int32[]es una matriz de valores en C #, Integer[]es una matriz de referencias a Integerobjetos y, como tal, no es adecuada para cálculos de mayor rendimiento.

Sin delegados ni eventos, debe usar interfaces. Afortunadamente, puede crear clases e implementaciones de interfaz en línea, por lo que esto no es tan importante.

La funcionalidad de fecha / calendario incorporada en Java es horrible en comparación con System.DateTime. Hay mucha información sobre esto aquí: ¿Qué pasa con la API de fecha y hora de Java?

Algunos de estos pueden ser trucos para un desarrollador de C #:

• La clase Java Date es mutable, lo que puede hacer que la devolución y el paso de fechas sean peligrosas.
• La mayoría de los constructores java.util.Date están en desuso. Simplemente instanciar una cita es bastante detallado.
• Nunca he conseguido que la clase java.util.Date interopere bien con los servicios web. En la mayoría de los casos, las fechas de ambos lados se transformaron enormemente en otra fecha y hora.

Además, Java no tiene todas las mismas características que traen el GAC y los ensamblados con nombre seguro. Jar Hell es el término para lo que puede salir mal al vincular / hacer referencia a bibliotecas externas.

En lo que respecta al empaquetado / implementación:

• Puede resultar difícil empaquetar aplicaciones web en un formato EAR / WAR que realmente se instalen y ejecuten en varios servidores de aplicaciones diferentes (Glassfish, Websphere, etc.).
• implementar su aplicación Java como un servicio de Windows requiere mucho más esfuerzo que en C #. La mayoría de las recomendaciones que recibí para esto involucraron una biblioteca de terceros no gratuita
• La configuración de la aplicación no es tan fácil como incluir un archivo app.config en su proyecto. Existe una clase java.util.Properties, pero no es tan robusta y encontrar el lugar correcto para soltar su archivo .properties puede ser confuso

No hay delegados en Java. Por lo tanto, además de todos los beneficios que aportan los delegados, los eventos también funcionan de manera diferente. En lugar de simplemente conectar un método, debe implementar una interfaz y adjuntarla.

Una cosa que resalta porque está en mi lista de entrevistas es que no hay una "nueva" palabra clave análoga en Java para ocultar métodos y, por lo tanto, ningún compilador advierte "debería poner una nueva aquí". La ocultación accidental del método cuando se pretendía anular conduce a errores.

(editar, por ejemplo) Ejemplo, B deriva de A (usando la sintaxis C #, Java se comporta de la misma manera que la última vez que verifiqué, pero no emite una advertencia del compilador). ¿Se llama al foo de A o al foo de B? (Se llama a A, probablemente sorprendiendo al desarrollador que implementó 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 no tiene LINQ y la documentación es un infierno. Las interfaces de usuario en Java son difíciles de desarrollar, se pierden todas las cosas buenas que nos dio Microsoft (WPF, WCF, etc.) pero se vuelven "API" difíciles de usar y apenas documentadas.

El único problema con el que me he encontrado hasta ahora al trabajar con Java procedente de C # son las excepciones y los errores son diferentes.

Por ejemplo, no puede detectar un error de memoria insuficiente utilizando catch (Excepción e).

Consulte lo siguiente para obtener más detalles:

¿Por qué-es-java-lang-outofmemoryerror-java-heap-space-not-capturado

Ha pasado tanto tiempo desde que estoy en Java, pero las cosas que noté desde el principio en el desarrollo de aplicaciones fueron el modelo de eventos C #, C # arrastrar y soltar frente al uso de Layout Managers en Swing (si está haciendo App Dev) y el manejo de excepciones Java asegurándose de detectar una excepción y C # no es necesario.

En respuesta a su pregunta muy directa en su título:

"Los desarrolladores de C # que están aprendiendo Java, ¿cuáles son las mayores diferencias que uno puede pasar por alto?"

R: El hecho de que Java es considerablemente más lento en Windows.

La diferencia más molesta para mí cuando cambio a Java es la declaración de cadena.

en C # string(la mayor parte del tiempo) en JavaString

Es bastante simple, pero créeme, ¡te hace perder tanto tiempo cuando tienes el hábito de sno hacerlo S!