Strategia dla Javy

[wrobell]

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;

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...

> 
> 3. Jestem za tym żeby pakować gotowe klasy jeśli są dostępne,
>    a nie kompilować ze źródeł.
Jestem przeciw. Patrz nizej.
 
> Komentarz do pkt 3
> Zanim ktoś mnie zruga za pomysły pakowania "binarek"
> pozwolę sobie na uwagi (wybaczcie, jeśli sprawa była poruszana,
> ale śledzę listę i nie przypominam sobie jakichś dyskusji na ten temat):
!#!@$!@#! ;-)

> 1. Binarki javowe, jak wiecie, to nie do końca binarki. Są interpretowane i przenośne
>    (tak, tak, nie zawsze, ale nie o takich mówię)
Ale tak jak kazdy kod, moze byc on zoptymalizowany, badz nie. Moze
miec mozliwosc debugowania lub nie. Odpowiednie przygotowanie spec-a
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.
 
> 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.

[...]

  wrobell <wrobell w posexperts.com.pl>
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 232 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20040626/50157b54/attachment.bin