Rellena esta pequeña encuesta para ayudar a definir el nuevo API de fechas Java
AbrahamSi dentro de las librerías Java hay algo que se puede considerar un "Epic fail", probablemente sea la gestión de fechas. Estas deficiencias son lo que hizo que naciese la librería open source Joda-Time, e inspirada en ella el Java Specification Request 310, "Date and Time API". Este JSR, que finalmente no pudo incluirse en Java 7 por no completarse a tiempo, se incluirá en Java 8.
En ese momento Stephen Colebourne, miembro de Apache y uno de los líderes del JSR 310, ha creado una pequeña encuesta para preguntar a los desarrolladores Java qué nombres les gustaría que tuviesen algunos métodos y enumeraciones que formarán parte de esta nueva API. Son tan sólo 10 preguntas sencillas que servirán al grupo de expertos de la especificación para decidir en los nombres definitivos de un conjunto de clases que todos nosotros tendremos que padecer para bien o para mal en Java 8.. Así que ¡aprovecha esta oportunidad para proporcionarles tu realimentación!.
Reader Comments (11)
Gracias por la información, abraham, yo ya he votado. Se agradece que le den a uno la oportunidad de opinar en esas cosas.
Por cierto, eso de gestionar los meses con un enum no sonaba muy bien...
los enum son el futuro deberíamos olvidarnos de los hacks del pasado que ahora no son necesaria enum typesafe claro no da oportunidad al error con una constante a la forma antigua podías ponerle cualquier cosa como que seleccione el mes 20 o el mes -21 y luego saltaría un bonito error en tiempo de ejecución
enum mas importación estatica es muy fácil de leer y entender
Los enum son presente. Existen desde JavaSE 1.5
Un ejemplo, algo largo, pero bastante significativo, de cómo se usan actualmente:
private enum ComboItems {
Contains {
@Override
public String toString() {
return fileContains;
}
@Override
PathFilter getFilter(String name) {
return PathFilters.getFileContainsFilter(name);
}
},
Starts {
@Override
public String toString() {
return fileStarts;
}
@Override
PathFilter getFilter(String name) {
return PathFilters.getFileStartsWithFilter(name);
}
},
Ends {
@Override
public String toString() {
return fileEnds;
}
@Override
PathFilter getFilter(String name) {
return PathFilters.getFileEndsWithFilter(name);
}
},
Is {
@Override
public String toString() {
return fileIs;
}
@Override
PathFilter getFilter(String name) {
return PathFilters.getFileMatchesFilter(name);
}
};
private static String fileContains, fileStarts, fileEnds, fileIs;
private static final Map<String, ComboItems> LOOKUP = new HashMap<>(2 * ComboItems.values().length);
abstract PathFilter getFilter(String name);
static {
final ResourceBundle bundle = JPToolsI18NServices.getI18N().getFBrowserBundle();
fileContains = bundle.getString("FileName contains");
fileStarts = bundle.getString("FileName starts");
fileEnds = bundle.getString("Filename ends");
fileIs = bundle.getString("FileName is");
for (final Iterator<ComboItems> it = EnumSet.allOf(ComboItems.class).iterator(); it.hasNext();) {
final ComboItems items = it.next();
LOOKUP.put(items.toString(), items);
}
}
public static List<String> getItems() {
return Arrays.asList(fileContains, fileStarts, fileEnds, fileIs);
}
public static ComboItems getField(final String element) {
return LOOKUP.get(element);
}
public static PathFilter getFileFilter(final ComboItems comboItem, final String name) {
return comboItem.getFilter(name);
}
}
Completamente de acuerdo en que los enum son algo muy útil: te permiten trabajar con nombres en lugar de códigos, iterar sobre el conjunto de enumerados y asegurar que no te sales del rango, entre otras cosas.
Lo que pasa con la propuesta de fechas que están haciendo es que:
- Todos los otros campos se manejan como int (year, day, minute, hour, etc.). Veo bastante raro manejar todo como int y que en los meses sea un enumerado.
- El caso de los meses no es como el de los Comboitems del ejemplo de choces. Todo el mundo desde muy pequeño conoce los meses del año, sabemos que los meses del año son doce y que, por ejemplo, mayo es el quinto mes. Es algo que domina cualquier persona de cualquier parte del mundo ya sea peluquero, economista o programador.
- Respecto al argumento de Luis sobre que con int puedes poner el mes 21: también se puede poner para una fecha el día 42, la hora -47 y el minuto 99 y no se está proponiendo usar un enum para las horas o los minutos.
public enum Months {
January {
@Override
public int getMonth() {
return 1;
}
@Override
public int getDays() {
return 31;
}
},
February {
@Override
public int getMonth() {
return 2;
}
@Override
public int getDays() {
return isLeapYear() ? 29 : 28;
}
},
// resto de los meses siguen aquí...
public abstract int getMonth();
public abstract int getDays();
}
Que es una manera de aglutinar datos conocidos, e inmutables, dentro de una estructura simple y eficaz. Es fácil añadir nuevas propiedades, si fuese necesario, como por ejemplo, la internacionalización de los nombres de los meses, de una manera similar al ejemplo del Combo anterior.
El problema que le veo a usar la enumeración para obtener los días de un mes es cómo se resolvería isLeapYear(). Un enum no tiene estado y el año habría que pasarlo como parámetro, ¿no?
En cualquier caso, queda claro que si has votado, choces, ha sido a favor de que haya un enum para los meses :-)
Lo de isLeapYear() es un (mal) ejemplo :D
Está claro que algún año debe pasarse como parámetro para determinar si es bisiesto o no.
En cualquier caso, ese método (con su parámetro) tanto puede ser un private static del propio enum, o uno público "importado" de otro enum, u otra clase.
Dada la flexibilidad, y seguridad, que ofrecen los enum, sí he votado a favor de ellos ;)
La gestión de fechas no es tan Epic Fail como se expone en el principio de este artículo al menos no tanto como la gestión de E/S de puertos (serie, usb, etc...) o la gestión de aquello relacionado con la multimedia
Para mi mas terrible que el manejo de fechas es el método close() del InputStream con su IOException
Tener que usar IOUtils.closeQuietly( ... ) me molesta muchísimo (intelectualmente digo)
Con el tema del enum @lacayo, que se haga un enum no quita que se pueda utilizar alguna forma de obtener el enum correspondiente dado un int (creo que es bastante trivial de hecho)
Saludos
@diego
Eso está resuelto en JavaSE 1.7 donde InputStream implementa AutoCloseable.
http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html
Listo ya vote. La verdad que no me termina de convencer el enum, pero en fin habrá que adaptarse si al final lo agregan.
Por otro lado, ¿alguien sabe si este JSR trae una actualización al manejo de fechas en Jdbc (que es otro dolor de cabeza)?
K'