Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

183
Views
Java: compromiso de compatibilidad de estilo

Me preguntaba el otro día sobre la compatibilidad y el estilo de mi código Java. A partir de Java 14, la nueva arquitectura de switch está realmente disponible. He adjuntado esto a continuación para comparar. Ahora me parece cuestionable si realmente debería usar este buen estilo, porque tendría que compilar en la versión 14 de Java en este caso. ¿Me recomendaría usar la antigua arquitectura de switch para poder compilar en el ampliamente utilizado Java 8, o debería usar la nueva arquitectura para tener menos compatibilidad?

 int a = 42; // Old switch switch(a) { case 42: // Do something break; default: // Do something else } // New enhanced switch switch (a) { case 42 -> { // Do something } default -> { // Do something else } }
over 4 years ago · Santiago Trujillo
1 answers
Answer question

0

Tiene razón en que la nueva declaración switch y la sintaxis de expresión no funcionarán en versiones anteriores de Java. Eso significa que debe considerar si necesita su código para compilar y ejecutar en versiones anteriores de Java.

Pero esto no es un problema nuevo. Por ejemplo, en Java 5, introdujeron una serie de nuevas construcciones del lenguaje Java que incluyen genéricos, anotaciones, autoboxing, etc. Y Java 7 introdujo la prueba con recursos. Y Java 8 introdujo expresiones lambda. Java está evolucionando.

Depende de cada programador/proyecto decidir cuándo comenzar a usar las nuevas funciones del lenguaje... de acuerdo con sus requisitos y limitaciones específicas. Realmente no podemos aconsejarle porque no sabemos cuáles son sus requisitos y limitaciones.

Pero si tarda demasiado en cambiar a funciones de lenguaje más nuevas, es posible que termine con una base de código con demasiado código anticuado; por ejemplo, empaquetado/desempaquetado explícito, tipos sin procesar, limpieza de recursos escamosos en bloques finally , etc. En última instancia, su productividad sufre.

(Y el corolario es que debe juzgar cuánto beneficio obtendrá en productividad y capacidad de mantenimiento a largo plazo de cada nueva función de lenguaje que esté considerando. Algunas serán menos beneficiosas que otras).


Cuando se trata de la compilación, estoy más preocupado por los consumidores que pueden tener solo una versión baja de Java instalada...

La otra cara de la moneda es que hay costos adicionales >para usted< al brindar soporte a los clientes que no pueden o (más probablemente) no quieren actualizarse a una plataforma Java más reciente. En cierto punto, es mejor para todos si declara que las versiones antiguas de Java "ya no son compatibles" con su producto. (Pero no podemos decirle cuándo hacerlo. Hay demasiadas variables no cuantificables...)

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!