Joseph Darcy es el encargado del Project Coin, un proyecto que busca incluir pequeños cambios a Java que faciliten la vida de los programadores. Estos cambios los puede proponer cualquier persona y se implementarán los que más votaciones reciban en el sitio del proyecto. Para aceptar una propuesta de cambio existen 2 criterios:
1. Que el cambio facilite el día a día de los programadores.
2. Que sea compatible con otros cambios de la JDK7
Algunas de las propuestas las resume Jeremy Manson en su blog y son bastante interesantes:
1. Strings en switch, para evitarte tantos if anidados al comparar cadenas.
2. Bloques de recursos automatizados, propuesto por Joshua Bloch para permitir cosas como:
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}
3. Expresiones de bloque por Neal Gafter, la idea es que la expresión delimitada dentro de un paréntesis devuelva un valor, lo que haría posible algo como:
double pi2 = (double pi = Math.PI ; pi*pi)**; // pi al cuadrado
3. Mejoras al manejo de excepciones, también por Neal Gafter:
try {
doWork(file);
} catch (final IOException | SQLException ex) {
logger.log(ex);
throw ex;
}
4. Mejoras al manejo del Tipo en Generics propuestas por Jeremy Manson que permitiría declarar algo como
Map<String, List<String>> anagrams = new HashMap<>();
Por cierto, los Closures no entrán en esta categoría. ¿Que opinas de estos cambios, has pensando en alguno que facilite tus desarrollos? En el enlace a la noticia, podrás encontrar el formulario que hay que llenar para hacer tus propuestas.
La 1 me parecen un adición muy útil. La 2 creo que podría haber sido abordada con closures si estos hubieran sido agregados.
La 1 y la 3 me parecen muy útiles, ojalá sean incluidas
- El GOTO. Lo hecho a faltar desde cuando el spectrum.
lo del goto debe ser broma!!!
Broma o no, en Java existe el GOTO (salto incondicional a una etiqueta), y como es lógico, es una palabra reservada, auqnue me reservo lo que opino sobre su uso, por no ofender...
Aquí se muestra su uso: http://java.sun.com/developer/TechTips/2000/tt0613.html#tip2
A lo que vamos: personalemente me gustan los lenguajes simples, aunque hoy en día sean una mera utopía: yo a Java, más que ponerle, le quitaría cosas...
Acabo de ver que en mi anterior comentario me he saltado una frase:
...palabra reservada....
aunque no tiene uso (no es una "stament"). Los saltos a etiquetas en Java se hacen con "break" nombrados. Aunque me res ervo...
¿Punto y coma a final de línea opcional?
a mi me gustaria que incluyeran el uso de operadores matematicos en los BigDecimal. Solo es cuestion de un poco de azucar al lenguaje.
Por ejemplo:
BigDecimal a;
BigDecimal b;
BigDecimal c = a + b;
y al compilar simplemente se transforme a : BigDecimal c = a.add(b);
Lo de los Swicth con String tambien me parece muy util...
Si quieren encontrar posibles adiciones, ya que C# se copió de Java, ahora Java se puede copiar de C#.
Muchas de esas mejoras que se proponen ya están implementadas en C#.
PD: Por ejemplo, me encantaría eso de los switch con Strings
¿Y qué tal los switch con intervalos?
switch( n )
{
case 1...4: break;
}
Coincido plenamente con la propuesta de peyrona de los switch con intervalos (como se te nota que has "sufrido" también con lenguajes no derivados de C).
Me gusta mucho la 1 y la 3, otras no las entiendo bien (por ejemplo la 2). Las de tratamiento de excepciones en mi opinión sobran, lo que hay que evitar sencillamente son las excepciones checked. No nos engañemos, en el 99% de los posibles casos en donde puede producirse una excepción, sencillamente NO tenemos nada útil que hacer más que dejarla pasar.
Se me olvidaba, una cosa que estaría genial sería lo siguiente:public class Prueba
{
public static void main(String[] args)
{
Prueba$Saludo obj = new Object("Hola")
{
String msg;
public Object(String msg) { this.msg = msg; }
public void hola() { System.out.println(msg); }
};
obj.hola();
}
}
El ejemplo tonto anterior es lo de menos (se que el msg podría capturarlo de una variable externa), el asunto es que a veces se necesitan clases muy pequeñitas en donde una inner class está muy bien y es lo más parecido a un closure, pero se echa de menos no poder añadir algún atributo. Si el compilador permitiera ponerle nombre a la clase inner (según el ejemplo Prueba$Saludo), o al menos dejar usar el nombre interno (Prueba$1) sería factible lo anterior.
De todas formas en mi opinión y que no se me enfade nadie, a veces tengo la impresión de que el afán por introducir cambios sintácticos que "ayudan a escribir menos" está muy influenciado por los programadores-tira-lineas-código-plano, es decir aquellos que son absolutamente incapaces de hacerse una función de utilidad, la sintaxis de un lenguaje debe ser minimalista, la riqueza debe estar en las librerías y en la extensibilidad que proporciona dicho lenguaje.
Es que hoy tengo ganas de provocar :)
Otra opción sería :
public class Prueba
{
public static void main(String[] args)
{
Prueba$Saludo obj = new Prueba$Saludo("Hola")
{
String msg;
public Prueba$Saludo(String msg) { this.msg = msg; }
public void hola() { System.out.println(msg); }
};
obj.hola();
}
}
En donde el compilador "ve" que Prueba$Saludo está siendo definida "insitu" y podría ser usada fuera usando dicho nombre.
"Si quieren encontrar posibles adiciones, ya que C# se copió de Java, ahora Java se puede copiar de C#.
Muchas de esas mejoras que se proponen ya están implementadas en C#."
Jejeje, es divertido ver frases tan contradictorias como "C# es una copia de Java pero Java debería tener tales cosas de C#".
Desde la primera versión C# salió con switch con strings, atributos, propiedades, eventos y delegados, sobrecarga de operadores, ciclo foreach, enums, tipos de valor, autoboxing/autounboxing, tipos integrales sin signo, etc. En la versión 2.0 se agregaron genéricos reales, métodos anónimos (closures), continuaciones y evaluación diferida. En la 3.0 se agregaron expresiones lambda, métodos de extensión, tipos anónimos, inferencia de tipos, sintáxis especial para inicializar objetos y colecciones, LINQ, etc. La versión 4.0 traerá el tipo dinámico, tipos genéricos con parámetros covariantes/contravariantes para interfases y delegados, métodos con parámetros opcionales y nombrados, etc.
Quizá tantas características hagan a C# un lenguaje "kitchen sink", pero esa es otra cuestión. Lo que no veo es cómo se puede seguir diciendo que C# es una copia de Java, mientras que la mayoría de las agregaciones a Java 1.5 ya existían en C# desde su versión 1.0, y la mayoría de las características del lenguaje para Java 7 (que la mayoría no se agregarán) también ya existen en C#. Es cierto que Java no ha querido agregar muchas de esas características por diseño, y eso no es malo, incluso es una prueba de que C# no copió tampoco la filosofía minimalista de Java.
O aparte de la idea de basarse en la sintáxis de C++ (a la cual es más fiel C# que Java), que otra cosa copió C# a Java?
Tomar la sintaxis de C++ fué el primer error de Java.
Si Java hubiera tomado otra sintaxis no habría usado Java casi nadie, nos guste o no la sintaxis C/C++ sigue siendo una lengua franca, las innovaciones que parten de una sintaxis C/C++ tienen muchas más probabilidades de prosperar que cualquier otra variante.
Prueba a listar los lenguajes más populares del mundo:
C, C++, Java, C#, PHP y JavaScript al mismo tiempo que Perl y VBasic languidecen y Ruby no parece prosperar más allá de un nicho y Python es una incógnita cuyo futuro dependerá mucho de Google.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
C# no cabe duda que fue inicialmente un clon de Java, lo que pasa es que como lenguaje posterior obviamente fue más innovador (al igual que Java está basado en C++).
Además sencillamente Microsoft está más obligado a innovar que Java pues su status quo es de inferioridad respecto a Java (en adopción, no hablo técnicamente), y también puede permitirse el lujo de dar más banzados pues para eso es el proveedor exclusivo de la tecnología lo cual no ocurre con Sun que tiene que preguntar mucho a otros antes de dar un paso y está obligado a ser mucho más conservador pues tiene mucho más "que perder" si se mete la pata en las innovaciones.
coincido con la 1 y la 2, saludos
apollo la 3 ,, con respecto a la 1 ,, no me agrda paa nada la idea .. para mi switch es muy ma la practica (claro esta que ese es mi punto d vista)
Apoyo a jmarranz y creo que puedo agregar (sin exagerar tanto) que .Net tiene mucho de Java a escalas mayores, lenguages compilados - interpretados, lo de que C# tenga muchas funciones desde el principio es obvio, de lo contrario la afirmación de que está basado en Java ( copia ) no tendría validez.
WG
jmarranz:
Otra opción sería :
public class Prueba
{
public static void main(String[] args)
{
Prueba$Saludo obj = new Prueba$Saludo("Hola")
{
String msg;
public Prueba$Saludo(String msg) { this.msg = msg; }
public void hola() { System.out.println(msg); }
};
obj.hola();
}
}
En donde el compilador "ve" que Prueba$Saludo está siendo definida "insitu" y podría ser usada fuera usando dicho nombre.
jmarranz, yo creo que si agregan algo de inferencia de tipos, desde mi humilde punto de vista, esta funcionalidad que tu pides vendría implícita de la siguiente manera:
final String saludo = "Hola";
// aquí := es el inicializador/declarador que infiere el tipo de obj
obj := new Object{
String msg = saludo;
public void hola() { System.out.println(msg); }
};
obj.hola();
El lenguaje Java esta bien como esta (escepto alguna cosilla), yo mejoraria otras cosas fuera del lenguaje tipo:
Servicios de Windows /Demonios
Mejora integracion con Windows(que deja de ser multiplataforma 100% , pues si pero ganaria mucho)
Integracion con *.dll, *.so mas sencilla
en cuanto al lenguaje con delegados me basta
Yo en muchas ocasiones, y en un proyecto que tengo en marcha el vencedor ha sido .Net frente a java por estas razones. Sin duda preferia java, pero .net me facilita mucho mas la vida
Si java agregara eso dejaria .net y seria muyyyyyyyyyyy!!!!!!!!!! pero muyyyyyy!!!! feliz
en fin es tarde y no se ni lo que digo
saludos PNPF
Al anónimo anterior:
"Mejora integracion con Windows(que deja de ser multiplataforma 100% , pues si pero ganaria mucho)"
Eso es algo para mi inimaginable, loco, contradictorio, antiético, etc.
Java así como está me ha dado progreso, bienestar social, emocional y moral, y sobre todo "Libertad", libertad de elegir entre las mejores opciones en el mundo.
Sean Libres y averiguen por ustedes mismos que es lo mejor.
Saludos
JPedro
tus argumentos son demoledores
tanto daño a tu "libertad" haria la existencia de clases especificas para windows o linux???
sin animo de ofender pareces Hugos Chavez dando argumentos
"Java así como está me ha dado progreso, bienestar social, emocional y moral, y sobre todo "Libertad", libertad de elegir entre las mejores opciones en el mundo."
con esto casi me convences, solo te ha faltado llamarme demonio
saludos PNPF
Sin el concepto "multiplataforma" Java no tiene sentido. Mejor dicho, no tiene sentido para mí. Yo programo en WindowsXP, pruebo en Linux, predespliego y despliego en Solaris, con el MISMO .class...
Sin la mulitiplataforma de Java tendría que hacer las cosas de manera diferente, y creo que o será igual de sencillo.
Saludos.
Espero que no llegueis más lejos en las descalificaciones o esto acabará como una guerra de anónimos.
Respecto a la inferencia de tipos de atesti, pues no está nada mal, mi opción es más viable porque es un pequeño apaño, apenas un par de modificaciones del compilador.
Anónimo: Integracion con *.dll, *.so mas sencilla
Bueno, algunos nos hemos roto los cuernos para conseguir más o menos lo que tu pides. Te doy ideas:
* JNIEasy
* JNA
Coincido con jmarranz con respecto a las excepciones: este es uno de los aspecto más criticados de Java.
Por lo demás, de verdad que a mi lo que me gustaría es que tuviera menos cosas, no más... perotal y como van los tiempo, creo que lo mio es una batalla perdida.
Yo en lugar de agregar nuevas funcionalidades corregiría la implementación de Generics, que en ocasiones pueden provocar varios dolores de cabeza.
Yo añadiría, como siempre digo, diseño por contrato y también, como dice el último anónimo, corregir la implementación de los genéricos.
aunque a mi no me molestaria que incluyeran alguno de los cambios mencionados, a mi el lenguaje me dejo de importar hace un buen tiempo, a mi me interesa rendimiento, escalabilidad, mejor soporte a otros lenguajes, invoke dynamics, mvm, modulos, algo como JavaRebel integrado al JDK, mejor API para manejar archivos, cosas de ese estilo que realmente me harian mucho mas feliz.
Los lenguaje en estos tiempos comienzan a ser algo mas de gustos, comodidad (entre mas comodo me siento, mas rapido programo), costumbres, pereza, ignoracia tal vez? etc. La plataforma, el bytecode, el entorno de ejecucion y los IDEs es lo que realmente importa.
Y si alguien quiere seguir programando en java pero tener soporte para otras cosas (closures, etc) que programe en Groovy (el primo moderno de Java), si no me creen:
Clase Groovy:
public classs MyClaseGroovy{
private String hacerAlgo;
public String hasAlgoUtil(BigDecimal a, BigDecimal b){
BigDecimal c = a + b;
println("Joder esto es igual que java, pero puedo imprimir esto: $c mejor");
return "si tienes razon, $a + $b es igual a $c"
}
}
De acuerdo con que el lenguaje es cuestion de gustos. Es mas, he provado groovy y esta muy bien, pero que mas da, el editor hace cas¡ todo. Para mi es mas agil programar en java y dejar que el autocompletado complete, que me sujiera los metodos, que me cree los catch cuando es necesario, que implemente los metodos necesarios dandole a la bombilla, sin teclear nada. Una variable solo la escribo la primera vez en todo el proyecto, luego uso ctrl-space.
Con groovy y sin tipado, pues no, a picar teclas. A buscar que metodos tiene la variable sin tipado. Por que para el compilador esta claro que si tiene plumas y hace cuac es un pato, pero cuando escribes el codigo aun no puede saber si es pato o avestruz. Adios ctrl-space.
Ahora, mola mucho hacerte un map, partirlo, doblarlo y peinarlo en una sola linea super-elegante. Pero francamente me da igual. En java el editor me avisa si intento ordeñar un pato en vez de una vaca.
Una cosa que se me había olvidado...
Se ha comentado el tema de las excepciones comprobadas. Es verdad que a veces se recarga mucho el código añadiendo todas las excepciones comprobadas necesarias pero yo me pregunto -y lo digo en serio, sólo me lo pregunto- si realmente es buena idea seguir el ejemplo de C#. Lo digo porque en Microsoft existe un proyecto llamado Spec# que pretende dotar a C# de características que faciliten lograr un código correcto; entre estas características están el diseño por contrato y mira por dónde las excepciones comprobadas. Eso me hace dudar de hasta qué punto ellos mismos piensan de verdad que las excepciones comprobadas sobraban.
Saludos.
Es seguro que cualquier mejora que se destaque en Java sera copiada por C#, pero aunque se mantengan copiando a Java no creo que puedan superarla,ellos tienen el temor de que les roben el mercado pero por estable que sea siempre tendra algunas deficiencias
"Es seguro que cualquier mejora que se destaque en Java sera copiada por C#"
Como cuál mejora?
jomaveger: "Lo digo porque en Microsoft existe un proyecto llamado Spec# que pretende dotar a C# de características que faciliten lograr un código correcto; entre estas características están el diseño por contrato y mira por dónde las excepciones comprobadas. Eso me hace dudar de hasta qué punto ellos mismos piensan de verdad que las excepciones comprobadas sobraban."
Las características de Spec# serán parte de .Net 4.0, no de la sintáxis de C# (por el momento). Los contratos de excepciones especifican qué excepciones puede arrojar un método y qué garantías tiene el cliente sobre el estado del objeto después de una condición excepcional, pero no va hasta la comprobación de si se está tratando la excepción como en Spec# o Java, cuando menos en lo que se ha publicado del CTP.
De cualquier manera, cuando se incorpore el diseño por contrato en la sintáxis de C# (quizá en la versión 5), sólo será azucar sintáctica sobre la librería de contratos de .Net 4.0 y ésta no contempla, cuando menos en esta versión, el tratamiento de excepciones checadas al estilo Java. Si en Microsoft no pensaran de verdad que la excepciones checadas como parte del lenguaje sobraban, hace mucho tiempo que se las hubieran agregado a C#.
10 PRINT "HELLO"
20 GOTO 10
Esto era programar y no lo de ahora.
Jejeje.
A mi me gustaría que permitieran decidir si quieres pasar un parametro por valor o por referencia, no es que lo use muy amenudo, pero, a veces toca y hay que hacerse mucho lio con tipos primitivos por referencia.
Estoy de acuerdo.
Parámetros por valor o referencia. El final en los objetos no me sirve, ya que puedes modificar cualquier valor del objeto.
No estaría mal que al pasar un objeto por valor se hiciese una copia del objeto automáticamente. Esto haría que el código fuese algo más limpio ya que cuando pasas un objeto a una función no sabes si la función modifica, o no, alguno de sus valores u objetos contenidos.
JJRoset.
Me gustaría... (Igual y ya lo hace pero lo desconozco)
1. Que usara xml, xpath de forma nativa.
2. Que hubiera un tipo array asociativo como en php
3. una manera fácil y económica de cargar beans
Estaría molt requete be (aglutinando mex-catalá jejeje)
Escribe tu comentario