library - ¿Hay algo como LINQ para Java?
linq en java (8)
Comenzó a aprender LINQ con C #.
Especialmente LINQ to Objects y LINQ to XML.
Realmente disfruto el poder de LINQ.
Aprendí que hay algo llamado JLINQ una implementación de Jscript.
También (como Catbert publicó) Scala tendrá LINQ
¿Sabes si LINQ o algo similar será parte de Java 7?
Actualización: Publicación interesante desde 2008 - LINQ para la herramienta Java
¿Hay algo tan simple de usar como LINQ-2-SQL en la JVM? Quiero generar entidades (clases) desde el esquema de base de datos utilizando alguna herramienta y usarlas para interactuar directamente con la base de datos. ¿Hay una solución libre de XML? No quiero tener que anotar las clases. En .NET, la herramienta se llama sqlmetal. Es una especie de preprocesador que genera todas las clases de DB, por así decirlo.
Una vez hecho esto, creo que será bastante fácil usar las construcciones de lenguaje incorporadas de Scala.
Al utilizar la biblioteca lambdaj , puede encontrar los usuarios de mayor reputación de la siguiente manera:
List<User> topUsers =
select(users, having(on(User.class).getReputation(), greaterThan(20000)));
Tiene algunas ventajas con respecto a la biblioteca Quaere porque no utiliza ninguna cadena mágica, es completamente segura y, en mi opinión, ofrece un DSL más legible.
CQEngine o Collection Query Engine http://code.google.com/p/cqengine/ parece extremadamente prometedor. Aunque no lo he intentado. Te permite construir índices sobre colecciones y consultarlos. Se supone que es muy rápido.
Echa un vistazo a Quaere . Es un DSL similar a LINQ para Java que puede incluir como una biblioteca. Ejemplo:
// Get all users with more than 20,000 reputation points.
Iterable<User> topUsers = from("u").in(entityManager.entity(User.class)).
where(gt("u.getReputation()", 20000)).
select("u");
System.out.println("Users with more than 20,000 reputation:");
for (User u : topUsers) {
System.out.println(u.getName());
}
Sin embargo, tenga en cuenta que Java no tiene un concepto análogo a los métodos de extensión. Lo que sea que esté en Quaere es bastante con lo que estás atrapado; Si necesita hacer sus propias utilidades especiales, probablemente tendrán que estar en clases de utilidades separadas (ick).
Además, como Java <7 no tiene cierres nativos, está atascado con cadenas para hacer referencia a las cosas, y su IDE no puede hacer una introspección para mostrarle problemas si se equivoca al escribir algo. (Sin embargo, un IDE más inteligente podría manejar esta deficiencia, si alguien escribiera complementos de introspección para Quaere).
Es importante tener en cuenta que LINQ son cuatro cosas:
- Comprensión monádica
- Integración de base de datos
- Sintaxis similar a SQL
- Manipulación de AST
Las personas que acaban de oírlo pueden pensar en él simplemente como integración de base de datos. Las personas que han trabajado un poco con él probablemente piensen en una sintaxis similar a la de SQL. Quienes realmente cavaron estarán conscientes del aspecto de la comprensión monádica, incluso si no lo saben por lo que es.
Si uno toma a Scala, por ejemplo, tiene una comprensión monádica sin los otros tres. Existe una biblioteca llamada ScalaQuery que proporciona integración de base de datos a través de la comprensión monádica (la capacidad intrínseca de hacerlo es la razón principal por la que las mónadas son geniales). Otro proyecto, llamado ScalaQL , creo, pretende proporcionar casi lo mismo, pero utilizando un complemento del compilador para mejorarlo. No estaba al tanto del trabajo de Miguel García que mencionaste, pero, habiendo visto otras cosas que ha logrado, me emociona.
Sin embargo, no se necesita una sintaxis especial para hacer una comprensión monádica. Simplemente lo hace ordenado por boilerplate. De modo que ese aspecto está disponible instantáneamente para los idiomas con el nivel adecuado de soporte de genéricos.
Dos cosas que Scala no hace. La primera es la sintaxis similar a SQL. Eso no se puede evitar: la sintaxis SQL parece fuera de lugar en Scala. Creo que es seguro decir que la mayoría de los programadores de Scala preferirían quedarse con lo que les es familiar: la llamada comprensión.
La otra cosa es la que no he discutido todavía, la manipulación AST. Esa es la capacidad de manipular el código que ha sido analizado por el compilador, pero que aún no se ha transformado en código de bytes, lo que le permite modificarlo antes de que se complete la generación.
Creo que tal cosa sería una bendición para Scala, diablos, para cualquier idioma. Pero, nuevamente, tengo antecedentes como programador de Forth, donde la capacidad de alterar el código a medida que se compilaba era un derecho dado por Dios. .Net puede hacerlo a través de LINQ, y también otros idiomas, como Ruby.
LINQ sería difícil en Java debido a la actual falta de cierres. Suponiendo que Java 7 realmente obtenga un soporte de cierre y métodos de extensión razonablemente compactos, LINQ en términos de "notación de puntos" debería ser factible incluso si no obtiene el equivalente de expresiones de consulta.
La Biblioteca de Google Collections (ahora en la versión 1.0, pero para ser reemplazada por Guava cuando esté lista) contiene muchos de los métodos requeridos, y no me sorprendería que aparezcan 101 API similares a LINQ en cuanto aparezca el soporte de cierre. razonablemente final
Sin embargo, no puedo ver (en este momento) que Java obtenga algo así como árboles de expresiones, así que sospecho que estará limitado a LINQ to Objects a menos que tenga una compilación personalizada.
Mire Scala , que es un potente lenguaje de programación funcional, pero es similar a Java y se ejecuta en la plataforma Java.
En Scala es posible usar esencialmente las mismas construcciones de código que en LINQ, aunque sin una sintaxis especial de comprensión de consulta presente en C # o VB.
EDITAR:
Aquí hay un ejemplo de las capacidades de consulta de Scala:
// Get all users with more than 20,000 reputation points.
val topUsers = for{
u <- users
if u.reputation > 20000
} yield u;
println ("Users with more than 20,000 reputation:")
for (u <- topUsers) {
println u.name
}
Podría intentar diting qué implementa los métodos de consulta chainable en una colección.
Integer[] values = new Integer[] {0,1,2,3,4,5,6,7,8,9,10};
Enumerable<Integer> query = new Enumerable<Integer>(values).where(new Predicate<Integer>(){
@Override
public boolean evaluate(Integer value) throws Exception {
return value % 2 == 0;
}});
for(Integer i : query)
{
System.out.write(i);
System.out.write(''/n'');
}