Obtener directorio del ".class"

[jrariasf]

Hola,
¿Cómo puedo obtener el directorio en el que se encuentra el fichero ".class" de la clase que estoy ejecutando?

Por dar más información, la Property "user.dir" contiene "C:\Documents and Settings\Jose Ramon".
Sin embargo el directorio donde se encuentra el ".class" es "C:\Download\MisPruebas".

Me he creado un ejecutable con el JEXECreator y obtengo el fichero "C:\Download\MisPruebas\Prueba.exe".
Si desde la consola de MSDOS me voy al directorio "C:\Download\MisPruebas" y ejecuto el programa con así: "Prueba fichero", todo va bien.

Sin embargo, si desde Windows pincho y arrastro un fichero sobre el icono del ejecutable "Prueba.exe", me toma como "user.dir" el "C:\Documents and Settings\Jose Ramon" y entonces no encuentro unos ficheros de imágenes que tengo en el directorio original donde se encuentran las clases o el ejecutable que es "C:\Download\MisPruebas".

De ahí mi pregunta inicial.... no sé si habría alguna forma de obtener el directorio donde realmente se encuentra el ".class" y así actualizar la Property "user.dir".
Muchas gracias y un saludo.

[GreenEyed]

Encontrar el fichero donde se encuentra el .class es posible, pero es mucho mejor cargar las imagenes usando getResource, por ejemplo, y asi tienes independencia total, las puedes incluir en un .jar etc. etc.

Aqui puedes ver más informacion:
http://java.sun.com/docs/books/tutor...ml#getresource

Y buscando por "cargar imagen getResource" te saldran mas cosas.

S!

[jrariasf]

Iniciado por GreenEyed

Encontrar el fichero donde se encuentra el .class es posible, pero es mucho mejor cargar las imagenes usando getResource, por ejemplo, y asi tienes independencia total, las puedes incluir en un .jar etc. etc.

Aqui puedes ver más informacion:


Y buscando por "cargar imagen getResource" te saldran mas cosas.

S!

Hola,
¿Y cómo se podría localizar el ".class"?
Es que lo de la imagen que tengo que buscar es un ejemplo que he dado para simplificar la explicación.... Lo que necesito es saber el directorio donde está el ".class" asociado con la clase/objeto que está en ejecución.

A ver si puedes ayudarme en eso.
Muchas gracias y un saludo.

[GreenEyed]

Y por curiosidad, ¿para que necesitas saberlo? Vaya por delante que la propiedad "user.dir" creo que no se puede modificar una vez arrancada la JVM.

S!

PD: Luego te miro lo del .class pero ahora tengo que irme

[jrariasf]

Iniciado por GreenEyed

Y por curiosidad, ¿para que necesitas saberlo? Vaya por delante que la propiedad "user.dir" creo que no se puede modificar una vez arrancada la JVM.

S!

PD: Luego te miro lo del .class pero ahora tengo que irme

Hola,
Por las pruebas que he hecho yo, sí se puede modificar la propiedad "user.dir".

El porqué de todo esto, intento explicarlo brevemente:
- He colgado en la red un programita llamado JSigpac que permite generar mapas más o menos grandes a partir de una serie de mapas o cuadrantes pequeños (Tienes más información en http://www.lanzadera.com/jsigpac).

Para facilitar su uso a la gente y que no tuviese que andar ejecutando con "java JSigpac", lo que hice fue generar un ejecutable "JSigpac.exe" con una utilidad que hay port ahí llamada JEXECreator.
Hasta ahora no ha habido ningún problema pero una opción del programa es que si se le pasa el nombre de un fichero como primer argumento, pues a continuación descarga el mapa topográfico asociado a la ruta que hay en ese fichero.
Con lo cual, si tú desde el Explorador de Windows pinchas y arrastras un fichero con una ruta sobre el icono del ejecutable "JSigpac.exe", automáticamente empieza a descargar y a generar el mapa topográfico.
Pero ¿cuál es el problema? Pues que al hacerlo así, el directorio de trabajo, en lugar de ser el directorio donde está el ejecutable, pasa a ser otro que es el "C:\Documents and Setting\José Ramón" (o el usuario que sea).

Y resulta que en el directorio donde está el ejecutable hay un subdirectorio llamado "dat" donde guardo algunos ficheros que pueden ser modificados por el usuario para configurar diferentes cosas del programa. Pero laro, no encuentra esos ficheros de configuración porque busca en la supuesta carpeta "dat" del directorio "C:\Documents and Setting\José Ramón".

No sé si ha quedado más o menos claro el problema... El caso es que el programa consta al final de un ejecutable y de una carpeta que cuelga del mismo directorio en el que se encuentra el ejecutable. Pero como el directorio de ejecución cambia dependiendo de si:
1.- o bien utilizo el método de pinchar y arrastrar un fichero sobre el icono del ejecutable; o bien
2.- ejecuto el programa haciendo doble-click sobre él y ya después en el interfaz gráfico que ofrece cargo el fichero con la ruta.

Gracias de nuevo y a ver si con esta "aclaración" puedes ayudarme
Un saludo.

[Willie]

Supongo que con el setProperty puedes cambiar el user.dir, pero no se si eso solucione tu problema, porque igual tienes tu que especificar el directorio donde esta tu class (es decir, no lo detecta automaticamente).

Yo diria que podrias envolver tu aplicacion en un script (archivo batch .bat, en Windows) donde primero cambias al directorio donde esta tu clase, y luego invocas a tu aplicacion; alternativamente podrias simplemente especificar a la JVM el user.dir.

Sugerible seria parametrizar (?) en este archivo la ruta hacia tu directorio donde se encuentra la clase, en caso quisieras mover el .bat a otra maquina. Este archivo .bat adicionalmente tendria un parametro: el archivo que quieres cargar.

No se si el archivo batch soportaria que le `arrastres' ficheros; pero presumo que si: Windows los pasaria como parametros (no trabajo mucho con Windows).

[GreenEyed]

Una opcion tambien es usar un directorio conocido para almacenar los ficheros temporales, de trabajo. Asi no dependes del directorio donde esta instalada la aplicacion. Como user.home más algo etc.

En todo caso, para averiguar donde esta un .class, puedes intentarlo con el metodo

myClass.getProtectionDomain().getCodeSource().getL ocation();

De todas formas, creo que no te aseguran al 100% que todos los JDK devuelvan un valor coherente, ya que el API permite que getCodeSource() devuelva null.

S!