Java: en busca de hack para manejar las rutas de archivos de Windows en Linux

Question

Digamos que tiene un gran ColdFusion heredado sobre Java en la parte superior de la aplicación de Windows. El acceso a los archivos se realiza a través de java.io.File y de CFFILE (que a su vez también usa java.io.File), pero no se centraliza de ninguna manera en una única biblioteca de acceso a archivos. Además, supongamos que tiene rutas de archivos codificadas en el código y también en una base de datos.

En otras palabras, suponga que las rutas de archivo no pueden cambiar. Podrían ser considerados como rutas de archivos de Windows locales o remotos:

• c: \ temp \ archivo.txt
• \\ server \ share \ archivo.txt

¿Hay una manera de ejecutar este aplicación en Linux con cambios mínimos de código? Estoy buscando soluciones creativas que no impliquen tocar el código heredado.

Algunas ideas:

• ejecutarlo en vino. Esto realmente funciona, porque WINE traducirá las rutas locales y tiene un cliente samba para las rutas remotas.
• ¿Hay alguna manera de anular java.io.File para realizar la traducción de la ruta del archivo con código personalizado? En este caso, traduciría las rutas remotas a un punto de montaje.

Answer 1

¿Hay una manera de anular java.io.File para llevar a cabo la traducción ruta de archivo con código personalizado? En este caso, me gustaría traducir los caminos remotos a un punto

Sí montaje, puede realizar su propia implementación de java.io.File y colocarlo en un recipiente separado y luego cargarla en lugar de la verdadera java.io.File.

Para que la carga JVM que se puede utilizar la opción java.endorsed.dirs propiedad o java -Xbootclasspath/p:path en el lanzador Java (Java)

pero !!!

La creación de su propia versión de la clase java.io.File no será tan fácil como modificar el código fuente legado.

Si tienes miedo de romper algo que se podía extraer primero todos sus caminos codificados a utilizar un paquete de recursos:

Así:

File file = new File("C:\\Users\\oreyes\\etc.txt"); 

sería:

File file = new File(Paths.get("user.dir.etc")); 

Y Paths tendría un paquete de recursos internamente

class Paths { 
    private static ResourceBundle rs = ResourceBundle.getBundle("file.paths"); 
    public static String get(String key) { 
     rs.getString(key); 
    } 
} 

Usted puede tener toda esta extracción caminos codificados con un IDE (por lo general un plugin de internacionalización)

Proporcionar un paquete de recursos diferentes para Linux y listo. Pruebe y vuelva a probar y vuelva a probar

Por lo tanto, utilice su propio java.io.File solo como último recurso.

Answer 2

El java.io.File no es una clase final, y puede ampliarse. En su extensión puede tener uno (o más) constructores que traduzcan las rutas de archivos. Esto solo requerirá que escriba el traductor y cambie cada inicialización de File para su clase extendida.

Dado que su clase se extendería java.io.File no es necesario otro cambio de código que no sea cambiar la inicialización.

java.io.File file1 = new ClassThatExtendsFile("C:\temp\file.txt"); 

[editar]: o se puede extender el cffile, y anular es constructores.