Az OSGi specifikációról és keretrendszerekről...

Programozás

... még sosem hallottam, pedig Java fejlesztő vagyok
4% (15 szavazat)
... még sosem hallottam, de nem vagyok Java fejlesztő
30% (125 szavazat)
... még sosem hallottam, de nem vagyok szoftverfejlesztő
34% (144 szavazat)
... hallottam már, de még nem használtam
12% (50 szavazat)
... hallottam már róla és tervezem használni a jövőben
5% (19 szavazat)
... hallottam már róla és aktívan használom
5% (20 szavazat)
... hallottam már róla és committer vagyok valamelyik framework projektben
0% (0 szavazat)
... akár hallottam róla, akár nem, csak az eredmény érdekel
11% (48 szavazat)
Összes szavazat: 421

( turul16 v | 2012. 03. 11., v – 06:59 )

Jon a jira-val..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( espakm | 2012. 03. 11., v – 08:51 )

Használom, de nem Java fejlesztőként. A CTK, illetve korábban a BlueBerry plugin rendszerét. (C++)

off: nekem a kedvenc Javas kerdesem amikor valaki nagyon kiralynak erzi magat, es le kell huteni kicsit, az az, hogy implementalna cachet, illetve az, hogy hogyan irna olyan factoryt, ami szamolja, hogy hany altala letrehozott objektumot evett mar meg a GC.

az elso konnyebb, a masodikon gondolkodni kell, es el is szoktak verezni az emberek, aztan mikor mentokerdeskent felteszem, hogy es hany referenciatipus letezik Javaban, akkor neznek ram, mint borju az uj kapura...

[off]
Egyebkent ez a kerdes valojaban mit arul el? Azaz mitol jobb a factorys kerdes, mintha megkerdezned, hogy mi az a weakreference? Ha valaki tudja a referenciatipusokat, akkor biztosan meg tudja oldani a kerdest, ha nem, akkor biztosan nem. Eleg sokat interjuztattam (szerintem 100 korul jarok), mara mar leszoktam arrol, hogy 'trukkos' kerdeseket tegyek fel, mert nem sokat mond el arrol, hogy valojaban mennyire jo fejleszto az illeto.

Konkret kodot kell iratni, az arul a legtobbet, talan. Anno C++-bol 'hazifeladatot' adtunk, aminek a megoldasat el kellett hozni az interjura, aztan beszeltunk rola, az meg jobb.
[/off]
----------------------
while (!sleep) sheep++;

ha kodert keresel, semmit :) megkapja a specifikaciot, kodol, aztan kesz.

ellenben ha arra kivancsi az ember, hogy valaki milyen melyen ismeri a nyelvet, arra jo, szerintem. hiszen minden nyelven lehet szar kodot irni, de Javaban a legegyszerubb, ha valaki nem ismeri elegge, ezert lehet hallani, hogy "omg mekkora szar a Java, lassu, bloatware".

en mar talalkoztam olyannal, amikor az ember konkretan nem tudta, hogy hogy mukodnek ezek a nyelvben, de elkezdtunk a GC-rol beszelgetni, es belegondolt, hogy ha minden hard reference lenne, akkor mi lenne, majd ebbol kikovetkeztette, hogy hogy kene a cachelest csinalni. es akkor latom, hogy hogy gondolkodik, hogy kepes ra, hogy nem csak a bemagolt valaszokat tudja. es akkor sokkal szivesebben alkalmaznam.

a masik oldalrol szerzett (mint interjuzo) tapasztalatok is azt mutatjak, hogy ilyen embert keresnek a legtobb helyen; nem a targyi, lexikalis tudasa erdekel, hanem tud-e gondolkodni. bevallom, a factorys kerdes lehet, hogy kicsit a lexikalis tudasra epit, de ezt is el lehet utni egy "es van-e elet a finalizeon tul"/"halhatatlan objektumot szeretnek csinalni" tipusu kerdessorozattal :)

Aha, van benne valami. Nekem idaig az adta a legjobb vegeredmenyt, ha nem lexialis tudast igenylo feladatot (pl. valamifele algoritmikus problemat) probalok papiron lekodoltatni a jelentkezovel. Rengeteg olyan jelolt van ugyanis, aki
- elolvasott X konyvet patternekrol es a nyelvrol magarol
- elmeletben jonak tunik, mert sokat tud beszelni

.. aztan amikor a konkret problemat kellene megoldani, akkor baj van. Tehat megdobbento modon van olyan, hogy valaki tudja, hogy mi az a card table egy GC-algoritmusban, de nem bir megirni egy tizsoros fuggvenyt, ami eltavolit egy elemet egy trie-strukturabol.

Teny visoznt, hogy az egesz interjuztatas egy fekete magia, nem lattam meg univerzalisan mukodo strategiat (meg olyan nagy cegeknel, mint a Google is teljesen szarul kepesek csinalni).

----------------------
while (!sleep) sheep++;

Szerintem a weakrefes cache nem olyan jó ötlet, mint amilyennek elsőre látszik. Értelmesebbnek tűnik az az igény, hogy a cache tárolja pl. a legfrissebben használt 100 objektumot (amiket szemétgyűjtéstől függetlenül megtart), de sose tároljon 200-nál többet. Vizsgafeladatnak is jobb.
--
ulysses.co.hu

Mi a weakrefes cache baja? Része lehetne a vizsgakérdésnek. Jön a gc, kipucolja a cachet. Mely elemek tűnnek el? Hát azok, amikre véletlenül éppen nem mutat normál referencia. Azok, amikre mutat, azok megmaradnak. De hát nem pont fordítva kellene működnie? Minek olyan elemeket tartogatni a cacheben, amiket amúgy is ismer a program.
--
ulysses.co.hu

Ez oké, amíg annyi elemed van, ami befér a cacheba, vagy statikus a cache tartalma. Felénk a cache tartalma dinamikus, és nem is biztos, hogy ugyanaz az elem töltődik bele, ami legutóbb ki lett belőle törölve, hiszen x rekordból cachelünk 0.1 * x rekordot, tehát teljesen evidens, hogy ami épp nem kell azt dobja ki, aztán töltsön bele olyat, amire szükség van, és nagy valószínűséggel szükség lesz rá legközelebb. Egyébként a cache felhasználásának két különböző aspektusáról beszélünk, így max csak azt jelenthetjük ki, hogy a weak reference nem a szent grál, és nem alkalmas mindenféle cache létrehozására.
-
Weak és Soft referenciák a Javaban

( NagyZ v | 2012. 03. 11., v – 10:31 )

1, koszi treynek az ekezetek javitasaert!

2, foleg az erdekelt volna a szavazasban, hogy hanyan irnak OSGi-os bundleoket, nem pedig az, hogy a JIRA/GlassFish azon alapul, akkor mar hasznalod is :-)

Én aktívan fejlesztettem sokáig OSGi bundlekat, és mondhatnám még tetszett is, de...

Nem értem, hogy a körkörös hivatkozásokat miért nem lehet rendesen lekezelni, ha A hivatkozik B-re, és B is A-ra, és mindkét modul bent van, akkor ez miért nem feloldható függőség. Sajnos 20-30 bundle esetén olyan komoly refaktorálásokat kellett sokszor csinálni emiatt, és a fejlesztési idő 90%-át az vitte el. Lehet mondani, hogy persze tervezés meg minden, de mivel ez egy 3-4 éve kezdett projekt, ami folyamatos fejleszt alatt áll, néha előfordul, és akkor roppant zavaró, hogy 2 fejlesztő töri a fejét rajta, hogy a végén ne legyen gány az egész.

Mikor kezdtük, akkor még egy csomó mindent nem lehetett betenni OSGi alá, pl Hibernate, ezért a teljes portál backend JDBC prepare statementekkel van összerakva, ami nem túl kényelmes megoldás.

-
Weak és Soft referenciák a Javaban

Én kb 2005-ben léptem be az iparba. Mivel egyetemen Eclipse-eztünk, ezért első munkahelyemen szinte mániákusan használtam az OSGI-t. Bevallom, hogy legalább egy hetem ráment, de sikerült OSGI alá hegesztenem a Hibernate-et :-).

Akkor csináltam egy programot, ami az összes OSGI bundle-ból függőségi gráfot rajzolt (és minden éjjel elküldte email-ben a tesztek futtatása után). Sikerült megoldani azt is, hogy az összes általunk fejlesztett szoftver egyetlen OSGI konténerben fusson, így egyetlen szerveren belül tudtuk konfigurálni, hogy melyik termékünk fusson. Persze ezt végül sosem használtuk így, de ifjúi lelkesedésből jó volt megcsinálni :-).

Azóta is OSGI-t használok szinte mindenhez, ami Java. Nekem főleg a deklaratív függőség leírás tetszik, illetve az, hogy kikényszeríti fordításkor, hogy ne legyenek véletlen bennfelejtett hivatkozások egyéb komponensekre. Így el lehet kerülni vele azt a tipikus Java betegséget, hogy csak indításkor derül ki, hogy egy függőség hiányzik. Persze néha okoz némi fejfájást a körkörös referenciák feloldása, de mindig meg lehet oldani interfészen keresztüli szolgáltatás-injekcióval.

Legújabban arra tértem át, hogy a programot bundle-ként fejlesztem, de aztán az egészet egyetlen jar-ba teszem, és hagyományos módon indítom. Egyszerű programok esetén ugyanis az egész OSGI dinamikusan töltök mindent felfogás overkill, főleg, hogy az Equinox az osztályokról cache másolatot készít, amit aztán sokszor elfelejt az ember törölni. A fejlesztéskori megkötései viszont jól jönnek egy bizonyos projekt méret felett.

A körkörös hivatkozás architekturális hibát szokott jelenteni és még mindig olcsóbb ha az ilyesmi fejlesztési időben derül ki, mintha élesben jönne elő. Általában ilyenkor sérül a "Single Responsibility" és vagy A-ban vagy B-ben megbújik egy C funkcionalitás, amit igazából ki kell emelni önálló modulba. A kiemelés után mondjuk A függ B-től és C-től, de B már csak C-től függ (és A-tól már nem) feloldva a karikát (C pedig nem függ egyiküktől sem).

De hogy lehet, hogy ez nálatok nem fordítási időben derül ki (mert nekem úgy tűnik)?

Fordítási időben derül ki, csak az eclipse folyton fordít a háttérben. A körkörös hivatkozás pedig nem mindig olyan evidens, ahogy mondod. Sajna a konkrét példa nem jut eszembe, de elhiszed vagy sem nem vagyunk hülyegyerekek, és többször volt már olyan, hogy keményen feladta a leckét.
-
Weak és Soft referenciák a Javaban