NetBeans IDE 6.5 Beta (diskuse)

[Lukas]

nemam problem s rychlosti .... laptop, FS Celsius H250, C2D 7700, 4Gb Ram, 7200ot. disk ani na starsi Sun WS Ultra 20m2, 3Gb Ram, Opteron64 (2core). Porovnani s Eclipse na techto strojich je Netbeans pro me (samozrejme subjektivne ...) o dost rychlejsi. Pokud nekdo ovsem za rychlost aplikace nepovazuje jeji start :)

[Daniel Kvasnička ml.]

Tak start u NetBeans povazuju za o hodne rychlejsi nez u Eclipse. Ale jinak je to peklo.

Vcera jsem NetBeans (6.5M1) pouzival cely den. Kazdou chvili se cele IDE zaseklo a nezbyvalo nez cekat, nez se zase probudi. I jine ukony trvaly uplne neskutecne slouho oproti Eclipse -- hledani resource pres Ctrl+Shift+R (tak je to v E, v NB jsem si to premapoval) a i hledani nad celym projektem podle obsahu souboru -- to se absolutne neda srovnat. Radsi ani nechci videt, jak by NB hledal nad projektem, ktery mame v praci... to bych si mohl zajit na obed...

Eclipse na stejnem stroji s pluginy, ktere funkcnosti prevysuji full verzi NB 6.5 Beta, je neporovnatelne rychlejsi (nehlede na to, ze je vizualne lepe integrovane do systemu). Tot moje zkusenosti. (Navic podpora SVN je opravdu jeste v plenkach oproti Subclipse a Subversive a ta editace PHP je taky jeste spis takove "preview" )

Ale dopredu se vyvoj hybe, to se musi nechat.

[Lukas]

jen konstatuji jak je to u me :) subversion plugin nepouzivam, takze nemohu hodnotit. NB pouzivam pouze na Javu a nic jineho, takze ostatni take nehodnotim (PHP, Ruby, C/C++ ...) Jedine co me drzi pri myslence na Eclipse je QT Integration plugin. Bohuzel jsem jeste nemel casu to vyzkouset (Budu muset sestavti eclipse pro solaris x86 pro S10).

[BlackShark]

Já používám 6.5M1 od jeho prvního uvedení (build 200807070101). Používám ho každý den celou pracovní dobu (Vývoj J2EE aplikací) a šlape mi to jako hodinky (na Linuxu). Popisované zadrhávání jsem taky zažil, ale na 6.1 beta. Start aplikace je pomalý, ale pouštím ho jen ráno . S rychlostí GUI problém taktéž nemám. SVN plugin používám také od samých počátků a problém se mi objevil zatím jen jednou, kdy NB nenastartovaly, dokud jsem nesmazal všechny .svn adresáře v projektu. Tuším, ale že to bylo ještě na 6.1.

Toliko pro změnu moje zkušenost s NB.

[Daniel Kvasnička ml.]

No na J2EE jsem ho radsi jeste ani nezkousel pouzivat, kdyz jsem videl, jake problemy ma s nacitanim kontextove napovedy a nazvu fci/trid pro PHP At zije Eclipse a WTP

[Ladicek]

WTP? Už je to vůbec schopné editovat průměrné JSPčko bez hlášení milionů chyb způsobených neschopností parsovat HTML + JSP dohromady? Nemluvě o redeployi aplikace přes pohled Servers, který bylo potřeba dělat tak natřikrát, než si toho Eclipse všiml? Ach, kde jsou ty doby, kdy jsem ještě JSP používal…

[Daniel Kvasnička ml.]

Už je to vůbec schopné editovat průměrné JSPčko bez hlášení milionů chyb způsobených neschopností parsovat HTML + JSP dohromady?

S tim problemy nemam. Mozna je to zpusobeno tim, ze vubec nepouzivam tu puvodni syntaxi JSP a vsechny moje JSPcka jsou validni XML.

Nemluvě o redeployi aplikace přes pohled Servers, který bylo potřeba dělat tak natřikrát, než si toho Eclipse všiml?

?... nevim o cem mluvite Ulozim JSP, vterina dve, je to tam

[Ladicek]

Jo, hot redeploy fungoval. Ale když došlo ke strukturální změně a bylo potřeba redeploynout celou aplikaci, tak to nějak blblo. Ale to už je tak půl roku zpátky, kdy jsem se na to naposled koukal.

[Petr Adámek]

Já NetBeans použávám na Java EE už pěkně dlouho a jsem velmi spokojen. Hodnotit kvalitu a rychlost celého nástroje podle modulu, který je úplně nový a nepříliš odladěný, mi nepřijde jako příliš spravedlivé.

[Daniel Kvasnička ml.]

Na J2EE jsem ho samozrejme taky zkousel. Pripadlo mi proste neohrabane, oproti Eclipse. (neohrabanym nemyslim ted nutne pomale v kazdem ohledu, proste asi moc jine pro cloveka, ktery si na Eclipse opravdu hodne zvykl...)

[Sid]

povedal by som ze proste ste Eclipse pozitivny clovek co hodnoti IDE podla toho ako rychlo vyhladava v suboroch, sorry ale pre mna smiesne

[Deleted [8409]]

Jenže ono ta rychlost celkem zdržuje.

Mám eclipse a používám pydev (python) a aptana (js) a můžu říct, že už jsem měl 100 chutí začít používat nějaký lepší poznámkový blok.

Zdrojáky mají tak okolo 1000 až 2000 řádků na soubor. Já musím čekat například když chci něco smazat. Zmáčku backspace a nevidím jak se to maže, musím ho pustit abych viděl kde jsem. To samé například při Ctrl+šipka nahoru/dolů (tak 2 řádky/s). Jako líbí se mi ty nástroje, ale je to fakt příšerně pomalé. O css editoru bych se radši ani nebavil:)

Teď s novou verzí aptana se to hodně zlepšilo, ale pořád to není ono.

mám 1.6GHz procesor a 1GB ram, což by snad na vývoj mělo stačit:)

[Daniel Kvasnička ml.]

Souhlas, Aptana je fakt lina. Jenze lepsi CSS & JS editor pro Eclipse neni

[Daniel Kvasnička ml.]

Sorry, ale tohle je bezny ukon, u ktereho je pro me nemyslitelne, aby trval tak smesne dlouho jako u NetBeans.

[Sid]

Bezny? hm... neviem ako vy pre mna je vyhladavanie v suboroch bezne ak dostanem do ruk cudzi kod a musim robit udrzbu a na zaciatku je to same find, find, find ... Ale beriem ze mozno mate projekt kde musite v kuse hladat nejake veci a potom by ta pomalost bola pre vas klucova. Moj pohlad na vec a vacsie projekty je : - ako dobre dokaze pracovat s projektom ktory nebol vytvoreny v IDE - tj. sami si vytvorite buildovacie skripty (ci uz ant alebo maven) pretoze to co vychrli zo seba IDE je dobre na one man show. - praca s VCS - refactoring - kvalitny editor - GUI editor

a obecne ohladom rychlosti - niekedy mi to pride ze zopar jedincov by potrebovalo k IDE rovno Deep Thought . Keby ich nezdrzoval editor,...,....,atd tak naozaj by z nich siel kod rychlostou 1000 riadkov za sekundu, take fantasticke veci by napisali ale nemozu, nemaju dostatocne rychle IDE

[Daniel Kvasnička ml.]

Ja jsem mluvil hlavne o tom, co Eclipse dela pri Ctrl+Shift+R/T. To je absolutni zaklad u velkeho projektu... Nebudu jak sasek litat v package exploreru nebo navigatoru a hledat kde to je, kdyz muzu napsat par prvnich pismenek a stisknout enter. NetBeans ma tuhle vec zoufale pomalou a to proste rapidne snizuje produktivitu.

[Ladicek]

Mimochodem, už umí Eclipse CamelCase zkratky? Tzn. když hledám třídu MyBloodyHorribleClass, stačí napsat MBHC, u často používaných tříd to člověku za chvilku přejde do krve a je to obrovské urychlení.

[Daniel Kvasnička ml.]

Umi, ale zjistil jsem to az diky vasemu komentari

[Ladicek]

Paráda, když jsem to zkoušel naposled, splakal jsem nad výdělkem

[Sid]

este jedna doplnujuca otazka, co je pre vas velky projekt? nech je jasne ci sa bavime v rovnakych dimenziach

[Daniel Kvasnička ml.]

Uz od stovek trid si zivot bez takove veci nedokazu prestavit.

[Sid]

A to ste mal s Netbeans problem pri stovkach tried? Sorry ale kazdopadne si myslim ze bud je problem s tym ako ho pouzivate alebo chcete vidiet len cierno/bielo (milujem Eclipse Netbeans su shit a naopak pripadne) - mozem vas uistit ze som pouzival netbeans 5.5 a potom vyvojove verzie 6 na projektoch ktore mali niekolko tisic tried, mozna desatice (nikdy som to nezistoval, bolo to automaticky generovane pre SNMP)

[Daniel Kvasnička ml.]

Zkousel jsem si to ted na Java SE projektu s neco malo pres 300 trid a ten rozdil byl jasne postrehnutelny. Nebyla to zadna katastrofa, ale kdyz je takovych "malickosti" vice (namatkou vytvareni a mazani Java projektu -- co mu na tom trva tak dlouho?), tak to k celkovemu pojmu o sviznosti vubec neprispiva...

NetBeans rozhodne nezavrhuji. Nepovazuju ho za spatne IDE, jen ho kritizuju tam, kde si osobne myslim, ze ma rezervy...

[freshmouse]

Hmm, nějaké IDE (konkrétně Eclipse) používám asi dva, možná tři měsíce a jeho jediný přínos vidím v tom, že se tam dá hezky spouštět JBoss a Apache Ant. Samotná editace textu nic moc a dalších výhod to moc nemá. Dosud jsem např. nenašel nic, co by způsobilo zalamování řádků, pokud se nevejdou na obrazovku (konkrétně tato vlastnost mě ubíjí nejvíc)...

Jsem již téměř rozhodnut nahradit to všechno Geditem (nebo Vimem) a GNOME Terminalem.

[freshmouse]

Ke kladům Eclipse ještě řadím spolupráci s CVS.

[sid]

No a ja zase radim CVS ke kladum NetBeans.

[freshmouse]

Já myslel obecně spolupráci IDE s CVS.

[Ladicek]

Takové věci jako (v Eclipse tuším) Ctrl+Space nebo Alt+Shift+R nebo Ctrl+Shift+T znáš? A to jsou jenom ty nejtriviálnější věci, na které jsem si jako IntelliJ IDEA zelót vzpomněl

Zalamování řádek ve vývojovém prostředí nemá smysl, nebo snad váš coding style připouští řádky dlouhé 200 znaků?

[freshmouse]

Takové věci jako (v Eclipse tuším) Ctrl+Space nebo Alt+Shift+R nebo Ctrl+Shift+T znáš? A to jsou jenom ty nejtriviálnější věci, na které jsem si jako IntelliJ IDEA zelót vzpomněl

Nejsou to ty funkce, co ti přeformátují zdroják? Ty jsem použil jednou -- omylem.

Zalamování řádek ve vývojovém prostředí nemá smysl, nebo snad váš coding style připouští řádky dlouhé 200 znaků?

Smysl to u mě má.

Nejedná se jen o *.java; třeba jsem dělal na nějakém *.properties, kde byly hodnotou dlouhé řetězce... Bylo to peklo.

Ale i v *.java zalamuji (pomocí Enter) jen tam, kde to má logický smysl -- nikdy kvůli tomu, že e mi to nevejde na obrazovku, to má být věcí editoru.

[Ladicek]

Nejsou to ty funkce, co ti přeformátují zdroják? Ty jsem použil jednou -- omylem.

Ne, to je doplňování identifikátorů, přejmenování a navigace podle tříd. Extrémně užitečné nástroje.

Nejedná se jen o *.java; třeba jsem dělal na nějakém *.properties, kde byly hodnotou dlouhé řetězce... Bylo to peklo.

Lomítko. Co víc k tomu říct, kromě toho, že standardní resource bundle (tedy ten, který smí být jen v iso-8859-1) je ohromně nepoužitelný hnus. Jo, a kvalitní IDE mají na editaci bundlů specializované nástroje

Ale i v *.java zalamuji (pomocí Enter) jen tam, kde to má logický smysl -- nikdy kvůli tomu, že e mi to nevejde na obrazovku, to má být věcí editoru.

V Javě má odřádkování smysl prakticky po každém středníku, a leckdy ještě prázdný řádek navíc. To prostě není běžný text, nečte se tak a taky se tak nepíše. Ale možná, že v tomhle ohledu mám trošku deformující návyk Mimochodem leckteré jazyky umožňují odřádkováním i ukončit příkaz a středníku se úplně vyhnout (a nemluvím o Pythonu, spíš třeba o Groovy).

[freshmouse]

Ne, to je doplňování identifikátorů, přejmenování a navigace podle tříd. Extrémně užitečné nástroje.

Ctrl+Mezerník jsem přehlédl; tuto funkci samozřejmě používám. Ale nepovažuji ji za nějak výjimečnou.

Lomítko. Co víc k tomu říct, kromě toho, že standardní resource bundle (tedy ten, který smí být jen v iso-8859-1) je ohromně nepoužitelný hnus. Jo, a kvalitní IDE mají na editaci bundlů specializované nástroje

Lomítka mě tam zbytečně ruší. Navíc to chci mít opravdu na jedné řádce, jiank by to bylo nepřehledné.

Eclipse má na *.properties jakýsi nástroj, co převádí ne-ASCII znaky na nějaké sekvence znaků.

V Javě má odřádkování smysl prakticky po každém středníku, a leckdy ještě prázdný řádek navíc. To prostě není běžný text, nečte se tak a taky se tak nepíše. Ale možná, že v tomhle ohledu mám trošku deformující návyk Mimochodem leckteré jazyky umožňují odřádkováním i ukončit příkaz a středníku se úplně vyhnout (a nemluvím o Pythonu, spíš třeba o Groovy).

Ano, v 99 % zalamuji po každém středníku.

[Daniel Kvasnička ml.]

Ctrl+Mezerník jsem přehlédl; tuto funkci samozřejmě používám. Ale nepovažuji ji za nějak výjimečnou.

To myslis jako konkretne tuhle zkratku nebo obecne napovedu v kodu? To te bavi neustale civet do JavaDocu nebo si pamatovat veskere metody a properties tvych trid?

[freshmouse]

Myslel jsem napovídání kódu obecně. Mám dojem, že to umí i nějaký modul pro Gedit, takže to asi nebude tak výjimečná funkce...

[Daniel Kvasnička ml.]

To jsem zvedav. Pochybuju, ze pro Gedit bude plugin, ktery zajisti code assist pro Javu na urovni Eclipse.

[freshmouse]

Já o tom taky pochybuju, ale základní funkčnost by to asi mělo umět...

[petr]

Ve vimu doplnovani metod trid, polozek struktur atd. je. Alespon pro c++, v jave nedelam.

[Daniel Kvasnička ml.]

Ale i v *.java zalamuji (pomocí Enter) jen tam, kde to má logický smysl -- nikdy kvůli tomu, že e mi to nevejde na obrazovku, to má být věcí editoru.

To prave ze nema To je veci coding style. Kod ma limit na urcitou delku radku a at se otevre kdekoliv, musi vypadat stejne, co se tyka delky radku a mista zalomeni -- at uz to editor umi nebo ne.

Pouzivej Checkstyle plugin do Eclipse, ten te bude kvuli takovym vecem hezky otravovat

[freshmouse]

V práci mám monitor s 22" a nevidím důvod se tam patlat jen s nějakými 80 znaky na řádek. Kdo má menší monitor, kód se mu sám zformátuje dle potřeby. Tohle je zdroják a ne žádný device independent dokument...

A jak někdo řekl dole, jde např. i o formátování HTML.

[Daniel Kvasnička ml.]

Kdo má menší monitor, kód se mu sám zformátuje dle potřeby.

Ale jak? Jak zajistis, ze kazdy editor bude umet dobre zalomit zdrojak v Jave tak, aby byl rozumne citelny? Jak uz nekdo zminil, pres 200 znaku radku by kod jit nemel.

A jak někdo řekl dole, jde např. i o formátování HTML.

Nevim jak HTML, ale XML umi Eclipse velice dobre zformatovat tak, aby bylo dobre citelne nezavisle na tom, v jak schopnem editoru ho otevres.

[Ladicek]

200 znaků jsem plácnul jako nesmyslně vysoké číslo Osobně používám limit 100 znaků a vím o firmě, kde mají limit 120 (ale to nejsou javisti ), dál už bych fakt nešel.

[Daniel Kvasnička ml.]

Ja mam pocit, ze my v praci mame Checkstyle nastaveny na 200.. ale je fakt, ze to je asi moc.

[freshmouse]

Ale jak? Jak zajistis, ze kazdy editor bude umet dobre zalomit zdrojak v Jave tak, aby byl rozumne citelny? Jak uz nekdo zminil, pres 200 znaku radku by kod jit nemel.

A jak zajistím, aby každý editor uměl Unicode? Jak zajistím, aby každý editor správně zvýrazňoval syntaxi? Atd.

To asi nijak nezajistím, ale předpokládám to na takové úrovni, že jsem si tím dokonce skoro jistý.

Nevim jak HTML, ale XML umi Eclipse velice dobre zformatovat tak, aby bylo dobre citelne nezavisle na tom, v jak schopnem editoru ho otevres.

Já si chci XML nebo HTML formátovat sám, na to snad ani není třeba IDE (i když jsou chvíle, kdy je potřeba nechat dokument nechat automaticky zformátovat -- např. pokud člověk dostane XML, které má nějak "zkomprimované" bílé znaky atd.). Jediné, co potřebuji, je automatické odsazování.

Když ale píšu např.:

[ul]
  [li]Dlouhý, dlouhý, dlouhý, dlouhý, dlouhý, dlouhý, dlouhý, dlouhý, dlouhý text[/li]
[/ul]

... tak nevidím důvod, proč by to editor neměl zobrazit zalomené (představte si tam správné závorky).

[Daniel Kvasnička ml.]

Ja kdyz pisu markup, snazim se o toto:

[ul]
  [li]
    Dlouhý, dlouhý, dlouhý, dlouhý, 
    dlouhý, dlouhý, dlouhý, dlouhý, 
    dlouhý text
  [/li]
[/ul]

Eclipse treba umi XML a jeho dialekty takto pekne zformatovat. Editor, ktery to proste zalomi, to tak hezky neudela. Videl bych tak, ze by to skoncilo asi nasledovne:

[ul]
  [li]Dlouhý, dlouhý, dlouhý, dlouhý, dlouhý, dlouhý, dlouhý, | zalomeni
dlouhý, dlouhý text[/li]
[/ul]

...a to teda opravdu nechci. I kdyby ten druhy radek byl automaticky odsazen na uroven oteviraciho [li], je to pro me mene prehledne nez to prvni. Proste a jednoduse, kdyz si to zformatujes sam na nejakou rozumnou delku radku, mas jistotu, ze to bude vypadat vsude stejne.

[PaJaSoft]

Jen jestli Vam prilis nevadi, ze oba zapisy ze semantickeho hlediska znamenaji neco jineho a mozna Vam to jednou bude desne vadit, kdyz se budete vztekat nad renderingem...:-r

[Daniel Kvasnička ml.]

Tak to bych rad znal ten semanticky rozdil

[xsubway]

80 znaků je (i pro mě) málo, ale jakmile délka řádku přesáhne 120 začíná být kód pro člověka pohodlně. A "device independent" dokument se hodí, pokud nevíš, kdo na ten zdroják sáhne po tobě. Podobně: tab vs space nebo psaní závorek, apod. Nakonec je nejdůležitější mít stejná pravidla pro celý projekt ... jasně: každý si v těch pravidlech najde něco, na co může při každé příležitosti nadávat. Jen na okraj: nejsem zastáncem programovacích jazyků typu Argh! nebo Python, ve kterých skutečně záleží na formátování

[xsubway]

"... pro člověka pohodlně čítelný."

[freshmouse]

Stejně, jako používám tabulátory namísto mezer proto, aby si každý mohl nastavit, jak velké odsazení chce, až na logické formátování (tělo podmínky odsazeno atp.) kód nijak neformátuji. Ať si každý nastaví svůj editor dle potřeb.

[Petr D.]

Ahoj!

Mrkni se sem: http://qa.netbeans.org/issues/show_bug.cgi?id=89894

Aneb: kdyz pouzivas NetBeans a neco pekneho tam chces (pripadne Ti neco vadi), zadej RFE nebo hlasuj pro issue, v tomto pripade jiz existujici a velmi casto zadanou... Od toho je to preci open-source, ne? ;) Pomoct muze kazdy...

Mimochodem - zalamovani radku je velmi uzitecne pro (X)HTML nebo PHP - vim ze zkusenosti...

S pozdravem,

Petr Dvorak

[Daniel Kvasnička ml.]

jediný přínos vidím v tom, že se tam dá hezky spouštět JBoss a Apache Ant. Samotná editace textu nic moc a dalších výhod to moc nemá.

Refaktoring a kontrola kodu nic? To jako budes psat Javu v Geditu a cekat na hlaseni chyb az na kompilaci? A importy si budes psat taky rucne (viz Ctrl+1 nad neimportovanou tridou v Java zdrojaku)?

[Sid]

asi to pre vas bude sok ale naozaj sa tak pracuje, skuste obcas zostupit zo sveta klik,klik projektov a zistite ze naozaj obcas je dolezite hlavne to aky dobry je editor. Spravu kodu robite rucne cez command line, buildovanie tiez.

[Ladicek]

Jak správně podotkl Martijn Dashorst na mailing listu Wicketu,

You *really*, *really*, *REALLY* should use an IDE. There is absolutely *no* reason not to use one.

Jasně, jsou lidi, co ve vimku dělí všechna čísla v souboru deseti, ale to je lehce úchylárna

[Sid]

ale jasne IDE je skvele ale obcas nie je vseliek - casto totiz vas IDE nuti robit veci len jednym smerom a zdrojaky mat napr v urcenej podobe - ked nemate, tak smola ziadne zazraky nebudu (zrovna napr netbeans a navrh Swing Application Framework - ked nemate resources tam kde chce IDE mate smolu a ziadna GUI editacia nebude) V tom pripade sa vam IDE zredukuje na zvyraznovanie syntaxe, doplnanie kodu, pripadne refactoring. A teraz si predstavte ze napr mate strom ale nemozete menit v nom vsetko, pretoze napr niektora cast kodu je absolutne mimo vas a zrovna mozete zabudunut aj na sen o refactoringu v ramci celeho stromu. Staci ze napr pristupove prava na urcite casti ma vas kolega v nemecku a on zase potrebuje nejaky kod z USA atd.

[Daniel Kvasnička ml.]

V prvni rade je uchylne definovat GUI v programovacim jazyku. Ty editory GUI pro Swing, co vygeneruji Java kod, to bych nemohl pouzivat. Zlate Qt XML UI, XRC a podobne. Pro Swing taky par takovych veci je.

[Sid]

ved hej, ked pouzivate eclipse sa ani necudujem

[Sid]

a za druhe to s GUI bol len priklad - ci vy nemate skusenost ze vas IDE prinutilo mat projekt v nejakej presnej podobe a ked nebol tak ste mal smolu?

[Ladicek]

Ale jo, různé automatické nástroje vyžadují dodržování různých pravidel. Nejde jenom o IDE, ale třeba Maven a určitě se najdou i další. Má to svoje klady, ale háže to člověku klacky pod nohy při věcech, se kterými autor automatu nepočítal (generování kódu skriptem apod.). Vždycky je to holt něco za něco.

[petr]

Zkuste si v nejakem IDE otevrit treba jadro linuxu. Je to *really*, *really*, *REALLY* pomale.

[Ladicek]

Opravdu? No, to jsou teda céčkovská IDE docela mizerná, ale spíš bych tipoval, že bohapustě kecáte Ale mně to je celkem jedno, a ostatně celá diskuse je o javovském IDE.

[Daniel Kvasnička ml.]

omg... vy snad patrite mezi ty lidi, co si mysli, ze kdyz nepouzivaji IDE, tak jsou drsni programatori... Prave IDE je to, co vam diky automatizaci nudnych veci dovoli soustredit se na to, o co u programovani opravdu jde. Takze ano, ja si klidne budu delat klik, klik, kdyz mi to pomuze ulehcit nejakou rutinni cinnost.

[Sid]

Neviem kde ste na to prisiel : iba akurat som vam chcel povedat ze svet nekonci pri tom ze klikate v gui, keby to zalezalo len na mne tak s radostou vyuzijem vzdy IDE. Vy sa pozerate na to z pohladu vsetko mam pod kontrolou, zdrojaky na jednom mieste, vsetko mozem ovplyvnit - skuste sa pozriet na nejaku naozaj velku firmu a projekty a uvidite ze to bohuzial tak naozaj nefunguje vzdy.

[freshmouse]

Refaktoring jsme jednou (v Eclipse) zkusili, ale stejně jsme si to museli ještě zrefaktorovat sami. Psaní importů je pro mě velmi rychlé a nevadí mi.

Pro korektnost ale udávám, že jsem se ještě neúčastnil opravdu velkých projektů.