Oracle nabídne placené JVM

Oracle se rozhodl rozdělit Java Virtual Machine. Horší varianta bude open source a bezplatná a ta lepší bude za peníze. Budoucí verze OpenJDK budou postavené nad výsledkem sloučení Sun JVM a JRockit VM. Zatím není známé, jaké funkce budou navíc v placené variantě.

8.11.2010 08:50 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[yedpodtrzitko]

nudou -> budou

[Algi]

třeba je to tak správně. třeba budou nové funkce placené javy nudou

[mess]

Osobně si myslím, že ty placené überfunkce šikovní vývojáři dodají i do OpenJDK a Oracle ostrouhá

[.]

Já bych byl mnohem více skeptický. Ve vývoji JDK je spousta peněz a bez Sunu (dnes teda bez Oraclu) se nějak moc muziky nekoná. Příkladem nechť je stav OpenJDK na alternativních platformách.

[aubi]

Odkud ji zase promtnne odstrani; hned pote, co dostanou dopis od patentoveho pravnika. Je mi smutno

[píča]

No tak o tom pochybuju. Nerad bych se pletl, ale OpenJDK má ještě nějaké problémy i se Swingem (oproti výrobku Sunu / Oraclu)...

Nicméně to vidím tak, že drtivé většiny lidí se to nijak nedotkne, takže nevím, co tady diskutující tak jančí. Vždyť JRockit byl snad placený vždy - a nikdo si tu na to nestěžoval.

[xm]

Nikdy jsem s OpenJDK žádné problémy neměl. Jasně, úplně ze začátku v něm některé věci chyběly, ale to už je dlouho minulostí.

[Jardík]

Nevím, ještě před měsícem mi v OpenJDK "nefungoval" FreeRapid downloader. Tím "nefungoval" myslím, že to každou chvíli házelo samý výjimky.

[píča]

Ale zase jste si mohl dosyta užít té svobody, ne? :)

[Jardík]

To určitě, OpenJDK šlo dopryč a nahradilo ho JRE/JDK od Sunu.

[píča]

Já to udělal stejně. Nemám nic proti OpenJDK, ale dokud mi nebude fungovat, má smůlu.

[Ferš]

Dobrý den,

musím říct, že poslední verze OpenJDK už jsou poměrně hodně dobré. Např. FlexiBee mělo dříve problémy se swingem v OpenJDK (nefungovalo to). Nicméně poslední verze OpenJDK v Ubuntu 10.10 už funguje naprosto bez problémů.

A tak se už nebojíme ho uživatelům na této distribuci doporučovat.

S pozdravem

Petr Ferschmann

[píča]

Dobrý den, díky za informaci. Podívám se, jestli je verze OpenJDK z Ubuntu 10.10 i ve Fedoře (předpokládám, že jistě bude).

[xkucf03]

Ještě lepší je OpenJDK 7 – hlavní je se toho nebát

[Pavel Stárek]

Přestaňte prosím šířit tyto bludy o OpenJDK. Citace z wikipedie:

n June 2008, Red Hat announced that the packaged binaries for OpenJDK on Fedora 9, built using IcedTea 6, had passed the Technology Compatibility Kit tests and could claim to be a fully compatible Java 6 implementation.[50] In July 2009, an IcedTea 6 binary build for Ubuntu 9.04 passed all of the compatibility tests in the Java SE 6 JCK.[51]

[píča]

Nikdo neříká, že to de jure není kompatibilní. Já jen mluvím o tom, co jsem sám zažil - OpenJDK se někdy chová jinak něž Sun / Oracle Java.

[Filip Jirsák]

Vždyť jsou to taky dva různé produkty. Kdyby se měly chovat zcela stejně, musely by mít identický kód a být identickým způsobem sestavené. Jenže k čemu by to pak bylo mít to samé pod dvěma jmény? Implementací překladače C++ nebo standardní knihovny je také spousta, některé placené – a nezdá se, že by to byla nějaká katastrofa a celý vývoj v C++ by měl za pár měsíců skončit.

[píča]

Tak pak nechápu tohle

and could claim to be a fully compatible Java 6 implementation

:)

[Filip Jirsák]

Specifikace nepopisuje 100 % chování. Takže můžete mít dva produkty, oba splňují specifikaci, a každý se chová jinak. Už jenom to, že je možné přidávat další věci do standardní knihovny způsobí rozdíly – a aplikace, která závisí na nějakém doplňku od Oracle a nepočítá s tím, že na některé JVM nemusí být dostupný, pak na jiné implementaci nebude fungovat. Což ale není chyba OpenJDK…

[Pavel Stárek]

Děkuju Ti náčelníku, že ses mě zastal

[pit0]

Takze uz mi je jasne preco nedavno Jobs zahlasil, ze uz Apple nebude aktualizovat Javu pre Mac, ale necha to na Oracle...

[kolcon]

jak psali na ./ , oracle se evidentne rozhodl zlikvidovat po solarisu a Openoffice i javu... ne ze by byla javy velka skoda

[píča]

Jak říkala stará Vomáčková, letos bude tuhá zima.

Váš názor je zajímavý, ale bohužel pro vás v negativním slova smyslu. Mohl byste nás prosím obohatit nějakými důkazy o tom, jak Oracle likviduje Solaris a Javu? Co se týká Solarisu, Oracle dokonce (i v ČR) nabírá lidi, co na něm budou dělat. A kecy o Javě jsou už totálně mimo - vždyť ji sám Oracle implementuje a navíc na ní staví své produkty. OpenOffice.org - to je diskutabilní, ale ani ty podle mě nelikvidují. Proč taky?

[kolcon]

racej si to vygooglit, co se stalo opensolarisu, voni pico

[píča]

Zaprvé jste mluvil o Solarisu, ne OpenSolarisu.

A zadruhé OpenSolaris byl propadák už za dob Sunu, takže nechápu, čemu se divíte.

[kolcon]

jasne, openoffice je vlastne taky propadak, zejo

ja se ted rozmyslet, v cem delat projekt a mit pred sebou vizi, ze Oracle javu nejak zkripli (cti napr. v placene verzi si udela vlastni "standardy"), nebo ze tam nekomu hrabne a zacne uplatnovat patentove pozadavky proti free verzi,

tak si to sakra rozmyslim.

Ale treba je cilem Oraclu posilit M$ s jeho .Netem

[píča]

jasne, openoffice je vlastne taky propadak, zejo

To bych upřímně řečeno rád věděl. Zajímalo by mě, jak a kolik na tom kdo vydělává. Třeba to propadák skutečně je.

ja se ted rozmyslet, v cem delat projekt a mit pred sebou vizi, ze Oracle javu nejak zkripli (cti napr. v placene verzi si udela vlastni "standardy"), nebo ze tam nekomu hrabne a zacne uplatnovat patentove pozadavky proti free verzi,

To je príma vtipná vize, a kdyby to byl film, jistě by to byl trhák. Do depresivního podzimu jako dělaný.

tak si to sakra rozmyslim.

Jestli jste uvažoval o Javě, tak by mě zajímalo, k čemu byste přešel. Nejbližší (a možná i jediné blízké) řešení je .NET, které je ve všem "horší" než vaše katastrofická vize výše. Jasně, pokud je tím "projektem" systém pro váš blog, tak se můžete rozhodovat od Javy po BASH, ale pokud je ten projekt trochu větší a významnější, těžko někam utečete.

[xkucf03]

S Oraclem to jde vůbec do háje – po zpoplatnění aktualizací Solarisu nedávno zpoplatnil i aktualizace firmwaru, což je věc celkem nevídaná (firmware si chce stáhnout zákazník, který již zaplatil dost vysoké částky za hardware, teď musí platit ještě za podporu, aby měl firmware, který opravuje chyby). Na závěr přidám kousek e-mailu od kolegy, který se o tyhle servery stará:

Všichni výrobci dávají upgrade BIOSu (OPB), servisních procesorů a firmware řadičů zdarma, protože ví, že to nelze použít u jiných serverů a tedy vystavené soubory slouží pouze jejich klientům. Jenom Oracle chce za všechno prachy. Jsem naštvaný a příště se budu spíš dívat po serverech od konkurence.

Ostatním bych doporučil totéž. Oracle už prostě není Sun, jakákoli nostalgie nebo shovívavost není na místě. Software lze používat svobodný (LibreOffice, OpenJDK, OpenIndiana) a na poli hardwaru je celkem dobrá konkurence.

[píča]

Neznám.

Jen by mě zajímalo, proč (teď) utíkat třeba od Oracle Javy k OpenJDK. Vy děláte, jako kdyby to Oracle přestal vyvíjet. Přitom podle mě tomu (minimálně) z technologického hlediska pomohl.

[xkucf03]

Když OpenJDK začínalo, tak byly pořád nějaké problémy – řešením většinou byl přechod na Sunovské JDK/JRE. Dneska už je to výrazně lepší a na OpenJDK mi chodí vše, co potřebuji – otázka tedy spíš je, proč používat Oraclí JDK, když je tu funkční svobodné JDK.

[píča]

Vždyť Sun / Oracle Java je z obrovské části taky svobodná! Aby taky ne, když ty kódy jsou stejné jako u OpenJDK...

[rastos]

Prosím ťa: zmeň si nick.

[Jardík]

Třeba na vagína

[píča]

Netykejte mi, nikdy jsem vám to nenabídl. A nick si změňte sám, jestli máte rád změny nicků.

[dustin]

Píča netykavka :)

[rastos]

Netykejte mi, nikdy jsem vám to nenabídl.

Ospravedlňujem sa. Prepáčte. Prosím, používajte iný nick.

A nick si změňte sám, jestli máte rád změny nicků.

Nemám rád zmeny nickov. Ale občas chcem nejakú tunajšiu stránku odporučiť šéfovi alebo niekomu inému ... skrátka by som chcel, aby si tu ľudia všímali argumenty a nezatracovali server pre nejaký nick.

[píča]

Ospravedlňujem sa. Prepáčte.

Netřeba se omlouvat.

Ale občas chcem nejakú tunajšiu stránku odporučiť šéfovi alebo niekomu inému ... skrátka by som chcel, aby si tu ľudia všímali argumenty a nezatracovali server pre nejaký nick.

Pokud někdo půjde jen po argumentech, pak mu jistě nebudou vadit neobvyklé přezdívky.

[rastos]

Pokud někdo půjde jen po argumentech, pak mu jistě nebudou vadit neobvyklé přezdívky.

To je práve to, čo sa Vám snažím vysvetliť. Bude. Na diplomovku alebo obchodnú ponuku si tiež nedáte na titulnú stránku hard-core porno obrázky. Teda pokiaľ ten diplom/obchod chcete dostať.

[Milan Jurik]

A zadruhé OpenSolaris byl propadák už za dob Sunu, takže nechápu, čemu se divíte.

V cem byl volny pristup k vyvojove vetvi Solarisu propadakem?

[píča]

Obchodně to byl propadák. Na volném přístupu nesejde.

[kolcon]

a co jako, obchodni vysledek produktu oraclu je mi uplne u ..., co me zajima, je ten volny pristup a to, ze az si oracle/m$/... usmysli, nebudu platit jak mourovatej kvuli vendor lock-inu a jeho proprietarnim dodelavkam

[píča]

No jasně, vám se OpenSolaris líbí, tak ať ho někdo vyrábí, i kdyby na tom měl prodělávat... Já mám zas rád tvarohový koláče, ale musejí stát do tří korun - pčřece těm vydřiduchům nebudu platit kolik si řeknou...

[kolcon]

Oracle si muze delat se svymi produkty co chce - pokud je ale uzavre/zdrazi/zastavi vyvoj/... , nemuze zaroven ocekavat jasot komunity

[píča]

Myslím, že zrovna váš nebo můj jásot není to, na čem by Oracle stál a padal.

[kolcon]

... nebo jasot nekterych zakazniku...

[pavlix]

Myslím, že Oracle není něco na čem bysme zase stáli a padali my, nebo ano?

[Milan Jurik]

Drobna technicka, OpenSolaris biweekly builds nebylo nic jineho nez development vetev Solarisu, takze je Oracle stale vyrabi, testuje a uziva(ji je zamestnanci), jen nejsou poskytovany verejne. To jen k tem nakladum na vyrobu.

[Milan Jurik]

Obchodně to byl propadák.

A to vite odkud?

Na volném přístupu nesejde.

A take tohle vite odkud?

[píča]

A to vite odkud?

OpenSolaris prostě nenaplnil zveřejněná očekávání.

A take tohle vite odkud?

Děláte ze sebe schválně blbce, nebo fakt nechápete, že "volnost" je pro danou diskuzi irelevantní?

[Milan Jurik]

A to vite odkud?

OpenSolaris prostě nenaplnil zveřejněná očekávání.

Ktera ocekavani?

A take tohle vite odkud?

Děláte ze sebe schválně blbce, nebo fakt nechápete, že "volnost" je pro danou diskuzi irelevantní?

Nevim, kdo tu dela ze sebe blbce, ale asi nic netusite o marketingu/prodeji/strategii. A o OpenSolarisu (at uz projektu ci distribuci) toho vim asi radove vice nez vy.

[Pavel Stárek]

...vždyť ji sám Oracle implementuje a navíc na ní staví své produkty. ...

Což ovšem neznamená, že pokud si do Javy něco doprogramují, že to dají komunitě zpět (a zdarma, dejme tomu). Dalším krokem, může být i tříštění různých JVM (tak jako kdysi Microsoft měl "svoji" JVM), z kteréhož vyplyne to, že (zejména) komerční produkty budou zároveň vyžadovat tu placenou verzi Javy (JVM).

[píča]

doprogramují, že to dají komunitě zpět

Pokud něco někdo naprogramuje, těžko to může dát zpět někomu jinému.

[Pavel Stárek]

No chtěl jsem napsat něco jiného, ale zůstanu u:

To nemá cenu, já jdu domů

[Algi]

To je právě ono. Vlastníkem Javy totiž není komunita, je to Oracle... Ale to tu jaksi někdo nechápe Čímž se teda nechci zastávat Oraclu, protože (pravděpodobně) kvůli němu skončil Apple se svojí podporou Javy, což mě teda velmi a hluboce zklamalo...

[Pavel Stárek]

No dobře, myslel jsem to tak, že se Oracle bude chovat jako Canonical, který si z komunity bere, a (téměř) nic nevrací. To samé může nastat okolo Javy. Ti blbci (nemyšleno zle) z komunity budou odstraňovat chyby a přidávat nějaké věci (i pouhé optimalizace a čištění kódu třeba) do OpenJDK a Oracle si je vesele vezme do svého produktu. Ovšem své vylepšeniny (v placeném produktu), které by mohl rovněž vřadit do OpenJDK (pokud nebudou třeba patentově zatíženy, nebo prostě ze slušnosti) tam nevrátí. Jistě, je to firma, která Javu "vlastní" a potřebuje vydělávat tak nemusí projektu OpenJDK vracet nic, ale každopádně je (bude) to jakési neslušné.

Ideální stav by byl, kdyby Red Hat, Novell, Apache, IBM a třeba Debianí a Fedoří komunita založili jakousi foundation. Ta by vzala snapshot současné verze OpenJDK a udělali fork a ten spravovali. Ovšem nevím, jak je to s licencemi, patenty, ochrannými známkami (smí se vůbec používat slovo Java? - asi ne, když si Google svoji VM pro Android nazval Dalvik).

[Algi]

Ty licence by na tom byly asi problém, také tomu moc nerozumím. Ale v čem bych viděl větší problém je samotná idea. Těžko říct, jestli by se takhle někdo Javy ujal, protože Oracle (IMHO) by to chtěl sabotovat. Nicméně, pokud by to bylo právně ošetřené, pak by zbývalo dořešit jediný problém: zisk... Poté by už plně opensource implementaci vyvýjené silnými a schopnými společnostmi nic nebránilo.

[Pavel Stárek]

Se ziskem by třeba problém nebyl. Red Hat vlastní a vyvíjí aplikační server JBoss a k němu prodává podporu (ono je toho více). To samé má asi i IBM. A to nejsou malé firmy, takže nějaký ten dolar by mohly pustit

[Algi]

To je ale fakt! Vždyť už jenom kvůli tomu by se měli o ten vývoj zajímat

[pan jachta]

Bude zajimave jak se k tomu postavi komunita - vyvojari libek. Bez Apache, SpringSource, Codehausu a dalsich projektu by Java byla v prdeli jak Bata s drevakama. Timto "chytrym" cinem se rozhodli je hodit pres palubu. Bude nejaka reakce nebo to zkousnou a karavana jede dal?

Je to kratkozrake, ale company takhle funguji. Koupili si to a ted to se vsi paradou zabijou ... ja tleskat nebudu ;(

mala rekapitulace:

• solaris - kaput
• mysql - skoro kaput
• netbeans - kaput
• java - ?

Ehm, to kupovali Sun jen kvuli hardware?

[vencour]

Monopol ničí konkurenci přece.

[Christof]

proč je netbeans kaput a mysql skoro kaput? nějak jsem si nevšiml

[pan jachta]

netbeans je kaput z toho duvodu, ze v sunu/oraclu z puvodnich nb vyvojaru zbyla slaba tretina, ktera se venuje sustainingu a dalsim projektum, nic novyho se nevymejsli a opravuji bugy.

mysql - z marketingoveho hlediska to zazdili (proto pisu skoro)

[píča]

nic novyho se nevymejsli a opravuji bugy.

Jsem rád, že to Oracle vzal za správný konec. ;)

[pan jachta]

;) vytrzeno z kontextu to zni dobre, bohuzel realita neni tak ruzova

[gtz]

uvidíme co bude dále

[Pavel Francírek]

viděl jste nový ceník MySQL?

[píča]

Já ano, o co se jedná?

[Espinosa]

Proc by se k tomu nejak zvlast staveli? OpenOffice.org ma odjakziva placenou a free verzi a nikomu to moc zvlast nevadilo.

[Miki]

Placený OO? Viděl to někdy někdo?

[dustin]

Staroffice. Odjakživa :)

[Filip Jirsák]

Jak by se k tomu stavěli? To placené budou s největší pravděpodobností jen nějaké enterprise věci, takže se to běžných vývojářů nijak nedotkne.

Jinak jmenovat zrovna SpringSource, to se vám povedlo. Vždyť ti mají tohle dělení na placenou a volnou verzi už dávno.

[pan jachta]

Muzete mi prosim ukazat kolik a kde mam zaplatit za pouzivani Spring frameworku? Doted sem zil v blahove nevedomosti, ze je pod Apache licenci a SpringSource vydelaval penize na svych skolenich, nyni po odkoupeni VMware na skolenich a "VMware + Spring aplikacich pro cloudy/tc" resenich.

Clovek se muze mylit, ale vy nejspis mate ve vsem jasno, vsude ste byl a nejspis i mate od vseho klice, ze? Muzeme mi prosim vysvetlit (odkaz staci) jak je to s placenou a volnou verzi Spring frameworku?

Doufam, ze Vam tento lehce utocny ton nevadi, snazim se udrzet latku kterou ste nasadil ...

[Filip Jirsák]

SpringSource Enterprise Maintenance Policy FAQ. OpenJDK je pod GPL licencí. Model Spring frameworku a Oracle JVM tedy asi bude velmi podobný – základní verze, která stačí skoro každému, je zdarma, ale za poplatek je možné získat něco navíc, co je vhodné zejména pro entreprise sféru a pro ty, kteří sami díky Springu/Javě vydělávají.

Útočným tónem jste začal vy s tvrzením o „hození přes palubu“, které zřejmě vychází z nějakých informací (které jste neuvedl), které jsou v rozporu s původní zprávičkou.

[pan jachta]

To co jste poslal je pouze FAQ ktere popisuje, ze SpringSource nema kapacity/cas na maintanance starsich verzi a za urcity peniz nabizi ze to pro zakaznika udela. Tak jaky podobny model???

Prozradim Vam tajemstvi: Spring framework je jenom jeden - free, zadna free verze a placena verze s featurama navic. To o cem mluvite Vy jsou aplikace postavene nad frameworkem.

Patrne ste to nechopil, zkusim byt vic presnejsi specialne pro Vas: Ano, povazuji Spring framework (od SpringSource) za kvalitni produkt, ktery podstatne prispel k vyvedeni Javy EE ze slepe ulicky kde se nechazela. Programovani uz neni takova hruza jako driv a stale to prizivuje Javu jako platformu pro zajimave projekty. Tim, ze Oracle rika "Diky, ze ste nam zachranili Javu, my ji zpoplatnime a vy si vystacte s OpenJDK!" mi prijde jako hozeni pres palubu spolecnosti/jednotlivce co investovali usili/cas do Javy - je to svinarna.

Tajemstvi cislo 2: OpenJDK neni zas takova slava jak si nejspis myslite a stale jsou aplikace ktere maji s OpenJDK problem. Moc si malujete slouceni s JRockit VM. Damy prominou, ale "domrdane" a neodladene VMko pro Javu vazne neni sen zadne spolecnosti co ma byznys postavenej na Jave. Na stable Jave, ktera doted byla zdarma.

S tim co je Java EE ste urcite nalezl odpoved v jinych reakcich.

Jak vidite dalsi kroky Oraclu? Bude Java 7 podporovana jen Oracle VM?

[Filip Jirsák]

To, co jsem popsal, je model: tady máte aplikaci zadarmo, která stačí každému. Pokud vám na tom ale běží něco jo důležitého, zaplaťte nám, a my vám dáme pro tu vaši důležitou aplikaci ještě trochu něco navíc.

Pořád nevím, kde berete informace, že zadarmo bude jenom jakási nedodělaná JVM, zatímco současná JVM bude jen za peníze. Všichni ostatní to chápou opačně – současná JVM bude zdarma, ale vedle toho bude ještě nějaká „vylepšená“, ale za peníze.

To, že některé aplikace neběhají pod OpenJDK, je v drtivé většině případů problém těch aplikací, nikoli OpenJDK.

Ta „stable Java“ od Sunu také není žádná sláva, vždycky když se musím probírat zdrojáky tak mě fascinuje, jak to navenek vlastně docela dobře funguje.

Co je JavaEE nepotřebuju hledat v jiných reakcích. Jednak to vím, jednak se tady o ní nebavíme.

Zda bude Java 7 podporována jen Oracle VM? To jako myslíte, že by Oracle specifikaci Javy uzavřel? No vzhledem k tomu, co se do sedmičky chystá, by to nebyla žádná škoda… Ale jinak myslím, že specifikace zůstane veřejná a bude ji moci implementovat, kdo bude chtít.

[xkucf03]

jen nějaké enterprise věci

Ono dost záleží, co jsou to „nějaké enterprise věci“ – pokud by to byla část nebo dokonce celé JEE, tak by to byl celkem průšvih. JEE totiž není jen pro „enterprise“ zákazníky, ale používá se všude možně, navíc ani ti velcí zákazníci nechtějí zbytečně vyhazovat peníze. Otázka je, co bude s Glassfishem, jak se budou vyvíjet standardy kolem EE atd. Naštěstí tu jsou i nezávislé implementace (JBoss a pokud člověk nepotřebuje vyloženě aplikační server, je nabídka ještě širší). Asi největší riziko je, že půjde do háje standardizace – pak nebudeme programovat pro JEE, ale třeba pro JBoss… a časem se bude standardizovat někde mimo spáry Oraclu.

[Michal Vyskočil]

Asi největší riziko je, že půjde do háje standardizace – pak nebudeme programovat pro JEE, ale třeba pro JBoss… a časem se bude standardizovat někde mimo spáry Oraclu.

No v době docela nedávné neexistovala pořádná open source implemementace kdejakého JSR a taky se nic moc nedělo. A standardizace může jít do háje spíše v důsledku posledních událostí ohledně IBMa OpenJDK, pokud se obě korporace dohodnou, ostatní s tím mnoho nenadělají.

[píča]

Na jednu stranu čtu v diskusích nářky na "tříštění sil", na druhé straně čtu nářky na dohody o spolupráci...

[Michal Vyskočil]

na druhé straně čtu nářky na dohody o spolupráci...

Já na spolupráci nenaříkám, na druhou stranu JCP Committee bude těžko o něčem jiném, než o čisté politice. A pokud se dosavadní poměr sil Sun/Oracle proti IBM+ASF mění na Oracle+IBM, může to se světem Javy (a to i té open source) zahýbat daleko víc, než nějaké komerční doplňky pro JVM od Oracle.

[píča]

může to se světem Javy (a to i té open source) zahýbat daleko víc, než nějaké komerční doplňky pro JVM od Oracle.

To "zahýbání" ale nemusí být nutně negativní (pro Javu).

[píča]

Nerozumím vašim obavám. Vždyť už teď existuje mnoho placených implementací JEE. A ty používanější free jsou prakticky jen JBoss a Glassfish - a Glasfish byl a je jen osekanou verzí Sun Java AS. Tak nevím co trojčíte.

Nemyslím si, že by standardizace šla do háje.

pak nebudeme programovat pro JEE, ale třeba pro JBoss… a časem se bude standardizovat někde mimo spáry Oraclu.

Proberte se, tohle se dělá i teď. Některé servery prostě nabízejí technologie navíc (i třeba ten JBoss).

[Filip Jirsák]

Čekal bych, že to spíš bude třeba využití více jak 64 GB RAM, využití více jak 32 procesorů, update JVM za běhu, transparentní běh jedné java aplikace v JVM rozprostřené přes několik fyzických strojů nebo něco takového. Tedy věci, které se netýkají vývoje, ale nasazení.

[default]

pak nebudeme programovat pro JEE, ale třeba pro JBoss…

Tímto způsobem se v podstatě vyvíjelo už v dávných dobách za SUNu. Každý aplikáč má něco svýho navíc, a když to použiješ, tak se s tím aplikáčem svážeš. Platí to i o Glassfishi.

[xkucf03]

Jasně, jsou tu dodatečné funkce specifické pro daný VM, ale pořád tu je ten společný základ, kterého když se budeš držet, bude ti to fungovat všude. Od toho ta standardizace je. Pokud by se tohle rozpadlo, tak žádný společný základ nebude a „vyvíjet pro AS xyz“ bude jediná možnost.

[default]

Glassfish není VM.

[xkucf03]

njn, překlep – oprava: VM → AS. Ale k věci…

[leste]

To teda vydrží hooodně dlouho. V muzeu ve Zlíně je k vidění dřevák pro Wehrmacht - zateplený model pro východní frontu.

[Miki]

Proč je kaput netbeans? Díky

[gi]

Oracle intends to provide NetBeans as an "additional open source option" to complement JDeveloper and Oracle Enterprise Pack for Eclipse. Oracle makes it clear however, that JDeveloper is still "Oracle's strategic development tool" for Oracle Fusion and future enterprise applications. Oracle says that JDeveloper, Enterprise Pack, and NetBeans will all be options "for pure Java and Java EE development."

[Espinosa]

Oracle svoji JVM JRocket vzdycky prodaval, dodaval v ramci placenych produktu.

> .. the premium edition will likely see performance tuning and > tie-ins to Oracle's middleware.

Ty vyhody budou (asi jen) v oblati enterprise, tam jsou lide zvykli pustit chlup.

> Oracle claims that using JRockit can give significant performance gains, > but independent benchmarking has not always confirmed this.

Takze asi tak. Muzu to potvrdit z praxe, jsem zrovna na projektu kde vysledek bezi na JRockit a WebLogic. Vykonosot aplikace primarne zalezi na jinych faktorech.

> JRockit ... also provides hot swapability.

Hmm, ani jsem si nevsiml. Vyuzitelnost je stejne sporna. Vetsina zmen stejne potrebuje kompleni reload, zvlaste pouzivateli Spring a ladeni probiha na unit a integracnich testech.

Jediny funkcni a pouzitelny hot swap (vcetne pridavani novych method a fieldu) je JavaRebel, za ten si taky priplatite uz ted.

[omg]

DNES BYL TEN SLAVNY DEN KDY POHRBILI JAVU HURA HURA HURA SLAVA!!! DEKUJEME ORACLU.

[PMD]

Long live dotNET.

[x]

No az na to, ze M$ .NET taky hazi pres palubu.

[kralyk z abclinuxu]

é?

[BlackShark]

Označte si to do kalendáře, abyste za rok, za dva, dohledal, kdy jste plácnul takovou blbost

[omg]

no dobre, tak ji akorat zarizli. ted se bude cekat na to az ji nekdo zahrabe nebo shnije.

[kralyk z abclinuxu]

Normálně bych byl za to taky rád, jenže zdechnutí Žavy bohužel implikuje vzestup .NETu.
Ne, že bych proti .NETu něco měl, teda určité výhrady by se našly, ale celkově to je zajímavá platforma a C# relativně pěkný jazyk, bohužel MS na to aplikuje svoji obvyklou politiku, takže to funguje jen na MS produktech. Ostatní ostrouhaj, protože 1) nestíhaj kompatibilitu 2) čelí patentům.

Java? Šílený jazyk, ale alespoň funguje/fungovala všude.

[xkucf03]

V čem je to šílený jazyk?

[kralyk z abclinuxu]

Rok na gymplu jsme dělali v Javě, vysvětlovali nám na tom OOP (heh..). Vadila mi nutnost onanovat s interface (pravda, to je i v C#) a nemožnost přetěžovat operátory. A taky celková ukecanost knihoven...

[píča]

Můžete nám tu onanii blíže popsat?

Přetěžování operátorů - věc názoru. Stejně tak mi nechybí třeba dědění od více tříd.

A tu ukecanost knihoven bych taky rád viděl.

[kralyk z abclinuxu]

Eh, už jsou to léta...

Stejně tak mi nechybí třeba dědění od více tříd.

To přesně jsem na mysli tou onanií s iterface.

[Ladicek]

S interfejsy* vůbec onanovat nutné není, a krom toho je to jedna z nejlepších vlastností Javy Mít jazykovou konstrukci, ve které se dá skutečně vyjádřit jenom rozhraní (tedy vlastně typ) je k nezaplacení.

*) úmyslně tady rozlišuju interfejs (javovská konstrukce) a rozhraní (obecný pojem)

[kralyk z abclinuxu]

Mít jazykovou konstrukci, ve které se dá skutečně vyjádřit jenom rozhraní (tedy vlastně typ) je k nezaplacení.

Proč? Takhle, užitečné to být dejme tomu může, ale přijde mi blbost to po programátorovi vyžadovat. V C++ udělám prostě pure virtual třídu, ale nemusim, můžu klidně vícenásobně dědit, míchat pure virtual prvky s jinejma, atd...

[Filip Jirsák]

Bylo by ale zbytečné mít druhý jazyk úplně stejný, jako C++.

Pro programátora, který zrovna píše kód, je samozřejmě pohodlné, když má spoustu možností. Ovšem pro ty všechny, kteří se tím kódem budou zabývat později, je naopak pohodlnější, když se původní autor nemůže vyjadřovat moc květnatě a oni pak nemusejí dumat nad tím, co vlastně ten kód má dělat. Ano, Java je omezená tím, že nemá třeba vícenásobnou dědičnost nebo přetěžování operátorů a musíte to vyjádřit jen pomocí typů a instancí, což někdy znamená udělat košatější strukturu tříd, napsat víc kódu a víc volání. Na druhou stranu pak ale programátor nemusí znát spoustu konstrukcí a postupů, vystačí si se znalostí tříd a interfaců.

[kralyk z abclinuxu]

Jen bych přidal připomínku, že i v C++ je možnost kód přehledně komentovat... Ale asi se shodnem, že v praxi to nebývá zrovna pravidlem...
Jinak celkově souhlasím, jsou to dva různé přístupy.

[Filip Jirsák]

Komentáře jsou jen dílčí způsob, jak pomoci orientaci v kódu, a rozhodně to nezachrání.

[Ladicek]

Ale v Javě taky nemusíš. Jenomže časem přijdeš na to, že ve skutečnosti chceš (protože abstrakce, volná vazba, separation of concerns a takový ty sračky ze světa softwarového inženýrství).

Javovské interfejsy nejsou způsob, jak dělat vícenásobnou dědičnost, ta v Javě prostě není. Kdo je tak chce používat, je odsouzen k utrpení. (Ostatně můj skromný názor je, že dědičnost je univerzálně špatná, ale to je jiná pohádka.)

[píča]

Souhlasím, podepisuji.

[Radek Miček]

Protože má značně omezené vyjadřovací možnosti.

[píča]

Někomu vyhovuje psát méně typů konstrukcí za cenu více kódu, jinému ne. Třeba v Perlu se dá psát "úsporně", a přece bych v něm úsporně nepsal - raději bych psal (pro mě) jasnější konstrukce, byť by byly delší.

[Radek Miček]

Podle mě je problém v tom, že kód v Javě obsahuje spoustu balastu a s takovým kódem se pak těžko pracuje.

Někomu vyhovuje psát méně typů konstrukcí za cenu více kódu, jinému ne.

Málo typů konstrukcí neznamená nutně více kódu. Jazyky Haskell, ML a různé Lispy jsou toho důkazem.

[Filip Jirsák]

V přirozeném jazyce je také spousta balastu, a díky tomu se s ním lidem pracuje lépe. Proč by to podobně nemohlo platit i pro Javu?

[JS]

Prirozeny jazyk ma prekvapive malo balastu. Protoze prirozeny jazyk ma napriklad kontext, nebo domenove-specificke jazyky (aka zargon).

V Jave si DSL nenadefinujete. V Common Lispu ano, velmi snadno pomoci maker. Co se tyce kontextu, Common Lisp umi fantastickou vec, kterou jsem nevidel v zadnem jinem (mainstream) jazyce - anaforicka makra. To jsou makra, ktera automaticky vazi promennou (vytvareji kontext), takze vyrazne zkracuji kod. Prikladem muze byt "aif" - je to jako if, ktery automaticky vaze vysledek vyrazu na promennou "this", takze se muzete na ten vysledek odvolat v tele toho ifu. Vysledek je podstatne kratsi a prehlednejsi kod.

Je tezke vysvetlit vyhody Lispu (zejmena makro systemu) nekomu, kdo ho nezna. Pointa je, ze v konecnem dusledku na poctu konstrukci jazyka nezalezi, protoze neni jasna hranice mezi jazykem a knihovnou (i kdyz bych se vsadil, ze Common Lisp ma mene specialnich forem nez Java klicovych slov, a to toho umi 2x vic). Pochopit nejake (jiz napsane) makro neni v zasade obtiznejsi, nez pochopit nejakou funkci. A proti funkcim a jejich mnozstvi snad nikdo nic nenamita, nebo ano?

[Filip Jirsák]

Přirozený jazyk má mnoho balastu stejného typu, jako Java – tj. že se něco vyjadřuje pomocí víc písmenek, než by z hlediska přenosu informací bylo nutné.

V Javě si také neoloupu pomeranč, a nijak mi to nevadí. To, že nějaký jazyk něco umožňuje vyjádřit přímo pomocí nějaké konstrukce jazyka, a v jiném to musíte opsat, neznamená vůbec nic. Jeden jazyk může být vhodný na to a druhý zase na něco jiného. K čemu by byla Java, kdyby to bylo druhé C++ nebo druhý Lisp?

[Radek Miček]

V přirozeném jazyce se snadno zavádí nové konstrukce, v Javě to tak snadné není.

[píča]

Já myslím, že celé to srovnání s přirozeným jazykem není zrovna šťastné. Zavádění nových konstrukcí do jazyka jako takového mi v Javě moc nechybí. Osobně raději věci řeším co nejjednotnějším způsobem, i když to vyžaduje delší kód. Něco jiného je samozřejmě polymorfismus.

[JS]

A definovani nove funkce (tedy v Jave spis metody) neni zavedeni nove konstrukce do jazyka?

Problem je, ze vy jste udelal umele rozdeleni nekde, kde vlastne neni. V konecnem dusledku neni takovy rozdil pochopit, co dela funkce a co dela nejake makro (makro akorat - z hlediska uzivatele - a priori nevyhodnocuje sve argumenty a nelze ho predat jako funkci, to je cele ).

A ze vam nove konstrukce nechybi - kdybychom vzali nejake z Javy, chybely by vam? Nechybi vam, protoze nemate tu moznost a neznate je. Paradox je, ze mluvite o "jednotnem zpusobu", ale Lispova makra jsou super nastroj, jak te jednotnosti dosahnout. Vas problem je neznalost, a chucpe, ze nic uz dalsiho vedet nepotrebujete.

[píča]

A definovani nove funkce (tedy v Jave spis metody) neni zavedeni nove konstrukce do jazyka?

To záleží, čemu říkáme "nová kosntrukce". Já jsem schválně řekl "do jazyka jako takového", a tím jsem nemyslel vytvoření nové funkce (nebo třídy).

Problem je, ze vy jste udelal umele rozdeleni nekde, kde vlastne neni.

V některých jazycích ta hranice je, v jiných není. V Javě programátor pracuje na úrovni tvorby tříd a nic moc na tom nezmění. Ale zase v Perlu jsem viděl, že tam si lidé programují skoro veškeré části jazyka - třeba systém výjimek.

A ze vam nove konstrukce nechybi - kdybychom vzali nejake z Javy, chybely by vam?

Chápu, kam míříte. Já si ale myslím, že existuje víc přístupů, a jeden z nich zastáváte vy, druhý já. Oba přístupy mohou existovat vedle sebe s tím, že vy asi nepřijdete na chuť Javě a já Lispu.

Paradox je, ze mluvite o "jednotnem zpusobu", ale Lispova makra jsou super nastroj, jak te jednotnosti dosahnout.

Proti makrům nic nemám.

Vas problem je neznalost, a chucpe, ze nic uz dalsiho vedet nepotrebujete.

Nic takového jsem nikdy nikde netvrdil. Pouze jsem vyjádřil spokojenost s přístupem Javy.

[JS]

Pokud v Lispu pisete makra, take nedavate featury do jazyka jako takoveho - ten je vicemene definovan pomoci svych specialnich forem. Samotny CLOS je napsan pomoci maker.

Pokud skutecne jde o citelnost, musel byste uznat, ze pouziti makra neni o nic horsi, nez pouziti funkce. A stejne jako se nebranite funkcim (to by bylo absurdni), proc se pak branit makrum?

A pokud prijmete makra (jak tvrdite), pak musite uznat, ze Java (jazyk bez maker) proste ma omezene vyjadrovaci prostredky (=> spousta balastu), coz byla teze ze zacatku vlakna.

[kralyk z abclinuxu]

Já myslím, že celé to srovnání s přirozeným jazykem není zrovna šťastné.

Naprosto souhlasim, přirozený jazyk je něco úplně jiného a slouží na něco úplně jiného.

[Filip Jirsák]

Jaký je tedy rozdíl mezi programovacím jazykem a přirozeným jazykem a mezi jejich účely vzhledem k „balastu“ v daném jazyce? Já tedy v obou případech vidím „balast“ jako něco, co usnadňuje člověku pochopení významu zprávy, usnadňuje nalezení a opravu chyb a usnadňuje člověku zacházení s danou zprávou.

[kralyk z abclinuxu]

U přirozeného jazyka není tak úplně jasný, co je balast a co ne. V programování to je celkem jasně definované, v lidském jazyce to je fuzzy.
Alespoň takový je můj názor...

[Filip Jirsák]

Já tedy nevím, co je v programování balast, docela by mne ta definice zajímala.

[kralyk z abclinuxu]

Tak to se zeptej někoho jinýho Já výraz 'balast' nepoužil, já mluvil o 'ukecanosti knihoven', čímž mám na mysli třeba System.out.printf(), různé ty getCosiKdesiJaksi, různé ty import org.kdosi.cosi.cosi.cosi atd., prostě když to nemá alespoň 3 slova, není to pořádný javovský identifikátor...

[xkucf03]

čímž mám na mysli třeba System.out.printf()

A jak bys to chtěl jinak napsat? Zavést nějakou globální funkci pro výpis na standardní vstup? Proč? Proč to neudělat obecně? Ten System.out je instance PrintStream a má nějaké metody – jednou můžeš vypisovat do souboru, jindy do TCP spojení nebo na standardní výstup – vždycky je to stejné, můžeš udělat univerzální program/metodu a podle toho, jaký PrintStream mu podstrčíš, tam bude psát. Zavádět nějakou funkci print(), která bude vypisovat jen na standardní výstup, mi přijde dost hloupé. Jednak je to redundantní, jednak když budu chtít vypisovat jinam, budu ten program muset překopat – nebude stačit změnit jednu proměnnou. Čistota jazyka mi přijde daleko důležitější než ušetřených pár znaků.

Pokud tě to tak strašně trápí, napiš si statickou metodu, která ten System.out.prinln() bude obalovat.

různé ty import org.kdosi.cosi.cosi.cosi atd.

Balíčky jsou skvělá věc. Doporučuje* se použít vlastní internetovou doménu a další členění si udělat podle sebe – tím je zaručena globální jedinečnost** identifikátorů – takže až v programu namícháš X knihoven, nebudeš mít konflikty s názvy (ne jako když nějaký chytrák pojmenuje třídu Main a dá ji do nějakého jednoslovného balíčku, nebo pro jistotu do žádného). Opět nevím, proč by mě tahle „ukecanost“ měla trápit – celou cestu člověk napíše jednou do importu a pak už používá jen název třídy.

*) nikdo ti ale nebrání udělat si balíček jsem.lama.*

**) předpokládá se, že v rámci vlastní organizace (domény) si to zvládneš ukočírovat a že ostatní nebudou používat tvoji doménu pro svoje balíčky.

[kralyk z abclinuxu]

Já to nekritizuju principiělně, obecně jsou namespaces jistě dobrý nápad, to jo. Jen jsou prostě v Javě hodně ukecaný, to je všecko. V C++ jsem zvyklý na přinejhorším na nějaké to std::cout. Nebo takové Qt; v C++ buď namespace nepotřebuje, nebo tam jsou takové jako Qt:: QGL:: apod. V Javě com.nokia.qt.gui. nebo něco podobného...

Ono se to netýká jen importů, ale i názvů funkcí, taky jsou taky dost košaté. Ale to je samozřejmě jen můj postoj, mně osobně to přijde méně přehledné, ale někomu to třeba naopak může vyhovovat...

[Ladicek]

No, problém javovských jmenných prostorů (balíčků) není v jejich ukecanosti (ono to všechno zvládne vygenerovat IDE, a neexistuje důvod nepoužívat IDE), ale v tom, že stojí za vyližprdel. Sice javovské modifikátory pro viditelnost jsou plus mínus stejné jako ty obvyklé, ale v tom je právě ten problém: je potřeba univerzální modulový systém s verzováním, ve kterém lze definovat exporty, a uvnitř modulu klidně může vidět všechno na všechno. Balíčky by pak mohly sloužit jen pro logické rozdělení, bez ohledu na viditelnost. Jmenná konvence založená na URL není úplně hrozná, i když se na ni často kašle (a právem, ploché jmenné prostory jsou mnohem přirozenější než silně hierarchizované).

[default]

Nebyl na vylepšení vyditelnosti balíčků nějakej návrh pro Javu 7? Něco jsem o tom začetl a nevypadalo to zle — nepočítám, že to byl workaround.

[Ladicek]

Na modulový systém pro Javu je nějaké JSRko (a ještě jedno je na OSGi, aby toho nebylo málo), ale jak to dopadlo a co bude a nebude nevím. Pokud je tohle aktuální, tak nejdřív v Javě 8.

[Filip Jirsák]

Co si tak vzpomínám, měl se snad Javovský modulový systém a OSGi sloučit, a mělo by se to dostat už do Javy 7. Když jsem četl, co se nakonec do Javy 7 dostane, byl právě ten modulový systém jediná rozumná věc, vše ostatní rozumné se odsunulo do Javy 8. Ale je možné, že už je to zase jinak. Ale ten blogový zápisek vypadá poměrně čerstvě, a vypadá úplně opačně, tj. že se většina nesmyslů přesunula až do osmičky a většina užitečných věcí do sedmičky.

[default]

Moc jsem to neštudoval, ale vypadá to, že na generika ve Swingu si ještě chvilku počkáme.

[Filip Jirsák]

Jenže to je právě úplně stejné, jako v přirozeném jazyce. Samozřejmě, že by to v Javě i v angličtině mohlo být Stm.o.prf – jenže člověku se líp pracuje se System.out.printf.

[kralyk z abclinuxu]

jenže člověku se líp pracuje se System.out.printf

Jak komu. Někomu (mně) takový kód připadá jako stránka z beletrie, čili takový kód se špatně čte jinak, než jako beletrie, což je nežádoucí.
To, že takový kód je podobnější přirozenému jazyku, je hezké, ale zatím nikdo neřekl, proč to je dobré? Imho moc není.

Podívej se například na formulace v matematice. Na to taky existuje jazyk, a ten je od jakéhokoli balastu oproštěn. Každá věta/výrok/atd. by mohly být popsány slovy (a kdysi to tak i bylo), přesto matematici preferují krátký zápis bez balastu, protože je prostě přehlednější a člověk z něj tu myšlenku snáze extrahuje.

Srovnej: "Pro každé x větší než nule přirozené platí, že..."
s: "∀ x>0∈ℕ: ..."

Imho programovací jazaky jsou účelem i vlastnostmi mnohem blíže právě jazyku matematiky...

[Filip Jirsák]

Tvrdíte, že nemám žádný důkaz, kterým bych podpořil tvrzení, že se s „ukecanějším“ jazykem člověku lépe pracuje, a pak stejně bez důkazu tvrdíte, že se lidem lépe pracuje s krátkým zápisem.

Matika se od přirozeného jazyka liší právě tím, že extrahuje tu jedinou myšlenku, a nic ostatního není důležité. Z x = f(y) opravdu nepoznáte, že x má problémy doma a špatně se soustředí, takže si na něj máte dát pozor, protože se snadno může splést a bude se rovnat f(y-1). V reálném světě jsou ale takovéhle doplňující informace důležité, a stejně důležité jsou i při programování. Možná ne v případě, kdy programujete nějaký abstraktní algoritmus a jste blízko té matematice, ale když programujete třeba nějakou část e-shopu, je dobré vědět i o kontextu a okolí, protože tak můžete snáz odhalit nedorozumění nebo chyby.

[kralyk z abclinuxu]

a pak stejně bez důkazu tvrdíte, že se lidem lépe pracuje s krátkým zápisem.

No, tvrdím to o matematicích, a tam mám imho pravdu... Pak jsem tvrdil, že programování je tomu blíž, ale na to důkaz nemám, to uznávám.

V reálném světě jsou ale takovéhle doplňující informace důležité, a stejně důležité jsou i při programování. Možná ne v případě, kdy programujete nějaký abstraktní algoritmus a jste blízko té matematice, ale když programujete třeba nějakou část e-shopu, je dobré vědět i o kontextu a okolí, protože tak můžete snáz odhalit nedorozumění nebo chyby.

Hm, nějak vůbec nevím, co si pod tím představit... Nějaký praktický příklad třeba?

[Filip Jirsák]

Třeba se o kódu snadno můžete bavit s dalším programátorem – „fakturaPrijata“ vyslovíte snadno jako „faktura přijatá“ a oba víte, o čem je řeč. Když ale budete mít v kódu „frp“, budete tomu stejně muset říkat nějak jinak, a snadno si to spletete třeba s „fpr“. Nebo když v kódu narazíte na switch podle názvů dnů v týdnu, kde bude chování pro neděli a pondělí jiné, asi vás zarazí, zda by to spíš neměl být víkend. Když tam ale bude switch pro čísla 0 až 6, bude vám to připadat normální. Nebo si ve zdrojáku přečtete nějaký assert, a hned víte, co programátor toho kódu předpokládal. To všechno jsou „zbytečnosti“, které výsledný přeložený program nijak neovlivní, ale pomáhá to programátorovi dostat se do souvislostí, spojit si ten program s něčím, co už zná. Nebo jinak – zkuste si třeba porovnat zápisy 123 + 14 = 231 a 7B + E = E7. Matematicky ty zápisy znamenají to samé, ten druhý je méně ukecaný, ale pokud nejste zvyklý denně počítat v šestnáctkové soustavě, v tom prvním vás asi zarazí chyba jen při běžném pročítání, ten druhý byste nejspíš ponechal bez povšimnutí.

[kralyk z abclinuxu]

Tak jasný, stejně tak ale když se mě kolega zeptá, jak vypisovat na standardní výstup, mu řeknu mnohem radši "použij printf()" než "použij System.out.printf()". Stejně tak bude lepší faktrura.prijata() než faktura.getIsPrijata(), že...

Čili viděl bych to na nějaký vhodný kompromis...

[Filip Jirsák]

Jenže System.out je zároveň standardní OutputStream jako každý jiný, nepotřebuju znát nic nového. faktura.prijata() může být metoda, která fakturu do stavu přijata změní, provede proces příjmu faktury atd. Ale faktura.isPrijata() je podle konvence getter booleovské property.

Moje zkušenost je taková, že tam, kde jde o nějaký algoritmus, Java není moc vhodná – algoritmus je většinou buď jasný, nebo jej stejně musíte někde nastudovat, a sáhodlouhé popisy (nebo názvy) v programu nepomůžou. Pokud jde ale o různé informační systémy a aplikace, tam není nic moc zajímavého v algoritmu, ale potřebujete vědět, s čím ten kód souvisí, jak modeluje realitu apod. A tam se zase delší popisy hodí.

[Filip Jirsák]

Můžete zkusit zavést do češtiny jedenáctý slovní druh nebo další typ větného členu, ale to už bude snazší zavést novou konstrukci do Javy.

[Radek Miček]

AFAIK v Javě si unless nezadefinuji.

[Filip Jirsák]

Pořád máte větší šanci, že se vám to podaří, než že se vám podaří do češtiny dostat jedenáctý slovní druh.

[píča]

Můžete dát příklady toho balastu?

[JS]

Muzu, ta knizka se jmenuje tusim "Design Patterns". Zkuste si ji nekdy porovnat s takovym "On Lisp". Zatimco v Design Patterns vas nuti stale dokola psat to same, v On Lisp se na to napisou vhodna makra a je to vyrizene.

[píča]

Pracovat s návrhovými vzory samozřejmě nikdo nikoho nenutí... Navíc - Design Patterns není výhradně javovská záležitost, to je záležitost OOP obecně.

Byl byste ochoten napsat nějaký příklad v Javě a v Lispu, abychom to porovnali?

[JS]

Napsat priklad ceho? Common Lisp ma CLOS (Common Lisp Object System), bohuzel ho moc neumim, ale je vyrazne mocnejsi nez Javove OOP.

Co se tyce Design Patterns, mozna to pouzivat nemusite, je to jen "doporuceni". Stejne jako byste nemusel pouzivat OOP a programovat proceduralne. Co me fascinuje je, jak se (vy zastanci Javy) chlubite jeji jednoduchosti, a pak prinesete "Design Patterns". Jde mi o to, ze to vubec neni tak, ze je Java jednodussi na programovani nez Lisp - akorat jste, protoze ji znate, zapomnel, jak slozite to je.

Jinak jestli chcete srovnani Javy s Lispem, doporucuji prednasku "Practical Common Lisp" na Google Techtalks (mimochodem me privedla k Lispu, i kdyz z jineho duvodu nez kvuli makrum, jejich silu jsem pochopil az pozdeji).

[píča]

Napsat priklad ceho? Common Lisp ma CLOS (Common Lisp Object System), bohuzel ho moc neumim, ale je vyrazne mocnejsi nez Javove OOP.

Nechci vám vkládat do úst, co jste neřekl, ale zdá se mi, že tady jsem našel příklad problému s jazyky bohatými na konstrukce. Zdá se, že Lisp znáte poměrně dobře - a přece jste ještě nepochopil jeho objektový systém. Což o to, třeba se ho budete učit rok a pak budete produktivní. Ale spíš pochybuju o čitelnosti.

Co se tyce Design Patterns, mozna to pouzivat nemusite, je to jen "doporuceni". Stejne jako byste nemusel pouzivat OOP a programovat proceduralne. Co me fascinuje je, jak se (vy zastanci Javy) chlubite jeji jednoduchosti, a pak prinesete "Design Patterns".

Na to ani nechci reagovat, je to nesmysl - děláte, jako kdyby pro jiné jazyky (styly programování) nebyly pospány některé "dobré postupy".

Jde mi o to, ze to vubec neni tak, ze je Java jednodussi na programovani nez Lisp - akorat jste, protoze ji znate, zapomnel, jak slozite to je.

Ne. Naučit se Javu (jazyk) je otázkou pár dní. Druhá věc je naučit se OOP - ale to je využitelné i v jiných jazycích.

[JS]

Na svoje programky jsem zatim CLOS nepotreboval, i kdyz mi obcas chybi, ale holt existuji dulezitejsi veci, co jsem chtel znat driv. Zajimave je, ze CLOS lze v podstate cely implementovat v Lispu. Z toho plyne, ze spoustu veci udelate jednoduseji primo nez pomoci CLOS.

Dobre postupy jiste existuji, bohuzel je casto nelze nijak formalizovat. Vetsina Design Patterns je obchazeni veci, ktere nejdou v Jave udelat snadno. Pointa je, to co jde formalizovat, jde v Lispu prevest do maker. Pokud nejaky postup formalizovat nejde, pak vam zadny "vzor" nepomuze.

Naucit se Javu neni otazka par dni. Java neni jen jazyk, jsou to i zakladni knihovny. Pokud se nechcete ucit Lispova makra (= ucit se jen srovnatelne featury), vyjde to s Lispem a CLOSem nastejno (viz knizka Practical Common Lisp).

[Radek Miček]

Například:

• Gettery a settery, co neprovádí žádnou speciální činnost.
• Cykly v místech, kde funkce vyšších řádů umožní přehlednější zápis téhož.
• Chytání výjimek jen kvůli uvolnění zdrojů.

[píča]

1. Souhlasím, že gettery a settery jsou svým způsobem balast, který si většina lidí nechává generovat... Na druhou stranu jde o docela užitečný balast. Mně se zapouzdření takovým způsobem líbí. Jaké jsou jiné alternativy v objektově orientovaném programování? Takové PHP, jestli se nepletu, dokonce má funkce __get() a __set(), které fungují jako gettery a settery pro všechny proměnné objektu. Někdy se to asi hodí, jindy ne. Ale je to alternativa - sice ne setterů a getterů obecně, ale setterů a getterů pro každou proměnnou zvlášť. Je samozřejmě i možnost zpřístupnit proměnné z vnějšku objektu...

2. Bohužel nerozumím, na co narážíte.

3. Nevím o tom, že by někdo kvůli uvolňování zdrojů odchytával výjimky. Ano, v bloku finally se zpravidla uvolňují, ale v tom nevidím žádný balast. Naopak mi to připadá přehledné.

[Radek Miček]

2. Funkce vyšších řádů jsou funkce, jejichž parametry jsou jiné funkce (anglicky higher-order function). Hodí se to třeba při práci s kolekcemi. Příklad v jazyce Haskell může vypadat takto:

take 15 $ filter ((==0) . (`mod` 7)) $ map (^2) [1..]

Vysvětlení: Napřed vezme všechna čísla od jedné a spočítá jejich druhou mocninu, pak odstraní druhé mocniny, co nejsou dělitelné 7, a nakonec vrátí patnáct takových druhých mocnin.

Domnívám se, že v Javě to takhle pěkně naprogramovat nejde. Tento příklad demonstruje funkce vyšších řádů (map, filter, .), líné vyhodnocování (máme nekonečný seznam čísel [1..]) a currying (funkci nepředám všechny argumenty, ale jen některé – výsledkem takového volání je funkce, která přijímá zbylé argumenty; příkladem je třeba (`mod` 7), která vrací zbytek po dělení 7).

Mj. v příkladě nepoužívám žádnou pomocnou proměnnou.

[Filip Jirsák]

Já se zase domnívám, že to v Javě nejde naprogramovat takhle ošklivě V Javě totiž nemůžete mít nepojmenovaný typ, takže pro tu funkci jako parametr musíte vytvořit interface. Můžete pak vytvořit i anonymní implementaci toho interface, ale přehlednější bude i tu implementaci pojmenovat. Až pak zjistíte, že ten samý nebo velmi podobný kód potřebujete i někde jinde, přirozeně to povede k znovupoužitelnosti kódu nebo k využití dědičnosti – ve vašem případě to přirozeně povede k okopírování části kódu. Takový přístup je vhodný pro prototypování, pro údržbu programu je ale vhodnější to „mé“ řešení – a k tomu vás Java dost silně tlačí. To, že nepoužíváte žádnou pojmenovanou pomocnou proměnnou a vejde se vám to celé na jeden řádek oceníte zejména v případě, až najdete tohle číslo řádku v logu a budete z křišťálové koule věštit, která z těch asi pěti operací vlastně způsobila chybu.

[Radek Miček]

V Haskellu ty typy mohu také pojmenovat. V jednoduchých případech to však nedělám.

Až pak zjistíte, že ten samý nebo velmi podobný kód potřebujete i někde jinde, přirozeně to povede k znovupoužitelnosti kódu nebo k využití dědičnosti – ve vašem případě to přirozeně povede k okopírování části kódu.

K tomu mám dvě námitky:

• Jazyky s líným vyhodnocováním mají typicky menší potřebu kopírovat nějaký kód. Viz Why Functional Programming Matters. Když nějakou funkci potřebuji vícekrát, tak ji pojmenuji a použiji ji vícekrát.
• Dědičnost s sebou může přinést mnoho problémů, zejména jsou-li potomci automaticky i podtypy.

[Filip Jirsák]

No, a výhoda Javy je právě v tom, že musíte (teda nemusíte, ale když to neuděláte, uvidíte rovnou, že je to horší, než to udělat).

[stativ]

Dá se to obejít pomocí functorů s nějakým definovaným rozhraním, ale musíš psát functor pro každou kravinu (=> spousta balastu o ničem).

[píča]

Díky za vysvětlení.

Ne, tohle v současné Javě nejde. Jde tady o zcela odlišný koncept, já bych to řešil třeba pomocí návrhového vzoru Command...

Sice v Javě SE 7 / 8 budou nejspíš podporovány lambda výrazy, ale z nich jsem rozpačitý.

[Ladicek]

Já sice tvrdím, že Java je superimpotentní jazyk, ale když vidím tyhle superstručné a supernečitelné příklady (haskellisti jsou na to superodborníci), mám pocit, že boj za vyšší vyjadřovací schopnosti mainstreamových jazyků je předem prohraný.

Já bych se úplně spokojil s něčím takovým:

lazyList(from: 1).map({ it ** 2 }).filter({ it % 7 == 0 }).takeFirst(15)

Mimochodem, s trochou implementační snahy kolem toho líného vyhodnocování by tohle mohl být platný kód v Groovy.

[Radek Miček]

Já bych se úplně spokojil s něčím takovým...

To já také. Například ve Scale to jde dost podobně jako v Groovy, akorát tam bohužel také chybí to líné vyhodnocování, které je někdy nesmírně užitečné (alespoň u kolekcí).

[Pavel Křivánek]

1. Souhlasím, že gettery a settery jsou svým způsobem balast, který si většina lidí nechává generovat... Na druhou stranu jde o docela užitečný balast. Mně se zapouzdření takovým způsobem líbí. Jaké jsou jiné alternativy v objektově orientovaném programování?

Self to řeší tak, že objekty jsou složeny ze slotů, kterými mohou být jak datové sloty, tak metody. K obsahu datový slot má jméno např. name resp. name: pro zápis do něj, což je stejný syntaktický zápis, který se používá pro volání funkce s jedním parametrem. Takže objekt je v podstatě zapouzdřený i sám před sebou. Pokud chcete změnit funkci slotu z pouhé datové položky na komplexní metodu, stačí změnit samotný slot a nemusí se nikde jinde nic přepisovat. Všechny sloty jsou veřejné.

[stativ]

Java? Šílený jazyk, ale alespoň funguje/fungovala všude.

Saying java is good because it runs on all platforms is like saying anal sex is great because it works on all genders [1]

[hehehe]

Nechápem ako sa ten dementný citát mohol uchytiť. Čo je také zlé na multiplatformovosti?

[stativ]

O tom ten citát vůbec není. Jde o to, že jedna vlastnost (multiplatformnost) nutně nedělá jazyk (Javu) dobrým.

[píča]

Však taky Java (a nejen jazyk, ale celá platforma) nabízí daleko víc než jen multiplatformnost.

[default]

Java je asi tak multiplatformní jako jsou Windows, OS X s Linuxem multiplatformní pro binární aplikace. Stačí v ní napsat jeden "multiplatformní" program a ani kvůli tomu nemusím zkoušet všechny možné, nemožné sexuální praktiky s oběma pohlavími.

Ti, co v Javě nikdy nic takovýho nenapsali, doporučuji nahlédnout do zdrojáků NetBeans Launcher.

[Filip Jirsák]

To je skutečně zajímavý diskusní obrat, jako příklad multiplatformnosti uvést aplikaci, která má řešit specifika nějaké konkrétní platformy. Nebudete příště přenositelnost gcc ukazovat na generátoru kódu pro instrukční sadu x86? Nebo jsem tu poslendí větu vašeho komentáře vůbec nepochopil?

[www]

jaky specifika konkretni platformy maji resit netbeans? to sou dzouky

[Filip Jirsák]

Třeba zástupce aplikace na ploše, umístění konfiguračních souborů, způsob spouštění externích aplikací, cesty.

[default]

Absolutně nepochopil.

A já jsem zase nepochopil, že multiplatformovost Javy je přenositelnost bytekódu přes různý JVM. To mi totiž tak trochu nestačí a předpokládal jsem více. Kolega níže to zmínil — API.

[píča]

Java je multiplatformní tak, jak jen to jde. Multiplatformita Javy = bytecode funguje na každém JVM. Berte, nebo nechte být. Nic lepšího není. Subjektivně.

[JS]

Jinymi slovy, je multiplatformni asi stejne, jako POSIXova aplikace napsana ve standardnim C.

[píča]

Nejsem si úplně jistý významem toho přirovnání, ale na první pohled bych řekl, že ano.

[JS]

Vyznam je, ze "multiplatformnost diky JVM" je jen hype? V pripade Javy je ta multiplatformnost dana spis standardni knihovnou nez tim, ze je to VM.

[píča]

Není to jen hype. Prostě to tak je.

[Saljack]

Ale houby, nechápu proč tady všichni mluví o svinstvu s názvem .NET. Copak neexistuje spousta krásnějších řešení třeba python nebo ruby. V pythonu a Qt (pyqt pyside) je super spojení, které funguje na všech obvyklých platformách.

[píča]

Ano, děkujeme za odborný názor studentovi, co ještě před chvílí řešil, jak vůbec fungují listenery...

[Saljack]

Dík, taky si cením názoru člověka, který vystupuje pod přezdívkou "píča" a navíc není ani registrovaný, člověk hned pozná, kdo sedí na druhé straně.

[píča]

Na přezdívce nebo nějaké registraci nezáleží. Záleží jen na tom, co kdo říká. A já neukázal svou odbornou nezpůsobilost - vy ano.

[Saljack]

Konkrétně kde?

[Martin Petr]

Proč by mělo někoho v této diskuzi zajímat, kdo sedí na druhé straně. Zajímají mě argumenty, technické znalosti a podobně. Prostě tě holt dostal, no. Tedy dostala.

[Saljack]

Konkrétně v čem?

[kralyk z abclinuxu]

A co efektivita? Má Python nebo Ruby nějaký bajtkód? Obvykle tyhle programy nepatří k nejrychlejším...

[Ladicek]

Python nevím od jaké verze a Ruby od 1.9 jsou implementované klasickým interpretem bajtkódu (a pro oba jazyky existují snahy o JIT překlad do nativního kódu), což sice na rychlost (suní) Javy nebo (microsoftího) .NETu nemá ani náhodou, ale pro spoustu situací to stačí až až. Vedlejším zábavným efektem je, že JRuby a snad i IronRuby (implementace Ruby pro JVM, resp. CLR) jsou rychlejší než klasické CRuby (výrazně rychlejší než MRI, tedy Ruby 1.8, protože ten interpret je klasický visitor, a tuším lehce rychlejší než YARV, tedy Ruby 1.9); obdobně to bude asi platit pro Jython, IronPython a CPython, ale tam jsem nikdy žádné benchmarky neviděl.

[Saljack]

Nevím jestli patří k nejrychlejším, ale desktopové aplikace psané v nich mají odezvu naprosto někde jinde než java a swing. Navíc vypadají mnohem lépe.

[Filip Jirsák]

To samé se ovšem dá napsat i opačně. Ono taky hodně záleží na nastavení a na konkrétním programu. U mne třeba javovské aplikace vypadají stejně dobře, jako ty nejlepší nativní (protože jsem si to tak nastavil), pár pythonovských aplikací bylo utrpení používat (vypadaly jako z roku raz dva a odezvu měly, jako kdyby běžely na hardwaru z téhož roku). Akorát já na základě této své zkušenosti netvrdím, že je to tak vždycky a u každého.

[Saljack]

Právě hodnotím podle toho jaké mám zkušenosti vyděl jsem dost aplikacích napsaných v pythonu a Qt a byly k nerozeznání od aplikací napsaných C++, zato jsem neviděl desktopovou aplikaci napsanou v jave s swingu aby se o ní totéž dalo prohlásit a u všech jsem hned poznal, že jde o javu.

[Filip Jirsák]

Vaši zkušenost vám nikdo nebere. Ale chybně ji zobecňujete.

[Saljack]

fuj *viděl

[Algi]

Je jenom tvůj problém, že jsi nikdy neviděl Javovskou aplikaci, která je plně zaintegrovaná do prostředí... Pro konkrétní příklad totiž nemusím chodit daleko: Swingová aplikace na Mac OS X s nativním look and feel. Můžu ti v Javě na Macu napsat aplikaci, kterou od Cocoa nepoznáš ani omylem. Ještě nějaká moudra?

[Saljack]

Poslední co by mě zajímalo je jak vypadá swing na Mac OS, navíc o tom silně pochybuji. To samé tvrdili i jiní, že je to k nerozpoznání na Windows a opravdu tomu tak není je to poznat.

[Algi]

Pochybovat můžeš, ale fakta jsou holt taková To, že na Linuxu nemáte žádnou integraci není chyba Javy, ale Sunu (nyní Oraclu)... Taktéž můžu říct, že poslední co by mě zajímalo, je vzhled Swingu na linuxu, páč tam je stejně taková spousta prostředí, že nativní pro všechny ani být nemůže

[xkucf03]

Spousta = dvě? No dobře, možná ještě enlightenment, ale jinak už prakticky nic (pokud to někdo používá, tak stejně je už smířený s tím, že jeho systém bude „každý pes jiná ves“).

P.S. Java umí jakž takž nativně vypadat pod GTK. Osobně ale stejně používám Nimbus, přijde mi hezčí.

[Algi]

Bohužel to není pod GTK stoprocentní pro všechna témata. A co mě osobně nejvíc chybí, tak je absence nativního vzhledu pro Qt. Kromě E17 je tam ještě spousta dalších prostředí, už si je ani nepamatuju... Nimbus není špatný, pořád lepší než jeho předchůdce

[xkucf03]

Prostředí je hodně, ale většinou jsou postavené na Qt nebo GTK. Ten nativní Qt vzhled by se mi taky líbil, ale bylo by to tolik práce, že to asi nikdo neudělá – tak leda použít Qt Jambi.

[xm]

Jaká spousta dalších prostředí? Qt a GTK jsou jediné široce používané toolkity, ta "spousta dalších prostředí" (momentálně mě napadá kromě nejrozšířenějšího KDE a GNOME snad jen XFCE) je postavena zas jen na nich. Ano, existují tu ještě toolkity jako OpenMotif/LessTif, Tk, FLTK, Fox, GNUstep. Ale ty v moderních distribucích prakticky nikdo nepoužívá, takže mohou být s klidem naprosto ignorovány.

[pozortucnak]

Pokud neumře projekt qtjambi... Qt vypadá dobře ve windows, mac os x, dokáže se tvářit jako GTK...

[Ladicek]

Což bude spíš tím, že to GUI ve skutečnosti dělá GTK nebo Qt; kdyby někdo v čistém Pythonu nebo Ruby napsal GUI toolkit (ne že by něco takového mělo smysl), bylo by to peklo

[pozortucnak]

Když si trochu rejpnu, tak jak je to s mono a patenty?

O mono je tu spoustu negativních názorů, na druhou stranu mono v porovnání s java žere méně paměti, má lepší integraci s desktopem a lepší podporu pro dynamické jazyky... tak co je na mono špatného?

[Karel]

No, kdyz to srovnas s aktualni Java situaci, tak na monu neni spatneho vubec nic :)

[juras]

Hrozí reálně vznik podobného problému jako v případě .NET a Mono (kde aplikace psané pro .NET nejdou spustit v Monu a opačně), nebo jde jen o výkřik v duchu všichni proti Oraclu?

[Filip Jirsák]

Reálně nehrozí. Různé JVM a implementace „standardní knihovny“ existují už dávno, ale odlišností je mnohem méně, než v .NEt vs. Mono (alespoň co jsem tak o .NET a Mono slyšel). Zatímco Mono zřejmě implementuje nějakou základní (malou) část .NET, u Javy ta společná část tvoří většinu, a rozdíly v implementaci se týkají nadstandardních věcí, které si vždy musíte speciálně najít a u kterých je vždy důrazné varování, že to není součást standardu, jinde to fungovat nebude a používáte to na vlastní nebezpečí. Případně jsou ty věci implementovány ve více JVM, ale v každé jinak, takže je tu příslušnou část nutné řešit vícekrát. Ale pokud se nějaká věc používá hodně, dostává se zpravidla do dalších verzí standardu.

[Karel]

Tak bez rict me app, co bezi na .NETu i v Monu, ze na monu bezet nema ty osle

[BlackShark]

Vy jste asi trouba, že? Nebo pokud jedna aplikace běží např. ve Wine, znamená to, že všechny aplikace běží ve Wine?

[Bob]

No Java, no cry, tadatadata :)

[kolcon]

asi tak, dokud je tu Perl, javu netreba...

[kralyk z abclinuxu]

Eh, mám pocit, že jsi špatně pochopil předchozí příspěvek. Jestli jsem to já dobře pochopil, tak je to narážka na Marleyho "No woman, no cry", což neznamená "žádná žena, žádný pláč", nýbrž "neplač ženo, neplač"

[deda.jabko]

mas pravdu, ale porad ty carky jsou blbe. protoze oficialne je to sice No, woman, no cry. ale vyznamove je to No, woman no cry, i.e, zenske naplacou. sveho casu nam na teto pisnicce lektorka v ESL vysvetlovala, jak je potreba si davat pozor na thought groups a pomlky.

[deda.jabko]

mas pravdu, ale porad ty carky jsou blbe. protoze oficialne je to sice No, woman, no cry. ale vyznamove je to No, woman no cry, i.e, zenske naplacou. sveho casu nam na teto pisnicce lektorka v ESL vysvetlovala, jak je potreba si davat pozor na tought groups a pomlky.

[Bob]

ja myslel java nasr*t :)

[Lukáš Zapletal]

Nevím co tady šílíte.

Oracle má v současnosti tři Javy. Tu "normální" od Sunu, "extra-speciál" od JRockitu určenou pro enterprise nasazení na serverech a OpenJDK, která je Open Source (je tedy dostupná i Oraclu).

Jenže Oracle chce mít Javy jen dvě. Tak se to prostě sloučí. O nic nejde, není to konec ničeho, ani začátek něčeho jiného. Bojí se zkrátka toho, že se všichni naštvou a začnou více používat OpenJDK.

Uvidíme jestli se mu podaří zarazit nastolený trend "migrace" na OpenJDK.

[Ladicek]

Ve skutečnosti chtějí mít jen jednu, proto se Sun+OpenJDK (jak už jsem psal výše, od verze 7 by to mělo být totéž) slučuje s JRockitem. A pak to zase rozdělí, aby mohli prodávat nějakou přidanou hodnotu, ghehe