Скажите, что у Вас есть крупный ColdFusion прежней версии сверху Java сверху Приложения Windows. Доступ к файлу сделан оба через java.io. Файл и CFFILE (который в свою очередь также использует java.io. Файл), но не централизованный всегда в единственную библиотеку доступа к файлу. Далее, скажите, что у Вас есть пути к файлам, и трудно кодированные в коде, и также в базе данных.
Другими словами, предположите, что сами пути к файлам не могут измениться. Они могли быть или локальными или удаленными путями к файлам Windows:
Существует ли способ запустить это приложение на Linux с минимальными изменениями кода? Я ищу интеллектуальные решения, которые не включают касание унаследованного кода.
Некоторые идеи:
Есть ли способ переопределить java.io.File для выполнения преобразования пути к файлу с помощью специального кода? В этом случае я бы перевел удаленные пути в точку монтирования
. Да, вы можете выполнить свою собственную реализацию java.io.File
и поместить ее в отдельный jar-файл, а затем загрузить его вместо настоящий java.io.File
.
Для загрузки JVM вы можете использовать свойство java.endorsed.dirs
или параметр java -Xbootclasspath / p: path
в средстве запуска java (java)
НО!!!
Создать собственную версию класса java.io.File
будет не так просто, как изменить унаследованный исходный код.
Если вы боитесь что-то сломать, вы можете сначала извлечь все свои жестко запрограммированные пути, чтобы использовать пакет ресурсов:
Итак:
File file = new File("C:\\Users\\oreyes\\etc.txt");
Будет:
File file = new File( Paths.get( "user.dir.etc" ));
И Пути
будут иметь пакет ресурсов внутри
class Paths {
private static ResourceBundle rs = ResourceBundle.getBundle("file.paths");
public static String get( String key ) {
rs.getString( key );
}
}
Вы можете получить все это жестко запрограммированное извлечение путей с помощью IDE (обычно плагина интернационализации)
. Предоставьте другой пакет ресурсов для Linux, и готово. Тестирование, повторное тестирование и повторное тестирование
Итак, используйте предоставить свой собственный java.io.File
только в качестве последнего ресурса.
java.io.File
не является окончательным классом и может быть расширен. В вашем расширении может быть один (или несколько) конструкторов, которые будут переводить пути к файлам. Это потребует только написания транслятора и изменения каждой инициализации File для расширенного класса.
Поскольку ваш класс будет расширять java.io.File
, никаких других изменений кода не требуется, кроме изменения инициализации.
java.io.File file1 = new ClassThatExtendsFile("C:\temp\file.txt");
[edit]: или вы можете расширить CFFILE и переопределить его конструкторы.