Strategia dla Javy

[Rafał Kleger-Rudomin]

wrobell <wrobell w posexperts.com.pl> writes:

> On Wed, Jan 24, 2001 at 01:44:51AM +0100, Rafał Kleger-Rudomin wrote:
> > 
> > Cześć,
> > 
> > Ostatnio potrzebuję zapakować parę rzeczy javowych.
> > Sprawy do omówienia:
> > 
> > 1. Gdzie ładować pliki .jar ?
> >    W xp i xt użyłem /usr/share/java/classes
> >    ale widzę w specach że są też inne propozycje ;)
> /usr/lib/java ponieważ bytecode Javy jest zalezny od platformy Java;

No dobra ale można go współdzielić miedzy architekturami i os'a mi
Więc powienien iść do gdzieś do /usr/share, czy nie tak?

> mimo to zgodnie z sugestiami z przed kilku miesiecy wydaje mi
> sie dobrym rozwiazanie by rpm-y byly jako noarch
>  
> > 2. Co z CLASSPATH? 
> >    Teraz jest tak że trzeba sobie samemu ustawić np 
> >    CLASSPATH=/usr/share/java/classes/xt.jar
> >    Jest jakiś pomysł żeby nie trzeba było ustawiać samodzielnie CLASSPATH?
> >    Ktoś się orientuje, może standard Javy przewiduje jakąś metodę
> >    odnajdywania bibliotek?
> >    Od razu mówię, że pomysł z ustawianiem CLASSPATH w profile.d mi się nie podoba ;)
> Niech kazdy sam sobie ustawia. Jesli jakis program potrzebuje kilku .jar-ow
> z innych pakietow, to proponuje pisac odpowiedni skrypt startujacy.
> Propozycja moja sie bierze stad, ze jak ustawilem sobie CLASSPATH na wszystkie
> .jar-y jakie mialem w systemie, to ddd ladowal liste klas dobrych
> kilka minut (fakt, wiekszosc programow tego nie robi). Poza tym,
> moga wystapic tez konflikty, jedne klasy beda przykrywac drugie...
> Chociaz, sam nie wiem...

Mi też to osobiście pasuje żeby każdy CLASSPATH sam ustawiał.
Myślałem pod kątem ułatwienia dla użytkowników. Ale skoro nie ma
odpowiednich standardów to lepiej nie silić się na ułatwienia.

Ktoś wspominał o pam_env. Nie podobaja mi się tego typu rozwiązania.
Nie podoba mi sie wszelkie manipulacje w środowiskiem jakie się podkłada 
użytkownikowi (wiem że czasem trzeba, ale lepiej unikać).
Poza tym to rozwiazanie nie działa natychmiast po instalacji.

> umozliwia pozniej szybkie przygotowanie sobie wersji, ktora jest
> tobie potrzebna:
> - bytecode
> - zoptymalizowany bytecode (javac -O)
> - kod do debugowania (javac -g)
> 
> Poza tym mozna to robic kilkoma roznymi kompilatorami, chocby
> jikes (szybki jak cholera) i standardowy javac, ktore maja
> swoje wady i zalety.

No tak tu się zgodzę.

> > 2. Nie ma potrzeby kompilować ich pod dany sprzęt, tak jak to robimy ze zwykłymi programami.
> Tylko pod Jave. :-)

??

> [przestawka :-)]
> > 3. Zwykle nie potrzebują konfiguracji w fazie kompilacji (ścieżki itp).
> > 5. Jedyna sytuacja kiedy IMHO trzeba kompilować to wtedy gdy potrzeba
> >    włączyć/wyłączyć jakieś opcjonalne włąsności/rozszerzenia przy kompilacji.
> Ale bedzie trzeba jakiego patch-a nalozyc, jak nie w tej wersji, to w nastepnej,
> o konfiguracji sam wspomniales (co tez moze sie zmieniac w zaleznosci od wersji).
> Na poczatku jest wiecej roboty, ale za to pozniej to zaprocentuje.

> > 4. Samodzielna kompilacja chyba nie da zysku na prędkości (?).
> Patrz wyzej.

OK, co do konieczności kompilowania to generalnie mnie przekonałeś.

Pozdrawiam,
Rafał


 
> [...]
> 
>   wrobell <wrobell w posexperts.com.pl>

-- 
Rafał Kleger-Rudomin (klakier w pld.org.pl)