Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Marek 20. 07. 2014, 19:00:57
-
Dobrý deň,
zaujímalo by ma, aký druh softwaru vyvíjate v Jave. Moja otázka mieri skôr na tých, ktorý sa Jave venujú roky a je pre nich denným chlebom. Diskusie ohľadom využitia tohto programovacieho jazyka (ako vlastne skoro každú diskusiu ohľadom čohokoľvek) som zavrhol. Všade sa nájdu tí, ktorí jazyk vyzdvihujú a tí, ktorí ho hania ale málokto dokáže podať uspokojivú objektívnu odpoveď.
Obraciam sa teda na Vás. Pochopil som to tak, že profi-Javisi majú uplatnenie hlavne v enterprise sfére (dokážem si predstaviť napríklad vývoj IS pre banky a korporácie). Zaujímalo by ma ale, čo konkrétne ako profi-Javista vyvíjate a prečo je v tejto sfére tak obľúbená práve Java, respektíve prečo sa usadila v tomto odvetví. Ďakujem.
Marek.
-
Ja? Nič. Ale, ďakujem za opýtanie.
-
Zdravim,
u nas v Jave programujeme v podstate vsechno. Nedelame pro banky a nejsme velka korporace. Delame v tom weby, administracni rozhrani k nasim sluzbam, webove sluzby (REST). Mimo JEE v tom mame napsane SMSkove brany a nejake backendy pro nase sluzby.
A k duvodum proc mame javu. Puvodne byly aplikace psane vetsinou v .NET. To bylo odsunuto po tom, co jsme premigrovaly servery na Linux. Cas jsem testovali PHP, ale od urcite velikosti projektu uz bylo spis na obtiz (neprehledne, spatne rozsiritelne). V Pythonu jsme meli napsanou jednu branu. Kdyz se musela upravovat, predelala se do Javy. Nastroje, podpora a dokumentace v Pythonu nebyly takove jako u PHP a Javy. A kdyz uz bylo vse ostatni v Jave, nebyl duvod udrzovat jednu vec v Pythonu.
Takze Javu mame pro jeji vykon (ano, ted se spousta lidi co videli javu naposledy pred 10 lety smeji), robustnost a cely jeji ekosystem. Produktivita je s Javou opravdu enormni (pokud nemusite psat pro prvni J2EE).
-
Jelikož je Java jeden z nejlepších jazyků, tak se používá skoro všude. Proč by to tak nemělo být? Hodí se na všechno a ještě je to spolehlivý nástroj.
-
J2EE (webove aplikace), aplikacni backendy (vyhodou je rychlost vyvoje, skalovatelnost, robustnost a multiplatformnost -> u jednoho zakaznika bezi na RHEL, u dalsiho na windows, sunos, aix, ...)
-
Projekty ktery si pamatuju z posledni doby:
self-care system pro mobilniho operatora (cr)
system pro spravu manualu a rozpisu planu praci pri udrzbach letadel (nemecka letecka spol.)
kontrolni hub pro spravu jobu v IT infrastrukture (radove tisice az desestitisice pocitacu, usa, zakaznici z rad bankovni ustavu)
statni sprava, centralni registry
duvody pouzivani:
1) relativne rychly a snadny vyvoj (oproti napr. c++)
2) obrovsky ekosystem, JEE, standardizace, kvanta frameworku a knihoven, hodne uzitecnych veci pro bussiness sferu
3) proverena, spolehliva technologie, miliony clanku, knih, howto etc
4) velke mnozstvi vyvojaru
Ostatni me urcite jeste doplni.
Jinak java je jen jazyk, nic vic, neni to cil ale prostredek. Pokud ti jde o uplatneni, java je jistota.
-
Ďakujem Vám za Vaše skoré odpovede. Teraz už majú moje predstavy a špekulácie jasné tvary :)
Ešte by ma zaujímalo, prečo nie je Java veľmi obľúbená na tvorbu desktop aplikácií. Programov napísaných v Jave, ktoré poznám, by som spočítal na prstoch jednej ruky a strýko google mi ich veľa nepridal. Zdá sa mi, ako by bolo všetko postavené na C/C++ (ak počítam programy ktoré sú multi-platform).
-
Ja? Nič. Ale, ďakujem za opýtanie.
++ ;D 8)
-
Ešte by ma zaujímalo, prečo nie je Java veľmi obľúbená na tvorbu desktop aplikácií. Programov napísaných v Jave, ktoré poznám, by som spočítal na prstoch jednej ruky a strýko google mi ich veľa nepridal. Zdá sa mi, ako by bolo všetko postavené na C/C++ (ak počítam programy ktoré sú multi-platform).
Protože Java je defective-by-design pro desktopové vizuální aplikace, tyto obvykle potřebují těsnou interakci s OS a na to Java není vhodná. Patrně proto se ani za 19-ti let nepodařilo vytvořit systém pro snadnou tvorbu kvalitních desktopových aplikací v Javě a proto prostě větší desktopové aplikace nebyly, nejsou a nebudou.
Jinak java je jen jazyk, nic vic.
Java rozhodně není jenom jazyk, používání Javy implikuje nutnost nainstalovat na cílovou mašinu JVM(+JIT), tedy infrastrukturu nutnou k provozování věcí napsaných v Javě.
-
Teď píšu jednu aplikaci v Clojure + GUI v NetBeans Platform (Java 8).
NetBeans Platofrm / Eclipse RCP možná nejsou snadné na naučení, ale rozhodně to jsou frameworky pro snadnou tvorbu velkých desktopových aplikací. V C++ ani .Netu jsem neviděl nic, co by se tomu přibližovalo. Možná Prism, ale ten nechává některé věci na programátorovi; Qt, GTK, WinForms i WPF jsou pouze knihovny, které řeší zobrazení oken + mají některé podpůrné funkce, ale rozhodně neřeší celkový životní cyklus aplikace.
Jo a Java je jen a pouze jazyk. Tvrzení že použití Javy implikuje něco neznamená, že Java není jen a pouze jazyk (logicky). To je jako říct, že C# není jazyk, protože implikuje nutnost nainstalovat .Net. Nebo že C++ není jazyk, protože vyžaduje instalaci msvcr11.dll.
-
NetBeans Platofrm / Eclipse RCP možná nejsou snadné na naučení, ale rozhodně to jsou frameworky pro snadnou tvorbu velkých desktopových aplikací.
Z tvrzení, že existuje framework pro snadnou tvorbu desktopových aplikací v Javě, by člověk očekával že se s nějakou takovou aplikačkou sem tam setká, jenže ono se to jednoduše neděje. Nějaké příklady desktopových aplikaček, které zajímaly Marka, by nebyly ?
Tvrzení že použití Javy implikuje něco neznamená, že Java není jen a pouze jazyk (logicky).
A java bytecode, JVM, JIT je tedy co, když to podle tebe není součást Javy ? :)
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
-
A java bytecode, JVM, JIT je tedy co, když to podle tebe není součást Javy ? :)
JIT se netýká jen Javy má ho i Visual Studio, když se píše kód pro .NET.
-
v jave robime vacsinou rozsiahle webove aplikacie a pevnych klientov + ich serverovske casti, generovanie reportov, predspracovanie dat.
Java desktopoviek je vela, ale nie su urcene pre beznych ludi ale pre enterprise sferu. Lebo a to lahko vyvyja a lahko nasadzuje, problemy s rychlostou nie su, lebo tie aplikacie su vacsinou formularove + dake reporty a pre beznych pouzivatelov to staci.
-
Ešte by ma zaujímalo, prečo nie je Java veľmi obľúbená na tvorbu desktop aplikácií. Programov napísaných v Jave, ktoré poznám, by som spočítal na prstoch jednej ruky a strýko google mi ich veľa nepridal. Zdá sa mi, ako by bolo všetko postavené na C/C++ (ak počítam programy ktoré sú multi-platform).
Protože Java je defective-by-design pro desktopové vizuální aplikace, tyto obvykle potřebují těsnou interakci s OS a na to Java není vhodná. Patrně proto se ani za 19-ti let nepodařilo vytvořit systém pro snadnou tvorbu kvalitních desktopových aplikací v Javě a proto prostě větší desktopové aplikace nebyly, nejsou a nebudou.
problem je v teto casti:
1) relativne rychly a snadny vyvoj (oproti napr. c++)
java totiz je navrzena tak, aby prenesla odpovednost za reseni problemu z implementace do provozu. takze co se usetri na programatorech to se zaplati za vypadky v provozu nebo za predimezovani kapacit tak aby aplikace prezila aspon 23 a pul hodin a pak se pravidelne kazdy den restartovala.
to je realita nasazeni java aplikaci a uspor za kazdou cenu.
-
nikdo kdo neutraci cizi penize si to pak domu neporidi. ale pokud jde o penize zakazniku/akcionaru, tak to samozrejme problem neni.
-
java totiz je navrzena tak, aby prenesla odpovednost za reseni problemu z implementace do provozu. takze co se usetri na programatorech to se zaplati za vypadky v provozu nebo za predimezovani kapacit tak aby aplikace prezila aspon 23 a pul hodin a pak se pravidelne kazdy den restartovala.
to je realita nasazeni java aplikaci a uspor za kazdou cenu.
to je jenom v pripade, ze tam pracuji hovada, kteri to neumi spravne nastavit a naprogramovat (coz je bohuzel celkem caste), nase aplikace treba bezi klidne pul roku bez restartu, pak se dela restart treba kvuli nasazeni nove verze
-
java totiz je navrzena tak, aby prenesla odpovednost za reseni problemu z implementace do provozu. takze co se usetri na programatorech to se zaplati za vypadky v provozu nebo za predimezovani kapacit tak aby aplikace prezila aspon 23 a pul hodin a pak se pravidelne kazdy den restartovala.
to je realita nasazeni java aplikaci a uspor za kazdou cenu.
to je jenom v pripade, ze tam pracuji hovada, kteri to neumi spravne nastavit a naprogramovat (coz je bohuzel celkem caste), nase aplikace treba bezi klidne pul roku bez restartu, pak se dela restart treba kvuli nasazeni nove verze
jenze cena vyvoje takhle napsane aplikace odpovida cene vyvoje v c++ se statickou analyzou kodu a klade obdobne vysokou latku na kvalitu programatoru.
-
java totiz je navrzena tak, aby prenesla odpovednost za reseni problemu z implementace do provozu. takze co se usetri na programatorech to se zaplati za vypadky v provozu nebo za predimezovani kapacit tak aby aplikace prezila aspon 23 a pul hodin a pak se pravidelne kazdy den restartovala.
to je realita nasazeni java aplikaci a uspor za kazdou cenu.
to je jenom v pripade, ze tam pracuji hovada, kteri to neumi spravne nastavit a naprogramovat (coz je bohuzel celkem caste), nase aplikace treba bezi klidne pul roku bez restartu, pak se dela restart treba kvuli nasazeni nove verze
jenze cena vyvoje takhle napsane aplikace odpovida cene vyvoje v c++ se statickou analyzou kodu a klade obdobne vysokou latku na kvalitu programatoru.
Napsat a odladit komplexni prenositelnou aplikaci v c++ zabere mnohem vice casu, nez ji napsat v Jave, proto se to nepise v c++.
A samozrejme, klade to vysokou latku na kvalitu programatoru (nebo snad chcete tvrdit, ze programatori v c++ jsou nadrazeni jinym programatorum?), taky si je firma dokaze peclive ohodnotit (neni zadouci mit caste vypadky v aplikaci, kdyz je dohodnute nejake SLA)
-
snad chcete tvrdit, ze programatori v c++ jsou nadrazeni jinym programatorum?
To je přece v Javě by-design, Java programátor je odkázán na to co mu připraví právě programátoři C/C++ v javac a JVM.
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
Jak se píše C# pro Linux?
-
cena takhle napsane aplikace totiz obsahuje proti C++ vyssi provozni naklady za "nepredvidatelnost" jvm. takze kdyz uz je dotazena tak, ze prezije bez restartu, tak porad zustavaji vyssi provozni naklady, ktere podle doby a objemu provozu dorovnaji naklady C++ vyvoje.
ale jak rikam. dokud se utraci penize zakazniku nebo akcionaru, kteri si navic mysli, ze tohle je v jejich pripade vyhodnejsi varianta, tak to je jejich analyza a jejich problem co oni resi. neni to problem dodavatele aplikace.
-
Jak se píše C# pro Linux?
http://en.wikipedia.org/wiki/Mono_%28software%29 (http://en.wikipedia.org/wiki/Mono_%28software%29)
http://en.wikipedia.org/wiki/MonoDevelop (http://en.wikipedia.org/wiki/MonoDevelop)
-
Ahoj,
programuji v Jave od od doby co byla verze 1.3. Tenkrat jeste na stredni skole. Kdyz zminim vetsi projekty na kterych jsem spolupracoval tak to bylo :
SW pro analyzu dat z vyroby. Distribuovane nasazeni Evropa, Asie.
Velky monolitycky system pro analytickou spolecnost, personalistika, sprava konferenci, analyzy prodeje, CMS pro webove stranky. Dale se v teto spolecnosti realizovala v jave serverova strana sw pro analyzy projedu v oblasti IT a Telekomunikaci.
System na spravu citlivych dat o zakaznicich pro jednoho mobilniho operatora. Nasazeni v 10 evropskych zemich + pocitano nasazeni v Asii. Z tohoto projektu jsem po 6ti mesicich vycouval. Kvalita kodu a provedeni byla strasna. Cely projekt byl strasne komplikovany a nikdo nepremyslel nad tim jak programuje. Napriklad pri prime praci s db nezaviral spojeni. Pak vznikaji pomluvy o jave.
Momentalne pracuji pro jednu velkou(5M zakazniku online) televizni spolecnost kde v jave vyvyjime back-end pro online streaming.
Duvody proc uprednostnuji javu?
Tak hlavne staticka typovost. Moznost prijit na plno chyb uz v dobe prekladu. Dnes jsou moderni dynamicke jazyky, ale ve firemni prostredi proste potrebujete vedet presne co za data dostanete a co mate zase vratit. Take to je vyspelosti platformy a vyvojovych nastroju pro ni. Je zde vyreseno plno veci ohledne databaze a transakcniho zpracovani. A (male rypnuti) asi nejlepsi VM co momentalne mame.
Radek
-
Jak se píše C# pro Linux?
http://en.wikipedia.org/wiki/Mono_%28software%29 (http://en.wikipedia.org/wiki/Mono_%28software%29)
http://en.wikipedia.org/wiki/MonoDevelop (http://en.wikipedia.org/wiki/MonoDevelop)
Toho jsem se bál. MonoDevelop jsem před pár lety spustil a když mi každá operace trvala několik desítek sekund, tak muselo opustit můj stroj. Zlaté NetBeans. Třeba je to ale teď lepší a až budu mít čas, tak dám Monu ještě šanci.
-
V Javě dělám v práci GUI SIP klienta pro Android (jádro je nativní v C++). Doma občas pár drobností jen pro zábavu většinou opět pro Android, občas pro desktop. Žádné J2EE a podobné radosti, serverové věci pro banky, informační systémy a podobné věci nedělám. Pokud k tomu máte taky odpor, ale jinak se Vám Java líbí, naučte se Android, to je asi jediná široká a dobře prošlapaná cesta, jak se v Javě slušně uživit i bez těch serverových srágor.
-
Tak hlavne staticka typovost. Moznost prijit na plno chyb uz v dobe prekladu.
Statická typovost a kontrola syntaxe při překladu už tady byla 30 let před vznikem Javy, tedy nejedná se o přidanou hodnotu Javy.
Napriklad pri prime praci s db nezaviral spojeni. Pak vznikaji pomluvy o jave.
Solidní jazyk si umí zavřít spojení sám, když na to programátor zapomene. V Javě tohle jednoduše dost dobře nejde, rozhodně ne tak jak by bylo potřeba.
-
V Jave vyvijam system pre male stovky zakaznikov, ktory eviduje kopu veci, kontroluje vztahy medzi nimi, zvlada exporty, importy atd. GUI je Swingovske. Co do cielu viditelneho pre uzivatelov, Java tu sluzi ako "modernejsie FoxPro".
Dalej v Jave robim app pre Android. Ale to miestami podla Googlu nie je uplne tak Java.
-
Ešte by ma zaujímalo, prečo nie je Java veľmi obľúbená na tvorbu desktop aplikácií. Programov napísaných v Jave, ktoré poznám, by som spočítal na prstoch jednej ruky a strýko google mi ich veľa nepridal. Zdá sa mi, ako by bolo všetko postavené na C/C++ (ak počítam programy ktoré sú multi-platform).
lebo treba instalovat javu, lebo treba zistovat, ktoru z 3 major verzii a ktoru z 35tisic minor verzii, ma klient nainstalovanu, lebo si vsetci furt myslia, ze java je pomala, lebo si vsetci myslia, ze nativna integracia sux0rz, lebo programovat performantne gui v jave je otrava
v jave robim kadejake backendy na serveri, popri statickej typovosti mi viac pomahaju nastroje: dobre zvolene ide + pluginy robia zazraky. ked sa mi nechce syntaktizovat javu, switchnem do groovy. o knizniciach ani nehovorim.
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
Rozsáhlé serverové systémy pro energetiku pro Linux v C#? Rozumím tomu správně?
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
Rozsáhlé serverové systémy pro energetiku pro Linux v C#? Rozumím tomu správně?
Přesně, a naposledy dělal na navigačním systému pro nějaký rakety, real-time C# na Linuxu. Jmenovalo se to Topol, Dub nebo tak nějak :)
-
Napriklad pri prime praci s db nezaviral spojeni. Pak vznikaji pomluvy o jave.
Solidní jazyk si umí zavřít spojení sám, když na to programátor zapomene. V Javě tohle jednoduše dost dobře nejde, rozhodně ne tak jak by bylo potřeba.
Nemyslím si že by jazyk mohl (a měl) poskytovat víc než má aktuální verze Javy: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
-
Nemyslím si že by jazyk mohl (a měl) poskytovat víc než má aktuální verze Javy: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
No evidentně mohl, když jsou pořád potíže s neuzavíráním spojení ;)
Uvedená konstrukce funguje, ale musí se to pořád explicitně napsat.
-
Dobry den,
Chybne uzavirani databazoveho spojeni byl jen jeden z moji praxe. Veskutecnosti je problematika daleko obsahnejsi. Samozrejme ze i toto lze v jave resit, s pouzitim vyssich ORM frameworku ci jinych konstrukci.
Pokud bych mel vyzdvihnout jeste dalsi duvody proc programuji v jave, tak to je velmi siroka komunita kvalitnich knihoven. Z nichz bych asi vyzdvihnul Spring Framework. Kvalitni IDE zdarma, moznost provozovat aplikace na linuxu, a nepochybne i vysoky vykon pri vyssi zatezi.
Co povazuji za dalsi skvelou myslenku v java komunite jsou buildovaci nastroje ktere resi problemy se zavizlosti projektu na externich knihovnach.
No a nakonec, pokud pouziju standartni API, tak na posledni verzi JVM rozjedu i 10 let starou aplikaci, a nemusim resit to, ze pro provozovani sveho interniho projektu musim pouzivat starou(neurdrzovanou verzi s bugy) verzi behoveho prostredi jen kuli tomu, ze nekdo zmenil syntaxi a nebo ostranil urcite vlastnosti jazyka.
Samozrejme ze java ma i sve zaporne stranky, dokonce ke kazde vlastnosti kterou zde zminuji jako pozitivni bychom nasli to proc je negativni, ale to ma kazdy jazyk.
Radek
-
lebo si vsetci furt myslia, ze java je pomala
Je pořád 2x pomalejší než C/C++. Takže céčkaři si to můžou myslet naprosto oprávněně :-)
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
Rozsáhlé serverové systémy pro energetiku pro Linux v C#? Rozumím tomu správně?
Přesně, a naposledy dělal na navigačním systému pro nějaký rakety, real-time C# na Linuxu. Jmenovalo se to Topol, Dub nebo tak nějak :)
Myslíš tenhle Topol? :-D
http://en.wikipedia.org/wiki/RT-2PM_Topol
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
Rozsáhlé serverové systémy pro energetiku pro Linux v C#? Rozumím tomu správně?
Přesně, a naposledy dělal na navigačním systému pro nějaký rakety, real-time C# na Linuxu. Jmenovalo se to Topol, Dub nebo tak nějak :)
Myslíš tenhle Topol? :-D
http://en.wikipedia.org/wiki/RT-2PM_Topol
Měl jsem na mysli jistý Buk a jeho nedávné použití, kdy nejspíš trefil trochu jiné letadlo, než odpalující čekali :)
-
No evidentně mohl, když jsou pořád potíže s neuzavíráním spojení ;)
predpokladam, ze sa rozpravame o projektoch, ktore robia ludia pri zmysloch alebo ktori maju technicke vedenie pri zmysloch a nie nahodni patlali alebo ludia odsudeni na projekt autorovany nahodnymi patlalmi - to je katastrofa v kazdom jazyku
napr. (bohuzial) praca s databazou cez jdbc api je natolko zla, ze sudny clovek rovno zoberie nejaku zmysluplnu kniznicu, ktora zatvaranie vsetkych prostriedkov vyriesi sama (spring napr.)
alebo try with resources, co sice nie je raii, ale je to lepsie nez doby pred nou
Je pořád 2x pomalejší než C/C++.
nie (http://forum.root.cz/index.php?topic=8057.0)
-
Určitě je to pěkné povídání, ale nehodlám číst třináct stránek. Já radši nějaké to měření (http://forum.root.cz/u64/benchmark.php?test=all&lang=gcc&lang2=java&data=u64).
-
Oprava:
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=gcc&lang2=java&data=u64
-
Nemyslím si že by jazyk mohl (a měl) poskytovat víc než má aktuální verze Javy: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
No evidentně mohl, když jsou pořád potíže s neuzavíráním spojení ;)
Uvedená konstrukce funguje, ale musí se to pořád explicitně napsat.
Sice nemám Javu rád a za náhradu RAII výjimkovým systémem a další podivné nápady (např. Stringy v JNI, kde chybné UTF vyvolá pád JVM místo nějaké výjimky) bych jejich autory nechal občas usmažit, ale tohle je chyba toho, kdo v ní píše, ne samotné Javy.
-
Rozsáhlé serverové systémy pro energetiku pro Linux v C#? Rozumím tomu správně?
Přesně, a naposledy dělal na navigačním systému pro nějaký rakety, real-time C# na Linuxu. Jmenovalo se to Topol, Dub nebo tak nějak :)
;D
-
Mno ... ja se pridam ... jakozto (z donuceni) uzivatel nekolika java aplikaci. Mam tu (kuprikladu) wireless switch, ktery ma v jave administraci. A ta nefunguje ... protoze mam moc novou javu. Kdyz si nainstalim starsi, tak prozmenu prestanou fungovat jiny veci. Pak tu mam v jave administraci zalohovaciho SW. Vecne z toho padaj neosetreny vyjimky (takovy to dlouhy povidani na par stranek) a reakce to ma doslova sneci. A moh bych pokracovat.
Takze za me osobne, s radosti zaskrtim kazdyho, kdo prijde s naprosto cimkoli v jave.
-
Protoze vsichni vime, ze v jave se prasi a jinde pise poradne. Tak urcite.
-
Mno ... ja se pridam ... jakozto (z donuceni) uzivatel nekolika java aplikaci. Mam tu (kuprikladu) wireless switch, ktery ma v jave administraci. A ta nefunguje ... protoze mam moc novou javu. Kdyz si nainstalim starsi, tak prozmenu prestanou fungovat jiny veci. Pak tu mam v jave administraci zalohovaciho SW. Vecne z toho padaj neosetreny vyjimky (takovy to dlouhy povidani na par stranek) a reakce to ma doslova sneci. A moh bych pokracovat.
Takze za me osobne, s radosti zaskrtim kazdyho, kdo prijde s naprosto cimkoli v jave.
to by odpovidalo uzivatelskym zkusenostem s management applety typu HP iLO mezi ruznymi firmwary a generacemi hardware. s jednim operacnim systemem a jednou verzi jre pripadne jdk neni mozne dosahnout toho, aby fugovaly vsechny applety.
-
Protoze vsichni vime, ze v jave se prasi a jinde pise poradne. Tak urcite.
problem je jinde: Java je navrzena tak, aby dodavatel aplikace mohl prodat smejd a do nekonecna argumentovat nekonecnou potrebou navysovani provoznich zdroju a jeho zakaznik mu nemohl dat protiargument, ze lze.
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
Rozsáhlé serverové systémy pro energetiku pro Linux v C#? Rozumím tomu správně?
Ty serverove systémy pro energetiku to bylo psáno v C# pro Windows Server. Tam byly také realtime prvky, dá se říct, že přesun takových dat má klíčovu důležitost. Začali jsem dělat port na Linux, udělala se první verze, ale nakonec zákazník rozhodnul přejít na Windows.
Ty real-time systémy napsané v C# jsou dost běžné v automatizaci v průmyslu, tam už se to dá dost dobře udělat, že se jádro systému napíše tak aby to bylo kompilovatelné jak pod windows, tak pod Linuxem a Gui se udělá konkrétně tak aby to jelo pod Win, KDE, Gnome, ale většinou se to dělá pro Windows. Ale Linux to je fakt menšina je toho čím dál méně.
Proč se tak rozmáhá Windows, nevím, asi je to kvůli výrobcům HW, kteří snad ani drivery pro Linux nedělají (teď jsem ze zvědavosti kouknul na stránky jednoho výrobce HW a občas nějaký driver pro Linux tam je).
-
Desktopových aplikací v Javě moc není, ale něco málo se najde:
http://project-x.sourceforge.net/
http://java-apps.org/
Jinak já si programuju (spíš patlám) malý blbůstky pro radost.
-
Ještě k tej pomalosti:
http://java.cz/article/cz-podcast-90-psani-low-latency-java-aplikaci
-
Ďakujem všetkým za užitočné informácie :) Zase som o niečo máličko múdrejší ;D
-
...praca s databazou cez jdbc api je natolko zla, ze sudny clovek rovno zoberie nejaku zmysluplnu kniznicu...
To podla teba znamena sudny clovek = clovek neznaly SQL ?
Sorry, ale ja mam na to opacny nazor. Pri JDBC aspon clovek vie co robi, lahko sa to debuguje a lahko sa to udrzuje.
A okrem toho pouzivas iba standardnu kniznicu a nie s zavisly od nejakych dalsich high-level frameworkov inych autorov.
Predpokladom pre pouzivanie JDBC ale samozrejme je, ze si ochotny zacat sa viac zaoerat aj databazou.
-
Vůbec nic. Dělám v C# a to hlavně realtime systémy pro průmysl, ale dělal jsem v tom i rozsáhlé serverové systémy pro energetiku. A to jak pro windows, tak pro Linux.
Rozsáhlé serverové systémy pro energetiku pro Linux v C#? Rozumím tomu správně?
Ty serverove systémy pro energetiku to bylo psáno v C# pro Windows Server. Tam byly také realtime prvky, dá se říct, že přesun takových dat má klíčovu důležitost. Začali jsem dělat port na Linux, udělala se první verze, ale nakonec zákazník rozhodnul přejít na Windows.
Ty real-time systémy napsané v C# jsou dost běžné v automatizaci v průmyslu, tam už se to dá dost dobře udělat, že se jádro systému napíše tak aby to bylo kompilovatelné jak pod windows, tak pod Linuxem a Gui se udělá konkrétně tak aby to jelo pod Win, KDE, Gnome, ale většinou se to dělá pro Windows. Ale Linux to je fakt menšina je toho čím dál méně.
Proč se tak rozmáhá Windows, nevím, asi je to kvůli výrobcům HW, kteří snad ani drivery pro Linux nedělají (teď jsem ze zvědavosti kouknul na stránky jednoho výrobce HW a občas nějaký driver pro Linux tam je).
Aha, takže jste začali ty serverové systémy pro energetiku dělat v C# pro Linux. Zákazník si toho naštěstí včas všimnul, zarazil vás a dodšělali jste to na Windows. To mi spadnul kámen ze srdce, alespon ti zákazníci v energetice mají soudnost.
Ale teď se nám rýsuje další nejasnost - můžeš prosímtě vysvětlit co si mám představit pod pojmem "real-time systémy napsané v C#"? Na jakém OS to běží? Jak je to tam zhruba s časy a vytížením systému? Co se s tím řídí?
Díky.
-
A teď ješte takový menší dotaz - C# vs. Java co so hodi na co víc ? webové aplikace, nejaké realtime programy, práca s pamäťou a podobné veci..
Vedel by mi to niekto zrovnať trochu ? :)
-
To máš prašť jak uhoď. C# je podstatně progresivnější jazyk, ale zase není zrovna moc multiplatformní.
Napsat se dá v obou v podstatě cokoliv, samozřejmě ne na všechno je každý jazyk vhodný. To by ale bylo na delší povídání, stačí trochu zagooglit. Každopádně pro "realtime" aplikace bych osobně nevolil ani jeden z nich.
Práce s pamětí, to je v Javě spíš takový oxymoron. Jde to, ale je to pořád něco jako hack a ani bych to nedoporučoval. V C# se s tím počítá, dá se to pomocí "unsafe" operací. To má zase svoje, výkonem to zaostává za C++ a troufám si tvrdit, že většina C# programátorů u takového kódu ani nebude tušit, která bije. Rozhodně ale pořád 100x lepší, než v Javě.
-
To máš prašť jak uhoď. C# je podstatně progresivnější jazyk, ale zase není zrovna moc multiplatformní.
Napsat se dá v obou v podstatě cokoliv, samozřejmě ne na všechno je každý jazyk vhodný. To by ale bylo na delší povídání, stačí trochu zagooglit. Každopádně pro "realtime" aplikace bych osobně nevolil ani jeden z nich.
Práce s pamětí, to je v Javě spíš takový oxymoron. Jde to, ale je to pořád něco jako hack a ani bych to nedoporučoval. V C# se s tím počítá, dá se to pomocí "unsafe" operací. To má zase svoje, výkonem to zaostává za C++ a troufám si tvrdit, že většina C# programátorů u takového kódu ani nebude tušit, která bije. Rozhodně ale pořád 100x lepší, než v Javě.
V Jave je taky unsafe balicek, ktery obsahuje metody pro primy pristup k pameti (ale pouzivat by se nemel)
-
Jenom mě tak napadá: všimli jste si, že 90% obsahu této diskuse je přesně to, co původní tazatel explicitně nechtěl?
-
naposled toto:
http://forum.root.cz/index.php?topic=9013.msg100916#msg100916
a jinak android (java?!) a nejake tools
-
Pri JDBC aspon clovek vie co robi, lahko sa to debuguje a lahko sa to udrzuje.
A okrem toho pouzivas iba standardnu kniznicu a nie s zavisly od nejakych dalsich high-level frameworkov inych autorov.
nemyslel som prave hibernate, ci jpa, myslel som prave java.sql.*.
kym clovek napise obsluhu pre jeden select, napise asi tak 5x tolko boilerplatu (otvaracky connectionov, preparedstatementov, resultsetov, a hlavne zatvaracky toho vsetkeho, co je naslapna mina pre zabudnuty close pri nejakej vynimke)
projekty, kde som robil, si vzdy urobili nejaky wrapper nad jdbc: bud pouzili onen spring jdbc alebo napr. mybatis alebo si napisali jeho variant, ktory haluze so spravou resourcov (nehovoriac o sprave samotnych sql dotazov) urobili za nich.
-
Pri JDBC aspon clovek vie co robi, lahko sa to debuguje a lahko sa to udrzuje.
A okrem toho pouzivas iba standardnu kniznicu a nie s zavisly od nejakych dalsich high-level frameworkov inych autorov.
nemyslel som prave hibernate, ci jpa, myslel som prave java.sql.*.
kym clovek napise obsluhu pre jeden select, napise asi tak 5x tolko boilerplatu (otvaracky connectionov, preparedstatementov, resultsetov, a hlavne zatvaracky toho vsetkeho, co je naslapna mina pre zabudnuty close pri nejakej vynimke)
projekty, kde som robil, si vzdy urobili nejaky wrapper nad jdbc: bud pouzili onen spring jdbc alebo napr. mybatis alebo si napisali jeho variant, ktory haluze so spravou resourcov (nehovoriac o sprave samotnych sql dotazov) urobili za nich.
Jeden z nejsilnějších nástrojů v Javě jsou anotace, protože ty mohou generovat vcelku libovolný kód. Ale není zrovna jednoduché annotation processor napsat.
Jinak já pro implementaci RAII (hlavně pro zdroje z nativního kódu) používám takový malý hack: ve finalize javovského objektu pošlu pomocí JNI do fronty funktor, který umí zdroj uklidit. To zavání deadlockem, protože finalize nemá moc záruk, kdy probíhá, nicméně jedna, která se dá využít, tam je. Ostatní vlákna totiž buď běží (tj. k deadlocku nemůže dojít) nebo jsou v synchronizovaném stavu. Takový stav v JVM může být celkem kdykoliv (tedy fronta může být zamčená a dojde k deadlocku), ale v JNI nastává pouze při přechodu mezi nativním kódem a JVM, takže pokud nativní kód během jednoho volání JNI příslušnou frontu zamkne i odemkne (bez volání JVM mezi tím), tak to vlákno nemůže být zastaveno se zamčenou frontou a tedy nemůže dojít k deadlocku.
-
Jinak já pro implementaci RAII (hlavně pro zdroje z nativního kódu) používám takový malý hack: ve finalize javovského objektu pošlu pomocí JNI do fronty funktor, který umí zdroj uklidit.
Hmm, zajímavé, ale... proč? Obdobný mechanismus nahrazující finalize přeci byl přidán již v JDK 1.2 (PhantomReference a ReferenceQueue).
Druhá věc je označení RAII, ale na to tady určitě naběhne zásahová jednotka, takže to raději nechám stranou :-)
-
Jenom mě tak napadá: všimli jste si, že 90% obsahu této diskuse je přesně to, co původní tazatel explicitně nechtěl?
nas v tom gulas. odpoved 6 tazatel zatrolil: "Ešte by ma zaujímalo, "
-
Jinak já pro implementaci RAII (hlavně pro zdroje z nativního kódu) používám takový malý hack: ve finalize javovského objektu pošlu pomocí JNI do fronty funktor, který umí zdroj uklidit.
Hmm, zajímavé, ale... proč? Obdobný mechanismus nahrazující finalize přeci byl přidán již v JDK 1.2 (PhantomReference a ReferenceQueue).
Druhá věc je označení RAII, ale na to tady určitě naběhne zásahová jednotka, takže to raději nechám stranou :-)
Rozdíl je v tom, že ReferenceQueue je pasivní a je nutné ji pollovat, zatímco to moje je aktivní a uvolňuje zdroje ve chvíli, kdy GC uklidí ten ukazatel. Ten rozdíl se může zdát nepatrný, ale na telefonech to u dlouhoběžící aplikace dělá docela velký rozdíl ve spotřebě baterie.
-
Jenom mě tak napadá: všimli jste si, že 90% obsahu této diskuse je přesně to, co původní tazatel explicitně nechtěl?
nas v tom gulas. odpoved 6 tazatel zatrolil: "Ešte by ma zaujímalo, "
Je poměrně smutné že když někdo explicitně nezdůrazní "nechci kydy" tak je to automaticky považováno za trolling.
Ještě smutnější je, že to reálně může být fakt záměrné rozpoutání flamewar a těžko se to dozvíme.
-
pošlu do fronty funktor, který umí zdroj uklidit.
Rozdíl je v tom, že ReferenceQueue je pasivní a je nutné ji pollovat, zatímco to moje je aktivní a uvolňuje zdroje ve chvíli, kdy GC uklidí ten ukazatel. Ten rozdíl se může zdát nepatrný, ale na telefonech to u dlouhoběžící aplikace dělá docela velký rozdíl ve spotřebě baterie.
To jsem trochu zmatený... Pokud se ten funktor provede okamžitě, tak to tam není fronta, ne? Já si pod pojmem "fronta" představím datovou strukturu (FIFO, v tomto konkrétním případě). Jak vypadá aktivní fronta? Že se při vložení funktoru probudí vlákno které funktor vyzvedne a provede? To by se asi dalo udělat i v bytecode (možná ne tak efektivně, nevím jak jsou na tom synchronizační primitiva u ARM JVM).
-
pošlu do fronty funktor, který umí zdroj uklidit.
Rozdíl je v tom, že ReferenceQueue je pasivní a je nutné ji pollovat, zatímco to moje je aktivní a uvolňuje zdroje ve chvíli, kdy GC uklidí ten ukazatel. Ten rozdíl se může zdát nepatrný, ale na telefonech to u dlouhoběžící aplikace dělá docela velký rozdíl ve spotřebě baterie.
To jsem trochu zmatený... Pokud se ten funktor provede okamžitě, tak to tam není fronta, ne? Já si pod pojmem "fronta" představím datovou strukturu (FIFO, v tomto konkrétním případě). Jak vypadá aktivní fronta? Že se při vložení funktoru probudí vlákno které funktor vyzvedne a provede? To by se asi dalo udělat i v bytecode (možná ne tak efektivně, nevím jak jsou na tom synchronizační primitiva u ARM JVM).
Jde o frontu smyčky zpráv (v Androidu Handler, ve Swingu SwingUtilities.doLater), takže ano, pokud to vlákno neběží, tak jej to probudí, a pokud ve frontě nic není, tak se vlákno uspí.