Wątki w Javie bez dodatkowych klas

0

W języku C# można uruchomić dowolną procedurę w osobnym wątku. Sprawa jest prosta, wystarczy takie coś:

Thread ThPrgWork = new Thread(new ThreadStart(this.ProgramWork));
ThPrgWork.Start();

przy założeniu, że procedura ProgramWork() jest procedurą bezargumentową i to ona ba być uruchomiona w osobnym wątku. Co do dostępu do zmiennych klasy, w której procedura jest wywołana, wygląda tak samo, jak zwykłe, bezpośrednie uruchomienie procedury (w tym przypadku procedury ProgramWork).

Po pobieżnym googlowaniu doszedłem do opisów wielowątkowości w Javie, ale w każdym przypadku trzeba było zrobić drugą klasę i w tamtej byłaby procedura uruchamiana w drugim wątku.

Jak uruchomić procedurę w drugim wątku w analogiczny sposób, jak w przedstawionym przykładzie w C#?

0

Nie da sie tak samo, Java nie wspiera literalow funkcyjnych (this.ProgramWork). Najblizsze temu jest cos takiego:

Thread ThPrgWork = new Thread(new Runnable() {
@Override
public void run() {
KlasaZMetoda.this.ProgramWork();
}
});
ThPrgWork.Start();

Java 7 lub 8 ma wspierac closures lub co najniej SAM (single abstract method) wiec powinno sie dac zroic takie cos jak w C#.

Tak, skladnia Javy jest dosc uboga. Jedni uwazaja to za dobra rzecz, w tym ja. Od skladniowych cudow sa inne jezyki. Ale to inny temat.

0

Na upartego można też zrobić coś takiego:

public class Main implements Runnable {

    public void fun() {
        new Thread(this).start();
    }

    public void run() {
        System.out.println(1);
        System.out.println(2);
        System.out.println(3);
        System.out.println("Stop.");
    }

    public static void main(String[] args) {
        new Main().fun();
    }
}

Lepiej jednak zrobić klaskę anonimową.

W Javie 7 raczej nie będzie domknięć czy SAM, czy innych rzeczy tego typu. Nie doszli jeszcze do konsensusu dotyczącego składni. Tak czy siak jeżeli ktoś oczekuje skalowalnego języka to niech zwróci się w stronę Scali.

0

Dokladnie ten jezyk, jak i jythona czy groovy mialem na mysli.

0

Groovy czy Jython jednak są woooolne w porównaniu do Javy, Scali czy C#. No i nie mają statycznej analizy kodu.

0

Ale maja swoje zastosowania. Pythona bardzo lubie wiec i jythona rowniez. Zamist groovy jest groovy++ ktory dodaje nieco statycznej analizy.
Dzieki swojej dynamicznosci sa to jezyki skryptowe, mozna nimi bardzo ladnie rozszerzac Jave. Scala nie jest jezykiem skryptowym, nawet nie implementuje JSR 223, i na liscie scali podobno wlasnie to jest powodem, ze scala jest nieodpowiednia bo nie jest skryptowa.
To tak gwoli uzupelnienia dlaczego nie mowie tylko o scali - moim zdaniem nie jest zlotym srodkiem.

0

W Javie projektanci starali się rozwiązywać wszystkie problemy za pomocą spójnego mechanizmu obiektów, dzięki czemu maszyny i systemy operacyjne nie obsługujące wielowątkowości nadal mogą ją symulować. W ten sposób programy w Javie tak samo się pisze na maszyny proste i zaawansowane. Różnica pojawia się tylko w wydajności obliczeniowej. Fakt, że nazwy interfejsów i wielu klas Javy zostały nadane niefortunnie ponieważ na przykład Runnable powinno się nazywać Task, co lepiej określałoby przeznaczenie takiego interfejsu.

Skróty składniowe jakie są obecne w C# czy wcześniej w C++ nie pomagają w przejrzystości kodu, a wręcz powodują jego zaciemnianie. W przypadku C# takie rozwiązanie wątków jest obsługiwane przez system operacyjny Windows. Jednak na innych systemach ten sam kod może wykonywać się dużo wolniej (co akurat jest korzystne dla MS). Składnia C#, to niestety składniowy i logiczny śmietnik. Microsoft nie potrafi dobrze projektować języków programowania. Przykładem choćby VB i psucie swoimi rozszerzeniami wczesnych wersji C, C++ i Javy.

0

Wszystkie mysli subiektywne, przekazane w postaci nie dajacej mozliwosci sprzeciwu, powtorzone z wodolejstwem to co bylo we wczesniejszych postach.

0
::. napisał(a)

Ale maja swoje zastosowania. Pythona bardzo lubie wiec i jythona rowniez. Zamist groovy jest groovy++ ktory dodaje nieco statycznej analizy.
Dzieki swojej dynamicznosci sa to jezyki skryptowe, mozna nimi bardzo ladnie rozszerzac Jave. Scala nie jest jezykiem skryptowym, nawet nie implementuje JSR 223, i na liscie scali podobno wlasnie to jest powodem, ze scala jest nieodpowiednia bo nie jest skryptowa.
To tak gwoli uzupelnienia dlaczego nie mowie tylko o scali - moim zdaniem nie jest zlotym srodkiem.

Skrypty da się pisać i w czystej Javie - BeanShell. W Scali też można, jest REPL, można pisać w niej skrypty powłoki, kompilować i wykonywać kod w czasie działania programu, itp itd

http://lotrepls.appspot.com/ (100 % Java)
http://scalatrix.blogspot.com/2011/01/how-to-write-shell-script-in-scala.html

Kod Scali jest na tyle zwięzły, że nie ustępuje praktycznie językom skryptowym, a dzięki temu, że Scala ma statyczną analizę to IDE mogą dawać dużo lepsze podpowiedzi, dużo więcej błędów jest wyłapywane podczas kompilacji, co redukuje ilość potrzebnych testów - mniej testów, mniej kosztów. Dodatkowo Scala jest szybka, wersja 2.9 ma wbudowane równoległe przetwarzanie kolekcji.

Co to daje, że ktoś implementuje ten jakiś tam JSR? Nie szukałem długo w Google, ale już jakieś tam wysiłki są: http://www.scala-lang.org/node/5257

Edit:
W ogóle na co komu JSR 233 czy jakieś tam inne badziewia skoro kod Scalowy można dowolnie mieszać z Javowym? W końcu Scala kompiluje się do bajtkodu.

Jython się słabo integruje z Javowym kodem (trzeba jakoś ręcznie przeładowywać klasy), a Groovy ZTCP kiedyś tam nie obsługiwał składni Javy w 100 %.

0

No to piszesz skrypty w czystej Javie czy bean shell? Bo na moje to co robi BS to nie jest czysta Java, ale co ja tam wiem.

Skomentuje jeszcze tylko ostatni fragment, bo tak traci ignoracja i fanboyism (prosze nie obrazaj sie, znam Twoje wypowiedzi z forum i wiem ze trzymasz poziom) ze musze. Wiesz ze sa inne jezyki na JVM niz Java i Scala? Wiesz, ze ktos moze chciec rozszerzac aplikacje wieloma jezykami, i miec standardowe podejscie jak to wiazac, zamiast tworzyc hacki dla kazdego z osobna? Podam przyklad.

Nasza aplikacja jest napisana w Javie jako core, czyli minimalna funkcjonalnosc, servisy, persistence, wyszukiwanie, definicja form itp. Taki mikrokernel. Teraz, kazdy klient ma inne wymagania, ktore inaczej troche wykorzystuja te uslugi. Najczesciej sa to jakies male skrypciki typu obrobka stringa czy jakies szczegolne procesowanie zwroconych wynikow wyszukiwania itp. Chcemy aby takie cos mozna bylo pisac w roznych jezykach - teraz ludzie pisza to w jythone bo tak sobie wybrali, ale jak ktos przyjdzie nowy i bedzie chcial zrobic dopasowanie do klienta w groovy, to zrobi, jak w clojure, to rowniez zrobi, w JavaScript zrobi, w Bean Shell zrobi, w JRuby zrobi, w Scali rowniez ale to juz trzeba bylo specjalnie silnik kodowac bo nie ma implementacji 223 (sa jakies szczatkowe, ale to nie jest production-ready).
Teraz, mamy komponent tzw customizer, ktory definiouje pare (nascie) interfejsow, pozwala ladowac skrypty, itp. Teraz, aplikacja definiuje wiele miejsc-hookow, ktore moga wywolywac te skrypty, wystarczy skonfigurowac wywolanie, np. powiedzmy "java:funkcjaFoo(parametry ...)*", "groovy:funkcja(parametry...)" czy "scala:funkcja(paramy)" (itd, dla kazdego jezyka ktory wspieramy. Wiekszosc z tych co zintegrowalismy (tylko te ktore ludzie chcieli uzywac, plus Scala, bo ja lubie ale nikt jej i tak nie uzywa) mozna wywolac za pomoca paru linijek, tych samych, gdzie wazny jest prefix (groovy, python, ...) tylko Scala wymaga jakichs cudow, wymaga ifa i specjalnego traktowania.

(*Takie wywolanie i jego konfiguracja u nas nie jest stringiem, chcialem tylko dla prostoty zademonstrowac o co mi chodzi.)

Teraz o tym jak to jest uzywane: klient kupuje licencje i support i zleca stworzenie konfiguracji. Siada z jakims kolesiem od nas, tzw. project developer (1 klient == 1 projekt), tworza to i tamto, np. wyglad form, moduly ktore maja byc itp. Nastepnie koles musi (najczesciej, prawie zawsze, z wyjatkiem maluczkim kliencikow) napisac tzw. custom logic. Wybiera sobie w czym chce to napisac. Jako ze to sa ludzie z progranicza IT i innej domeny, nie sa to super mastahy, nie wiedza czesto co to typy itp. Duza czesc z nich zna VB (troche starsze osoby), i bardzo im sie podoba ze mga pisac w pythonie. Inni (ostatnio jakis mlody szczun) jest fan(boyem) Ruby, wiec az dostal wypiekow jak sie okazalo ze moze pisac w tym kod i bedzie dzialal. Dla czesci zadan bardzo fajnie pasuje Clojure, mamy jednego takiego co czaruje. Ktostam pisal sobie w JS (Rhino). Scali nie uzyl jeszcze nikt (nie twierdze ze jest zla, po prostu malo osob ja zna u nas).

REPL to nie skrypty, to jest ad-hoc interactive mode. To nie to samo.
Scala i IDE? Prosze nie rozsmieszaj mnie - to co oferuje Scala IDE to jest namiastka. Sam Martin Odersky do niedawna kodowal w Vi albo Emacs i nie uzywal tego badziewia - poszukaj w necie ktore, sa artykuly. Zdaje sie ze ostatnio sie przesiadl, ale co z tego wyniklo to nie wiem. Wniosek - Martin doesn't eat his own dog food. Pewnie wiesz co to oznacza po polsku, i jakie mozna wyciagnac z tego wnioski. Podpowiem - Vi / Emacs jest dla niego lepszym rozwiazaniem.

Wielowatkowe przetwarzanie kolekcji mamy tez w Javie, wystarczy lib, poszukaj, razem z libem do kontunuacji.

Jython sie integruje z kodem javowym bardzo dobrze bo moge pisac skrypt w pythonie, klasy implementuja jakistam interfejs, lub nawet nie, bo jest duck typing, uruchamiam skrypt za pomoca wsplnego interfejsu z 223 i wyciagam z niego to co mnie interesuje.

To o czym Ty mowisz to pisanie aplikacji od samego poczatku gdzie jest mieszkanka Scali (czy czegokolwiek) i Javy, i jedno i drugie moze uzywac nazwajem swoich jednostek. Moj use case jest inny, mam nadzieje ze widzisz roznice.

0
Wibowit napisał(a)

Co to daje, że ktoś implementuje ten jakiś tam JSR? Nie szukałem długo w Google, ale już jakieś tam wysiłki są: http://www.scala-lang.org/node/5257.

Znam te "wysilki", i nie jest to cos co (przynajmniej dla nas, mozliwe ze robilismy cos zle i tyle) dzialalo na tyle dobrze ze chelibysmy to wykorzystac. Dodatkowo, jak zaczynalismy zabawe to te wysilki byly jeszcze malymi piardami, niezdatnymi do uzytku.

0

Widzę, że się rozpisałeś.

Wcześniej nie pisałeś o wielojęzykowości twoich (czy przez ciebie używanych) rozwiązań. W przypadku, gdy chcę tylko rozszerzyć framework Javowy o możliwość odpalania Scalowych skryptów to nie powinno być wielkiego problemu z tym. Ty pewnie korzystasz z jakichś libów polegających na JSR 233.

Napisałeś wcześniej:

Dzieki swojej dynamicznosci sa to jezyki skryptowe, mozna nimi bardzo ladnie rozszerzac Jave.

Tak jakbyś sugerował, że tylko języki dynamicznie typowane nadają się do robienia skryptów. Tymczasem ani język luźno typowany nie musi być skryptowy, ani język skryptowy nie musi być luźno typowany.

Jedyny problem ze Scalą jaki u ciebie występuje to to, że nie ma implementacji JSR 223 dla Scali. Zamiast napisać, że tylko to jest problemem to napisałeś twierdzeń opierając się na fałszywym założeniu że język skyptowy to taki i tylko taki, który implementuje JSR 223.

Ze Scala IDE nie korzystałem (nie lubię Eclipse). Korzystam z wtyczki do NetBeansa. Wtyczka jest bardzo uboga, ale tak czy siak zintegrowana z Scala Presentation Compiler, a więc widzę gdzie są błędy kompilacji oraz mam podpowiedzi. Kolorowanie składni też działa. Refaktoryzacja jest bardzo uboga, ale wtyczkę do NB tworzy niestety tylko jedna osoba.

Z drugiej strony nie znam żadnego przyzwoitego IDE do Pythona, z podpowiadaniem czy refaktoryzacją porównywalną do tej ze Scali.

Wg mnie też Scala nie jest złotym środkiem (zależy w sumie co przez to miałeś na myśli). Być może Scala byłaby dużo lepsza, gdyby nie musiała być kompatybilna z JVMem. Ale wtedy to w ogóle chyba nikt by jej nie używał na szeroką skalę. Tak czy siak wg mnie ma prawie same zalety wobec języków luźno typowanych, a osobiście jestem bardzo przywiązany do języków silnie typowanych.

0

"Dzieki swojej dynamicznosci sa to jezyki skryptowe, mozna nimi bardzo ladnie rozszerzac Jave."
Masz racje, zle napisalem. Wydaje mi sie ze to sa 2 mysli napisane przypadkiem w tym samym zdaniu (dzieki swojej dynamicznosci vs sa to jezyki skryptowe), gdzie nie skasowalem wszystkiego, ale mozliwe ze zle napisalem co mialem na mysli, czesto mi sie to zdarza. Sory za wprowadzenie w blad.

Tak, implementacje 223 to jary, ktore sa dostarczane przez tworcow / community, np groovy, jython itp itd. Ale nie sa to tylko jary, implementuja pewne interfejsy, dzieki czemu moge wiele skryptow w innych jezykach uruchamiac tak samo. Ta sama zasada co JDBC - nie powiesz mi ze to jest bez sensu, bo przeciez wszyscy uzywaja Oracla / Postgres / MySQL / inne *niepotrzebne skreclic) i mozna w kodzie uzywac bezposrednio ich klas?

Przyklad (taki prawie pseudocode):
ScriptPoint sp = ... // pobieramy nasz skonfigurowany skrypt
ScriptingEngine evaluator = ScriptingEngineFactory.getEngine(sp.getScriptintLanguage());
evaluator.evaluate(sp.getScript());
return evaluator.getResult(SomeFancyClass.class);

I wszystko - dodanie nowego jezyka to wrzucenie jara z 223 i juz ScriptingEngineFactory umie sobie skrypt w takim jezyku zinterpretowac i daje mi wyniki. Core aplikacji guzik obchodzi jaki to jezyk. Dla scali tak nie moge.
(nasz kod wyglada nieco inaczej, ale zasade na pewno czaisz)

Nie przypominam sobie zebym napisac ze jezyk skryptowy to tylko taki ktory implementuje 223. Ale mozliwe ze zle napisalem. Z tego co wiem napisalem ze Scala nie jest jezykiem skryptowym (zdaje sie to mozna nawet przeczytac gdzies w jakiejs wypowiedzi Lexa Spoona, kto to jest powinienies wiedziec jak czytujesz i pisujesz w scali) i nawet nie implementuje 223, mimo tego ze teoretycznie powinno byc to proste (sam tak twierdzisz, bo ma REPL itp itd). Uwaga: nie uwazam ze scala-all.jar powinen miec odpowiednie klsy w sobie, moze to byc dodatkowy jar czy cokolwiek, nie ma problemu.

Scala IDE tez nie uzywam, i nie porownywalem do IDE do jythona (nota bene, eclipse z pythonem / jythonem sobie bardzo dobrze radzi, w moim odczuciu lepiej niz ze scala). Odparlem tylko argument ze scala jest taka dobra i tak statycznie typowana ze mozna zrobic dobre ide. Poki co scala-team dowodzi inaczej.

Ostatecznie chcialem tylko odrzucic Twoj postulat ze Scala to i tamto i najlepsza itp itd. Napisalem tylko ze to nie zloty srodek, i podalem dosc zaawansowany use case gdzie akurat zintegrowanie scali to byl najwiekszy problem (uzywamy niepublicznych api, i byl problem miedzy 2.7 a 2.8). Jak wspomnialem, lubie scale, pisze w niej, nawet FizzBuzz z pattern matching potrafie napisac, wiec rozumiem ze jestes nia zachwycony. Moze i jest najlepszym jezykiem swiata, moze i nie, ale na pewno nie jedynym i sa ludzie i zastosowania gdzie sie albo nie nadaje albo jest za trudna (nie powiesz ze ma latwa skladnie) albo utrudnia sprawe (nasz case).
Pozdrawiam.

1 użytkowników online, w tym zalogowanych: 0, gości: 1