Acaba de comenzar un nuevo proyecto y tiene estas dos tecnologías para elegir, Java y .NET. El proyecto que está trabajando no implica tener características que faciliten la elección entre las dos tecnologías (por ejemplo, .NET tiene esto que necesito y Java no) y ambas deberían funcionar bien para usted (aunque usted solo Necesito uno, por supuesto). Tener en cuenta:
- Actuación
- Herramientas disponibles (incluso herramientas de terceros)
- Compatibilidad multiplataforma
- Bibliotecas (especialmente bibliotecas de terceros)
- Costo (Oracle parece intentar monetizar Java)
- Proceso de desarrollo (más fácil / más rápido)
También tenga en cuenta que Linux no es su plataforma principal, pero también le gustaría portar su proyecto a Linux / MacOs. Definitivamente, debe tener en cuenta el problema que ha estado girando en torno a Oracle y la comunidad de Java y las limitaciones de Mono y Java también. Sería muy apreciado si las personas con experiencia en ambos pueden dar una visión general y su propia visión subjetiva sobre cuál elegirían y por qué.
Respuestas:
La decisión más importante (editar: técnica) es:
Si no, entonces debería ir con Java.
La conclusión de Mono se usa con frecuencia para decir "Sí, .NET es multiplataforma". ¿Cuán válido es ese reclamo? fue que Mono es solo una opción IFF que desarrolles en contra de ella!
No puede esperar que las aplicaciones .NET funcionen de fábrica.
@Basic dijo que esto era más un comentario que una respuesta. Para ser precisos, considero que es una cuestión ir al principio de la lista, porque esta es quizás la decisión técnica más importante que debe tomar cuando se trata de .NET. Como dice Basic, probará contra Mono, entonces eso está fuera del camino, y consideraría que Java y .NET son bastante adecuados. Tengo muy poca experiencia con .NET, pero bastante en Java.
Rendimiento: Java funciona bastante bien, pero todavía tiene bastante tiempo de inicio. Esto se debe a que una JVM comienza desde cero cuando se inicializa, y el acceso aleatorio del archivo jar de la biblioteca en tiempo de ejecución es bastante lento cuando es necesario leerlo desde el disco. Los Java 6 recientes tienen un proceso en segundo plano para tratar de mantener los archivos jar de la biblioteca en tiempo de ejecución en la caché del disco para que el acceso sea rápido cuando sea necesario.
Herramientas disponibles. Existen muchas herramientas, y hay muchas disponibles como código abierto de alta calidad. IBM tiene algunas herramientas muy avanzadas disponibles, pero también requieren bastante dinero para ellas. Es posible que desee echar un vistazo a MyEclipse, que se gana la vida reuniendo las mejores partes del mundo de Java y hacerlas accesibles por un bajo costo, para ver qué hay disponible. Netbeans tiene un editor GUI muy agradable. JDeveloper tiene un buen depurador Swing. El Sun 6 JDK tiene VisualVM, que es un buen generador de perfiles de nivel de entrada que puede analizar programas que ya se están ejecutando (que es una característica excelente).
Compatibilidad multiplataforma. Muy bueno, tendiente a excelente. La JVM es muy, muy confiable y predecible. Los problemas solo se muestran cuando las diferencias del sistema operativo se filtran, como separadores de archivos, mayúsculas y minúsculas y comportamiento del menú.
Bibliotecas Hay muchos y muchos de ellos están disponibles y son de uso gratuito, pero están escritos principalmente en Java, ya que es bastante difícil extraer código escrito en lenguajes que no son JVM.
Costo. Java está básicamente disponible gratuitamente. Lo que Oracle está indicando es que las herramientas eléctricas, probablemente provenientes de JRocket, tendrán un costo. También tenga en cuenta que el soporte ampliado ("Java for Business") también tiene un precio. Las plataformas que no son x86 son una especie en extinción, pero IBM tiene mucho e IBM les proporciona una excelente implementación de Java. Esto tiene un precio como parte del sistema operativo, muy probablemente para una mejor adopción.
Proceso de desarrollo. Se pasa mucho tiempo con Java investigando y eligiendo la tecnología adecuada y aprendiéndola, pero cuando eso se hace, creo que hay muchas tecnologías con las que es bastante rápido desarrollarse. La última versión de Java EE permite escribir páginas web muy potentes utilizando Facelets que pueden recargarse al menos tan rápido como las páginas PHP.
Creo que a menos que usted no es experto en ninguno de Java o .NET, se ahorrará tiempo y dinero mediante la elección de la tecnología usted y su organización son los más familiarizados.
fuente
OK, intentemos analizar esto:
Tanto las plataformas Java como .NET tienen muchas buenas herramientas de prueba de rendimiento disponibles, sé que en el espacio Java hay muchas herramientas gratuitas de código abierto que son adecuadas para la mayoría de los escenarios. No puedo hablar por el lado de .NET.
Java tiene una ventaja aquí: se requiere el proyecto Mono (o similar) para que .NET se ejecute en algunas plataformas. No estoy seguro de que Mono sea 100% a prueba de balas y de rendimiento, algo que espero que alguien más pueda intervenir.
Ambos tienen un fuerte apoyo aquí. Inicialmente, el ecosistema Java lideró el camino (hay literalmente una biblioteca de código abierto gratuita para casi cualquier cosa que se te ocurra), pero diría que .NET ciertamente se ha puesto al día donde importa (NHiberante para persistencia, NUnit para pruebas unitarias para nombrar dos básicos + estoy seguro de que hay un camión métrico cargado más).
Todas las empresas intentan monetizar hasta cierto punto, pero en el caso de Java, creo que su declaración es un poco engañosa. Java fue de código abierto a partir de la versión 6 (el proyecto OpenJDK) y Oracle no ha mostrado ninguna inclinación a monetizar Java más allá de lo que Sun estaba haciendo. Entonces, sí, venden servidores de aplicaciones y extensiones a la JVM (extensiones de administración en particular), pero ¿el núcleo de Java en sí? No, y nunca lo harán (esto se ha dicho públicamente muchas veces).
Creo que tanto MS como Oracle se benefician enormemente debido a los ingresos indirectos con sus respectivas plataformas.
Costo total de propiedad (TCO)? Ni siquiera voy a entrar en este debate ya que no hay forma de probarlo (la programación es una actividad humana creativa después de todo). Personalmente, creo que los sistemas basados en Java tienden a tener un costo inicial más bajo, ya que puede utilizar una pila de código abierto de arriba a abajo en la mayoría de los casos. Sin embargo, las grandes empresas tienden a preferir tener contratos de soporte para anular ese beneficio particular.
Depende de lo que intentes construir. Yo personalmente argumentaría que son bastante parejos, aunque C # tiene algunas características adicionales en el lenguaje central sobre Java en este momento. Sin embargo, con lenguajes (múltiples interoperables con Java) en la JVM (Groovy, Scala, Clojure, etc.) puede tener todas las características de idioma que desee.
.NET tuvo una clara ventaja para construir 'cosas' de front-end web por un tiempo (desarrollo rápido de aplicaciones, por así decirlo), pero creo que JEE6 y / o Spring y otros frameworks web / de aplicaciones prácticamente han cerrado esa brecha.
Si desea portar a Linux, UNIX y en particular a Mac OS, como se indicó anteriormente, Java tiene una ventaja allí.
¡Espero que ayude!
fuente
Teniendo en cuenta su lista de puntos, estaría dividido y realmente dependería de lo que necesite construir.
.Net gana por estos aspectos:
Java gana por estos aspectos:
Es un empate para estos aspectos:
.Net es, para todos los efectos, una pila de tecnología de plataforma única. Sí, hay Mono, pero hasta que Mono sea 100% compatible con la implementación de Windows, no proporciona una verdadera experiencia multiplataforma. El único subconjunto con el que puede contar para el soporte multiplataforma es lo que cabría en Silverlight.
Dicho esto, .Net tiene un mejor rendimiento percibido (mediciones reales por determinar). A los ojos del usuario, el rendimiento percibido es lo único que importa. Después de haber desarrollado en Java durante los últimos 12 años y hacer recientemente .Net, puedo apreciar el poder de la plataforma.
Java, por otro lado, tiene un conjunto de IDE mucho más rico para elegir, y el costo de estos IDE superiores es mucho menor que el costo de la variación .Net. Por otro lado, el costo de los motores J2EE profesionales eclipsa fácilmente los costos del entorno de desarrollo. En .Net tengo la percepción de ser mimada y muerta. En Java existen soluciones a los enormes costos, que pueden compensarse fácilmente con el tiempo del desarrollador que los configura. Fuera del IDE, para las herramientas que importan (perfilador, cobertura, etc.) los costos son iguales.
Al final , realmente depende de la necesidad . Si voy a implementar en Windows de todos modos, .Net es obvio. Tengo clientes que son solo tiendas de Windows. Si voy a implementar en Unix o necesito admitir sistemas heterogéneos, entonces Java es obvio. Incluso puedo ser radical y sugerir una pila de tecnología mixta. Después de todo, el hecho de que el cliente requiera que el servidor sea Unix no significa que lo ejecuten en sus escritorios. No todas las aplicaciones se convierten mejor en una aplicación web.
fuente
Rendimiento - Incluso
Ambas plataformas funcionan extremadamente bien para prácticamente todas las aplicaciones.
No es mucho para diferenciarlos, aunque mi experiencia subjetiva es que Java tiene una ligera ventaja para las aplicaciones de larga ejecución, mientras que .Net es más rápido para el tiempo de inicio de la aplicación.
Herramientas disponibles (incluso herramientas de terceros) - Debatible
Depende de qué herramientas necesita y con qué está familiarizado.
.Net ciertamente tiene algunas excelentes herramientas proporcionadas por Microsoft. Por otro lado, existen herramientas igualmente buenas en el mundo Java, por ejemplo, en los entornos Eclipse, Netbeans of IntelliJ.
Compatibilidad multiplataforma : Java win
.Net está fundamentalmente vinculado a las plataformas de Microsoft (Windows, Xbox, etc.). Las implementaciones completas no están disponibles para ninguna plataforma que no sea de Microsoft .
Mono es agradable, pero en realidad no le brinda una capacidad multiplataforma completa porque no admite todas las bibliotecas .Net (por ejemplo, no puede esperar que todas las cosas de la GUI de Windows funcionen correctamente, así que a menos que cambie a un kit de herramientas multiplataforma como GTK # no podrá ejecutar su aplicación en diferentes plataformas)
Java es realmente portátil. No solo el lenguaje, sino mucho más importante, todas las bibliotecas Java son portátiles. Siempre que se limite a las bibliotecas Java puras (por ejemplo, Swing para GUI), su código se ejecutará en cualquier lugar donde tenga un entorno de ejecución Java.
Bibliotecas (especialmente bibliotecas de terceros) - Java gana
Probablemente, la mejor fortaleza de la plataforma Java es el vasto ecosistema de bibliotecas, especialmente las bibliotecas de código abierto. Algunos ejemplos:
Costo (Oracle parece intentar monetizar Java) : Java gana si va a código abierto, de lo contrario, incluso.
Puede tener una pila Java 100% de código abierto que es gratuita y no lo vincula a ninguna plataforma patentada en particular. Esto es 100% gratis.
Alternativamente, puede comprar IntelliJ IDEA, ejecutar Java en Windows y usar una base de datos propietaria, en cuyo caso es más o menos el mismo costo que una pila típica de Microsoft .NET.
Proceso de desarrollo (más fácil / más rápido) : debatible
Esto probablemente depende más de la experiencia de sus desarrolladores con cada plataforma en lugar del atributo particular de la plataforma.
.Net ciertamente tiene algunas excelentes herramientas que pueden hacerlo muy productivo para aplicaciones GUI simples en Windows. No es sorprendente ya que este es el "punto óptimo" para el desarrollo de .Net.
Por otro lado, prefiero la pila Java para el desarrollo del lado del servidor. Con herramientas como Maven y todas las capacidades de implementación / integración continua, puede establecer un proceso de desarrollo muy efectivo para aplicaciones robustas del lado del servidor.
Language-wise C # tiene algunas ventajas de productividad sobre Java. Pero, por otro lado, si está desarrollando en la plataforma Java hoy en día, la tendencia no es usar Java en sí, sino usar uno de los nuevos lenguajes JVM como Scala, Groovy o Clojure; si lo hace, será mucho más productivo que C # o Java.
fuente
.Red
Es difícil responder a esta pregunta sin ser subjetivo o prender fuego (tengo la sensación de que voy a ser rechazado), pero .Net es un lenguaje en alza y Java parece estancado por cuestiones legales y se está volviendo menos popular.
Además, .net hoy en día es, con mucho, un lenguaje mucho más coherente y moderno con un excelente soporte para programación multinúcleo (Parallel.net) y asíncrona (extensiones reactivas), sin mencionar LINQ sin el cual no podría vivir. .Net también tiene una serie de herramientas gratuitas, pero Visual Studio Express, Sql Server Express, Web Matrix, etc.
Es cierto que Java tiene algunos beneficios multiplataforma. Tiene algunas opciones para .Net con mono, etc., lo que podría ser útil para aplicaciones tradicionales o componentes de back-end, pero algunas se vuelven dudosas si está haciendo algo muy especializado (y no hablemos de WPF).
Otra opción si la plataforma cruzada es realmente muy importante es ir a Silverlight, personalmente no estoy tan interesado en las "aplicaciones" de Silverlight, pero al menos funciona.
La plataforma cruzada es el punto de dolor, pregúntese si realmente es realmente necesario, al menos en este punto.
fuente
En nuestra organización, en este momento, elegiríamos Java. La razón de esto es simple: nuestro equipo de Java es más grande, más experimentado y mejor formado que nuestro equipo de .NET (que también están lo suficientemente involucrados en el mantenimiento de los sistemas existentes que les faltan los recursos para asumir nuevos proyectos importantes) .
Dicho esto, si hubiera razones apremiantes para usar .NET (por ejemplo, los requisitos del cliente, algunos clientes pueden tener una gran base instalada de software .NET y desean que su nuevo sistema se ajuste a esa base, se hagan cargo del mantenimiento, etc.) hacerlo y contratar contratistas para hacer el trabajo donde no podemos liberar a nuestra propia gente.
No forzaría ninguna de las tecnologías en un cliente en contra de sus mejores intereses, y algunos clientes simplemente se benefician (debido a su organización interna) más de uno que del otro debido a las inversiones necesarias para implementar el sistema (nuevamente, digamos que tenemos un cliente que ya tiene una serie de aplicaciones .NET en ejecución y tiene el personal para apoyarlas, no vamos a tratar de obligarlas a contratar personas y comprar licencias de hardware y software para ejecutar una aplicación Java en el lateral, y por supuesto lo contrario también sea cierto. De hecho, les aconsejaríamos que no lo hicieran si nos lo pidieran).
fuente