Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Java je tazkopadna, plna balastu a dnes uz koncepcne prezita. Jedine preco stale preziva je ze je na nej postavnene obrovske mnozstvo systemov a ma velky ekosystem ale kazdy kto by mohol by sa jej naradsej zbavil. Staci sa pozriet aky zlepenec z toho vznikol na Androide (aj ked to nieje len vdaka Jave). Myslim ze Oracle je dost optimisticke ked dufaju ze otvorenie im prilaka vyvojarov.
V dnešní době stále není za javu náhrada, takže nadávat můžeš jak chceš, ale dokud tu nebude nic lepšího, tak jí nemůžeš posílat do propadliště dějin.
Jinak na Jave běží většina enterprise a ještě dlouho poběží. Díky Google k tomu přibyl Android a celý ekosystém okolo, čímž dostal javu k "obyčejným" vývojářům a rozšířil tak pole její působnosti o další míle.
Jediné, co může v dnešní době Javu reálně ohrozit, je MS s jeho C#, tedy pokud by ho 100% otevřel, což se asi nikdy nestane.
Zdar Max
.NET Core je plně open source.
Jenze core je naprosto nedostatecny na nejaky realny pouziti.
A jestlipak víte, co je součástí .NET Core, když ho zmiňujete?
Skoro nic ;-).
Zdar Max
Kdyby jste alespoň o tom něco věděl, než něco napíšete,... nebudete pak za hlupáka..
https://github.com/dotnet/core/blob/master/Documentation/core-repos.md
.NET je dnes otevřenější než Java.
Java je otevrena cela. V .NET je otevreny jen core... ktery je jen mala cast z kompletniho .NET.
Nebo si to muzeme porovnat aby to pochopil i totalni neznalek. Muzu v otevreny jave napsat aplikaci s gui ? Ano muzu. Muzu v otevrenem .NET napsat aplikaci s gui ? Ne nemuzu.
že jsem tak smělý, nebavíme se celou dobu o EEčku? Samozřejmě mi můžete vyhodit 1000 různých definicí, kde je třeba i Java SE součástí Java EE (a dokonce je pár hacky možné pustit SE na stejném VM jako EE), ale primárně a troufám si tvrdit, že v 99% případů je pod označením "Java EE" vnímáno webové prostředí.
Jinak.. Pod .NET Foundation patří i Xamarin.
https://open.xamarin.com/
který sice není pro desktopy, ale je pro mobilní aplikace a zrovna Javu na mobilech v multiplatformosti drtí.
Ale jinak.. Nemyslím si, že WPF či WinForms někdy budou OpenSource, protože jsou na tvrdku napojené na WinApi,.. Možná jednou UWP (ale to je z velké části WPF).
Net Core nemá žádný multiplatformní UI a chybí slušné bindingy na současné grafické toolkity (i když něco málo to má, žádná sláva). to jen v případě, pokud se bavíme o nějakém desktopu.
Je to jen přepsaná část ASP.NET MVC frameworku. Tzn. web a konzole (tzn. něco jako alternativa k Java EE). Je to nativní, žádný runtime nepotřebuje.
Pokud to zamýšlíte jako nějakou web apps, tak bez podvozku (spustit samotnou app jako službu v systému a před to hodit apache jako proxy, nebo nginx), tj. žádný aplikační server.
Tzn., že zatím nic oslňujícího, spíše něco, co je v počátku nějakého vývoje.
Dále Java SE je GPL2, pokud uvolní v podobném duchu i EE, což asi budou muset, pokud chtějí nějakou pomoc, tak nevím, v čem by mělo být .Net core otevřenější.
Zdar Max
.NET není nativní, má pod sebou normálně .NET runtime.. jen není hostnutý v žádném IISku (třeba myslíte to samé). Kestrel je plně boje schopný server, který má největší propustnost ze všech,. nebo máte pocit, že třeba node server (který je stejně lightweight) je nepoužívaný? Současná doba směruje k malým Owin-like řešením a middlewarum.. ale to si svět JavaEE rozmluvit nedá a dál bude pouštet gigový server v paměti...
Pustí se miniaturní kestrel, na který se přibalí co je potřeba a před to se hodí IIS / Nginx.
Tak ono není moc překvapivý, že to má pěkný výkon, když ten web server nic neumí (a to bohužel doslova). Nevím, jak přesně funguje Kestrel, ale třeba projekt lwan vyřešil výkon tak, že si naimplementovali vlastní TCP/IP stack do userspace, viz pojednání kolem toho :
https://jvns.ca/blog/2016/06/30/why-do-we-use-the-linux-kernels-tcp-stack/
Co jsem tak koukal, tak Kestrel ani neumí sharovat port, takže co app, to vlastní port. To není úplně ideální řešení. Zatím je to ve stavu tech preview. Určitě to má budoucnost, začali na čisté louce a jsem za to rád. V jobu vyvíjíme/přepisujeme vlastní IS v C# nad IIS, takže kdo ví.
Ale jako alternativu / náhradu současných řešení to ještě rozhodně není.
Zdar Max
Mám pocit, že jste ale absolutně nepochopil í pointu kestrelu... To není žádný velký webhost a ani nikdy nebude.. Je to jen primitivní pipelining pro. Net kde to začíná nějakým bindingem .. Pravděpodobně Vždy a všude před tím bude vystaveny poradny webserver, který má všechno to o čem mluvíte.. Říkat tedy o Kestrelu že nemá ani port sharing značí, že jste nepochopil co kestrel je... Nehledě na to, že je hloupost mít obrovský web server, když to chcete třeba do dockeru a mít to jako webmicroservisu.. Se kterou externí client vůbec nekomunikuje.
Pokud tu mluvíte o náhradě Java EE a aplikačních serverů, na kterých běží, tak jsem opravdu fci Kestrelu nepochopil.
Zdar Max
Omyl, nahrady su. Vzdy existuju nejake alternativy len je to o tom ci sa chce do nich ist. Je fakt ze Java je mohutne zastupena a hlavne v enterprise sektore ale to neznamena ze je super. Nepoznam snad nikoho kto robi z javou, a teraz nemam na mysli nejku malu appku/kniznicu na lokalnom jvm, aby nenadaval na to ako je potrebna vzdy specifikca verzia javy a vm. Mnohe systemy bezia len na jednej verzii. Netvrdim ze je to chyba jazyka alebo samotnej Javy ale je to proste realita.
Je super ze existuje kvantum kodu a nastrojov, len zasa pri jave to potom dopada ako napriklad pri vyvoji v Androide. Clovek si vygeneruje prazny projekt z jenou aktivitou a hned to ma cez 1000 suborov !!!! Sa ani ntereba divit ze na to treba nejaky build system a gradle chrochta aj na ssdcku ako sialene.
Konfigurovanie aplikacnych serverov cez zahrabane xmlka a podobne. Java nema dodnes na desktope rozumne gui. Sice sa tu snazi kde kdo presviedcat ze je to pouzitelne ale zasa staci si otvorit IntelliJ Idea / android studio alebo eclipse a dalsie desktop aplikacie postavene na jave. Pokial sa uzivatel kroti tak to ako tak ide ale akonahle potrebuje pracovat s vecsim projektom alebo datami tak konec.
Ano java ma pozitiva ale netreba si zakryvat oci a tieto "muchy" su tu prakticky od zaciatku.
Nevýhody javy ale nikdo nerozporuje. Pokud jsou náhrady, tak co např.?
Požadavkem je, aby to bylo minimálně na srovnatelné úrovni.
Zdar Max
Proč si teda stěžujete na Javu, když zároveň píšete, že to vlastně není problém Javy? Na stejné problémy způsobené neschopností nebo nezkušeností vývojářů udržet zpětnou kompatibilitu narazíte u všech programovacích jazyků.
A se stížnostma na náročnost eclipse/idea na HW jste trochu zaspal, před pár lety bych s Vámi souhlasil, ale dneska? 4jádro, 16GB RAM a SSD najdete pomalu i v kancelářských PC.
Náš standardní kancelářský PC je :
HP ProDesk 400 G4 MT
- Intel Core i5–7500
- 256GB SSD
- 8GiB DDR4
A monitor Dell 24" U2412M (někdo má dva). Vývojáři mají většinou to samé, jen občas místo 8GiB ram mají 16GiB.
Zdar Max
HP ProDesk 400 G4 MT ...
Šílenej krám... teda z venku to vypadá hezky, pravda. Ale viděl jsi to někdy vevnitř ? Zkus si v tom třeba jen přesadit RAMku :))) o jakékoli náročnější manipulaci s čímkoli dalším ani nemluvě. Kvalitu použitých komponent (třeba MB) komentovat ani nebudu :))))
Zdar ExRepair Foxconn
Je to po dlouhé době case, který se mi u HP líbí, má styl i nápad :).
A manipulace je easy, má to odendavací panel s diskama, takže manipulace s ram je plně ok. Vejde se tam 2x 3,5" hdd + ta slim mechanika + ssd disk. Jen škoda, že to má jen 3x SATA a 2x SATA napájení :-/. Ale to jsem v jobu vyřešil napájecí sata rozdvojkou a DVD nepoužívám :).
O kvalitě PCB si myslím to samé, co ty.
Zdar Max
Ano, je to "paráda" :))
Příklad postupu při podezření na blbě "zacvaklou" RAM (pokud nemáš prstíky jako Mongolka) :
Když se sundá kryt (který se sundává hůř, než kryty předchozích HP modelů posledních let) tak je pod ním koš na disky a mechaniku. Ten koš se mimochodem u prvních várek v mnoha případech velice rád zasekával. Takže musíš nejdřív odpojit a vyndat mechaniku. Pak odpojíš kabely od disků (to je celkem jednoduchý - zpátky se to dává o fous hůř) a vyndáš ten koš. Následně můžeš manipulovat s RAMkou. V pohodě ? Tak to zase můžeš všechno zapojit.
User friendly vskutku...
U jednoho kusu ti to vadit asi nebude. U padesáti je to horší - věř mi :)))
A teď mě ještě tak napadá (ono je to už nějaká chvilka) jestli se nemuselo sundávat i čelo... To je mimochodem speciální v tom, že se snadno sundává a ...o něco hůř... nasazuje zpátky.
A ten designově zešikmený "kryt" mechaniky je vůbec případ sám pro sebe. Protože to tam nacvakávali blbě, tak se na pravé straně velice ráda ulamovala packa, která to drží. A s výměnou byl problém, protože zbytek pacičky zůstával v čele mechaniky. "Vyšťourávat" ty zbytky byla opravdu zábava, měnit mechaniku...(to se nelíbilo nahoře) a pak se přišlo na způsob, jak to udělat, aby to vypadalo že je to OK. Ale je riziko, že to přece jen někdo z Foxu čte, tak to dál popisovat nebudu. Prostě "NOU HAU" :))))))
pretoze napriklad na Androide sa bez Javy nezaobidem. Xamarin je docela zabugovany a robit vsetko nativne sa tiez neda (okrem toho aj pri nativnej aplikacii furt treba riesit javovsku vrstvu)
No asi som uz stary a zacinal som ked nativna aplikacia nebola sproste slovo a pod scriptom sa myslel bat/bash scriptik na nejake kopirovanie a podobne veci. Nie dnes ked sa kde kdo chvali desktop aplikaciou ktora je dolepena v nejakom scriptovacom jazyku co vola cez libky nejaky gui framework a tesime sa z hellou world. Sice to cele potrebuje 150+ MB kniznic a v pameti to zozere pol giga ale co, sak je taka doba ze ano. Ak na to aby som si otvoril textovy subor, co v zasade zdrojak je, v nejakom projekte, potrebujem povedzme 8jadrove PC s 16-32GB Ram, tak je asi nieco zle nie ?
Používám na noteboku Dell E6500 Core2Duo 4GB RAM a 128GB SSD naprosto bez problémů PHPStorm, InteliIdea a Android Studio. Nejvíc nenažrané jsou prohlížeče.
Co je na Javě zastaralého a koncepčně přežitého? Java se v podstatě skládá ze 2 části - virtuální stroj a runtime knihovny. Zajímalo by mi, co byste na této koncepci chtěl měnit. Všichni konkurenti Javy totiž fungují úplně stejně, ať už je to .NET, Android ..., liší se jenom v detailech, jako podporované platformy, obsah runtime knihoven, syntaxe psaní závorek ...
Programovani neni jen o pouzitem jazyku. Staci kouknout na aktualni windows... zadna java tam neni a presto se ten system seka a to i na nekolikanasobne vykonejsim hardware nez na jakym beha android plynule.
"Staci kouknout na aktualni windows... zadna java tam neni a presto se ten system seka a to i na nekolikanasobne vykonejsim hardware nez na jakym beha android plynule."
Pokus o cerny humor? Nebo nejaky sen, ve kterem behal Android plynule? :-D
To je uz spoustu let realita. Staci si vybrat pristroj od nejakyho rozumnyho vyrobce.
A k t e re h o v rob c e b y s m i d o por c i l ?? (S o r y, pi s u z A n d ro i d t el fo n u. )
> Java je tazkopadna, plna balastu a dnes uz koncepcne prezita.
To lze rici o spouste jazyku. Treba takove C, ktere i dnes nekteri brani do krve, ma dnes smysl akorat pro psani kernelu a v mikrokontrolerech. Presto v nem i dnes vznika tuna projektu...
> ale kazdy kto by mohol by sa jej naradsej zbavil.
.... a proto ma pulka novych dynamickych jazyku interpreter / compiler napsan v Jave :) realita je takova, ze neexistuje zadny vykonnejsi a odladenejsi bytecode interpreter nez JVM, a jeste chvili existovat nebude. Klidne se muzete postavit na hlavu, tancovat a davat mi minusky, nic se na tom nezmeni :)
> Myslim ze Oracle je dost optimisticke ked dufaju ze otvorenie im prilaka vyvojarov.
Ano. S Oracle je hlavne problem jakym zpusobem to otevrou, staci se podivat na MySQL a OpenOffice. Byli "otevreni" tak, ze vsichni si radeji udelali fork. Ono totiz kupodivu nestaci hodit kod pres plot a vyhlasit hura ted jsme otevreni...
Jiste... existuje halda lepicu kodu co si mysli jak je java uzasna. Mozna jsou opravdu silenci co v jave napisou dokonce interpreter ci compiler. Jenze kdyz se vratime zpatky na zacatek, tak ta samotna java od oraclu je napsana v C++. Proc ? No protoze vykon javy je proste tragedie a kdyby zitra chcipla tak si velky mnozstvi lidi v it oddechne.
Tak ono jaksi interpretovany jazyk nemuze byt napsany sam v sobe. U kompilovaneho to neni problem, ale JVM proste musi byt napsane v necem co nevyzaduje pro beh JVM.
Ale to snad ne. Každý jazyk (a neexistují interpretované a kompilované jazyky, pouze jejich interpretující a kompilující implementace) může být napsaný sám v sobě, to je snad jasné už z principu (jakýkoli jazyk může sloužit jako substrát pro libovolný jiný jazyk, ale z téhož důvodu i jako substrát sám pro sebe), pouze je třeba přijít na to, jak ho bootstrapnout. Třeba interpretovaný Squeak byl taky napsaný sám v sobě (a bootstrapnut byl na starším Smalltaku-80 s jádrem v assembleru MC68k na MacIntoshi) a JITovaný Squeak/Pharo pokud vím pořád ještě je.
Moved to recycle bin.
Javu doma v pocitaci nemam, javovske programy nevedu. Uplne mi staci lagdroid, jeste abych si rval deravou Javu do PC. V praci at si to maji, tam je mi to jedno, jsem nastesti placen hodinove nikoliv ukolove, takze si klidne dam kafe nez mi javovsky zkripleny program prekouse data.
Za co minusy? Ja preci nemuzu za to, ze je Java z principu pomala. Ano, umoznuje psat aplikace multiplatformne, staci mit pro platformu napsan javovsky virtual stroj a jiz vam na tom bezi javovska aplikace, pomalu ale bezi. Jenze to proste zdrzuje.
Treba proto, ze clanek pojednava o Java EE coz neni tak uplne Vami uvedeny pripad "Javu doma v pocitaci nemam, javovske programy nevedu. Uplne mi staci lagdroid, jeste abych si rval deravou Javu do PC."
To proto, že píšete nesmysly. S vyjímkou triviálních prográmků typu "Hello world" není mezi javou a C++ moc velký rozdíl co se rychlosti týká. JVM kompiluje za běhu kód aplikace do nativního kódu. Diky tomu, že má k dispozici informace o tom, jak je kód skutečně používán, může vygenerovat lepší a tedy i rychlejší kód než klasicky AOT cečkový překladač.
A teď prosím tu o karkulce..
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2...
http://benchmarksgame.alioth.debian.org/u64q/java.html
Jasný,.. JVM a jakákoliv VM může detekovat jaký HW má k dispozici a podle toho upravit výsledné instrukce pro využití efektivní instrukční sady atp..
Ale už z důvodů spoustu omylů v Javě právě "běžný" program napsaný v Javě se nikdy nemůže Céčku (a ani třeba .NET Core) ani přiblížit.. Běžně najdeme právě v tomto SW kolekce z STD::LIB a Java je s výkonem v koncích kvůli boxingu..
Tak prosím si nechte tyto pohádky.
+1
A ano.. to co skutečně způsobuje to, že je něco rychlejší / pomalejší, není ani tak práce CPU, ale práce s pamětí...
Zde GC (u rozumného jazyka) udělá velkou část práce programátora za něj, protože si po GC "naturálně" přenese věci co se používají do paměti k sobě - nedochází tedy k takovému shardingu...
Takže zatímco první běh bude pomalý, tak po GC se to zrychlí... Zkuste si někdy třeba na-alokovat pole objektů po jednom a po každém 1 naalokování si naalokujte něco "bokem", tak aby došlo k tomu shardingu..
Dobrý C/C++ programátor, si ale alokuje paměť tak, aby byly věci co se používají v jeden moment, co nejvíce u sebe a nedocházelo k takovému cache miss. Dokonce to má i název - data-oriented programming, kde se vykašlou na OOP pravidla a dogmata a napíšou to skutečně efektivně..
Dobrý C/C++ programátor pracujici na velkem projektu si predevsim implementuje SLAB alokator.
"Dokonce to má i název - data-oriented programming, kde se vykašlou na OOP pravidla a dogmata a napíšou to skutečně efektivně.."
Přijde bizarní, jak vždycky někdo přijde s nějakým tím "Something-Oriented Programming"em. A přitom je to vždycky taková blbost...
Navíc nějaká "OOP pravidla a dogmata" jsou v C++ stejně naprd, protože C++ je jako objektový jazyk na baterky, kdežto jako generický jazyk na tom není zase až tak špatně.
Vámí odkazované srovnání rychlostí C/C++/Java atd. je sice zajímavé, ale ne moc relevantní. Hlavně proto, že je používán starý šrot Q6600. Ve své době to byl výborný procesor, ale přeci jenom, za 10 let od jeho vydání přibylo v x86 CPU spousta optimalizací, mimo jiné rychlejší volání volání virtuálních metod. C toho nevyužije, všechny objektové programovací jazyky ano. Např. C++ je v naměřených výsledcích často o dost pomalejší než C.
Java vs .NET core je víceméně plichta, půlku testů vyhrává Java, druhou .NET. Jak v Javě tak i v .NETu je tedy stále co zlepšovat.
Taky nechápu vaší poznámku o boxingu. Autoboxing je jenom jeden z mnoha nástroju, které java nabízí. Programátor by měl vědět, kdy a jak je vhodné je použít. Pokud je List<Integer> pomalý, můžete místo něj dát IntArrayList. Jestli výše uvedené testy penalizují Javu používáním objektových typů místo primitivních, znamená to pouze to, že jsou ty testy napsány blbě.
Odkazované výsledky jsou zcela k ničemu, protože jsou měřené metodicky úplně blbě. Ono totiž není vůbec jednoduché napsat v Javě mikrobenchmark tak dával korektní výsledky. Můsíte se vypořádat se 2mi problémy - nejprve musíte nechat kód několikrát proběhnout, tak aby JVM mohl nasbírat statistiky potřebné pro optimalizaci kódu. Druhý problém - pokud např. výsledek výpočtu uložíte pouze do lokální pro proměnné, JVM zjistí, že může beze změny na chování programu celý výpočet přeskočit a pak také budete měřit nesmysly. V odkazovaném webíku nejsou žádné zmínky o těchto problémech, z toho tedy usuzují, že o těchto problémech autor nic netuší a prostě něco měři a doufá, že to bude správně.
Zajímavy je akorát regex-redux Java vs C++. Vítězství Javy v tomto testu by mohlo být díky tomu, že JVM umí provést tzv. devirtualizaci volání, pokud zjistí že může bezpečně nahradit volání virtuální funkce statickým voláním.
Je to vtipne, jak se NAPROSTO U KAZDEHO clanku o Jave vyroji C#pisti a pravoverni Ceckari a zacnou vsem vysvetlovat, jak je Java na picu...
A okoreni to mistni pepek vyskoc historkou, jak se mu v praci pomalu spousti java programy + nezbytny mem "lagroid" :-D
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.