🚀 go-pugleaf

Dnia 12.07.2015 Borneq <borneq@antyspam.hidden.pl> napisał/a:
> Eksportuję program do jara. Jest napisany z użyciem SWT, więc eksportuje
> wszystko. Czy można wybrać tylko używane klasy/metody?

To że ty korzystasz tylko z klas X i Y oraz metod powiedzmy X.a i Y.b nie
oznacza, że te metody wewnętrznie nie korzystają z innych klas/metod. Nawet
na poziomie kompilacji może być problem z określeniem wszystkich
potrzebnych klas, bo te moga być ładowane dynamicznie w trakcie
działania programu (Java ma pod tym względem wiele mechanizmów, można na
przykład w trakcie działania programu załadować klasy/obiekty nie tylko z
pliku na dysku, ale też z działającej innej maszyny wirtualnej czy przez
internet - nie wiem czy SWT z tego korzysta, bo nie używam, ale generalnie
biblioteki załączam w całości).

> A może lepiej jeden STW.jar dla wszystkich, które go używają?

Można jar wewnątrz jar-a (definiując odpowiednio classpath w manifeście) a
można bibliotekę załączyć do jar-a "rozpakowaną" (wtedy może być więcej
zabawy z manifestem, bo generalnie każda biblioteka *.jar ma swój manifest
i swoje ustawienia).


> Następny problem: trzeba wołać: java -jar moja_aplikacja.jar
> pomaga napisanie .bat czy .cmd, jednak jest kłopot: gdy wołam zostaje
> czarna konsola na ekranie, co gorsza - nie zamyka się po ukończeniu
> programu!

Jeśli nie zamyka się po zakończeniu programu, to znaczy, że... program się
nie kończy, a jedynie zamykasz okienko programu (maszyna wirtualna chodzi
dalej). Na pewno prawidłowo obsługujesz kliknięcie w "krzyżyk" głównego
okienka programu? Sprawdź w procesach :D
Robienie "exeka" spowoduje, że stracisz jedną z zalet Javy - przenośność
(taki plik *.exe nie będzie już działał na Mac-u czy pod Linuxem bez
dodatkowych zabiegów). Ja w Windowsie "mapuję" pliki *.jar z programem
javaw i okienko tekstowe w ogóle się nie pojawia ale do testów oczywiście
używam "tekstowej" wersji przy tworzeniu programu, bo często wyrzucam na
konsolę różne informacje diagnostyczne pomocne przy szukaniu błędów.

> Czy więc nie lepiej napisać callera jako execa jak eclipse.exe ? Choć i
> tak jest duży (326 kilo) jak na programik, który tylko woła inny program.

Jeśli to ma być tylko na Windowsa, to można, ale większość zwykłuch userów
ma zainstalowane tylko JRE a ono pod Windowsem domyślnie ustawia obsługę
plików *.jar przez program javaw, więc nie ma z tym problemu.
Co do samej wielkości gotowego programu - nie przejmuj się tym, czasy
dyskietek już dawno minęły :D

Dnia 12.07.2015 Borneq <borneq@antyspam.hidden.pl> napisał/a:
> W dniu 2015-07-13 o 01:08, Borneq pisze:
>> Eksportuję program do jara. Jest napisany z użyciem SWT, więc eksportuje
>> wszystko. Czy można wybrać tylko używane klasy/metody? A może lepiej
>> jeden STW.jar dla wszystkich, które go używają?
>
> W związku z tym jeszcze jedno pytanie: ja zrobić aby obrazki nie były
> czytane z wielu plików png, nie były czytane z jara ale w z images.zip
> leżącym obok jara? Jest jakaś możliwość strumienia zipa.

Można (zresztą sam znalazłeś odpowiedź) ale nie wiem czy jest sens, bo plik
*.jar to tak na prawdę *.zip

Dnia 12.07.2015 Borneq <borneq@antyspam.hidden.pl> napisał/a:
> Czy więc nie lepiej napisać callera jako execa jak eclipse.exe ? Choć i
> tak jest duży (326 kilo) jak na programik, który tylko woła inny program.

Swoją drogą w czym napisałeś tego callera? Bo mi napisany w C (Visual
Studio 2013) zajmuje kilka kilo :D

W dniu 2015-07-13 o 01:08, Borneq pisze:
> Eksportuję program do jara. Jest napisany z użyciem SWT, więc eksportuje
> wszystko. Czy można wybrać tylko używane klasy/metody? A może lepiej
> jeden STW.jar dla wszystkich, które go używają?

W związku z tym jeszcze jedno pytanie: ja zrobić aby obrazki nie były
czytane z wielu plików png, nie były czytane z jara ale w z images.zip
leżącym obok jara? Jest jakaś możliwość strumienia zipa.

W dniu 2015-07-13 o 01:47, Borneq pisze:
> W związku z tym jeszcze jedno pytanie: ja zrobić aby obrazki nie były
> czytane z wielu plików png, nie były czytane z jara ale w z images.zip
> leżącym obok jara? Jest jakaś możliwość strumienia zipa.

To ostatnie pytanie to :
http://stackoverflow.com/questions/5465511/java-reading-multiple-images-from-a-single-zip-file-and-eventually-turning-the

W dniu 2015-07-13 o 02:57, Pit pisze:
> Dnia 12.07.2015 Borneq <borneq@antyspam.hidden.pl> napisał/a:
>> Czy więc nie lepiej napisać callera jako execa jak eclipse.exe ? Choć i
>> tak jest duży (326 kilo) jak na programik, który tylko woła inny program.
>
> Swoją drogą w czym napisałeś tego callera? Bo mi napisany w C (Visual
> Studio 2013) zajmuje kilka kilo :D
Chodzi mi o plik eclipse.exe bo eclipsec.exe który pokazuje konsolę ma
tylko 31 kilo. Może tam (eclipse.exe) wrzucili różne inne rzeczy.

W dniu 2015-07-13 o 02:49, Pit pisze:
> Jeśli nie zamyka się po zakończeniu programu, to znaczy, że... program się
> nie kończy, a jedynie zamykasz okienko programu (maszyna wirtualna chodzi
> dalej). Na pewno prawidłowo obsługujesz kliknięcie w "krzyżyk" głównego
> okienka programu? Sprawdź w procesach :D

Masz rację, nie kończy się, w Eclipse zostaje czerwony kwadrat. A
poprawiałem wyjątek na zakończenie bo pojawiał się w display.dispose()
gdy bl włączony timer, teraz timer przez zwolnieniem timer stopuję:
display.timerExec(-1, timer);

Robię w SWT według książki Adama Bochenka "Eclipse. Biblioteka SWT".
	public class MidPlayerApp {
	public static void main(String[] args) {
		Display display = new Display();
		new MainWindow();
		display.dispose();
	}
}

Więcej robię w kreatorze MainWindow, aby nie robić wszystkiego w Main.
To też ma wadę bo ten kreator ni kończy się przez całe trwanie programu.

public MainWindow() {
		display = Display.getCurrent();
		shell = new Shell(display);
		init(); //creates components
		shell.open();
		startEventLoop();
		commandsPlayback.stop();
		display.timerExec(-1, timer); //stop timer before 	display.dispose();
to avoid error
	}

	private void startEventLoop() {
		while (!shell.isDisposed()) {
			if (!display.readAndDispatch()) display.sleep();
		}
	}


Już wiem! Obsługuję midi i przed końcem wołam co prawda sequencer.stop()
aby nie została mi muzyka ale nie zamykałem go.
Teraz po zamknięciu program się zamyka. Dzięki konsoli zobaczyłem że coś
nie gra, bło mnóstwo otwartych javaw. Co ciekawe Eclipse było otwarte
przez Eclipse.exe a nie przez javaw (może dlatego "aż" 300 kilo)
Już po zamknięciu konsola się zamyka.
Ale nie wiem, dlaczego w ogóle się otwiera, nie tylko dla java ale i dla
javaw, mimo że wyrzuciłem dwa wywołania println i nic nie wypisuje na
konsolę.

W dniu 2015-07-13 o 02:49, Pit pisze:
> Jeśli to ma być tylko na Windowsa, to można, ale większość zwykłuch userów
> ma zainstalowane tylko JRE a ono pod Windowsem domyślnie ustawia obsługę
> plików *.jar przez program javaw, więc nie ma z tym problemu.
> Co do samej wielkości gotowego programu - nie przejmuj się tym, czasy
> dyskietek już dawno minęły :D

Caller niepotrzebny - w TotalCommaderze czy w Exploratorze Plików
wystarczy klik na .jar i wtedy nie pokazuje się konsola! Aby było
jeszcze łatwiej można zrobić np. skrót na pulpicie. Czyli problem
rozwiązany.
Tylko się zastanawiam - Java ma tę zaletę że jest raz zainstalowana,
natomiast wszystkie programy mogą być malutkie (gdy są małe, nie uzywają
np. SWT itp), gdyby tak dało się raz zainstalować SWT...

Dnia 13.07.2015 Borneq <borneq@antyspam.hidden.pl> napisał/a:
> Tylko się zastanawiam - Java ma tę zaletę że jest raz zainstalowana,
> natomiast wszystkie programy mogą być malutkie (gdy są małe, nie uzywają
> np. SWT itp), gdyby tak dało się raz zainstalować SWT...

Owszem, da się. Definiujesz w systemie (Windowsie, Linuxie czy czym tam
jeszcze) zmienną środowiskową CLASSPATH, w której podajesz ścieżki do
wszystkich niestandardowych bibliotek (tych, których nie ma domyślnie w
JRE). Możesz te biblioteki składować gdzie chcesz, na przykład trzymasz
lib1.jar i lib2.jar w C:\extralibs, to definiujesz zmienną
CLASSPATH=C:\extralibs\lib1.jar;C:\extralibs\lib2.jar  (to dla Windowsa, bo
w innych systemach jak na przykład Linux biblioteki rozdziela się
dwukropkiem ale w Windowsie dwukropek jest częścią nazwy
urządzenia/partycji, więc trzeba było inaczej). Wtedy biblioteki dodatkowe
nie muszą być zawarte w pliku *.jar każdej Twojej aplikacji tylko mogą być
wspólne.