Ritka eset, hogy szükségünk van rá, de velem megesett. Szükségem volt a java-t futtató rendszer típusára és architektúrájára. Ráadásul futásidőben. Az ok egyszerű. SWT alkalmazást fejlesztek, és nem akarok minden platformra külön kiadást csinálni, ne a felhasználó találja ki, hogy milyen rendszert futtat. De ez mellékes, a probléma adott, futásidőben kell meghatározni, melyik platformfüggő csomagot töltsem be?
Egyszerű a megoldás – írják a lelkes és segítőkész, ám nem teljesen tájékozott fórumozók – A System.getProperty() paranccsal le lehet kérni a szabványosított, így minden JVM-ben létező “os.name”, “os.version” és “os.arch” tulajdonságokat, amikkel egyszerű beazonosítani a futtató rendszert. A szabvány valóban rögziti, hogy milyen tulajdonságmezőknek kell lenniük, azonban ezeknek a lehetséges értékeit nem. Most jön csak a szenvedés.
A kisebb problémát az “os.name” mező jelenti, ami többé-kevésbé konzisztens értékeket ad vissza a Sun és az alternatív
Ennél sokkal komolyabb fejtörést okoz a rendszer architektúrájának meghatározása. Ennél rendkívül változatos értékeket tapasztaltam különböző gépeken, rendszertől függetlenül. Még a Sun JVM-ek se konzisztensek ebben. Az még nem túlzottan meglepő, hogy a 64 bites, intel-alapú rendszeremet “amd64”-nek hívja, hiszen a disztróm hivatalosan amd64-re van fordítva. Más gépeken viszont szinte véletlenszerűen kerül elő a fent említett megnevezés mellett “x86_64”, illetve “x64” is. További érdekesség, hogy mivel “Mac OS X”-en még nincs 64 bites 1.6os Java, így azt “i386”-osnak jelzi. Ebből látszik, hogy a kérdéses mező nem a rendszer, hanem a JVM tulajdonságát adja vissza. Ennél a pontnál elérkeztünk a régebbi, 32 bites rendszerekhez, ami lehet “x86”, “i386”, “i686”, és hasonszőrű társai bármelyike. Utolsóként megemlíteném a Power PC architektúrát, ami lehet “ppc”, vagy “PowerPC” elnevezésű is.
A fenti mezők értékeire vonatkozólag láthatóan a Sun berkein belül sincs megegyezés, különböző rendszereken, vagy akár csak különböző verziók más-más értéket adhatnak. A legnagyobb probléma mégis az, hogy ez nincs sehol dokumentálva! A néhány kicsit használható gyűjteményt lelkes felhasználók hozták össze, de ezek hiányosak, és/vagy régen frissültek. Íme az általam talált legjobb, ami határozottan kevés: [[http://lopica.sourceforge.net/os.html]].
Végső megoldás lehet kitaposott úton járni, azaz felhasználni egy már létező megoldást, ami talán megmondja, mégis milyen rendszeren vagyok. Hasonló megoldásokban szinte kizátólagosan az [[http://lopica.sourceforge.net/os.html|Ant]] projekt kerül szóba, ami tartalmaz egy osztályt, mely egy szimpla enumerált értéket állít elő a létező operációs rendszereknek megfelelően. Az “os.arch” változót pedig csak nemes egyszerűséggel kivezeti a felhasználó számára az összes JVM tulajdonsággal egyetemben. Továbbá az Ant csak fordítás-idejű megoldást kínál, ezzel én nem lettem okosabb.
Végső elkeseredésemben azon kezdtem agyalni, hogy a program első futásakor végigpróbálgatom az összes rendelkezésre álló SWT lib-et, és amelyik nem dob kivételt, az működik. Ha ehhez hozzávesszük, hogy felismerhetünk pár “os.name”, “os.arch” értéket, akkor nem is olyan elvetemült ötlet.
(Update) A megoldás
[[http://cubussapiens.hu/user/30|Happy]] [[http://cubussapiens.hu/node/593#comment-117|hozzászólása]] alapján a zseniálisan egyszerű megoldás:
package proba;
import org.eclipse.core.runtime.internal.adaptor.EclipseEnvironmentInfo;
public class EnvInfo {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
EclipseEnvironmentInfo eei = EclipseEnvironmentInfo.getDefault();
System.out.println(eei.getWS()+"."+eei.getOS()+"."+eei.getOSArch());
System.out.println(eei.getNL());
}
}
, ami nálam a következő kimenetet adja:
linux.gtk.x86_64
hu_HU
Stampie jól gondolta, ezt a problémát már megoldották az Eclipse-ben, csak akkor én ezt nem találtam meg. Az [[http://mobius.inria.fr/eclipse-doc/org/eclipse/core/runtime/internal/adaptor/EclipseEnvironmentInfo.html|EclipseEnvironmentInfo]] osztály a org.eclipse.osgi_3.4.0.v20080605-1900.jar csomagban található meg, és ez az swt csomagok elnevezésével kompatiblis jelölésekkel adja meg a rendszer jellemzőit.
A tényleges témához nincs sok hozzáfűznivalóm – nem értek hozzá.
De az, hogy valamit ne nevezzünk szabványosnak, mert azt nem az ISO szabványosította… A Java nevet nem lehet akármire rátenni (jogvédelem), gyakorlatilag csak arra lehet rátenni, ami megvalósítja a szabványt. Jellemző, hogy a Google annak érdekében, hogy eltérhessen bizonyos pontokon a Javatól, azt mondta, hogy nem Java alapú a rendszer. 🙂 A jogi helyzet mindenesetre meglehetősen érdekes.
Az alternatív JVM-ek legfőbb oka pedig az, hogy a Sun JVM-e még ma sem teljesen nyílt forrású (régen meg egyáltalán nem volt az), ráadásul a Sun a UNIX-világban a saját Solaris rendszerét próbálja erőltetni. Így nem feltétlen szerencsés a disztribúciókba csomagolni. Persze vannak egyéb JVM-ek is (pl. az IBM-é biztosan nem ilyen indokkal született 😀 ). De ez már messzire vezet.
Igen, itt jön elő a különbség a “de jure” és a “de facto” szabvány között. Az ISO, és más (W3C, IEC, stb..) nemzetközi szabványügyi hivatalok adják meg a “de jure”, azaz jog szerint meghatározott szabványokat. Ezzel szemben a “de facto” szabványok jogilag nem azok, de a mögöttük álló ipari erő teszi őket széles körüen használt technológiává. A java egyértelműen ilyen, csak a Sun próbálja azt a látszatot kelteni, hogy ennél több, egy saját szabványügyi testület segítségével. Ennek az az előnye, hogy a Sun mondja meg, mit tartalmazhat a nyelv, és mit nem. Azaz az IBM nem teheti meg, hogy a Sun nélkül belerak egy új funkciót a nyelvbe (lásd a rég óta vita tárgyát képező “properties”, ami pl. a .NET-ben benne van, és várhatóan a java 7-be fog bekerülni). Ezáltal az alternatív JVM-ek csak követik a Sun-t, jobb JVM-et nem csinálhatnak soha. Voilá, a Sun monopol-helyzetbe került. Ebből kiút csak a Google általad említett módszere lehet.
Végezetűl megemlítenék egy érdekes kezdeményezést OpenL (http://openl.org/) néven, ami arra irányúl, hogy a nyelv szabadon alakítható legyen az alkalmazásnak megfelelően. De ez már tényleg távolra mutat, és nagyon nem témája a cikknek.
Nézd, az, hogy a Sun monopolhelyzetbe került a nyelv megalkotásával kapcsolatban, az olyan szempontból előnyös, hogy ha írsz egy programot, annak tényleg minden JVM-en futnia kell! Ha egy JVM-en egy programod nem fut, az az esetek 99,99%-ban bug. És ez fontos.
A szabványokról: nem sokat számít szerintem(!), hogy egy szabvány de jure vagy de facto – ami számít, az az, hogy mennyire elterjedt, mennyire támogatott, mibe kerül használni. És azt hiszem, jobb, hogy az IBM nem rak bele funkciókat a Java nyelvbe 🙂 .
Viszont ez a monopolhelyzet csak kvázi-monopolhelyzet. Ugyanis senki sem kötelez rá, hogy Javaban fejlesszen akármelyik cég. Lehet váltani C/C++-ra (ahol nagyon durva különbségek vannak az egyes fordítók között – ez akár olyan szintig is elfajulhat, hogy a Gecode nevű CSP megoldó azt mondja, hogy OSX-en és Linuxon a GNU toolchain segítségével fordul, de Windows-on Cygwinen nem támogatott, és a levlistás levelek alapján nem is megy!). Szóval az sem biztos, hogy jó dolog, ha a nyelveket szabadon lehet piszkálni.
OpenL-ről még nem hallottam, de felírtam magamnak, hogy majd ránézek. De addig is valami, ami eszembe jutott a témával kapcsolatban: vigyázni kell az ún. monkeypatchinggel (http://www.codinghorror.com/blog/archives/001151.html), mert a hibák keresését nagyban megnehezíti. És a nyelv alkalmazás – azaz programozók általi alakítgatása ilyen veszélyekkel járhat. Ez különösen a mai modern, sok komponensből (sok programozótól, esetleg cégtől) álló programok esetén életveszélyes.
Update: És amit még hozzátennék, az az, hogy te most éppen azzal szívsz, hogy van egy adott dolog, ami a Javaban nem lett szabványosítva, így mindenhol másképp van megcsinálva. Szal nem olyan rossz dolog, ha valami le van fixálva.
Pontosan, egyetértek, nagyon fontos a szabványosítás, de nem mindegy, hogy milyen a szabvány. És ebben meghatározó probléma az a tény, hogy a szabványosítás folyamata ma legalább annyira céges politika dolga mint az adott tudományé. A rossz szabványok leggyakoribb forrása egy cég, aminek sikerült átvernie másokon a saját félig átgondolt módszerét/technológiáját. Hozzátenném, hogy ebből a szempontból a java különösen jó, ritka a cikkben említetthez hasonló rés.
Valóban nem örülnék annak, ha az IBM önkéntesen pakolna bele új dolgokat a nyelvbe. Sőt, annak sem örülök, hogy a Sun ezt teszi (jelenleg megteheti, mert övé a szabvány). Ha a nyelv valóban szabványosított lenne nemzetközileg, akkor egy gazdaságilag független szervezet alakíthatná ki, ahelyett hogy egyetlen céget követne az egész iparág. Ez a különbség a “de facto” és “de jure” szabvány között.
Még egy apróság, nyelvmódosítás témakörben: a TrollTech (http://trolltech.com/products/qt) saját nyelvi elemmel bővítette a C++-t, amivel leírhatja a Qt-ben az eseménykezelést. Ehhez egy előfordítót ad, ami olyan kódot generál, amit már megeszik a gcc (http://gcc.gnu.org/). Ronda, alapjaiban különbözik pl. a java-s eseménykezelés gondolatmenetétől, de a KDE-s fejlesztők esküsznek rá.
A helyzet az, hogy a Sun nem “önkényesen” pakol bele funkciókat a nyelvbe. Amikor a Java elindult, akkor nagyon oda kellett figyelnie, mit tesz bele, mert kemény volt a verseny, és egy rossz nyelvvel esélye sem lett volna. Akkoriban még egy virtuális gépen futó gép ötlete nem igazán volt ott a mainstream programozási nyelvek körében.
Most más akadályozza meg, hogy minden sz*rt beletegyen: egyrészt az, hogy a Microsoft-féle C# igencsak komoly vetélytárs, másrészt pedig a visszafelé kompatibilitás. A Microsoft a C# nyelvvel ügyes dolgot tett le az asztalra, amit láttam belőle, Javasoknak igencsak könnyű átszokni, és vannak benne tényleg remek ötletek. A visszafelé kompatibilitás meg egy nagyon kemény dolog: a Sun úgy bővíti csak a nyelvet, hogy az ne lője el a korábbi programokat, azaz a korábbi bytecode fusson az új JVM-en is, illetve a korábbi forráskód leforduljon az új fordítóval. Emiatt van például a Java-féle faramuci genericitás-kezelés.
Ez a típus-törlésen alapul: egyszerűen bytecode szinten visszafordul a korábban használt castolgatós módszerre. Ennek helyenként érdekes következményei vannak a használhatóságot illetően, de ebbe nem mennék bele. A lényeg az egészben, hogy ez egy határozottan nem triviális problémakör.
Emellett van még egy szempont, hogy a Sunnak miért kell(ene) hallgatni a többiekre is: mivel sokaknak van rutinjuk már JVM/Java compiler írásban, sokakban megvan a potenciál, hogy egy megfelelő fork-ot csináljanak. Ehhez csak az kell, hogy megfelelő elhatározás érjen meg bennük ehhez.
A nyelv kicserélésére a JVM felett már vannak is működő dolgok: mind a Scala (http://www.scala-lang.org), mind a Groovy (http://groovy.codehaus.org/) viszonylag ismert nyelvek (a mainstreamtől messze vannak azért, de viszonylag ismertek). És elég komolyan változtatnak a Java filozófián – pl. a Scala részben deklaratív nyelv, típusrendszere sokkal korrektebb elméleti szempontból. A Groovyról jóval kevesebbet tudok, de az is előfordul több helyen.
A Qt-t nem ismerem (nem csináltam Linux programozás tárgyat, és KDE-t sem hakkoltam még ilyen szinten…), de majd, ha úgy adódik, ránézek.
Megjegyzés: az IBM kapcsán szerintem az önkéntes helyett az önkényes szót kerested. 😀
Az MS.NET-hez egy kis megjegyzés, arról, hogy mit is jelent a “menedzselt környezet”. A C# (vagy más .Net) fordító egy exe-t állít elő, amely valójában egy kutya közönséges windows futtatható állomány, azzal az apró kivétellel, hogy a winapi rendszerhívások helyett a .NET csomaghoz adott dll-ekben található függvényeket hívogatja. Tehát ezek a programok csak félig futnak virtuális környezetben, az alapszintű műveletek (és a memóriakezelés egy része) gépi kódban fut, mint bármelyik natív program.
Ezzel az egyik probléma az, hogy csak a memóriafoglalások egy része esik a garbage collector hatóköre alá. A másik probléma akkor kerül elő, ha megpróbálunk futtatókörnyezetet létrehozni más platformra. Nem véletlen, hogy több évnyi fejlesztés után se teljesen működőképes a Mono (http://www.mono-project.com/Main_Page).
Szerény véleményem szerint maga a nyelv jó, ám az alatta ketyegő motor nem elég virtuális ahhoz, hogy elérje a java rugalmasságát, de a natív fordítók hatékonyságát már elveszti. Egy másik apróság: a WinForms api, ami az alapélrtelmezett widgetkészlet .NET-hez, nem platform-független, és bizony visszaszaglik rajta a winapi néhány tulajdonsága.
A Scala-t ill. a Groovy-t nem ismerem, majd rálesek, hátha hasznosak.
A .NET kapcsán kevés dolgom volt, és ott sem grafikus cuccot csináltam, hanem a Spec# (http://research.microsoft.com/specsharp/) nyelven írtam parancssori programot. Nem az volt a lényeg számomra, hogy mittudomén milyen csilivili dolgot összehozzak, hanem az, hogy megnézzem, hogy a design by contract metodológia hogyan alkalmazható, illetve milyen constrainteket lehet bevinni a rendszerbe. Így az általad említett dolgok nem jöttek elő.
Viszont ha olyan bizonyítót választottunk, ami elment OSX-en, akkor úgy elvitte a Spec# nyelvet is a Mono.
A nyelv viszont tényleg tetszett.
A Scala egy érdekes konstrukció: a Javahoz képest vannak a dinamikus nyelvek, ahol pl. tipizálás gyakorlatilag nincsen, ezzel szemben a Scala pont az ellenkező irányba megy el – metamodell, nagyon bonyolult típusok és sok egyéb. Ja és persze funkcionális nyelv is(!). Amit jól csinál, hogy a Java osztályokat egy szó nélkül megeszi. Modern nyelv, nincs mese – de finoman szólva nem mainstream.
A Groovyról meg a http://en.wikipedia.org/wiki/Groovy szerint egy dinamikus nyelv, a Javahoz képest viszont megjelent benne az operator overload, a closure és a dinamikus tipizálás.
Egyik nyelvet sem próbáltam még ki, de egyszer érdemes lenne. Segítene az embert megfelelő helyre pozícionálni.
Valóban, mindkét nyelv igéretesnek látszik. Ha kilátszanék a munkából, biztos több időt szánnék rá. Python, Ruby és egyéb jószágok mellett, mert azok is kimaradtak eddigi életemből..
A Python is leginkább amiatt érdekel, mert várhatóan ez lesz a legfontosabb nyelv KDE4 Plasmoidok (http://plasma.kde.org/) kreálásában C++ után, amiről ismered a véleményemet.
Hát, látszik, hogy más a hozzáállásunk. Mármint itt is…
Magam részéről örülök neki, hogy a Dashboard widgetek OSX-en HTML/CSS/Javascript alapon lettek fejlesztve – ennek előnye számomra az, hogy a három nyelvből kettőt nagyrészt ismerek 🙂 . Kicsit univerzálisabban szemlélve az, hogy a felületet könnyű tervezni, viszonylag sokan értenek hozzá, emellett megkapnak minden támogatást a már amúgy is beépített Webkit motortól (ami nem mellesleg egy nagyon ügyes, gyors böngészőmotor), és mellesleg lehet hozzá hakkolni mélyebb funkcionalitást…
Persze nem vitatom, hogy a KDE4-ben komolyabb szerephez jutnak a Plasmoidok, mint OSX-en a widgetek. Emiatt nem is lenne biztos, hogy ez szerencsés megközelítés lenne a weblap jellegű témázás – de azért nem is vagyok benne biztos, hogy hülyeség…
Nyelvek részéről a Scala komolyabban kellene, hogy érdekeljen, mert az ETAPS után kaptam a Spec# bizonyítórendszerének egy Scala-ban leimplementált változatát…
És ami nyelvet a leghamarabb meg kellene tanulnom most, az számomra egyértelműen a Javascript. Nagyon nyomják a cégek, van esélye, hogy ez is nagyon elterjedt legyen. De erről később talán részletesebben is írok valamit.
Félreértettél, alapvetően jobban örültem volna, ha a Plasma-t deklaratív UI jelleggel csinálják meg, de ez kb. fel sem merült a fejlesztőkben. Egy C++ API-t csináltak arra, hogy a megfelelő pontokat meghívva bizonyos függvényeket, a plasmoid a globálisan beállított stílusnak megfeleljen. Személy szerint ez nekem nem tetszik, bár hozzátenném, hogy egy nagyon alaposan átgondolt, és jól szervezett API született meg.
A KDE fejlesztők ezt találták ki, nekem ehhez kell igazodnom, és ha komolyabban testre akarom szabni a gépemet, a Plasmoid-fejlesztést nem úszom meg. Persze csinálhatnék OSX/Dashboard widget-et is, hiszen KDE4.2-re igérik a teljes támogatást hozzá, csak ebben az esetben esélyem sincs a kinézetét integrálni a rendszerbe.
A javascript egy ügyes nyelv egyébként, meglepően rugalmas, és valóban affelé fejlődik, hogy a de facto nyelv legyen webes alkalmazások fejlesztésében. Bár szerintem nem alkalmas (még) arra, hogy komolyabb alkalmazást készítsünk vele. De ezen segítene, ha a Dom API helyett nyelvi elemként lehetne használni benne XML tag-eket (amit a java7-re terveznek).
Kevesen gondolnak deklaratív UI leírásra. Más kérdés, hogy intelligens módon a meglevő C++ API fölé lehetne deklaratív API-t húzni (pl. XML-ből valaki C++ hívásokat állít elő) – de ez igényli, hogy az alap API teljesen kiforrott legyen.
OSX/Dashboard widgetet OSX nélkül csinálni macerás – ugyanis vannak bizonyos csomagolási követelmények (a szokásos app bundle-ök egyikét kell hozzá előállítani). És ezeket nem triviális összeállítani kézzel. Sőt, a legtöbb konfigfájl bináris – és az Apple szerkesztőprogramja alakítja szövegessé. Ez egy határozottan csúnya lépés, de sajnos ez van…
Megjegyzem, némi ügyeskedéssel lehetne ezt is szépen integrálni. Például a rendszer témája felüldefiniálja a CSS bizonyos pontjait. De ez megint egy hack-jellegű megoldás, amihez megfelelően szilárd alapokra van szükség. Meg persze megfelelő igényekre.
A Javascriptes állításaiddal ugyanakkor vitatkoznék: a Javascript már most is de facto nyelve a webes alkalmazásfejlesztésnek – a kliensoldali scriptelésre igazából nincs más lehetőség, ha a HTML/CSS mellett teszi le az ember a voksát. Az alternatívák (Silverlight, Air, Flash) egytől egyig kihívásokkal küzdenek – például a Flash plugin minősége Linuxra és OSX-re, vagy a Silverlight és az Air elterjedtsége, általánosan a Google indexelhetőség (jó, ez már Flashnél kevésbé probléma), és az a tény, hogy plugint kell hozzájuk telepíteni/frissíteni.
A Javascript meg ugyanolyan okokból nem alkalmas nagy alkalmazás fejlesztésére, mint a PHP. Nem arra lett tervezve… A Javascript egy scriptnyelv, igazából arra való, hogy kisebb felatokat végezzünk vele (adat lehúzása webszerverről, más néven AJAX, esetleg editor készítésére), nagyobb feladatokat egyelőre nem is érdemes a böngészőre bízni. Már csak azért sem, mert nem bízhatunk meg a böngészők által előállított adatokban, feltétlenül szükséges a szerver oldali ellenőrzés minden egyes webes rendszerben. Innentől kezdve, ha az üzleti logika a szerveroldalon van, sokkal egyszerűbb nyelvet is használhatunk a kliensoldalon.
És ami még érdekesebb a Javascript kapcsán: kezdi elhagyni a webet (webböngészőt). Az Amarok 2 scriptnyelve a QTScript – ez a dokumentáció szerint gyakorlatilag megegyezik a Javascripttel. A Java 6 beépítve tartalmaz egy Javascript interpretert. Az IBM egyik Tivoli szoftverében (most nem akarom kikeresi a nevét, de előző félévben volt vele egy labormérés) Javascripttel lehet egyedi kódokat írni. És végül, ami talán még érdekesebb, az Eclipse e4 koncepcióterve komoly szerepet szán a Javascriptnek – de ebbe se mennék most bele részletesen.
Szóval a Javascript előtt nagyon komoly jövő áll, pláne, hogy egy csomó nagy cég elkezdi nyomni. A böngészők elkezdik egyre jobban leimplementálni. Ez fog segíteni abban, hogy a Javascript komolyan elterjedjen.
Véleményem szerint minél deklaratívabb megközelítést alkalmaz valaki, annál jobb – akár UI definiálásnál, akár másnál. Az imperatív nyelvekben is egyre inkább kezdenek megjelenni ilyen tendenciák: Java annotációk, AOP, Inversion of Control stb. Én fontos szerepet jósolok ennek a szemléletnek a(z egyáltalán nem is távoli) jövőben.
Voltaképpen az ötlött fel bennem a szabványosítás és egyebek kapcsán (ez viszont elég messzire mutat), hogy eljön-e, eljöhet-e az az idő, amikor az inkompatibilitási problémáknak, a tetemes rendszerintegrációra fordított költségeknek búcsút mondhatunk. Meg lehet-e azt csinálni, hogy a technológiákat, amik úgyis elavulnak és lecserélődnek, elrejtjük mint implementációt egy egységes emberi interface mögé, amelyik interface-t hasonlóképp használhatnak felhasználók és fejlesztők, amelyik interface nem bűvszavakkal és hárombetűs rövidítésekkel van tele, hiszen ezek, ha absztrahálunk, éppolyan megvalósításhoz tartozó részletek, mint ahogy pl. az is, hogy egy List belül ArrayList vagy LinkedList-e? Természetesen ezek a formátumok, protokollok, technológiák továbbra is kellenek, hiszen az emberi szint ezekre épül, csak máshogy helyezkednének el a szintarchitektúrában – hiszen közös emberi problémákat hivatottak megoldani: kommunikáció, tudásmegosztás, műalkotások befogadása stb. – amik nem igazán évülnek el. Ha ezeket sikerülne szemantikusan leírni, és a gép automatikusan (formalizált QoS követelmények alapján) választana ehhez belső működést!
Csakhogy a fejlesztők is emberek, a felhasználók sokfélék, vannak cégek marketingszakemberekkel, és hasonló megfontolások alapján, mint ahogy a globális ontologikus tudásbázis kollektív létrehozásának megvalósíthatósága is megkérdőjelezhető, kételyek merülnek fel bennem, és elég utopisztikusnak tűnik ez a vízió…
Minél deklaratívabb, annál jobb? Hát, majd akkor, ha megtanítjuk a gépet gondolatolvasni. Gondolj bele, hogy még a Prolognál is van lehetőség, hogy beavatkozz egy kicsit imperatív jelleggel, hogy hogyan fut le. Persze az SQL-nél ez viszonylag ritka lehetőség, de a probléma adott. Minél általánosabb a rendszer, annál inkább érződik, hogy a probléma komplexitása exponenciális/NP teljes – már ha szerencsénk van és megoldható… Szóval a következő 10 évben csak segíteni lehet a deklaratív dolgokat.
Rendszerintegráció… Na, ezzel is vitába szállnék… Lehet, hogy érdemes lett volna benn lenni a mai Nyílt hozzáférésű informatikai rendszerek előadáson… Pont ez volt a téma. Az óra egyik tanulsága: nem szabad elhanyagolni a mély rétegeket! Már az sem triviális, és az a része változik leggyakrabban a rendszernek…
Mivel csak egyetlen szoftverben nincsen hiba: amit nem írtak meg, ezért hibák biztosan vannak. Igaz ez a jó mély absztrakcióval elrejtett rétegekre is. És minél mélyebben van a hiba a rendszerben, annál perverzebb tüneteket produkálhat. És akkor még nem beszélünk arról, hogy ha a hiba Heisenbug (tipikusan versenyhelyzettől függ, stb.)…
Lényeg: az alsó rétegeket ugyanúgy meg kell írni/karban kell tartani, és erre megfelelő embereket kell allokálni. Vagy megfelelő terméket megvásárolni, és berakni a rendszerünk alsó rétegébe. De egyik sem triviális feladat.
Human interfészről: próbálkoztál már felhúzni egy más logika szerint működő felső réteget, mint a meglevő réteged? Rohadt nehéz. És minden felhasználónak (legalábbis szerep szerint) más interfész kell, szal egy egységes interfész nem igazán jöhet számításba. Hiszen egy könyvelő könyvelési fogalmakkal szeret dobálkozni a program használata közben, de nem biztos, hogy ez a megrendelő vágyálma… És nyilván a rendszert felügyelő rendszergazdát meg nem érdeklik ezek a részletek (talán jobb is, ha nem is ért hozzá 🙂 ). Más szóval csinálni kell sok, és ráadásul nehezen fejleszthető felhasználói felületet.
QoS követelmények formalizálása: ismét egy nagyon gyakorlatias megközelítés, csak két absztrakciós szintbeli különbség van (kb.): az élő nyelv nem egyértelmű -> egyértelműsíteni kell, és ezt összevetni az eredetivel, leképezni, stb. És persze reménykedni, hogy a leképezés kódjába nem üt be a mennykő.
És erre persze rájönnek az általad említett, nem-technikai jellegű problémák is (cég policy, stb. stb. stb.), de ez messze nem a teljes paletta. Szóval ez azért tényleg erőteljesen sci-fi szagú.
Az elkövetkező 5-10 évben nem valószínű, hogy ezen tényezőkben lényeges változás állna be. A számítógépek hiába tudnak már nagyon sok mindent, nem emberi gondolkodásuk van…
PS.: jó dolog, hogy panaszkodsz a hárombetűs betűszavak használata miatt, majd egy bekezdéssel később ellövöd a QoS-t.
PS2.: remélem, nem voltam túlságosan is leoltó hatású…
Nem tudom mennyire aktuális még a helyzet, de én a helyedben, kihasználnám az rcp/osgi adta lehetőségeket.
Ugyanis az swt “csomagok” az osgi szemszögéből platformhoz vannak kötve.
Pl.:
org.eclipse.swt.win32.win32.x86_3.3.3.v3349.jara manifest fájljában így van definiálva:Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86)).Ezért, hiába van minden platform jar-ja betöltve, csak az fog elindulni ami a rendszernek megfelel.
Ha nem akarsz teljes rcp-t betölteni, akkor érdemes megnézni a
org.eclipse.osgi_3.4.0.v20080605-1900.jar-ban a EclipseEnvironmentInfo class-t. Innét a getOS(), getWS(), getOSArch() hívásokkal mar ki tudod deríteni melyik swt jar-ra van szükséged.Amire még figyelni kell, hogy linux esetén csak GTK “ws” létezik, illetve ha az “os” mac akkor az “osarch”-nak nincs értelme/értéke. Így már meg is van az swt-jarban ez a rész:
win32.win32.x86 => ws.os.arch.Köszönöm a segítséget, ez valóban működik, és nem kell becsatolni az egész eclipse platform-ot, csak egy szűk 1Mb-os jar-ról van szó.
A cikket módosítom ez alapján. Még egyszer köszönöm.
Igazán nincs mit.
Ha Eclipse/RCP/SWT/JFace téren segítség kell, csak szólj. 🙂