2014-06-12 12 views
5

W systemie UNIX i jego pochodnych pliki konfiguracyjne aplikacji znajdują się pod/etc /, podczas gdy w innych systemach Windows. Filozofią java jest "Napisz raz, biegnij wszędzie", a aplikacja idealnie nie powinna dbać o to, na czym działa OS. Ale chcę, aby moja aplikacja ładowała plik konfiguracyjny podczas uruchamiania i muszę podać ścieżkę. W tej chwili ładuję różne lokalizacje plików wyłączając nazwę systemu operacyjnego, ale to nie wydaje się być najlepszą praktyką w Javie. Jak mogę to pogodzić?Sprawdzone metody Java dla lokalizacji plików konfiguracyjnych

+1

Kiedy powinien być przenośny, nie widzę nic złego w jego posiadaniu w katalogu aplikacji. – user432

+0

Java ma już interfejs API preferencji, który obsługuje różnice w systemie operacyjnym. http://docs.oracle.com/javase/7/docs/api/java/util/prefs/Preferences.html –

Odpowiedz

1

Kiedy tworzę grę/aplikację, po prostu umieszczam folder zasobów w tej samej ścieżce, co aplikacja. Na przykład w kodzie, katalog będzie miał postać "res/config.yml". W tym samym folderze co jar umieszczasz folder zasobów o nazwie "res". następnie umieść plik w pliku res. Tak więc aplikacja powinna pobrać plik.

0

W naszej aplikacji używamy różnych lokalizacji do konfiguracji w każdym systemie operacyjnym.

Na Linuksie

/etc/ApplicationName

W Windows

[Użyj Wybrane Install Dir]/conf

Kontrolujemy gdzie wygląd aplikacji za pośrednictwem właściwości systemowej

-Dconf.dir = ścieżka

nie koniecznie, że istnieje prawidłowa odpowiedź w tej sprawie.

0

Zwykle umieszczam pliki konfiguracyjne w katalogu .<appName> (zwróć uwagę na punkt wiodący) w domu użytkownika, który jest odczytywany w środowisku wykonawczym przez System.getProperty("user.home"). Jest to oczekiwana lokalizacja dla użytkowników systemu Linux, podczas gdy w systemie Windows wydaje się nieco egzotyczna (w porównaniu z katalogami profilowymi, takimi jak AppData/Local lub AppData/Roaming), nawet jeśli jest to bardzo popularny wybór dla narzędzi wieloplatformowych. Korzystanie z domu obecnego użytkownika oznacza, że ​​zazwyczaj nie masz problemów z prawami dostępu do systemu plików, a zamiast niestandardowej właściwości preferowane jest używanie user.home, ponieważ jest ono dostarczane z pudełka przez system (i nadal może być przesłonięte)

Innym podejściem jest użycie katalogu instalacyjnego, ale musisz użyć zmiennej środowiskowej, która wskazuje na to, np. $APP_HOME, ponieważ nie można jej wywnioskować w czasie działania aplikacji (w rzeczywistości można uzyskać katalog JAR wdraża grę, grając z adresami URL zwróconymi przez główną klasę ClassLoader, ale uważam, że jest to hack i nie należy jej używać). Aplikacja może odczytać zmienną za pomocą System.getenv("APP_HOME"), a ta zmienna musi być ustawiona za pomocą skryptów zależnych od platformy, które udostępniasz w celu uruchomienia aplikacji. Ta strategia ma tę wadę, że bieżący użytkownik może nie mieć praw do odczytu/zapisu do wskazanego katalogu.

Powiązane problemy