Jarhalla-local, encuentra el jar donde está esa clase
¿Alguna vez has tenido un ClassNotFoundException y has tenido que investigar a mano en qué jar estaba esa clase, y si realmente estaba añadido al proyecto o no?. Jarhalla-local es una sencilla herramienta que pretende ayudar en esta tarea. Se trata de una aplicación Swing opensource. En ella simplemente apuntamos a un directorio donde haya archivos jar y nos permite buscar empleando un campo de texto clases. Según vamos tecleando algo en ese campo de texto la aplicación nos muestra todas las clases que contienen el patrón tecleado y nos indica en qué archivo jar se encuentran. Lo que tecleemos podría ser tanto el nombre de una clase como de un paquete, y podemos emplear comodines.
Además, la herramienta detecta automáticamente si en el sistema tenemos instalada alguna herramienta para el control del ciclo de vida de un proyecto como Maven, Gradle o Ivy, y, automáticamente sin que el usuario haga nada, Jarhalla-local identifica el repositorio donde dicha herramienta almacena sus artefactos y nos permite hacer búsquedas sobre él.
Jarhalla-local todavía no ha llegado a su versión 1.0, pero está cerca ya es usable. Lo ha construido un veterano de esta comunidad, Isaac Ruiz Guerra (Rugi), y podéis encontrar su código fuente en GitHub. Aquí os dejo un pequeño video donde Isaac demuestra el funcionamiento de la aplicación:
Jarhalla-local Casi la v. 1 from Isaac Ruiz Guerra on Vimeo.
La aplicación es una "versión de escritorio" de otro proyecto de Isaac: Jarhalla, un buscador online de Jars donde nuevamente podemos buscar en qué archivos jar está una determinada clase. El buscador tiene indexados los archivos jar de múltiples repositorios open source.
¿Creéis que o resultaran útiles las herramientas Jarhalla-local y Jarhalla?
Reader Comments (15)
¿Util?... mucho más que útil.
Sobre todo ahora que hay tendencia a Frameworks que automatizan tareas y se supone que resuelven dependencias, pero que muchas veces fallan y te dejan tirado y parado en mitad del desarrollo.
Desde luego, para mí va a ser un fijo en mis marcadores.
Hace mucho que IntelliJ tiene esa funcionalidad (ctrl+n)
Me gusta la idea pero la verdad la he probado y va muy lenta al usar Swing.
Definitivamente pienso que java no es bueno para el escritorio, va siempre muy lento.
MMM a mí no me va lento ¿en qué sentido dices que "va lento" ?
Precisamente he tenido varios ClassNotFoundException esta misma mañana, después de un cambio bastante drástico en las dependencias de módulos, y NetBeans informa con mucha precisión dónde se ha producido la excepción, y las causas, por lo que localizar el módulo y las clases involucradas es cuestión de segundos.
@Miguel Tormo
"Java es lento, Swing es lento" son dos tópicos recurrentes, al igual que falsos.
También se puede escribir código muy mediocre en Java, lo mismo que en otros lenguajes, con resultados lamentables. Pero de ahí a deducir que el problema es el lenguaje, va más de un abismo.
Lo "lento" es aprender a usar a Swing con eficiencia, porque no es nada sencillo.
Yo siempre he usado ClassFinder desde la linea de comandos para hacer esto.
Aunque con este programa se hace todo más visual :-)
Con el winrar también puedes hacerlo.
Hombre, la idea del Winrar me parece ridículo; como tengas unas cuantas librerías vas a flipar abriendo archivo archivo y buscando dentro.
Respecto a lo de IntelliJ ¿Te busca también en los repositorios de Maven?.
Por otro lado, la versión online de JarHalla es bastante útil cuando el problema simplemente es que tú no tienes la librería; por ejemplo, alguien te pasa un proyecto y al ejecutarlo resulta que se lanza un ClassNotFoundException de una clase que no tienes ni idea de qué es, y te toca comenzar a buscar por Google (o al menos eso es lo que yo hacía antes),
Hola a todos!!
:)
Gracias por los comentarios.
La idea es que al final pueda tener una herramienta integral (unir jarhalla-local con la parte web).
La opción por línea de comandos la veo más sencilla con herramientas como JLine, así que, no duden que pronto esté incluida.
En general jarhalla-local es una herramienta muy sencilla, pero, útil.
Debido a la naturaleza de mi trabajo diario, es normal que cada semana toque un nuevo ambiente de desarrollo, por lo que, se me hizo sencillo comenzar a generar este tipo de herramientas para ayudarme en el día a día.
Espero que en algún momento les sea de utilidad.
Saludos!!
---
RuGI
En todos los lenguajes se puede escribir mal código, pero no creo que sea problema del lenguaje porque veo pocas aplicaciones por ejemplo en C++ lentas. Por supuesto que, usualmente (que nadie me malinterprete), un programador de C++ está mas acostumbrado a mirar la perfomance. Pero no creo que sea el tema.
Hay una metáfora que me gusta para esto: Si tu quieres indicar el camino hacia tu casa y le das a la gente un mapa que poca gente sabe usar, casi todo el mundo se perderá. Tú puedes decir que casi todo el mundo es idiota por no saber usar un mapa, o puedes cambiar el mapa. Es cuestión de asumir las cosas.
Cuando abres aplicaciones en Java que supuestamente han programado buenos equipos, por ejemplo netbeans o eclipse, y van lentas es cuando te das cuenta de esto que cuento.
Y ojo que no quiero flames, esto lo dice un programador java orgulloso de serlo. Pero las cosas son como son.
Hola Miguel!
Entiendo el punto, la aplicación aún no está optimizada, y la intención es dar tambien la opcion de usarla en línea de comandos.
Gracias por tus comentarios!
Saludos!
---
RuGI
Sobre la cuestión de fondo: Java es lento, o son lentos los programadores.
String test1 = "abc,cde,def";
String[] splitted1= test1.split(",");
Pattern pattern =Pattern.compile(",");
String[] spliited2=pattern.split(test1);
Ambos "splitted" obtienen los mismos resultados; sin embargo, basta con realizar un loop lo suficientemente grande sobre cada uno, para llevarse una sorpresa en los tiempos de ejecución:
splitted2 se ejecuta a mucha más velocidad que splitted1, a pesar de las apariencias.
Hola choces!!
No me había topado con lo que comentas en la vida real, pero, espero hoy mismo agregar tu recomendación ;)
Lo que sí me he topado, y se notará en el código es, la concatenación de cadenas,
desde hace años StringBuffer (y ahora) StringBuilder son mis amigos.
Vi varios servers enterprise caer por algo "aparentemente" insignificante (hasta que conoces como maneja java los String's)
Saludos!!!
---
RuGI
Una anotación al margen: en JavaSE 1.7 se han hecho cambios en el código del método split de la clase String, precisamente con el objeto de eliminar la necesidad de tener que recurrir siempre al Pattern, como se hacía en versiones anteriores de JavaSE.
Existe una nueva técnica, denominada internamente fastrack, que con determinadas condiciones en el delimitador, realiza el split sin usar el Pattern.compile interno.
No hay, que yo sepa, pruebas de rendimiento comparado para JavaSE 1.7
Para los interesados, aquí hay una reciente discusión sobre el asunto del split:
http://eblog.chrononsystems.com/hidden-evils-of-javas-stringsplit-and-stringr