Názory k článku Spúšťanie programov z viacerých zdrojových súborov v Jave
-
To já zrovna naopak. Poté, co jsem zkusil Python na scripty, tak jsem se vrátil k Java, i přes relativně komplikovanější build. Relativně je na místě - pokud se všechno vleze do jednoho souboru, je to ok, ale s růstem do více souboru už bude Python docela chaos. V Java pořád vytvořím jeden executable jar s
#!/usr/bin/env java -jarna začátku a mám vystaráno (pokud nestačí single source).A kolekce? Jak co, Java stream API je IMHO často čitelnější, obzvlášť u složitějších operací. Výběr je na taky na straně Java - u Python není v základní verzi ani TreeMap (!).
U toho
-sourcemi zatím chybí něco jakoimport jar, to by značně zvýšilo použitelnost na scriptování v případech, kdy stačí jeden soubor, ale vyžaduje externí závislosti. -
No jo jenže když potřebuji dělat s JSON a soubory, tak se s tím zrovna v Java nedělá moc dobře. U kolekcí jsem měl namysli hlavně práci s map a to, že se to dá zapsat jako v JSON. To je pro mě ten hlavní důvod, proč šáhnu po Python. Co mě naopak v Python chybí a v Java je, tak je security a HTTP client (protože ten ve standardním Python za moc nestojí, jenže s requests se zase dělá mnohem lépe než s nějakým jiným Java klientem).
-
Filip JirsákStříbrný podporovatelS kolekcemi, mapováním a JSONem se právě dělá dobře v Groovy. A když potřebuju něco silnějšího, pořád je tam ta Java.
Když nepotřebuji nic silnějšího, stačí mi JavaScript a Deno :-)
-
Jenže problém s Groovy je, že ho nyní skoro nikdo nepoužívá a neumí (z velké části kvůli Kotlinu a to je taky jeden z důvodů proč Kotlin moc nemusím). My jsme taky hodně používali Groovy (ale i Jython kvůli WebSphere), ale pokud chcete dělat něco s nějakým cloudem, tak se s Python knihovnou dělá většinou lépe než s Java knihovnou. Ten kód se mi zdá prostě jednoduší (pro využití ve skriptech).
Tím neříkám, že je Groovy nebo JS špatná volba, ale každému vyhovuje něco jiného. -
A v cem je v Jave pri praci s JSONem problem?
Pridam do mavenu GSON a hotovo, ve Spring Bootu je JSON podpora zabudovana primo a REST api mapuje JSON na Beany uplne samocinne.
Kdyz potrebuju JSONPath, dtto.
Delam nyni vyhradne v Pythonu a Jave a popravde nevidim jedinou vyhodu Pythonu v teto oblasti.
Naopak dynamicke typovani je pain, javovsky ArrayList<MyBean> opravdu nejde naplnit nesmysly v jinem formatu, jak v v Pythonu bezne.Zrovna ted jsem videl Python klienta, ktery cetl z JSON/RPC, pricemz absolutne bez jedineho slova prijme JOSN/RPC Error (je taky zformatovany jako JSON), akorat to o kus dal lehne.
17. 5. 2024, 08:06 editováno autorem komentáře
-
Pridam do mavenu GSON a hotovo, ve Spring Bootu je JSON podpora zabudovana primo a REST api mapuje JSON na Beany uplne samocinne.
A to je přesně ten důvod proč na skripty používám Python. Kvůli JSON nemusím nic přidávat a nemusím nic nikam mapovat a s JSON pracuju jako s normální mapou. V 99% to ve skriptech stačí. To samé ukládání objekt, mapu cokoliv a uložím to v JSON. V Javě na to můžu použít buď serializaci nebo properties, ale to není nic moc.Dynamické typování je pain v nějakém větším projektu u skriptů to vidím jako výhodu.
ArrayList<MyBean> opravdu nejde naplnit nesmysly v jinem formatu
Tohle bych opravdu netvrdil.List list = new ArrayList<MyBean>(); list.add(new Object());
Zrovna ted jsem videl Python klienta, ktery cetl z JSON/RPC, pricemz absolutne bez jedineho slova prijme JOSN/RPC Error (je taky zformatovany jako JSON), akorat to o kus dal lehne.
Což se vám může stát i v Java. To, že ten klient je blbě napsaný vůbec nic neříká o tom jazyku. -
tato klasika uz je vyresena (kovariance/kontravariance)?
class Ovoce { } class Hruska extends Ovoce { public String toString() { return "Hruska"; } } class Jablko extends Ovoce { public String toString() { return "Jablko"; } } public class Variance2 { public static void smichej(Ovoce[] kosik) { kosik[0] = new Hruska(); kosik[1] = new Jablko(); } public static void main(String[] args) { Ovoce[] kosik = new Hruska[2]; smichej(kosik); for (Ovoce ovoce:kosik) { System.out.println(ovoce); } } } -
A nebo z toho udělat binarku rovnou s PyInstaller https://pyinstaller.org/en/stable/
-
Pavel TišnovskýZlatý podporovatelNuitka umí udělat nativní binárku a hodit do ní i balíčky, potom to jde spustit na cílovém systému úplně bez Pythonu. Akorát si to vezme nějakej čas (minuty až desítky, ale pro menší projekty ty minuty).
-
Poukazoval jsem na to, že se pak ztrácí ta zdánlivá výhoda jednoduchosti napsat jeden script a máme hotovo. Ty možnosti pro oba jsou pak komplikovanější (setup.py s čímkoliv či třeba Maven s shared a executable-jar pluginy), ale u jen trochu větších projektů nevyhnutelné.
Ohledně dřívějšího komentáře, že
-cpjde napsat do#!/usr/bin/env -S java...- ano, jde, problém je, že není úplný standard, kde jsou ty knihovny instalovány - chybí tam něco jako standardní search path. Nejjednodušší pak bývá udělat Maven setup, který všechny dependencies zabalí do jednoho executable jar. -
přesně
probém je, že se kolegové groovy nechcou učit
a v poslední době rovnou říkají, že je to mrtvý jazyk ...nejlepší je, že v Groovy scriptech můžu použít i třídy, které mám napsané v Javě a nejsem odkázaný jen na příme sql dotazy atd.
a když už mi jiná možnost nezbývá Sql v Groovy je asi nejlepší abstrakce JDBC -
Filip JirsákStříbrný podporovatel
Přitom v Groovy se dá začít psát tak, že vlastně píšu v Javě a neřeším, že tohle by se v Groovy dalo napsat i stručněji. Takže je člověk hned od začátku produktivní.
-
My/Já jsme zaváděli Groovy cca v roce 2012.
V té době bylo Groovy něco jako Kotlin dnes.
Groovy bylo úplně všude.
Podívejte se v čem je skriptování v Jenkins, Gitblit, začal se prosazovat Gradle, který taky od roku 2013, je náš hlavní buildovací framework, ale poutžíval jsem Gradle na různých projektech už od verze 0.6 -
Tak jak sleduji vývoj v Javě, tak lze říci že množství revolučních(extrémních) inovací od Java3 drasticky klesá, a prakticky od Java7 jsou implementovány nepříliš důležité(prakticky bezvýznamné) až na výjimky( moduly, run-time images) inovace, které v oslovují a jsou využívány zanedbatelnou části vývojářů. Shodou okolností si myslím, že téma jimž se článek zabývá mezi ty bezvýznamné inovace patří.
-
Male opraveni - jakkoliv moduly muzou pusobit nesmyslne, a jako marna featurka, tak nejsou: umoznilo to poradne zapouzdrit privatni api a tim to konecne umoznilo vyhazet stary kod, zrusit api co meli byt odjakziva uzavreny (a to se s reflexi dela fakt blbe). Tedy konecne umoznilo jave nejak rust. PRavda od javy 9 uplnula nejaka to voda, ale trvalo minimalne do javy 17 nez se to nejak poradne usadilo. Takze hura do toho:)
Bezeni java source files me nejdriv pripadlo neuveritelne legracni, ale po hlubsim uvazeni... napre to sili vyvojaru spravnejsim smerem - napriklad misto opusti groovy a zustanou u javy. nebo to treba umozni ze znaikne ant jako XML, a bude jen ant jako java kod... Atak dale a tak dale....
-
Tak to asi nesledujete vůbec. Naopak Java 8 měla spoustu nových věcí, lambdy, method reference. Java 7 neměla skoro nic nového (switch se Stringy a try-with-resource). Jenom namátkou Java 8-17 switch expression, pattern matching (switch, instanceof), record, sealed classes, ZGC.
Java 18-21 Virtual Threads, String Templates, record patterns, Foreign Function and Memory.
Navíc mají rozjeto další projekty např. CRaC (Coordinated Restore at Checkpoint), Valhalla (Value Objects, Null-Restricted and Nullable Type), Loom (vylepšení Virtual Threads), Class-File API (API pro parsovaní a úravu java class).
Ukažte který jazyk toho přidal za posledních 5 let víc? Je taky nutné vyzdvihnout, že je ten jazyk stále velmi dobře zpětně kompatibilní a na novém JVM může běžet i kód zkompilovaný např. s Java 4 (až na malé výjimky).
Napsat, že tyhle změny jsou nepříliš důležité je výstřel úplně mimo, protože vývoj (struktura kódu, způsob psaní) v Java se s novými verzemi rapidně změnil. -
Ano. Podle me je java v soucastnosti jediny jazyk, ktery v cili na celou vekove-zkusenostni vyvojarskou mnozinu - od uplych zacatecniku co ani nevi ze je nejaky compiler, prez deti, juniory, prez seniory a principaly az po uplne magory co pisou kounstrukty ktery predchozi skupiny ani neprectou. Natoz aby to pochopili. Navic ma celkem rozumnou comunitu a codebase a je docela blbu vzdorna a citelna. Featury se pridavaji mnohem pohodlneji nez do C++ nebo i do Pythonu. A zpetna kompatibilita se opravdu drzi (napr naproti pythonu).
Napr C miri na horni polvinu skupiny, Python na spodni dve tretiny skupin.. atd... jen aby ch malinko upresnil pojmy:) Tezko rici kdy sit ohle hlanvi lide v jave uvedomili, ale uchopili to zpravne. Ted ma java decanko generacni gap, ale ma sanci to napravit.
Taky svet je o neco vetsi nez EU, USA a Indie... Tuhle se ke me hlasili studenitci ze statu ala Kazachstan a okoli, a jo umeli, ale jejich jazyk volby byl pascal...
-
To co si myslíš ty, že je důležité je jenom důkazem mého tvrzení že patříš do té minoritní skupinky kterou to oslovilo. Většina co jsi napsal jsou jenom tvz. "syntaxový cukřík" který řešil tvz. problémy které se dali řešit(programovat) předtím též, pouze jiným(složitějším) postupem. Některé přidané API o kterém se zmiňuješ sice v některých případech zmenšilo zdrojové kódy jako u všech nových API, ale na nativní úrovni díky němu nedošlo k nějakému zásadnímu zrychlení či zlepšení. A pokud ano, tak jenom v ojedinělých případech.
Podle mě se svým vlastním myšlením z bezvýznamných věcí děláš zbytečně významné. Možná protože neumíš poznat skutečně významné věci.
-
Skus si to zobrat tak. Niekomu staci asambler, alebo napriklad INTERCAL (vid https://esolangs.org/wiki/INTERCAL_Turing-completeness_proof ). Niekto chce vediet pohodlne precitat, co napisal, aj po mesiaci a neskor. Preto sa ten "syntakticky cukor" vcelku zide.
PS: Ak ta bavi sprtat sa v java 1.4 kode (to je to, kde napriklad nieje enum este), napis mi. Mozno by som ti vedel dohodit pracu...
-
Tohle už je pěkný blábol. FFM a Virtual Threads zrovna syntax sugar rozhodně nejsou a změn za tím je opravdu hodně. To samé pattern matching. Zrovna Virtual Threads mají obrovský význam. Project CRaC a nově project Galahad (GraalVM do OpenJDK) jsou zrovna velkým příslibem zrychlení.
Ty přidané věci rapidně změnili způsob psaní kódu. Zdrojový kód napsaný v Java 7 a Java 21 bude vypadat rapidně jinak a i Java vývojáři nyní využívají jiná řešení než dříve. Stačí se podívat na knihovny, jak se díky třídám z java.util.function a lambdám proměnily (a to je jenom syntax sugar). To samé udělá record.Tak napiš jaký jiný jazyk toho přidal víc za posledních 5 let. Co bys jako chtěl více?
Tvrzení, že syntax sugar je nepodstatný je taky dobře mimo. Protože to hodně rozhoduje, jak je jazyk úspěšný a jestli ho vývojáři rádi používají. Můžete mít skvělý jazyk, ale pokud nebude mít právě ten syntax sugar, tak ho nebude nikdo používat.
