05-09-2013, 07:43 PM
(Este mensaje fue modificado por última vez en: 05-09-2013, 07:51 PM por Reaper45.)
Sé que algunos de vosotros programáis/programábais en Java, así que a lo mejor suena la flauta si os pregunto.
Veréis, tengo entre manos cierto proyecto Android. El proyecto ni siquiera tiene entry point de ninguna clase, pues resulta que es un plugin. Dicho .APK sólo sirve como vehículo y la aplicación principal se encarga de cargarlo todo mediante reflection. Esto tiene la desventaja de que a la hora de compilar, puedes usar rutas relativas a la hora programar, pero en tiempo de ejecución explotará por todas partes, pues al usar reflection sobre la clase ésta pasa a ser parte de la aplicación principal y buscará entre sus recursos, y no los del proyecto plugin.
Para solucionar esto, calculo la ruta absoluta cuando haga falta gracias a que Android te puede dar la ruta de instalación de cualquier aplicación con una llamada a la API. Hasta ahí todo muy estable y correcto, la verdad es que me mola cómo me ha quedado el sistema de plugins.
Ahora bien, si resulta que necesito incrustarle un .JAR, la cosa se jode. No puedo editarlo pues no tengo su código fuente. Hay una llamada en el .JAR para cargar una librería nativa System.loadLibrary() que explotará si se llama dos veces, y para colmo está en el constructor. Es la primera vez que veo un programa Java suicidarse a lo bestia incluso con un try { } catch(Exception ex).
Sé que llamadas son y dónde están, porque le he pasado el Java Decompiler al fichero .jar en cuestión. Aunque me ha servido para detectar el problema, éste produce una basura de código, imposible de reutilizar y plagado de errores al estilo variables duplicadas, con nombres alienígenas y cosas por el estilo. Descartada la opción de importar los .java descompilados al Eclipse.
Si pudiese editar el fichero .class problemático para saltarse ese método, podría llamarlo una sola vez desde fuera y todo serían arcoiris de colores.
¿Habéis enredado con esto alguna vez? ¿Alguna otra solución creativa?
Veréis, tengo entre manos cierto proyecto Android. El proyecto ni siquiera tiene entry point de ninguna clase, pues resulta que es un plugin. Dicho .APK sólo sirve como vehículo y la aplicación principal se encarga de cargarlo todo mediante reflection. Esto tiene la desventaja de que a la hora de compilar, puedes usar rutas relativas a la hora programar, pero en tiempo de ejecución explotará por todas partes, pues al usar reflection sobre la clase ésta pasa a ser parte de la aplicación principal y buscará entre sus recursos, y no los del proyecto plugin.
Para solucionar esto, calculo la ruta absoluta cuando haga falta gracias a que Android te puede dar la ruta de instalación de cualquier aplicación con una llamada a la API. Hasta ahí todo muy estable y correcto, la verdad es que me mola cómo me ha quedado el sistema de plugins.
Ahora bien, si resulta que necesito incrustarle un .JAR, la cosa se jode. No puedo editarlo pues no tengo su código fuente. Hay una llamada en el .JAR para cargar una librería nativa System.loadLibrary() que explotará si se llama dos veces, y para colmo está en el constructor. Es la primera vez que veo un programa Java suicidarse a lo bestia incluso con un try { } catch(Exception ex).
Sé que llamadas son y dónde están, porque le he pasado el Java Decompiler al fichero .jar en cuestión. Aunque me ha servido para detectar el problema, éste produce una basura de código, imposible de reutilizar y plagado de errores al estilo variables duplicadas, con nombres alienígenas y cosas por el estilo. Descartada la opción de importar los .java descompilados al Eclipse.
Si pudiese editar el fichero .class problemático para saltarse ese método, podría llamarlo una sola vez desde fuera y todo serían arcoiris de colores.
¿Habéis enredado con esto alguna vez? ¿Alguna otra solución creativa?
![[Imagen: z4kSKUd.png]](http://i.imgur.com/z4kSKUd.png)