Pakowanie obrazków i plików konfiguracyjnych

Tworzymy aplikację Swingową, która korzysta z wielu obrazków oraz kilku plików konfiguracyjnych. Większość z tych plików konfiguracyjnych nie jest przeznaczona do edycji dla użytkownika, ot, prosty przyład: plik z URL'em, loginem i hasłem do połączenia JDBC.

Chcemy utworzyć "dystrybucję" aplikacji, czyli formę, w której program będzie dostarczony użytkownikowi końcowemu.

Pytanie: czy obrazki i te pliki konfiguracyjne, które przeznaczone są tylko dla programistów powinny być pakowane do jara z klasami aplikacji (nie chcemy, żeby użytkownik w nich grzebał, usunął niechcąco jakiś obrazek itd.), czy powinny się znajdować w jakichś podkatalogach (np. resource)s katalogu z aplikacją?

Szukałem w Internecie jakichś istniejących dyskusji na ten temat, ale niczego nie znalazłem. W każdym razie, kiedy patrzy się na jakieś poważne aplikacje, to przyjęte jest drugie podejście (zasoby nie są pakowane do jarów, tylko wrzucane do folderów). Stoją za tym jakieś konkretne argumenty? Czy duży rozmiar jara jest w jakiś sposób szkodliwy? Spowalnia wykonywanie aplikacji?

1. Obrazki możesz wstawić do jara i później dostawać się przez metodę getResourceAsStream
   http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getResourceAsStream%28java.lang.String%29

2. Aplikacja kliencka nigdy nie powinna się łączyć z bazą danych. Powinna wywoływać metody na serwerze, który łączy się z bazą.
   Takie rzeczy, jak adres serwera umieść wewnątrz jara w pliku tekstowym. Jeżeli użytkownik go zmieni, to jego sprawa.

__krzysiek85 napisał(a)

2. Aplikacja kliencka nigdy nie powinna się łączyć z bazą danych. Powinna wywoływać metody na serwerze, który łączy się z bazą.

A dlaczego nie? Jak ktos chce grubego klienta bez serwera specjalnego to niech sie laczy z baza.

__krzysiek85 napisał(a)

1. Obrazki możesz wstawić do jara i później dostawać się przez metodę getResourceAsStream
   http://java.sun.com/j2se/1.5.0[...]AsStream%28java.lang.String%29

Dzięki krzysiek, ale nie do końca o taką odpowiedź mi chodziło. Doskonale wiemy, że ładowanie zasobów aplikacji z jara jest możliwe, i wiemy, w jaki sposób można to robić.

Zastanawiamy się tylko, czy jest to dobra praktyka i czy są jakieś przeciwwskazania. Bo patrząc na różne inne aplikacje, to tam obrazki nie są raczej ładowane z jara, tylko z jakiegoś katalogu z obrazkami w strukturze katalogów projektu.

Np.:
Aplikacja
|
|-images
|-aplikacja.jar

Żeby podać banalny przykład.

Żeby dokładniej zarysować sytuację - nasza aplikacja jest raczej niewielka i nie ma potrzeby rozbijać jej na kilka jarów/modułów, więc wydaje nam się sensowne wrzucić obrazki do tego jednego jara z aplikacją. Gdyby było kilka jarów, to można by je wrzucić np do tego, który przechowuje moduł interfejsu użytkownika. Tylko czy to właściwa droga?

Kolega wysunął argument, że aplikacja musi sobie rozpakowywać obrazki z jara, żeby móc je wyświetlać, więc aby wyświetlać wiele obrazków potrzeba wiele rozpakowywania i może to wpłynąć negatywnie na wydajność. Czy ma rację?

ucilala napisał(a)

A dlaczego nie? Jak ktos chce grubego klienta bez serwera specjalnego to niech sie laczy z baza.

No taka jest mniej więcej nasza sytuacja. Póki co nie potrzebujemy kodu działającego po stronie serwera i prawdopodobnie nie będziemy potrzebować, dlatego łączymy się bezpośrednio z bazą. Ale dzięki za przestrogę, krzysiek.

__krzysiek85 napisał(a)

Takie rzeczy, jak adres serwera umieść wewnątrz jara w pliku tekstowym. Jeżeli użytkownik go zmieni, to jego sprawa.

Czy mogę to twierdzenie uogólnić i powiedzieć, że również inne pliki tekstowe, których użytkownik nie powinien widzieć, np. plik .properties z wykorzystywanymi przez nas zapytaniami sql'owymi wyrzuconymi poza aplikacje dla łatwiejszego utrzymania, message bundles z tłumaczenami stringów, plik konfiguracyjny log4j i wszelka inna konfiguracja, której użytkownik nie ma potrzeby oglądać a tym bardziej modyfikować powinny być raczej trzymane wewnątrz jara?

Czy mogę to twierdzenie uogólnić i powiedzieć, że również inne pliki tekstowe, których użytkownik nie powinien widzieć, np. plik .properties z wykorzystywanymi przez nas zapytaniami sql'owymi wyrzuconymi poza aplikacje dla łatwiejszego utrzymania, message bundles z tłumaczenami stringów, plik konfiguracyjny log4j i wszelka inna konfiguracja, której użytkownik nie ma potrzeby oglądać a tym bardziej modyfikować powinny być raczej trzymane wewnątrz jara?

To jest chyba standardowe postępowanie. I to jest ciekawe jak to jest z tą wydajnością do końca.
Nigdy nie zastanawiałem się jak to działa, ale być może jar jest "otwarty" przez cały czas trwania aplikacji i jest rozpakowany raz przy starcie. Moim zdaniem, to jest nawet wydajniejsze, wczytywanie zasobów za pomocą getResourceAsStream().

Poza tym zobacz sobie do jakiegoś Swing-owego forka jak to jest tam zrobione, np. w SAF.

[EDIT] Myślę też, że to http://java.sun.com/developer/technicalArticles/javase/swingappfr/#resource
wiele wyjaśni.

Z wydajnoscia mam jedna historyjke do opowiedzenia: wiecie dlaczego jadro linuksa jest pakowane? W trakcie boota jest wczytane i ropakowane w locie. Wiecie dlaczego? Otoz okazuje sie ze wczytanie malego pliku i rozpakowanie jest o wiele szybsze niz wczytanie wielkiego rozpakowanego.
Mozna to przeniesc na poziom tych pytan - jak wczytasz jara, robisz to raz, mimo ze jest nawet wiekszy. Jak masz 500 obrazkow, kazdy obrazek to operacje i/o, ktore szybkie nie sa. No i nie czarujmy sie - raz ze zakladam ze 1 gb ramu (ktory maja netbooki) styknie do tego programu; dwa - no jakich oczekujecie problemow wydajnosciowych jesli chodzi o takie pakowanie? No bez jaj, martwicie sie o jednorazowe wczytanie obrazka? Czy nawet 50?

GhostDog napisał(a)

Moim zdaniem, to jest nawet wydajniejsze, wczytywanie zasobów za pomocą getResourceAsStream().

Tak czy owak wczytywalibyśmy zasoby poprzez mechanizm ładowania klas, metodą getResourceAsStream().

ucilala napisał(a)

jakich oczekujecie problemow wydajnosciowych jesli chodzi o takie pakowanie? No bez jaj, martwicie sie o jednorazowe wczytanie obrazka? Czy nawet 50?

Heh, raczej nie oczekujemy żadnych problemów wydajnościowych. Prawdę mówiąc, to nie oczekujemy chyba żadnych problemów ani z jednym ani z drugim rozwiązaniem.

Po prostu stanęliśmy przed dylematem, w którym mamy do czynienia z dwoma, jak się wydaje równoważnymi, rozwiązaniami, jakże częstym dla programisty (patrz: http://stackoverflow.com/questions/3881/illegalargumentexception-or-nullpointerexception-for-a-null-parameter, http://stackoverflow.com/questions/875033/getters-setters-in-java i wiele innych...).

Szukamy po prostu czegokolwiek, co by przekonało nas choćby minimalnie na korzyść jednego z podejść i żebyśmy mogli z czystym sumieniem je zastosować i odrzucić drugie.

Tak naprawdę, to liczyłem na jakąś odpowiedź typu: "Przecież ogólnie przyjęte jest, że..." albo "Jak to, nie wiecie, przecież w każdym projecie robi się...". Tzw. good practices są fajną rzeczą, bo uwalniają programistę od takiego bezsensownego szamotania się pomiędzy podobnymi alternatywami. Niestety, czasem nie ma jasno określonych dobrych praktyk i trzeba szukać pomocy w wieloletnim doświadczeniu kolegów z forum ;).

W każdym razie dzięki, za ciekawą historyjkę, ucilala, może jej morał będzie tym czymś, czego potrzebujemy, żeby przekonać się i przychylić do jednego rozwiązania :).

Wysłaliśmy maila do naszego mentora z Nokia Siemens Network z zapytaniem na temat tego problemu i otrzymaliśmy następującą odpowiedź:

Ogólnie w rozwiązaniach komercyjnych, w większości przypadków unika się dystrybuowania produktów bez pakowania ich atomowych elementów (jakimi są np. poszczególne obrazki) w większe jednostki. Pozwala to uchronić się przed problemami, że user coś namiesze (np. podmieni lub skasuje część obrazków). Jary można też podpisywać co daje dodatkową kontrole.

Jak chcecie możecie rozdzielić sobie to na kilka jarów, np. Jeden trzyma grafikę a drugi skompilowane pliki class ale to nie jest mus.

Przyjrzałem się też bardzo popularnemu notatnikowi napisanemu w Javie JEdit i tam również zarówno obrazki, jak i pliki konfiguracyjne pakowane są do jara. Tak więc już bez żadnej wątpliwości również wybierzemy ten wariant. Pozdrawiam i dzięki za pomoc! :)