Rozšíření Visual Studio Code "Language Support for Java(TM) by Red Hat" dospělo do verze 1.0

Rozšíření Visual Studio Code "Language Support for Java(TM) by Red Hat" dospělo do verze 1.0. Přehled novinek s náhledy a videi v příspěvku na blogu.

22.10. 19:00 | Ladislav Hagara | Nová verze

Komentáře

[nadtržítko]

Co je to za anarchie? Javaci vzdyt kodi v editoru napsanem v jave. Ceckari v editoru napsanem v cecku. VS Code je pro javascript/typescript ne?

[ondra05]

Proč by tomu tak bylo? Např. pro Rust je VSCode nejpopulárnější (a poté myslím CLion/Idea).

[marmax]

jo, s tim se da i souhlasit :D

na druhou stranu, jakozto javistovi, je mi u zadele, ve kterem jazyce je moje IDE napsano, nicmene - kam se hrabe VSCode (coz povazuji stale za dost obycejny editor) na Jetbrains IDEA nebo Eclipse - sprava projektu, navigace v kodu atd. Ted navic zkousim VSCode misto Sublime a trpim a trpim...

[ondra05]

No, tak Java je tolik boilerplatu a překomplikovaných buildsystémů že to bez těžkotonážních IDE ani nejde.

[marmax]

ale no tak... u velkeho projektu clovek potrebuje kvalitni navigaci pres kod, hinty atd.

java samozrejme ma boilerplate codu mnoho, ale bavime se dnes u javisty asi obecne o libovolnem java based jazyce :P a build system?

Pokud nekdo stale jede na Mavenu, jeho chyba, davno uz tu je gradle, ktery toho udela vyrazne vic, v pohode jsem v nem spravoval multilanguage projekty (java, javascript, actionscript, C & C++) a jelo to vic nez v pohode...

[Bystroushaak]

Pokud nekdo stale jede na Mavenu, jeho chyba, davno uz tu je gradle, ktery toho udela vyrazne vic, v pohode jsem v nem spravoval multilanguage projekty (java, javascript, actionscript, C & C++) a jelo to vic nez v pohode...

+1, jako já z gradle nadšený úplně nebyl, protože ho v práci používáme na python, docker kontejnery a úplně všechno, ale zpětně musím říct, že asi neznám jinou podobně schopnou alternativu.

[Bystroushaak]

No, tak Java je tolik boilerplatu a překomplikovaných buildsystémů že to bez těžkotonážních IDE ani nejde.

Haha, vtip je právě v tom že není těžkotonážní. Já jsem kdysi přešel z VS code na pycharm právě ve chvíli, kdy jsem seděl v hospodě na srazu bývalých uložťáků a řešili jsme kolik komu žere paměti editor. Když mi řekli, že jejich nenažraný PyCharm žere až dva gigabajty, jako by se za to styděli, tak jsem se styděl já, protože mi ve VS code přestalo stačit 20GB paměti (se zaplým python doplňkem od MS). Když jsem si pak přečetl manuál (resp. knížku), tak mi došlo že doslova nemá smysl zabíjet čas s VS code, protože refactoring a všechno ostatní je někde úplně jinde.

[Heron]

Tve co s tím VSCode všichni děláte? Mám ve workspace otevřené svoje aktivní projekty (tj něco jako 8) v různých jazycích (golang, python, java) a mimo to jej používám "prostě jako notepad" - kdykoliv potřebuju napsat poznámku, zapnu vscode, new file a píšu. Start trvá 2.5s (měřeno ručně na stopkách). Hromada pluginů včetně MS Python, koukám i Jupyter, který teda nepoužívám. Na pracovním ntb s 16GB ram a třema virtuálkama se na 20GB pro vscode jen těžko dostanu. Aktuálně papá 200MB (na ansible playbooku).

Když jsem si pak přečetl manuál (resp. knížku), tak mi došlo že doslova nemá smysl zabíjet čas s VS code, protože refactoring a všechno ostatní je někde úplně jinde.

Jo, já asi taky s golangem potáhnu jinam, protože ve vscode je podpora refaktoringu taková .... na počátku. Když to u extract function automaticky pojmenuje newFunction a následně je nutné provést refactor rename ... jako už někdy v pravěku Eclipse umělo udělat extract a vyskočilo okno pro pojmenování nové func.

[Bystroushaak]

Tve co s tím VSCode všichni děláte? Mám ve workspace otevřené svoje aktivní projekty (tj něco jako 8) v různých jazycích (golang, python, java) a mimo to jej používám "prostě jako notepad" - kdykoliv potřebuju napsat poznámku, zapnu vscode, new file a píšu. Start trvá 2.5s (měřeno ručně na stopkách). Hromada pluginů včetně MS Python, koukám i Jupyter, který teda nepoužívám. Na pracovním ntb s 16GB ram a třema virtuálkama se na 20GB pro vscode jen těžko dostanu. Aktuálně papá 200MB (na ansible playbooku).

Je to víc jak rok zpátky, tak to třeba zoptimalizovali. Ale obecně prostě pracovní projekty, když to má pár desítek tisíc řádek, tak se tomu nedivím (všechno to indexuje a snaží se odvodit typy).

Jo, já asi taky s golangem potáhnu jinam, protože ve vscode je podpora refaktoringu taková .... na počátku. Když to u extract function automaticky pojmenuje newFunction a následně je nutné provést refactor rename ... jako už někdy v pravěku Eclipse umělo udělat extract a vyskočilo okno pro pojmenování nové func.

Jo. Jakmile má člověk jednou IDE, které efektivně zvládne refactorovat kód, tak už jde jen velmi těžko jít zpět. Takové ty věci jako "z tohohle udělej metodu", "tyhle věci přenes do jiného modulu a uprav všechny reference", "změň pořadí parametrů", nebo "z těhle deseti parametrů udělej konfigurační objekt". Přejmenování a vyhledávání použití a deklarací mi přijde jako samozřejmost, to afaik umí i to VSCode, i když se občas úplně nechytá a na něco zapomene.

Ono ve VSCode nějaká podpora byla (přes rope doplněk? dneska už je to koukám přímo v tom pythonním), ale člověk se na to nemohl moc spolehnout. V PyCharmu prostě beru refactoring jako běžnou součást editace, stejně jako třeba smazání řádky.

[sid]

urban myth. Staci sa pozriet na build nejakeho velkeho projektu v C++ ktory bezi napr medzi Windows a Linux a niecim embedded a potom poznas prave peklo :). Povacsine najviac somru ludia ktori maju problem pochopit hocico takze ked uz je pre nich problem maven tak je lepsie snad aby ani neskusali programovat. Nemoze to dobre dopadnut.

[Olaf]

Zdar. Sublime jsem používal místo VSC hodně dlouho a vždy jsem se bránil přechodu na VSC, resp. vždy jsem podvědomě otevíral projekty v Sublime. Můžu se zeptat, v čem je pro tebe Sublime lepší než VSC? Vůbec to nemyslím špatně, jen se ptám, protože jsem se přistihl, že posledních pár měsíců píšu ve VSC. Ani nevím, jak k tomu došlo. :o) Jo, JetBrains je hodně powerful, ale prostě se mi nelíbí editor. Něco mi na tom všem tam prostě vadí...

[marmax]

Tak zatim mi vadi primarne dve veci:

• brutalne pomale nacitani velkych (vetsich) souboru ve vscode, obzvlaste, pokud to ma nejak parsovat kvuli highligtingu apod. (napr. json data)
• jiny shortcut set, nez jaky jsem potkaval u ruznych editoru (klidne i na windows platforme) - napr. duplikace radky je bezne pod CTRL+D, ale ne, vscode to proste musi mit jinak :D

Nerikam, ze si nezvyknu, ale zatim fakt nejsem spokojen.
Navic, a to byl hlavni point, pro me to je porad "jen" editor s nejakym lehkym supportem a imho nema cenu to srovnavat s plne vybavenym/zamerenym IDE

[Bystroushaak]

jiny shortcut set, nez jaky jsem potkaval u ruznych editoru (klidne i na windows platforme) - napr. duplikace radky je bezne pod CTRL+D, ale ne, vscode to proste musi mit jinak :D

Tohle se dá nakonfigurovat, já to měl ve VSCode stejné jako v Sublime.

[Olaf]

Dík. No, mi spíše šlo o to, že VSC máš za pouhý editor, a zároveň používáš Sublime, takže mi z toho vyplývalo, že Sublime umí něco zásadního, co neumí VSC. :o)

Jo, Sublime je rychlejší, to je pravda. Zkratky -- alespoň pod macos -- jsou ale stejné, ne? Právě ten výběr slov u mě funguje stejně v obou prostředích. Ale možná myslíme něco jiného. Zdar.

[kralyk z abclinuxu]

Jo, JetBrains je hodně powerful, ale prostě se mi nelíbí editor. Něco mi na tom všem tam prostě vadí...

Mam to stejně. To prostředí toho umí opravdu hodně a funkce jsou na velmu dobré úrovni, ale přijde mi, že editor a navigátor struktury mají brutálně nepraktické ovládání.

[Bystroushaak]

Ale všechno je to konfigurovatelné na přibližně stejné úrovni, jako v tom Sublime / VSCode. Akorát na to nemáš JSON, musíš to naklikat (bleje to někam na disk XML, ale celkově není úplně jednoduché to editovat, není to jediný soubor).

Osobně mi trvalo pár týdnů, než jsem si to všechno doladil na tu samou úroveň, ale je to tradeoff, který se člověk určitě vyplatí udělat. Ač jsem byl dřív hodně proti tomu modelu, že člověk používá IDE na všechno, a používal jsem editor + deset terminálů, tak teď prostě všechno dělám z Ideii (bavím se o pythonu). Včetně integrace s gradle, kubernetem (tam teda dost používám ten k9s co jsi mi poradil separátně v terminálu, ale ta integrace přímo v IDE je super), databáze, a tak dál.

[kralyk z abclinuxu]

To není o konfiguraci, spíš o limitacích a design choices toho UI... Což třeba VSCode má taky, např. si tady někdo stěžoval, že si nemůže dát dva sidebary vedle sebe (AFAIK to fakt nejde). Je to asi jen o tom, že u toho VSCode mi ty limitace/rozhodnutí vadí míň...

[Bystroushaak]

Těžko říct co myslíš, přijde mi že Idea / PyCharm se dají co se UI týče konfigurovat jak chceš. Jakože doslova každý sidebar si můžeš vybrat z X chování (Dock pinned, Dock unpinned, Undock, Float, Window), přemístit kam chceš, nebo úplně vyhodit. Co se týče vzhledu a tak dál, tak to všechno je konfigurovatelné, třeba téma používám Sunburst jako v Sublime. Ale obecně u každého dialogu se dá volit pokokot věcí. Třeba před asi rokem zavedli nové commit window, které je nějak integrované, ale stále můžeš používat separátní commit window jak bylo možné předtím, což mi vyhovuje.

[kralyk z abclinuxu]

Já si nedělal nějaký poznámky, takže jen z hlavy pár věci:

Nenašel jsem dobrý UI nastavení pro přehled nad otevřenejma editorama. Celkem dost nemam rád taby, ve VSCode mam na levé straně vertikální seznam. Něco podobnýho v Idee jde, ale ten seznam je mimo ten běžnej sidebar a zvlášť pro každou skupinu editorů (ie. při vertikálním rozdělení na dvě skupiny každá dostane svůj seznam souborů), takže to zabíra nesmyslně obrovský množství místa.

U stromu souborů mi vadí široký indenty, takže zanořenější struktura se moc nemá šanci na šířku vejít.

Fajn věc ve VSCode je, že dost věcí jako třeba výsledky hledání, git diffy, markdown preview apod. to vede v UI stejným způsobem jako editor buffer, takže do/z toho můžu navigovat stejným způsobem, stejně to přesouvat mezi skupinama, zvětšovat/změnšovat, zavírat atd.

Nic z těch asi není nějak drasticky nepřekonatelný (asi bych se to prostě nějak přeučil, naučil se tolerovat taby a tak), ale VSCode má celkem dobrou podporu pro Rust, takže nemám kdovíjak velkou motivaci...

[Bystroushaak]

Jako nechci si to tady celé dojebat, ale přijde mi že všechno tohle to umí, jen se to musí pozapínat a případně vygooglit. Třeba na ten indent je option na menší indent. Git diffy právě mám v separátním okně, a taky je to nějak konfigurovatelné, ale právě ten nový styl to nějak hází do sidebaru, odkud by se to mělo nechat dát nastavit třeba jako celé okno, ale asi ne jako tab prostě jako soubor.

[kralyk z abclinuxu]

Jo, ten indent jde, to jsem si negoogloval, ale jinak ty ostatní věci dost jo... Nvm, spíš by to chtělo si porovnat ty CLion code a debugging featury s Rust Analyzerem, jestli to je natolik lepší, aby se vyplatilo kvůli tomu ohýbat to UI, psát si UI téma (což bych asi musel) a tak...

[Kate]

Co tak porovnávám s kolegy, je to dost vyrovnané. Něco má lepší RA, něco má lepší CLion. Alespoň co jsem koukala naposledy, největší bolest obou byl autocomplete kódu generovaného z procedurálních maker.

[kralyk z abclinuxu]

Zkusil jsem pokusně trial CLionu na akutálním projektu. Přijde mi, že ten code model je o něco lepší.

Taky jsem zjistil, že nedávno někdo vytvořil plugin na ovládání těch splitterů podobně, jako to umí VSCode.

Tzn. přejít bych asi mohl, pokud překousnu taby apod. a pokud bych našel čas na to to celý nakonfigurovat / domlátit kladivem k použitelnosti...

[Bherzet]

Mně vždycky přišlo škoda, že tyhle věci nejsou víc modulární. Měl bys pro každý jazyk (buildsystém, framework, …) nějaký samostatný toolkit/program, který umí doplňování kódu, validaci, navigaci apod. Pak by se to jen jednoduše propojilo s libovolným editorem.

Viděl jsem nějaký pokus tohle řešit přes headless Eclipse, jakože se prostě nastartoval kompletní Eclipse, skrylo se GUI a pak se tomu posílaly příkazy třeba z Emacsu, ale to je strašný overkill.

[Kate]

Něco jako LSP, na kterém je podpora všech jazyků ve Visual Studio Code postavená? Pluginy pro to mají snad všechny větší textové editory a některá IDE (Jetbrains přes plugin také)

[Bherzet]

Jo. Neznal jsem, dík.

[Kate]

Kolegyně to s úspěchem používá na vývoj v kombinací RustAnalyzer + NeoVim :)

[jancici]

ja som dosť používal eclipse, ale vo firme som zmenil team ktorý používa netbeans, tak som začal používať netbeans...

po čase môžem povedať že netbeans je oveľa stabilnejšia platforma a aj workflow sa mi zdá lepší ...

[marmax]

ja mel netbeans docela rad, pouzival jsem ho v dobe okolo verze 4.1, pak jsem presel na ideu
libila se mi i netbeans platforma (modularita, vcetne supportu osgi), ale prislo mi, ze to nejak umrelo...

[jancici]

ako to preslo pod apache tak je celkom živo