Čas:19.9.2006 13:42:56
Od:Jirka
Předmět:naprostý souhlas
Naprosto s Vámi souhlasím. Jenom si říkám, že tento článek by měl číst nějaký "zodpovědný pracovník" v Sunu aby se s tím něco stalo. Bylo by moc hezké pokud by se toto implementovalo.
Čas:19.10.2006 12:50:33
Od:Roman Strobl
Předmět:Zmeny vyvoje javy a nesouhlas
Dobry den, pokud chcete radikalnejsi zmeny ve vyvoji Javy, je treba toto prosadit pres Java Community Proces (JCP) - viz http://jcp.org. Pripadne muzete komunikovat s lidmi, kteri jsou zapojeni do vyvoje Javy a presvedcit je o nutnych zmenach. Cesky Sun vam prilis nepomuze, zvlast v pripade takto kontroverzniho tematu. Java je komunita a do vyvoje se muze zapojit kazdy - ale samozrejme musite mit na to nejdriv urcitou reputaci a znalosti. Co se tyka podminene kompilace, tak ta se v Jave pouziva napr. v Java ME. Je to z toho duvodu, ze existuje prilis mnoho ruznych zarizeni a je tam klasicky preprocesor. Viz: http://www.netbeans.org/kb/50/preprocessor-syntax.html Ja s vami nesouhlasim, ze by mel existovat univerzalni preprocesor v Jave, protoze kod, ktery vyuziva preprocesingu, je casto velmi necitelny. Take nesouhlasim co se tyka rychlosti vyvoje javy, protoze kdyby byl vyrazne pomalejsi, jave by mohl "ujet vlak", zvlast ve svete dynamickych jazyku. Myslim, ze tempo novych verzi je celkem rozumne - cyklus je myslim nekde mezi 18 mesici a 2 lety. Napr. ve verzi 6.0 nedochazi k zadnym zmenam syntaxe a k mnoha vylepseni. Jasne, verze 5.0 znamenala dost zmen, ale pokrok si takoveto zmeny vyzaduje.
Čas:24.10.2006 17:31:29
Od:Artur Linhart
Předmět:Re: Zmeny vyvoje javy a nesouhlas
Ahoj Roumene, Ad preprocesor - pokud mela byt Tva reakce nesouhlasem vzhledem k clanku - nepsal jsem o tom, ze by mel existovat preprocesor v Jave, jen jsem uvadel, ze se neexistence tehle "ficury" pres preprocesor obchazela - jsou jazyky u kterych vladne obecna shoda ze preprocesor nemaji a uvedena vec tam je - viz napr. priklad Pascalu. Samozrejme je to o hranicich co je a neni - klidne se muze rici, ze je to nesmysl co jsem navrhl k diskusi, resp. co postradam, ale problem mnoha verzi existuje a zvetsuje se, tak by mozna mohlo prijit nejake mnohem lepsi reseni nez v clanku uvedene - nicmene je pro mne (snad nejsem vyjimka) tezke se tvarit ze ten problem neexistuje. Ad verze - nemluvil jsem o verzi Javy jako takove ale o verzich JDKcek... A tam urcite nejde o jednu verzi za dva roky. Jak je videt ze stranky http://java.sun.com/products/archive/ tak: Javy 1.2 se da stahnout 13 ruznych verzi JDK (a to tam jeste nektere nejsou uvedene k downloadu - mozna nikdy uverejnene nebyly, nevim) Javy 1.3 se da stahnout 26 ruznych verzi JDK Javy 1.4 se da stahnout 25 ruznych verzi JDK Javy 1.5 se da stahnout doposud 9 ruznych updatu - pokud si vezmu, ze napriklad verze 1.4 se vyvijela cca dva a pul roku, tak to mame prumerne kazdych 6 tydnu (nebo tak nejak) upravenou verzi JDKcka - myslis, ze to neni prilis? ;-) Nicmene uznavam, ze trend je pozitivni - 1.5 mela uz jen 9 verzi, tzn. vychazi jedna asi na 3 mesice - no, ale porad, pokud by jich byl treba tretinovy pocet, tak by to asi nevadilo. Urcite by bylo i fajn, mit nejak jesne pristupnou rozdilovou dokumentaci - pokud existuje a jen jsem ji nenasel, muzes mne a ostatni ctenare navest, kde tak asi je? :-) Aby nebylo nutne stahovat kazde JDK znovu a patrat v nem (pokud to tam vubec je). Dekuju kazdopadne za reakci, je to prima ze ta komunikace tak funguje :-).
Čas:6.11.2006 17:08:51
Od:Martin Kosar
Předmět:Re: Re: Zmeny vyvoje javy a nesouhlas
Co se tyka releasu od jednotlivych verzi Javy, je to zrejme otazka vyvojoveho cyklu a ne nove funkcionality. Stejne by pro jakekoliv vaznejsi nasazeni melo platit, ze se to testuje a bezi na jedne verzi.
Čas:8.11.2006 19:18:28
Od:Maaartin
Předmět:Re: Re: Zmeny vyvoje javy a nesouhlas
Co myslis tim, ze packal preprocesor nema? To je formalita - ty krasne {$...} jsou okopceny z cecka a delaji totez co tam dela preprocesor. ze se to udela v jednom pruchodu je bezvyznamny implementacni detail. (A ze to neumi tolik jako v cecku je zas typicka vlastnost packalu.) A ze to v jave neni - no kazdymu kdo by to mohl pouzit to trochu chybi. A zas kazdy kdo se musel prohrabavat miliony vnorenych defajnu a maker je zas moc stastny ze to tam neni.
Čas:19.10.2006 1:07:49
Od:Cyril Sochor
Předmět:Preprocesor pro J2ME
Take jsem si napsal vlastni preprocesor, kdyz jsem programoval javahry pro mobily. To se totiz musely zrojaky pro ruzne telefony malinko lisit, slo by to take udelat nejakym konfigurakem a pouzivat if v jave, ale to bralo vice pameti, ktere ma java v mobilu pomalu...

Ale chapu autory javy, ze nam preprocesor nenadelili, v cecku je mocny preprocesor a je naprosto uzasnej do te doby, nez mam pochopit kod, ktery napsal nekdo jiny a hojne vyuzival #define

Čas:24.10.2006 18:33:23
Od:Artur Linhart
Předmět:Re: Preprocesor pro J2ME
Urcite souhlasim, nic se nesmi prehanet - ale zneuzit se da vsechno a uz dneska se da javovsky zdrojak s pomoci davno znamych rysu jazyka udelat zcela nepochopitelny a neprehledny.
Čas:19.10.2006 9:17:48
Od:Richard
Předmět:Naprosty nesouhlas
Popisovany problem sa sice vyskytuje, ale robit kvoli tomu Javu neprehladnu je hrozna predstava. A navyse by to nepomohlo. Neviem si predstavit vyvojarov nejakeho OS produktu, ako pri oprave nejakej chyby robia sucasne opravy aj pre starsie JDK. Skor by bol kod este menej stabilny.
Čas:19.10.2006 16:35:46
Od:Peposh
Předmět:Re: Naprosty nesouhlas - Absolutny suhlas :-D
Ak niekto ma potrebu zaradit preprocesor do javy, doporucil by som mu pozriet si zdrojaky Linux kernelu pre ARM platformu. V niektorych pripadoch som skoncil s pripisanim directivy ERROR - a tak som, ktoru z mnohych vnorenych ifdef kompilator vlastne "vykonava". Myslim si, ze java uz od prvopociatku mala snahu eliminovat vsetky potencialne zneuzitelne vlastnosti jazyka - a prave preto sa stala popularnou. Ja osobne som "podmieneny preklad" realizoval 2omi sposobmi. 1, Pre objekty, ktore mozu mat vela roznych nastaveni som vzdy realizoval abstract class a az jeho potomok urcil specificke spravanie sa. Factory metoda poskytovala implementaciu potomka podla nastavenia. 2, V pripadoch, pre ktore naozaj nemalo zmysel implementovat vyssie spominane - napriklad autentifikacny modul pre testovacie ucely, som v ant build scripte jednoducho prekopiroval verzie java suborov zacinajuce na Debug za ich produkcne originaly a bolo...
Čas:19.10.2006 11:30:16
Od:Lukáš
Předmět:Naprostý nesouhlas + 1
Někde tu došlo k naprostému nepochopení. Buď autor článku nepochopil co dělá import v Javě nebo já jsem nepochopil tento článek. Import v Javě jenom usnadňuje zápis. Zjednodušeně říká kompilátoru: "Pokud programátor použije jméno třídy bez jména balíku a ty ho nenajdeš v java.lang, tak se ještě zkus podívat do tohoto balíku, třeba tam ta třída bude." Uses v Pascalu dělá něco naprosto jiného. Pro řešení problému s knihovnami třetích stran existuje přeci jiné řešení. Tím je použití OOP. Pokud se bojím, že se mi se změnou verze změní knihovna tak, že nepůjde použít, zapouzdřím její volání do nějaké své třídy. Hodí se na to design pattern fasáda nebo adaptér. Toto řešení má několik výhod 1) Je to čistě objektové řešení, které funguje, je používáno a vyzkoušeno 2) Může kontrolovat závislosti za běhu! Případný preprocesor se spouští jenom při kompilaci. Neřeší změny nastalé po kompilaci (například nasazení hotové a zkompilované aplikace do jiného prostředí)
Čas:19.10.2006 11:58:46
Od:Cyril Sochor
Předmět:Re: Naprostý nesouhlas + 1
tve reseni ma vice kodu, zvlate o tridu navic, coz v J2ME vadi... ale cistejsi to samozrejme je
Čas:24.10.2006 18:08:58
Od:Artur Linhart
Předmět:Re: Naprostý nesouhlas + 1
Ahoj,
diky za reakci.

Ad ruzna reseni ... Sam jsem reseni, ktere popisujes, uvadel take, nezalezi jak pojmenujeme vzor o ktery se jedna. Dulezite ale je, ze se to neda vyresit jinak, nezli rozdelenim zdrojaku na ty, ktere kompiluju pod jednim prostredim a na ty, ktere pod druhym, nejde to spojit. Vetsinou se totiz jedna jen o male detailiky, kvuli kterym je ale zbytecne velky management.
Napr. pokud mam funkci, ktera v JDK 1.2 byla standardni, v JDK 1.4 nebo 1.5 je deprecated a jeji vyvolani zpusobi chybu protoze uz je nesmyslne (misto JDK se da dosadit libovolna knihovna od Apache atp. ktere vsichni pouzivame) nebo v nove verzi stara funkce vubec neni, nejsem s to napsat kod, ktery by fungoval korektne pro obe dve cilove platformy, popr. ho ani nezkompiluji (pro starou verzi tam nova funkce neni, v nove verzi stara funkce nefunguje spravne).
Jisteze se to da obejit jak jsme psali oba, ale kvuli vyvolani jedne funkce vytvaret dve varianty tridy jen s umele vytazenymi funkcemi, pouzit spravnou tridu do spravneho jaru a nezapomenout na to pouzit ty spravne atp. - vsechno to sice jde, ale je to nezmerne narocnejsi.
Pokud jsem hlupak (nebo genius :-) ), dokazu uz dneska z Javy nadelat krasne nesrozumitelny kod - myslim ze jednoduche IFDEF hierarchie jsou mnohem pochopitelnejsi a prehlednejsi, nez jiz dlouho existujici konstrukty jazyka jakoliv se mi treba osobne libi.

Ad spousteni za behu ... nechci s tim moc polemizovat, ale pokud nechci pouzivat reflexi, tak se vyse uvedenych problemu nezbavim a nejde to tak i onak. Pokud ji pouziju, ztracim vykon, typovou kontrolu a vytvarim mnohem neprehlednejsi kod - nic doc eho by se mi osobne chtelo.

Ad uses v Pascalu ... Mam na to trochu jiny nazor, co jineho je deklarace unit v uses nez urceni "baliku" funkcosti ve kterem se ma dana funkce nebo typ hledat... Pokud se ve vice unitach nachazi ta sama funkce, da se kvalifikovat funkce prave jmenem unity - tzn. princip, ktery se primo pouziva v deklaraci packages v Jave... Ale to je celkem off-topic.
Čas:19.10.2006 16:01:46
Od:Jiří Lepka
Předmět:Pro autora
Mohl byste být prosím kapku specifičtější a blíže specifikovat, u kterých knihoven se Vámi popisovaný problém s kompatibilitou mezi verzemi vyskytnul? (abych se jim do budoucna mohl vyhnout...)
Čas:24.10.2006 18:28:42
Od:Artur Linhart
Předmět:Re: Pro autora
Dobry den,

jedna se o vsechny deprecated metody, ktere uz nemaji smysl v novych verzich, protoze se zmenila filozofie.

Dale mne napadaji optimalizace - clovek neco slozite resil pro stare verze protoze tam funkcnost chybela, kdyz uz tam je a veri autorum ze jsou lepsi, rad by pouzival optimalnejsi novou funkcnost - ale zdroj by mu pak nefungoval na stare platforme, musi tedy budto rezignovat na optimalizace, nebo udrzovat paralelni verze zdrojaku - ani jedno neni dobre.

Mam tedy jen kulisackou odpoved na tu otazku - je to kazda funkcnost, ktera se v dalsi verzi, kterou jeste nezname, objevi na cerne listine "deprecated" bodu :-)
Nicmene na linku, ktery psal Lukas Barton
http://www.javalobby.org/java/forums/t73500.html
se zda, ze se tim problemem zabyvaji trochu vice a o nekterych problemech (predevsim s prevodem "dolu", coz nebyl primarne muj problem) se tam asi lze i vice docist.
Čas:26.10.2006 0:40:11
Od:JIndra
Předmět:Re: Re: Pro autora
Krasnym prikladem je balik java.util.regex (@since 1.4). Je to celkem dobra implementace regularnich vyrazu, ale pokud zrovna tvorite produkt ktery musi bezet i na JDK 1.3, tak ji nemuzete pouzit. Pouzijete tedy jinou implementaci, napr. Jakarta ORO, ale zase se pripravite o plnou podporu regex (napr. podporu locale - tu jsem nenasel u jinych OS implementaci nez u java.util.regex). Stejny problem ceka vsechny novosti v JDK6 (napr. pristup k vlastnostem sitovych rozhrani - vybrat si musite bud nekompatibilityu + nove vlastnosti, nebo kompatibilitu a zadne nove vlastnosti. Takze tak nejak o cem to je - ne jen o deprecated vecech, ale i o novych implementacich.
Čas:19.10.2006 17:09:28
Od:Lukas Barton
Předmět:Stara Java
Obcas muze pomoci nektere problemy s nasazenim na starou Javu vyresit pouziti nastroju jako Retrotransalator nebo Retroweaver (+ Ant nebo Maven). Viz: http://www.javalobby.org/java/forums/t73500.html . Behem pristich mesicu to budu muset pouzit (kus aplikace v Jave 5 musi bezet na Websphere 6.0). Jinak souhlasim s tim, ze prekotny vyvoj verzi je desivy: nasi RCP aplikaci piseme pro Eclipse 3.1 (posledni prelozena do cestiny), aktualni verze je 3.2 (ale jsou v ni nektere bugy, ktere nehodla zatim zda se nikomu nevadi), ale radi bychom pouzivali verzi 3.3, protoze ma mit JFace databinding :-) Podobne je to s Hibernatem, zacali jsme pred mene jak rokem na 3.0, ted pouzivame 3.1.2 (v 3.1.3 jsou kupodivu opet bugy, ktere nam vadi) a aktualni je ted 3.2, ktera ma zase nektere zajimave vlastnosti.
Čas:25.10.2006 18:53:18
Od:Lukáš Bartoň
Předmět:Re: Stara Java
Tak RetroTranslator mi funguje. V antim skriptu jsem si vyextrahoval jsem si z projektu potrebne tridy, zkompiloval, pustil na to retrotranslator, natahnul do noveho projektu jako jar, obalil to java beany a vygeneroval webovou sluzbu, ktera pod WS 6.0 slape bez problemu :-)
Čas:19.10.2006 21:12:11
Od:honza
Předmět:Nesouhlas
Kombinace Java a Preprocesor mi prijde absolutne zvestna. K jave jsem utekl od C/C++ a preprocesor je dle meho nazoru skvela vec, ale prinasi spoustu neprijemnosti. Dovedeno do absurdna s kazdou direktivou preprocesoru vznika nekolik moznych zpusobu prekladu a tedy verzi zdrojaku a to absoutne nici prehlednost a krasu javoveho kodu. Preprocesor do javy nepatri. Jinak s rychlosti vyvoje JDK absolutne souhlasim. Java6 by klidne mohla prijit az za rok ci dva. Java 5 se teprve dostava do main-streamu a java 1.4 je jeste stale hojne pouzivana, jeste je brzo na novou Javu.
Čas:20.10.2006 15:33:39
Od:Kamil
Předmět:Re: Nesouhlas
A nebylo by lepsi zavest do javy nejaky mechanizmus verzovani treba na bazi anotaci a pak cele jdk modularizovat? Ja bych naopak vyvojovy cyklus urychlil, protoze se pak nove ficurky jazyka zacnou pouzivat treba az za 5let, coz je v IT vecnost...
Čas:23.10.2006 17:21:24
Od:Lukas
Předmět:Re: Re: Nesouhlas
Neco takoveho uz prece existuje: http://www.osgi.org/ V Eclipse to funguje velice dobre, uz se tesim, az bude hotove Rich Server Platform ;-)
Čas:26.10.2006 0:49:33
Od:JIndra
Předmět:rozumne reseni asi neni
Nevim nevim, podle me jsou 2 reseni: "preprocesing" pomoci napr. freemarkeru (pak je problem s editorem, je potreba mu vnutit direktivy "preprocesoru"), nebo drzeni kompatibility pouze s posledni jdk (pak je ale problem pri spolupraci / touhou pouzit knihovny/tooly tvurcu kteri nejsou tak rychli jako vy (napr. velke firmy, ktere jsou radi ze dnes nabizeji jakz takz fungujici aplikacni servery, ktere ale bezi na JDK1.4 (a to jen ty lepsi, nektere bezi jen na 1.3 - pokud se nemylim tak IBM WebSphere bezi jen na 1.3). Osobne volim druhou variantu, ale preprocesing jsem taky uz pouzil (prave s freemarkerem), a klidne bych to doporucil i ostatnim. Prece jenom, nikdo nerika ze "jediny spravny" preprocesor muze byt jen ten od sunu primo v jazyce. Kdyz projekt pujde kompilovat jednoduchym zpusobem antem/mavenem, koho zajima ze "uplne zdrojovy" jazyk neni "ta java od sunu"?
Čas:20.11.2006 13:06:37
Od:Lukas
Předmět:Re: rozumne reseni asi neni
Zalezi na verzi Websphere:
6.0 - 1.4
6.1 - 1.5
Diskuzní příspěvky
Jirka naprostý souhlas
Roman Strobl   Zmeny vyvoje javy a nesouhlas
Artur Linhart   Re: Zmeny vyvoje javy a nesouhlas
Martin Kosar   Re: Re: Zmeny vyvoje javy a nesouhlas
Maaartin   Re: Re: Zmeny vyvoje javy a nesouhlas
Cyril Sochor Preprocesor pro J2ME
Artur Linhart   Re: Preprocesor pro J2ME
Richard Naprosty nesouhlas
Peposh   Re: Naprosty nesouhlas - Absolutny suhlas :-D
Lukáš Naprostý nesouhlas + 1
Cyril Sochor   Re: Naprostý nesouhlas + 1
Artur Linhart   Re: Naprostý nesouhlas + 1
Jiří Lepka Pro autora
Artur Linhart   Re: Pro autora
JIndra   Re: Re: Pro autora
Lukas Barton Stara Java
Lukáš Bartoň   Re: Stara Java
honza Nesouhlas
Kamil   Re: Nesouhlas
Lukas   Re: Re: Nesouhlas
JIndra rozumne reseni asi neni
Lukas   Re: rozumne reseni asi neni