Lo nuevo de Java 7

Multicatch está chido. Lo demás, meh... y ese try con recurso, creo que me gusta más la anotación de Lombok para hacer lo mismo, es más breve.

Habrá que revisar luego eso de nio2 (java.nio es medio obsoleto porque a pesar de ser más nuevo que java.io, con el hardware moderno multicore y demás, es mejor manejar varios hilos que hacer cambios contextuales como hace java.nio).

Lo de la clase Objects... si yo fuera Oracle ya dejaría de presumirla. Lo que realmente espero es que tenga mejor performance y manejo de memoria que Java 6 (que no está mal, pero pues si esto es lo que trae de cambios para programar, espero que lo demás sea de la JVM).

Lo cierto es que aunque muchos pudieran haber escrito la misma clase de utiliería de alguna forma resuelve el problema de estar escribe y reescribe el mismo código y reinventar la rueda y/o tener que agregar algun otro jar nomás para tener esta funcionalidad.

No es impactante es cierto, pero al menos es un pasititito a todo ese código repetido en muchas partes.

Hay que recordar que en el intento de hacer algo como esto se pueden estar cometiendo varias barbaridades. Uno no lo cree hasta que lo vez por ahí.

Ahora nomás falta que la conozcan y la usen je!

@OscarRyz Muy cierto lo que dices sobre evitar repetir código y sobretodo evitar errores. Respecto a dar a conocer clases como esta, nosotros podemos hacerlo (de hecho ahora mismo sucede). Podemos desde hacer un repaso aquí en la página hasta recomendarla a los compañeros del trabajo, conocidos, amigos y pues todo el que se deje. Jeje.

Lo de los literales binarios yo nunca eh podido darles un uso.
El multi catch, es solo como un "or" o ¿Puedes aplicarlo en varias lineas?. Y se me ocurren varias ideas para el nuevo switch :D

Pues está chido, me gustó lo de try/catch con recursos (ya nos podemos ir olvidando de finally mientras usemos Java 7). Respecto a las excepciones atrapadas prefiero la notación Scala aún más, es más descriptiva y puedes dar un tratamiento según la excepción, cosa que con Java 7 (a mi parecer) tienes que lidiar, ejemplo en Scala:
 

Y en Java 7 pues habría que revisar:
 

¿O existe alguna manera de manejar el comportamiento de manera más DRY con Java 7?

Es que el ejemplo que estás dando en Java es muy malo... no tiene caso cachar ambas excepciones para luego querer distinguir entre una u otra, y menos haciendo comparación por nombre de la clase. En todo caso:

Pero de todas formas para este ejemplo es mejor como se hace hoy:

Lo del multicatch es útil precisamente para el caso contrario: hoy en día si quieres hacer lo mismo con dos o tres tipos de excepciones pero no tienen una superclase común, tienes que copiar código, o ponerlo en un método e invocarlo:

Eso te obliga a tener en cierta forma código redundante o complicarte la existencia creando métodos que únicamente vas a llamar desde ahí. En cambio con multicatch:

Cuando el tipo de excepción no te importa tanto de manera específica, sino que quieres manejar esos tipos de excepción de la misma forma, es cuando sirve el multicatch. La idea es facilitar que no se tenga que repetir código para que menos programadores les dé hueva y terminen implementando el antipatrón Pokemon.

Era a lo que iba...en mi personal manera de verlo me gusta más el estilo multi catch. Aunque este nos da una opción más para tratar varias exceptions con el mismo comportamiento...

El hecho de que exista el multicatch no significa que lo TIENES que usar. Si dos excepciones distintas las debes manejar de manera distinta, pues hay que hacer dos bloques catch.

Es una lata tener que hace lo mismo para distintas excepciones:

Con el multicatch ya se puede escribir asi:

La notación de Scala usando pattern matching esta muy padre, pero efectivamente ahí es más bien cuando quieres hacer cosas diferentes con el mismo.

Por cierto como propuesta ( que a nadie le intersa ya sé ) yo estoy pensando usar una método "try" que recibe como argumentos dos bloques de código, uno el riesgoso ( el try ) y otro el manejo ( el catch ) que recibe un numero variable de argumentos. .. en fin.. aun esta muy verde esto:
 

Lo que me gusta es que no se utiliza ninguna construcción nueva, es lo mismo que ya se tiene, un método, parametros nombrados, bloques. Claro esta tendría que ser una función built-in. Ahh.. .falta tanto.

p.d. Quité el alimento de troll que habían dejado ahí, espero que no les importe.

Me quedé :¬| con lo del antipatrón Pokemón .... bueno, ahí va la liga, no creo ser el único aquí

Pues yo lo que hago es que generalizo las excepciones, por ejemplo al leer un archivo puedes atrapar IOException en vez de FileNotFounException pero de todas formas si necesitaba hacer una consulta tenia que poner el SQLException... o si encriptaba el NotSuchAlgoritmException... etc, a lo que voy es que (en casos especificos y generalmente cando ya se hace la implemntacion de algo) uso las excepciones generales... Cando se puede: por ejemplo que hay que leer y luego "encriptar" y luego guardar a base de datos y luego envialro a un ws por ejemplo lo unico que importa es saber "se pudo" o "no se pudo" y aplico solamente Exception y con e getMessage me basta y sobra

Cuando se cachan excepciones y no se les hace nada, el problema estalla eventualmente con la diferencia que es muchísimo más dificil saber que paso.

"Cuando un sistema va a fallar lo mejor es que falle rápido."

Lo mejor es dejarlas ir cambiándolas de acuerdo al nivel de la abstracción.

java.daba.doo ese es precisamente el antipatrón Pokemon: cachar Exception. Es una mala práctica porque cachas TODAS las excepciones posibles, cuando obviamente tu código no está manejando todas las excepciones posibles. Lo que mencionas de cachar clases más generales está bien: IOException, SQLException y GeneralSecurityException en vez de FileNotFoundException, SQLIntegrityConstraintViolationException, NoSuchAlgorithmException. PERO siempre y cuando estés muy consciente de lo que tu código puede arrojar y sabes que hay sólo 2 o 3 casos posibles y que todos los vas a manejar igual, entonces puedes cachar la excepción que sea común a los 3 casos: Si no hay algoritmo, o si usaste una llave de tamaño inválido, o si le pasas un bloque de tamaño inválido, esos son problemas que te van a salir durante el desarrollo y pruebas, eso no debe pasar en producción, y si llega a pasar al final la cosa es que no se pudieron cifrar los datos y entonces tienes que dar un error y ya.

Hay casos en que sí importa manejar distinto una NoRouteToHostException que una SocketTimeoutException o una ConnectException.

Pero si cachas Exception, es una mala práctica porque seguro que hay muchas excepciones que no deberías estar manejando. Si estás tratando de cifrar datos por ejemplo, y al crear un buffer donde vas a guardar los datos te quedas sin memoria y se arroja un OutOfMemoryError, o no se ha inicializado una variable y por eso se arroja una NullPointerException, o tienes un ciclo que genera recursión y entonces se arroja StackOverflowException, eso no lo deberías manejar, al menos no de la manera en que estás manejando los casos que esperas recibir (no algoritmo, error de IO, etc). Esos casos los debes dejar pasar y que los maneje alguien más o que de plano se atore la aplicación o se le presente un error al usuario. Y la mejor manera de dejar pasar esas excepciones es simplemente no cacharlas.

Lo que dices de los pokemon (no se por que el nombre) lo aplico cuando hago implementacion de codigo que ya previamente construi en donde pues no hay nada mas que hacer que mostrar mensaje y punto como expresaba en mi ejemplo "se envió" o "no se envió" y el getMessage (sea la excepcion que sea te da el mensaje de la excepcion)

Cuando estoy haciendo la estrucutra del sistema y esas cosas que le dan forma al negocio de la aplicacion ni pongo e try, prefiero darle el throw al metodo (a menos que pueda tener un proceso correctivo) pero por ejemplo, el archivo que tienes qe leer y hacer X proceso no está, que puedes hacer? pus nada manda el error y se acabo entonces me lanza directamente el FileNotFoundEx... ya sera tarea del codigo queimplementa ese metodo tomar esa excepcion y hacer algo que ya depende de su requerimiento del metodo

hacer BlindException es tan mal plan como no cacharlas y estoy de acuerdo solo que en algunos casos no es NECESARIAMENTE UTIL identificar una por una

Ya pusieron la liga, pero siendo viernes en la tarde y a la gente le da flojera seguir ligas: El slogan de los pokemon es "gotta catch'em all", o sea "tienes que agarrarlos a todos". Es precisamente lo que haces con  , que siempre ha sido un anti-patrón o mala práctica, sólo que a alguien se le ocurrió darle ese nombre.

Osease que cuando manejas   no solo estas manejando cosas que no podias preever ( como que se caiga la BD ) sino que también estás manejando cosas que SI se pueden evitar con código como   o  . Todas las   PUEDEN y DEBEN de ser evitadas con código.

Hay un tercer tipo de excepciones que tampoco deben de ponerse en un catch esos son los errores ( como   ) si se le acaba la memoria a la JVM no hay nada que se pueda hacer.

Resumen ni   ni   ni ninguna de sus subclases deben de ponerse en un catch a menos que haya una razón justificada. Cuando usas   estás manejando todas las Runtime y sus subclases.

Por último lo que haces de manejar una jerarquía de clases usando la clase padre esta genial! ( de nuevo siempre y cuando no sea Exception )

Oh mi dios, yo generalmente en mi código las excepciones las mando así
un simple  
Como menciona Oscar de que al usar   manejas todas las Runtime y sus subclases realmente creía que era mejor que estar colocando el tipo de excepción.
Uff que bueno que lo eh sabido a tiempo, aun no hago ninguna desgracia.

Con lo del alimento Oscar, je je, se me cayo de la bolsa sin querer.

Pues es que utilizar únicamente Exception es la desventaja, pero hay código en el que simplemente no sabes que excepción se puede producir. Ej.: un bloque de código que por medio de ftp va en búsqueda de un archivo, se lo descarga, verifica el checksum del archivo, lee el archivo línea a línea en búsqueda de datos (o metadatos también), ir a una base de datos y comprobar valores contra el archivo; de ahí los hacer los cambios según sea necesario...De ahí vienen varias excepciones, pero puede que se te pase alguna excepción que por falta de experiencia no sepas cual vas a atrapar. No sé yo lo veo que Exceptioin se utilizan para atrapar excepciones que no contemplas o sea al final de un multicatch.

Eso del pokemon esta simpatico, pero bueno la verdad se me hace un antipatron muy purista e innecesario, como dice java.daba.doo en ocaciones solo es necesario decir si se logro o no X cosa.
Estoy de acuerdo que si se puede hacer algo especial en el catch para alguna(s) excepciones pues hay que hacerlo, sin embargo cuando no puedes hacer nada no es mas simple poner Exception que cachar excepcion por excepcion para solo meterlo en el log y decirle al usuario "No se pudo".

Ademas el cachar una exception no quiere decir que no hayamos evitado las NullPointerException, ArrayIndexOutOfBoundsException, RuntimeException que menciona @OscarRyz.

O ustedes que opinan

No le habia puesto atencion al link de las Pokexcepciones

Es muy válido lo que dice Oscar, aunque no pienso defender ferreamene el cachar todas las Excepciones usando

Puede resultar util hacerlo en casos severamente especificos. Cuando estes utilizando el codigo en la ultima capa de implementacion, como dije anterior mente, quieres solo usar el codigo que ya ha sido tratado

 
 
 
Ejemplo 1:
 
Este es muy sencillo y solo lanza una excepcion personalizada
 
 
 

Ejemplo 2
 
Este tiene un poco mas de chiste y noten que se utilizan varias Excepciones antes de lanzar una especial. Cuando "cay" (cae) en IOExcepton, se intenta modificar el archivo y rehacer la tarea, en este caso cachar Exception es muy util orque lanze lo que te lanze solo o vas a lanzar #pfffft

 
 Quizas @java.daba.doo #estanmaloprogramando que le encanta lanzar las Excepciones, de tal modo que cuando necesito emplear en una capa intermedia de desarrollo prefiero lanzar en vez de aplicarle un try

 
 
Pero las Excepciones ya fueron tratadas anteriormente en su metodo correspondiente. Ojo, aqui todavia es necesario distinguir e tipo de Excep´cion que estamos lanzando para que cuando hagas esto:

 
 
puedas tratar los errores de acuerdo a tipo de excepcion o como yo mencionaba... simplemente no se pudo y punto entonces completemos el codigo con:

--- EDITADO ---
por cierto, FlieNotFundException fue puesto a proposito para expresar mas excepciones es que me acorde que "#estanmaloprogramando que usa el try-catch para hacer validaciones"

@wishmaster77 "pero hay código en el que simplemente no sabes que excepción se puede producir"

Aguas wishmaster77 ese no debe de ser pretexto, sé que es muy engorroso pero es necesario.

Cuando no sabes que excepción se puede producir el compilador te avisa que excepción se puede producir y en que linea y método se puede producir. Por eso se llaman "Checked exceptions" porque se "revisan".

A eso es a lo que se refiere el compilador cuando dice: BlahBlahBlaException must be handled or declared to be thrown" o algo así. O la manejas o la dejas ir.

Si no hay alternativa para manejarla ( si no hay nada que se pueda hacer ) lo mejor es dejarla fluir hacia arriba y quizá cambiarla de abstracción, ejemplo:

Cuando se tiene una excepcion checada, el compilador no nos dejará avanzar hasta que la manejemos ( en el ejemplo burdo relanzando otra excepcion ) o hasta que la dejemos subir ( agregandolo en la clausula   )

Es una lata si, pero es necesario. Un IDE te ayuda a escribir esto muy fácilmente o si sabes manejar bien tu editor lo puedes hacer con algunos search/replace. Pero al listar todas las excepciones que vas a manejar, evitas por ejemplo que se caches un NullPointerExcepion, que si bien tambien puede ocurrir, ese lo puede EVITAR CON CODIGO ( ese es la parte importante ) un ejemplo de como evitarlo con código es validandolo. Puedes no hacer nada con un null ( ejempo 1 ) o puedes lanzar un Npe tu mismo con un mensaje más apropiado.

Con el multicatch mi ejemplo en Java 7 se escribirá:

Y que conste que la razón es meramente práctica y no teórica. Cuando se tiene un código que maneja todo, entonces tiempo después alguién puede meter un error de programación ( como no validar que un dato sea un número ejemplo )

Si por ejemplo no se valida que un string sea realmente un entero y se parse, arroja un   que al ser un   pudo ser evitada con código

Cuando esto no pasa el valor de   seguirá siendo ... lo que tenía ( por ejemplo 0 ) y si este valor se usa para algo ( enviar correos o no se alguna cosa ) entonces extrañamente.. no pasara nada y alguien se tendrá que quedar a debuguear porque el sistema no hace lo que debde si se le está mandando tal y cual funcionalidad solo para descubrir después de varias horas de debug a las 3 de la mañana que "alguien" pusoo un catch Exception y y y y entonces al que se quedo a debuguear le van a dar ganas de matar al otro y después de ahí se va a ir a su casa en taxi y y .y .. ( ehem , ehem.. digo podría pasaaar jejeje )

O sea.. no lo hagan.

Bueno pero ese ejemplo solo cachas Exception sin embargo si manejas las excepciones necesarias y las que no puedas manejar las dejas aparte:

 
Solo por ejemplificar obviamente estoy provocando la excepcion.
Que pasa ahi sigo cayendo en el antipatron?

O es mas que tal asi:
 

El tema central es que si cachas Exception solamente para imprimir un log, puedes estar generando más problemas de los que crees que estás resolviendo (o manejando).

En este último ejemplo de CybJer: qué tal si la Exception que cachas al final es realmente una IOException (o una subclase de) indicando que ya no tienes espacio en disco duro, o que ya valió queso el filesystem porque el disco duro explotó? ese   muy probablemente va a disco, y pues no se va a grabar el mensaje, nadie lo va a ver, pero en vez de tronar la aplicación de manera visible, tu código a fin de cuentas, de manera efectiva, lo que hizo fue tragarse la excepción.

Qué tal si en cambio es una ConnectException o SocketTimeoutException o algo así porque en el momento de querer ejecutar el código de JDBC/JPA/loquesea, el equipo ya no tiene conexión de red? Tal vez no sea SQLException lo que se lanza, sino una subclase de IOException o SocketException. Y qué tal si tu logger está configurado con un appender para enviar el mensaje por red en vez de escribir en disco duro... lo mismo del caso anterior: el log no llega a su destino, no se graba nada, y el efectivo final fue sólo tragarse la excepción, o en todo caso, se arroja una RuntimeException de parte del logger y eso va a desconcertar bastante a quien lo trate de rastrear.

Si no vas a manejar la excepción, no la caches. El único caso válido es cuando alguien ya hizo una porquería de método que declara   y no tienes de otra (como el pésimo ejemplo que pone Apache Commons Pool).

"Que pasa ahi sigo cayendo en el antipatron?"

Si

Si me ha pasado

se arroja una RuntimeException de parte del logger y eso va a desconcertar bastante a quien lo trate de rastrear

Entonces es preferible mostrar el pantallazo de error del contenedor de servlets o servidor de aplicaciones antes que cachar una excepcion que no vamos a tratar o ¿que alternativas puedo usar?

Al usuario final no se le deben de presentar esos mensajes de error tan detallados porque además de que no le sirven de nada le van a dar la ( no necesariamente incorrecta ) percepción de que el sistema es frágil.

Al usuario final se le muestra una pagina como esta:

( bueno con la seriedad que la aplicación requiera )

O como la ballena de Twitter.

Y el error se registra en el servidor y debe de haber un proceso ( humano o automático ) que registre esos errores para que se revisen y se corrijan.

De esa manera no se muestra información demás al usuario que también es una de las vulnerabilidades del software ( no solamente es SQLInjection y XSS )

Cada caso es diferente y dependiendo de la excepción es la acción a tomar.

Bueno talves no me explique, a lo que me referia es que si no voy a tratar una excepcion, como me indica ezamudio

Si no vas a manejar la excepción, no la caches

Si no la cacho como le hago para que la excepcion no se muestre en pantalla, que alternativas usar, o es que cybjer #estanmalprogramador .
Porque no puedo entender como mandar a una pagina como la que mencionas sin cachar la excepcion que no pienso o puedo manejar

Ahh si si .. es correcto. Ya lo mencionó jdd pero es hasta la última capa precisamente donde podrían manejar todas las excepciones. Pero aún así las runtime deberían de estallarle en la cara al usuario final y eso debería de PROBARSE antes de ser liberado. Las excepciones que sabes que pueden suceder pero no sabes cuando, si irian en una pagina como la que digo.

No sé si captas la diferencia. Las runtime excepcion son errores de programacion:

Ambas son RuntimeException y deben de ser detectadas cuando se construye la aplicacion.

Cuando no puedes saber si la BD se caerá o no Y además no puedes hacer nada cuando suceda:

Y ahí si le pones el "Algo salio mal"

La cuestion es que una   es un error generado en tiempo de ejecución es posble capturar para aplicar un proceso correctivo si asi se desea... yo no veo que sea obligatorio el trato de escepciones pues NO EN TODOS loa casos SE NECESITA o SE DEBE hacer algo...

Por ejemplo tengo un valor por default, y en caso de que me manden otro valor lo sobreescribo, ese valor lo leo de un archivo plano y si por alguna razon no está, no se pudo leer, no tiene formato adecuado... etc. ES COSA QUE A CIERTA PARTE DEL CODIGO NO LE IMPORTA, porque el solo pregunta, "tenemos el datio: SI o NO ?"

Pero claro que en el método   (en mi forma de programar) hay que ponerles try-catch y lanzar esa misma excepcion en caso de que no se tenga un flujo alternativo que maneje esa Excepcion.

En el comentario pasado explique un poco de eso... Bueno, segun el criterio de los expertos podria preguntar... ¿Caigo en malas practicas? Seguramente dirian que si por mi codigo de este comentario, pero he aqui cuando digo "NO ME IMPORTA esa excepcion" pero tengo que cacharla porque quizas el metodo   tiene declarado lanzar   la que sea. Es por eso que estoy obligado a cachar la excepcion aunque no me interese que suceda un error (Si no lo pones y sucede el error se truena tu hilo del programa y crash)... El metodo siempre me tiene que pasar el error en caso de que él no lo pueda o simplemente no le competa corregir....

Un caso similar es el de NumberFrmatException:
 
Ves que no le compete solucionar pero si te retorna una Excepcion que te indica e fallo y es responsabilidad tuya capturar esa excepcion o lanzarla cuando menos... Ok, espero que con esto quede claro lo que he venido expresando

Los contenedores web y servidores web, frameworks web, etc tienen siempre una manera de presentar el error al usuario final, generalmente configurando una página de error, donde puedes elegir qué tanta info quieres mostrar al usuario (el tipo de excepción, o solamente el mensaje de la misma si es que venía uno, o de plano nomás decirle que ocurrió un error).

Cómo vas a resolver ese error? Hay varias maneras. Tal vez los usuarios reportan el error si es algo que ocurre todo el tiempo, y entonces alguien terminará llamando al desarrollador para que lo arregle cuanto antes. O tal vez hay una herramienta de monitoreo que reporta que están saliendo errores y aunque el usuario sólo ve una página con FAIL, queda un log con el registro de lo que ocurrió, para analizarlo y corregir el problema (haciendo todo el ciclo de pruebas previamente). O tal vez usas jAlarms para notificar a los involucrados (QA, desarrollo, etc) en cuanto ocurre algún problema grave (puede que hayas implementado tu propio ExceptionHandler para que haga eso cuando ocurre una excepción que ya nadie manejó en la aplicación; entonces se presenta error al usuario y se envía la alarma).

Muy ilustrativos sus comentarios e interesante esto de jAlarms, estaría genial leer los errores que ocurran de mis desarrollos desde Twitter

Jejeje...esa es la ventaja de usar un lenguaje compilado o un framework que te force a compilar antes de subir algo a producción. Por mi parte cómo de momento estoy usando Play! pues no tengo esa ventaja, lo bueno es que cuando las excepciones ocurren (las que no tenía contempladas) en el logger siempre pido el nombre de la clase de la excepción, una vez corregido el bug le agrego un catch con la nueva excepción, pero jamás le quito el último catch ( ) por si ocurre alguna excepción de tipo que de nuevo olvido o no contemplo. ;)

Muchas veces no es flojera o pretexto, a veces es porqué simplemente no sé y no tengo la ventaja de un compilador a la mano, ahí es cuando "justifico" su uso, pero pues por ejemplo cuando tienes una herramienta cómo Maven o cuando compilas a mano pues ya tienes la ayuda y basta con hacer copy/paste del nombre de la excepción (o excepciones) posible(s) y agregar un catch.

¿O de plano doy pinta de tan mal programador?...Aunque comparándome con @bferro, @luxspes, @ezamudio o tú pues la verdad que soy cómo el pajarillo de agua que usaba Homero Simpson en su computadora (cuando trabajó desde casa) xD!.

O sea que Play! no tiene integrada alguna facilidad para hacer pruebas unitarias o de integración o funcionales o de cualquier tipo? No es un framework Java? No compilas el código para subirlo a producción?

De todas maneras no deberías tener ese último catch con Exception. Si Play! es tan maravilloso como nos has contado, seguramente en modo desarrollo te puede presentar el stack trace completito en caso que ocurra una excepción, y en producción le presenta al usuario una página muy linda disculpándose porque algo malo ocurrió y deja registrado en un log el stack trace completito de la excepción.

Ya leí un poquito y Play! sí tiene facilidades para pruebas, incluso pruebas funcionales y te dan tu acordeón para las pruebas.

Así que no hay pretexto para no hacer pruebas, deben ser parte del desarrollo.

Sip si las tiene, pero por ejemplo (en desarrollo) que haces algo cómo "caja negra" (antes de mandarlo a pruebas) no tienes esa ventajas y cuando ocurren las excepciones (que no contemplo) las agrego, pero pues siempre es bueno tener un plan b o sea si se que viene una excepción específica pues la pongo y ya. Pero hay código (que tú no haces) y que tiene varias cochinadas maneras diferentes a las que acostumbras y ahí es donde uso esta manera. Ya cuando lo probamos pues te dice todo "de pé a pá", pero mientras tanto pues es lo que hago. Y ya estaba viendo la integración con Maven que también te avisa todo ese cuento, entonces veré si lo puedo integrar con Maven (aunque se antojaría más una integración con Gradle).

Respecto a lo del stack trace y de la compilada...Pues el código puede compilarlo o no, ponerlo en un war o no, subirlo a un contenedor web o no...depende la infraestructura y el dominio que tengas, digamos que Play! no es muy aceptado en Java por lo mismo, para muchos Play! es algo "muy esotérico". O sea si quieres subir una aplicación a producción editas los archivos de error 500.html y 404.html, de ahí cambias el valor en la configuración de "dev" a "prod" en application.mode y basta con ir a la terminal y teclear "play run ${path a tu aplicación}".

Y de hecho esto era la única desventaja (cuando estas desarrollando antes del testing).

666

Lee esto que escribió @luxspes

http://www.javamexico.org/blogs/luxspes/rtfs_read_f_stacktrace

Desde que lo presenten a que se emplee en entornos reales de desarrollo, aún va a pasar tiempo :)

En cualquier caso, Java como lenguaje avanza de forma muy, muy lenta y muy tímida. Sólo Java 5 trajo cambios reales y un impulso hacia delante.

Y ahora con Oracle... en fin, no creo que vaya a ir mucho más rápido, más bien al contrario :)

Juan - JuanMedin.com

Digamos que Java 7 prepara el terreno para otros cambios un tanto más fuertes que ventrán en Java 8.

Está próxima la presentación "official" de Java 7. Estén pendientes.

Regresando al tema original, acá les dejo una lista "Oficial" de las mejoras que están en Java 7

Básicamente lo que ya mencionó hmvictor

Pregunta para ustedes que saben y tienen buena experiencia en java.

quiero certificame en java. y mi objetivo principal es llegar a ser un Senior en Java EE.
y en un centro de capacitacion oficial que esta en DF y Monterrey me sugieren tomar OCP-Java SE 7 Programmer.

Si tomo la capacitacion oficial de Java para
OCP, Java SE 7 Programmer,,

me sirvirá para tomar la siguente capacitacion para
OCM, Java SE 6 Developer
y la ultima OCM, Java EE Enterprise Architect
???

saludos y gracias

Para qué quieres certificarte en Java 6 después de certificarte en Java 7? Java 6 será EOL-eado en febrero del próximo año. Y sí, seguirá en uso en muchos lugares, pero ya no habrá más actualizaciones ni recibirá ningún tipo de mantenimiento.

▲ LoL :D

Fuente: