Milyen Java IDE-t

Java

Úgy hozta az élet, hogy mocskolnom kellene ezen a java-ban írt projekten kicsit:

https://github.com/OpenAPITools/openapi-generator

Sajnos a módosítás mértéke úgy tűnik meg kell haladja azt a szintet amit gyalog módszerrel (kate + mvn clean install + jar futtatása) érdemes végezni.

Kellene valami IDE amiben tudok normálisan debugolni illetve egy sor módosítás compile-ja (vagy aminek Javaul épp nevezik) az nem két percig tart.

Mit ajánlatok erre a célra 2024-ben?

  • 1776 megtekintés

( gelei v | 2024. 02. 06., k – 20:44 )

Amire van Jetbrains IDE, arra a Jetbrains IDE-t. Java-hoz szerencsere pont van. :)

( gabrielakos v | 2024. 02. 06., k – 20:48 )

intellij idea ce

zászló, zászló, szív

Nekem csak eseti open source mocskolásra kell így pénzt nem adnék érte, illetve a Javat általánosan kerülöm mint gyújtogató a vizes szalmát.

Miután javasolták kb. 10 perc volt befűzni a projektet úgy, hogy már megy a debugger, szóval eddig maximálisan elégedett vagyok vele.

Ez nem igaz. Lehet dolgozni VI-ban is. De pl az segítség, ha egy JSF-es XHTML-ben szerkesztés közben az IDE érti a Java- context-et is, és pl van ilyen kódcomplete-ed. Persze a tanulást nem váltja ki, hanem ha jó a plugin a kezed alá dolgozik.

Miért rossz az, ha az IDE segít? Például a database integrációnál bejön code completition-ba az adatbázis minden adata, nem kell vadászni, hogy mi a mező neve, tud generálni és refaktorálni JPA-t sémaváltozás után, satöbbi. Ha még nem használtad ezeket, akkor nem tudod, miről maradsz le... ez nem arról szól, hogy kell-e még tanulnod, hanem arról, hogy mennyi boilerplate kódot kell kézzel írnod/módosítanod. És akkor az AI tool-ról nem is beszéltem, ami szintén tudja használni ezeket a metaadatokat a kódgeneráláshoz.

https://iotguru.cloud

Mondjuk, az AI asszisztált fejlesztésben még nincs gyakorlatom, de fenntartással kezelem az alapján, amiket eddig próbáltam.

Valamit elkezdek, vagy beírok egy megjegyzést, és az alapján (nagyon gyengén) megpróbálja kiegészíteni a kódot. A legtöbbször teljesen hülyeséggel, vagy egy középsz*r, vagy teljesen sz*r rutinnal, stb... Nem vagyok benne biztos, hogy ezek az AI asszisztens pluginok már használható minőségűek (de csak rövid ideig próbáltam).

De az is biztos, hogy a kódolás is teljesen megváltozna velük, még ha működnének is ezek a pluginok, akkor is. Nem tudom, hogy fejlesztő szeretnék-e maradni.

Itt a "kell" = legalább egy (de adott feladatnál akár több) nagyságrendbeli különbség van a szükséges időráfordításban és a mentális terhelésben, ami egy-egy feladat elvégzése során szükséges, és vannak olyan dolgok, amiket IDE nélkül egyszerűen nem tudsz normálisan megcsinálni, csak kínkeservesen.

Persze, greppel is lehet navigálni referenciák és osztályhierarchiák között, de egy IDE-hez képest a Zuzuval való beszélgetés minősített esete. :) Kódkiegészítés szintén egy ilyen alap dolog, de pl. IDEA igen komoly refaktorokat is tud csinálni pár másodperc alatt (anno még a korai Eclipse-es időkben is órákat szoptunk ilyesmivel). Arról nem is beszélve, hogy Javát debugolni IDE nélkül... ha ez lenne a feladat, hirtelen nem is tudnám, hogy kezdjek neki (azon túl, hogy Google). :) Napi szinten használom a beépített gites lehetőségeket (3-way merge IntelliJ környezetben szerintem világverő), szintén órákat lehet vele spórolni naponta.

És ezek direkt csak azok a dolgok, amik kb. minden Java-projektben előjönnek (avagy nem kell enterprise projekt ahhoz, hogy hasznos legyen), a speckóbb dolgokat még meg sem karcolják a fentiek. Napi szinten használok springes, openapis, gradle-ös, adatbázisos funkciókat IDEÁ-ban (most éppen 4 viszonylag nagy projekt van nyitva egyszerre, és mind kell is), pedig nem ma kezdtem, bár az biztos, hogy tanulásra mindig szükség van, ebben nincs vita. :)

Szóval szigorúan véve kell az IDE? Nem, mert meg tudnám oldani enélkül is a dolgokat. Vállaltam volna ezt a munkát IDE nélkül? Szinte biztos, hogy nem.

+1 a CE-nek; ezek a feature-ok frankon (haha) semmire se jok.

Menjunk sorjaban.

EE tamogatas: aki meg mindig ilyet hasznal, az terjen meg a netbeans-re rogton, vagy mondjon fel/le.

Spring: ez megintcsak nehezkes, leginkabb nem mukodik, mert a spring kontext osszerakasa baromi sokmindentol fugg; konfig (itt ugye tobbszintu is, amit mergel), environment, stb... A kezzel injektalt bean-eket ne is emlitsuk, meg rengeteg-rengeteg egyebet sem. Aztan amikor random fura hibakat dob, mert nem szerinte nem ugy van, akkor kikapcs.

Hibernate/JPA: mi ezeket konkretan kinyirtuk, mert tobb volt vele a macera, mint amennyit segitett. Iszonyat bonyolult alapvetoen, nagyon meredek learning curve-el (uj team membereknek jo is az), es sok black magic-el, amit mind tudnod kell, hogy hatekonyan tudd hasznalni. Ja, es mindenki masnak is a team-ben. Production-ben esik ki aztan gyakran, hogy osszerak egy nevetseges query-t meg hulyesegeket csinal. Tipikus esete a tool-nak, ami inkabb csak utban van.

Database console: na ez meg a docker/cloud koraban eleg haszontalan, mar elotte is az volt :)

Ne gondold, hogy mindenki hasonló cipőben jár. Más jellegű tapasztalatunk van.

EE tamogatas: Itt jó lenne konkrét példáról beszélni. Neked, lehet, hogy nincs rá szükséged. De nem csak olyan jellegű projekt van, amit Te is csinálsz. Alapvetően - én is meglepődtem - próbálja, és sikerrel tartja a lépést az EE a nagyvilággal, nem olyan nyögvenyelős, mint régen. Sokan használják, miért ne használnának hozzá bármilyen támogatást, ami segíti a munkájukat?

Spring: Itt gondolom valami IDE feature-re gondolsz, de csak egy példa: azért egy ilyen támogatás nélkül elég nehezen láthatod ezeket az aspectj-s/proxy-s dolgokat, amiket kell használnod, nem tudom megkerülni, egy alap pl a spring-ben is. - De 100%-ban nem vagyok biztos benne, hogy mire gondolsz.

Hibernate/JPA: Itt ha jól értem nem pluginról beszélsz: Ez pl egy olyan téma, ahol az alapoknak stabilnak kell lennie, van egy lelkivilága, és a hibernate/jpa esetén érdemes a kézikönyvvel kezdeni, és nem a stack overflow-val. Nem tudod anélkül használni, hogy az SQL-hez értenél, és figyelembe vennéd, illetve ahhoz is kell érteni, hogy mikor mit csinál - de ezek egyszerű dolgok. És így már nem is rak össze nevetséges query-ket. - Azért remélhetőleg nem a production-ben derül ki, hogy mit csinál, fejlesztés közben is nyomon lehet azt követni, pl látni a konkrét SQL-eket, megfelelő logolási beállítások mellett - és meglepően optimális query-ket gyárt.

Database console: Nincs köze a dockerhez, tök mindegy mi hol fut. Ha használsz adatbázist, akkor kellhet.

De nem biztos, hogy mindenhol egyről beszéltünk.

Miota oracle kiugrott az EE-bol, kb. flatline-on van, veheted EOL supportnak kb.

Aspect-eket igy se, ugy se tudod kovetni, pont ugyanazert, amiert a kontext init-et se. Tudnod kell, hogy hogyan epul fel a (micro)service-d, illetve egy jol iranyzott breakpoint + stack frame egybol megmutatja az around() okat.

hibernate az izlesek es pofonok; szerintem az talalja hasznosnak, aki meg nem kapott egy-ket irtozatos pofont tole production-ben. Aztan o is inkabb kezzel irkal sql-t. Ha mar ilyen szinten automatizalni akarod a sql-t, akkor hasznalj valamilyen document store-t. Ezt az 'automatizaljuk az enterprise db schema hozzaferest' nem is ertem igy a microservice-k koraban.

Az aspect-eket normális IDE-ben is tudod követni, ha nem, akkor ott más gond lehet. És pont az lenne a lényeg, hogy ne csak a stacktrace-ből lásd debuggal.

A hibernate: vagy pont fordítva mondanám, az találja hasznosnak, aki megtanulta használni, és tudja, hogy mire jó.

Aki a kalapácsot ismeri, annak minden szög. Egy nagyon szűk szeletkéjéről beszélsz a szoftver fejlesztésnek, a saját tapasztalatod alapján.
Meg ne lepődj majd pár év múlva, ha még egyszer az életben egy Java EE fejlesztésben találod magad, egy másik helyen, ráadásul még az is kiderül majd, hogy annyira mégsem elavult és elhagyatott dolog. :)
Microservice-ekhez én sem használnék feltétlen Hibernate-et, mert egy felesleges réteg egy olyan alkalmazás esetén, ahol az a cél, hogy az alkalmazás minimális erőforrás használattal fusson, és a lehető leggyorsabban induljon el, tudjon skálázódni. De emellett egymillió másik eset létezik, amikor nagyon hasznos cucc. (Azt is említsük meg, hogy a Hibernate az évek alatt rengeteget fejlődött, egy letisztult, kiforrott, érett eszközről beszélünk, szóval ez az overhead/plusz réteg dolog sem biztos, hogy kritikus.)

Ez egy igen jó példa a selection bias-ra, amikor azt hiszed, hogy abból áll az IT, amivel éppen foglalkozol és nincs más... :D

És szintén azt kell mondjam, hogy érzésre nem használtál még tartósan Ultimate-et, különben tudnád, hogy mennyit segítenek a benne lévő plusz eszközök. Az Ultimate nem azon segít, hogy kevesebb tudás is elég, hanem abban, hogy ha van megfelelő tudásod, akkor akár drasztikusan is lerövidíti az időt, ami a feladat elvégzéséhez kell.

https://iotguru.cloud

Hasznaltam ultimate-t. Aztan meguntam, hogy kb. par havi rendszeresseggel volt valami baj a key server-rel, mert no a ceg es folyton keson vettek uj licenc-eket. Ugyhogy kiprobaltam a CE-t, es rajottem, hogy kevesebb ram-ot eszik, gyorsabban indul, es semmi se hianyzik.

 

Hasznaltam eleg sokmindent BTW, es mostanra kikristalyosodott, hogy mi az, ami mukodik gyakorlatban, es mi az, amit csak java dev-ek altalanos konzervatizmusa. Dolgoztam par platformon/nyelven, de az teny, hogy a java dev-ek kozott talalni a legvaskalaposabb embereket. Ilyet mashol nem latni, hogy elmagyarazod neki reszletesen, hogy miert nem jo, amit csinal, vegig bologat, aztan folytatja, ahol felbehagyta... :/ Mondom ezt ugy, hogy az elmult 20 ev 2/3-at java vilagban toltottem. En konkretan ezert menekultem kotlin fele, mert egyszerubb volt az, mint a szelmalomharc.

Hasznaltam ultimate-t. Aztan meguntam, hogy kb. par havi rendszeresseggel volt valami baj a key server-rel, mert no a ceg es folyton keson vettek uj licenc-eket. Ugyhogy kiprobaltam a CE-t, es rajottem, hogy kevesebb ram-ot eszik, gyorsabban indul, es semmi se hianyzik.

Szerintem te nem használtál Ultimate-et... nem kell élő licence server, ha kaptál licence fájlt, onnan lehet használni offline is hónapokig, illetve, ha a cég nem vesz új licencet és az lejár, attól még tudod használni, csak az upgrade nem megy, átvált ún. perpetual fallback license módba: https://sales.jetbrains.com/hc/en-gb/articles/207240845-What-is-a-perpe…

de az teny, hogy a java dev-ek kozott talalni a legvaskalaposabb embereket. Ilyet mashol nem latni, hogy elmagyarazod neki reszletesen, hogy miert nem jo, amit csinal, vegig bologat, aztan folytatja, ahol felbehagyta... :/

Na, te pont ilyen vaskalapos vagy, az ember elmagyarázza, hogy miért faszság, amit írsz, aztán folytatod, ahol félbehagytad... :D

https://iotguru.cloud

( _Franko_ v | 2024. 02. 06., k – 21:06 )

Ahogy a többiek írták, a JetBrains IntelliJ IDEA minden más IDE-t gyakorlatilag kiírtott. Mondjuk fizetős, de a harmadik évtől nettó 100 euró, ami lófasz se, illetve ha all products pack-ot veszel, akkor se vág földhöz a nettó 173 euró évente...

https://iotguru.cloud

( uid_17626 | 2024. 02. 06., k – 21:34 )

Szerkesztve: 2024. 02. 06., k – 21:34

Nekem a Netbeans is bejött és az STS is (van még?) ami lényegében egy customizált Eclipse, de ma már csak tools van Eclipse-hez: https://spring.io/tools

ps.: tény, hogy a Jetbrains jó, csak fizetős

( joco01 v | 2024. 02. 06., k – 23:26 )

Nekem az IntelliJ-vel sok bajom van, de muszáj ezt használni. Alapvetően működik, érdemes megpróbálnod. Az Eclipse egy fokkal jobb volt, de már rég használtam, lehet, hogy megszépültek az emlékek.

A legjobb IDE, amit valaha láttam, az a Visual Studio. A VSCode szarabb tőle, de pl. az is tud Javát. Ha esetleg az MS szimpatikusabb, ezt is ki lehet próbálni.

Az Eclipse egy fokkal jobb volt, de már rég használtam, lehet, hogy megszépültek az emlékek.

Az könnyen lehet, mert nekem anno az upgrade, meg a modul install környékéről még mindig idegrángást okozó emlékeim vannak, ~10 év távlatából. SZVSZ egy kalap kaki a komponens menedzsment benne, az sem véletlen, hogy bármilyen vendor ha a saját szarjait Eclipse-re építve akarta terjeszteni, akkor csinál belőle egy pakkot, amiben minden benne van, és csak egyben le kelle tölteni, és használni. Bármilyen más megoldás (mondjuk pl. 2 vendor szarjait egyesíteni egyetlen működő installban) a tömény és kőkemény szopás szinonímája.

Igen, a telepítőjét én sem kedvelem, mert tömény szívás. Viszont elképesztően hatékony inkrementális buildet tudó compilere van. A teljes compiler környezetet memóriában tartja és egészen nagy projekteket is pillanatok alatt újrabuildel. Plusz tudja azt is, hogy a futó debug session alatt kicseréli a kódot szintén másodpercen belül. De beágyazott web szerverrel egy teljes újraindítás 1 másodperc alatt van. Elképesztő hatékonyan lehet használni, ha az ember tudja, hogy mit csinál.

Sokan nem a natív Eclipse projektet használják, hanem Maven buildet vagy ilyesmit: úgy összerakva sajnos éppen olyan lassú lesz mint bármi más, mivel ugyanaz a build fut alatta mint más alatt.

Én főleg Eclipsezek, de dolgozom .NET-es projekten is, Visual Studio alatt, ott minden tesztindítás "egy kávé".

Ez mind nagyon szép és nagyon jó, de ezt a szuper compilert hogyan hajtod meg CI pipeline-ból, automatizáltan? Mert a "sehogy, ott egy másik compiler állít elő egy másik kódot" is szar válasz (mást tesztel a fejlesztő, mint ami utána fog futni), meg a "hát futtatunk valami vm-ben egy eclipse-et, és valami gui automatizációs szar megnyomja a virtuális gombot" is szar válasz. A "nem használunk CI pipeline-t, a fejlesztő maga buildeli a kiadott kódot, a saját kis random környezetében, kézzel" meg a lehető legszarabb válasz (reprodukálható buildek, szevasztok!)

Simán tudod használni az Eclipse-et maven-nel együtt. Viszont ha te ott lokálban irod a kódot, akkor az menet közben fog buildelni, és nem kell megvárni, amíg a maven egy külön parancsra lefut. Egyébként IntelliJ-ben is be lehet állítani hogy használja az Eclipse fordítót, annyira hogy az alap IDE része.

https://www.jetbrains.com/help/idea/java-compiler.html#compiler

E mellett bátran lehet CI pipeline-t építeni, a kettő nem zárja ki egymást.

>mást tesztel a fejlesztő, mint ami utána fog futni

A Java szépen definiált nyelv, meg van mondva hogy mit kell csinálnia. Az, hogy a fejlesztő mással fordítja, mint a CI, az nem probléma. Egyszer láttam különbséget: egy generált osztályt az egyik nem volt hajlandó lefordítani, mert valami túl sok vagy túl hosszú volt benne. A specifikáció valóban lekorlátozza az osztályok méretét, amit csak az egyik fordító követelt meg. Na, ez volt eddig a legnagyobb eltérés, amit tapasztaltam.

De össze lehet rakni a CI-t is az ECJ.jar-ral, van ahol megcsináltuk. Az is gyorsabb lesz, mint a "hagyományos" megoldások, persze az inkrementális rész ott nem játszik.

De össze lehet rakni a CI-t is az ECJ.jar-ral, van ahol megcsináltuk.

Ez a lényeg. Ez viszont azt jelenti, hogy nem csak az Eclipse-ben tud ilyen inkrementális build lenni - bármilyen más IDE-vel is használható ezek szerint.

Az, hogy a fejlesztő mással fordítja, mint a CI, az nem probléma.

Az nem túl hihető, hogy az optimalizálás eltéresei ne okozhatnának valódi problémát ("de az én gépemen jól megy" c. klasszikus), és biztosan létezik Java esetén is a compiler bug fogalma, amikor hibás kód keletkezik. Azt értem, hogy ez nem túl gyakori, meg ilyet nem láttál még.

Ez viszont azt jelenti, hogy nem csak az Eclipse-ben tud ilyen inkrementális build lenni - bármilyen más IDE-vel is használható ezek szerint.

En nem vagyok tul jaratos a Java vilagaban hal' Istennek, de meggyozodesem, hogy nem csak az Eclipse tud inkrementalis buildet, sot.

Amugy a CI/CD vs lokalis build kompatibilitast en tesztekkel biztositanam, nem a compilerre biznam. Ha nem fontos, akkor azert nem, ha meg fontos, akkor azert, mert ugysem lesz a build agent 100%-ban azonos a lokalis kornyezettel.

>Ez viszont azt jelenti, hogy nem csak az Eclipse-ben tud ilyen inkrementális build lenni - bármilyen más IDE-vel is használható ezek szerint.

Nem, mert koncepcionálisan másképp működik az Eclipse alatt: a teljes build memóriában csücsül folyamatosan. Az inkrementális buildnél ezért nem kell a függőségeket újra tölteni, hanem tényleg csak az van parszolva és buildelve ami változott. Ezt nem lehet külső parancssori tool-lal megcsinálni, mert az mindig nulláról indul és az inkrementális build is azzal kezdődik, hogy a függőségeket be kell tölteni.

Elvben össze lehetne rakni hasonló inkrementális buildet persze más rendszer alatt is, de egyáltalán nem triviális, nem annyi, hogy elindítjuk az ECJ.jar-t csak a változott fájlokra.

>Az nem túl hihető, hogy az optimalizálás eltéresei ne okozhatnának valódi problémát

Pedig kb 20 év tapasztalata, hogy a compiler különbség még sosem okozott problémát (azon kívül amit fentebb említettem). De ha okozna, akkor az direkt jó lenne, mert az ember tanulna belőle valami újat. Ha a két rendszeren nem azonosan működik ugyanaz a program, akkor vagy a program szar (pl versenyhelyzet van benne, amit előhoz a fordító különbsége), vagy valamelyik fordító. Fordító hibát eddig sosem fogtunk. JRE hibát már igen (azt is régen, 6 vagy 7 környékén utoljára talán), fordítót még nem. Ahol biztosra kell menni, ott meg a tesztelés a CI kimenetén történik, ami ugyanaz, mint ami productiönben fog futni. Amit a fejlesztő futtat az IDE-ben az nem számít tesztelésnek.

Elvben össze lehetne rakni hasonló inkrementális buildet persze más rendszer alatt is, de egyáltalán nem triviális, nem annyi, hogy elindítjuk az ECJ.jar-t csak a változott fájlokra.

Gyakorlatban is. Söt, IntelliJ IDEA tudja ezt remote deploy és Android esetén is, tehát a gépre kötött telefonon rebuild nélkül kicseréli a változást.

https://iotguru.cloud

Kb. azonnal. Olyat is tud, hogy megy a debug remote szerveren, megakad a breakpoint-on, látod, hogy rossz, visszalépsz az előző stack frame-re, módosítod a programot és folytatod ugyanazt a debug folyamatot, az IDE hotswap cserélte a remote class-t úgy, hogy az alkalmazás közben futott.

Szerintem te le vagy maradva mintegy 10-15 évvel, ha az Eclipse a csúcs...

https://iotguru.cloud

Azt állítottam, hogy az Eclipse build rendszere az általam ismert leggyorsabb abból a koncepcionális okból, hogy a build állapotot memóriában tartja. Még azt se állítottam, hogy nincs más ami tudja ezt, mert nem ismerek mindent. Azt állítottam még, hogy parancssori módon nem lehet ezt a feature-t lemásolni, mert éppen az a lényege, hogy az állapot memóriában van, tehát ha folyton újrahívjuk a programot, akkor nem úgy fog működni.

Az is tény, hogy egyszerűen az SSD és a processzorok fejlődése miatt is minden más érzésre mellé gyorsult, és lehetséges, hogy a függőségek betöltésével együtt is le tud futni egy inkrementális build néhány száz milliszekundum alatt. De ha koncepcionálisan lassabb, akkor elképzelhető olyan projekt, aminél érzékelhető a koncepcióból adódó különbség. Ezért kérdeztem volna azt is, hogy ez alatt is memóriába be van kesselve a build állapot, vagy fájl változáskövetés alapon fut le egy inkrementális build? Tehát hogy hogyan működik a technológia alatta? Pusztán érdekességképpen.

Az Eclipse számomra teljesen jó, úgyhogy valóban nem is kerestem aktívan alternatívát az utóbbi 10-15 évben. Nem láttam olyan funkciót még sehol, ami ne lenne meg Eclipse-ben is vágytam volna rá. Lehet, hogy maradi vagyok, lehet, hogy nem láttam eleget.

Ami IDE-vel találkoztam, az mind gyengébb volt valamilyen szempontból. Androidra egy évekkel ezelőtti fejlesztőkörnyezettel fejlesztettem csak egy mini játszós programot, munkában nem Androidozok. Az Android Studio-t töltöttem annó le, ami a hivatalos Google által kiadott IDE. Az a verzió gradle-t használt belül, és idegesítően lassú volt a build. Azt mondod, hogy az InelliJ Idea sokkal gyorsabb? Vajon az Android Studio is gyorsabb lett azóta?

Szerintem nem ment át, hogy mi a lényegi különbség amiről beszélek. A Java fordító úgy működik, hogy ahhoz, hogy lefordítsd az A.java osztályt ezt kell csinálnod:

 * Beparszolod a szöveget és felépíted az AST-t. (ezt inkrementális build esetén is nulláról meg kell csinálni, elvben az AST-t is karban lehetne tartani diffként, de ilyen megvalósításról nem tudok, normál esetben nem is éri meg, mert a forrásfájlok jó esetben kicsik.)

 * Az összes függőséget ki kell keresni (importok, package info, hivatkozott külső osztálynevek alapján ki kell keresni és be kell tölteni ezeket). A függőség lehet class formában (lefordított libre függés esetén), vagy .java formában, ha ugyanabban a build egységben van a függőség. A függőségek publikus API-ját be kell tölteni memóriába a fordító adatszerkezetébe! Ez az a lépés, amit egy memória rezidens inkrementális build ki tud spórolni. A függőségek nevei eleve indexelve a memóriában vannak, tehát a fájlokat sem kell újratölteni. Ezen belül az ösztályok API-ja a fordító belső adatszerkezete szerint beindexelve szintén a memóriában csücsül. Nem kell ezeket a .class és .java állományokat újraolvasni. Ezzel szemben ha a build folyamatot tiszta lappal indítod mindig, akkor ezt a lépést mindig újra kell csinálni!

Ha egy fájlt átírsz (IDE-t használva tipikus hogy minden fájlt azonnal mentünk amint szintaktikailag helyes a szerkesztésünk, és mentésre azonnal fut a build: a változás tehát mindig kicsi és csak 1 fájlt érint egyszerre.), akkor a fordító által végzendő munkának sokkal nagyobb része a függőségek újratöltése, mint az egyetlen fájl újrafordítása! Egyszerűen azért, mert a divatos módszertanok szerint az osztályok kicsik, viszont mivel minden kicsi, ezért a függőség meg jó sok darabra is. Ha a függőségek memória rezidensen őrizgetve vannak, akkor az újratöltést, tehát a munka nagyobb részét meg lehet spórolni.

(Illetve ha a szerkesztett osztályunk publikus API-ja változott, akkor az őrá épülő osztályokat is újra kell fordítani. De csak akkor ha az API változott, ha csak egy implementáció, akkor már nem! Ezt is akkor lehet egyáltalán követni, ha a fordítónak fejben megvan az előző fordítási állapot kimenete és ahhoz tudja viszonyítani az újat.)

Tehát simán a függőségi fa követése és csak a módosítások újrafordítása nem ekvivalens azzal, ha memória rezidens a fordító, és a saját struktúráiban tényleg csak azt frissíti be, amit szükséges. A második pont feladatait ugyanis így nem kell újra végigcsinálni, a munka oroszlánrésze megspórolható.

Egy Java és egy C fordítás nagyon másképpen működik, mivel Javában header fájlok helyett az implementációból van kitúrva a publikus API. De azért egy hasonlóságot fel lehet fedezni a "precompiled header" technika és a függőségek memóriában tartása technika között. A C világot jobban ismerők számára talán így lehet magyarázni a különbséget, hogy a függőségek memóriában tartásával kb azt lehet megnyerni, amit a precompiled headerrel lehet a C világban meg lehet nyerni. Ott is az van, hogy sok esetben a headerek parszolása többszöröse magának a forrásfájlnak a parszolásának, mivel a forráskódok a divat szerint kicsit, a gyári headerek viszont az összes szabványos csellentyűcskét tartalmazzák és ezért jó komplexek.

A gradle leírása alapján én úgy értem, hogy a fordító implementációt egy bemelegített JVM-ben tudja tartani, ami gyorsít az induláson (lásd JIT problémakör), de a fordító belső állapotát nem őrzi meg két hívás között. A linkelt leírások mind erre utalnak. De szívesen tanulok újat, ha rámutattok arra, hogyan őrzi meg a gradle a fordítás belső állapotát két inkrementális build között.

Gradle képes cache-t építeni a teljes build folyamatról, akár elosztottan is, tehát egy csapatnak lehet egy projekt cache szervere, ahonnan a Gradle a build előtt lehozza a teljes build cache-t és csak azt fordítja, ami ahhoz képest változott. Szóval, de memóriában van, de vannak korlátai meg nagy előnyei is, ha jól van beállítva.

De az IntelliJ IDEA nem Gradle-t használ belül, felolvassa a Gradle vagy Maven vagy egyéb faljt és felépíti a memóriában azt, amit Eclipse sajátosságnak hiszel, de kb. minden IDE tud, másképp nem működne a hot swap, pláne a remote debug közben a hot swap.

Az Eclipse nem az IDE választék csúcsa, és már 10-15 éve se volt az.

https://iotguru.cloud

Azt állítottam, hogy az Eclipse build rendszere az általam ismert leggyorsabb abból a koncepcionális okból, hogy a build állapotot memóriában tartja.

Én meg azt, hogy ez egy alap feature 10-15 éve.

Azt állítottam még, hogy parancssori módon nem lehet ezt a feature-t lemásolni, mert éppen az a lényege, hogy az állapot memóriában van, tehát ha folyton újrahívjuk a programot, akkor nem úgy fog működni.

A gradle például tudja részlegesen CLI-ből, ezért van az, hogy egy daemon formában ott marad futva két build között, de kell hozzá jó IDE support.

Az Eclipse számomra teljesen jó, úgyhogy valóban nem is kerestem aktívan alternatívát az utóbbi 10-15 évben. Nem láttam olyan funkciót még sehol, ami ne lenne meg Eclipse-ben is vágytam volna rá. Lehet, hogy maradi vagyok, lehet, hogy nem láttam eleget.

Ezzel semmi baj nincs, hogy maradtál az Eclipse-nél. A baj az, amikor azt mondod, hogy csak az Eclipse tudja ezt-vagy-azt.

Az Android Studio-t töltöttem annó le, ami a hivatalos Google által kiadott IDE. Az a verzió gradle-t használt belül, és idegesítően lassú volt a build. Azt mondod, hogy az InelliJ Idea sokkal gyorsabb? Vajon az Android Studio is gyorsabb lett azóta?

Kérdés, hogy mikor, mert eleinte Eclipse alapú volt az Android Studio, egy jelentős ideje IntelliJ IDEA alapú. És pusztán a Gradle build lassú, viszont az IntelliJ IDEA alapú AS tudja az "apply" funkciót", írsz változást, apply changes, aztán ott van a telefonon a futó alkalmazásban a módosított kód.

https://iotguru.cloud

Mikor bejött at 5-ös Java, és vele a generic cuccok, ott volt egy kis ideig eltérés az ecj és a javac között: már nem emlékszem a részletekre, de kovariancia vagy kontravariancia esetén komplikáltabb esetben az ecj jól működött, a javac pedig elszállt... vagy fordítva. Később ki lett javítva.

Az Eclipse incremental buildje pedig mesés volt, imádtam. Play gomb -> azonnal indult az alkalmazás. Hot code replace debuggolt alkalmazás közepén. Manapság persze divat mindenféle postprocessing-et tenni a pipeline-ba, meg mindent maven/gradle-el buildelni lehetőleg szarrá customizálva, emiatt szívás vagy lehetetlen a beépített fordítót használni.

( sz332 v | 2024. 02. 07., sze – 17:49 )

IntelliJ, Eclipse, VS Code, Netbeans, szerintem bármelyikkel megoldható. Én egyébként főleg IntelliJ CE-t használok, amire nekem kell, tökéletesen elég. 

( Nickname | 2024. 02. 07., sze – 18:51 )

2004 óta használok NetBeans-t. Igen, akkor még IntelliJ sem volt. Mindent is tud, most már az apache égisze alatt. Cserébe ingyen van és egy rakat plugin van hozzá is.

Tud onSave compile-t gradle-t, mavent és persze php, python, go vagy javascript/html, kotlin.

Ingyen van és még contributálhatsz is hozzá. Kedvet kaptam én is a Database plugin diagram save to dot -ra.

 

Nosza.... :-)

A Stackoverflow 2023-as felmérése szerint a Netbeans-t a fejlesztőknek 3-4%-a használja. Ami valóban nagyon elenyésző ahhoz képest, ami pár éve volt, de majdnem annyian használják még, mint a VSCodium-ot (vigyázat, ez nem VSCode, az külön volt mérve a felmérésben, azt 73% használja), Emacs-et, Qt Creatort. A halottól így messze van.

Nekem az összes javás szutyok közül még pedig a Netbeans volt anno a legszimpatikusabb, bár én mindet utálom, NagyZ a megmondhatója. Ha valami javás szutykot is kéne patkolni, annak is neovim-mel mennék neki, szépen bedrótoznám neki gyorsbillentyűre, hogy a szerkesztendő fájlra futtassa le a mvn clean install + jar-t futtassa. Igazából ehhez még neovim konfig se kell, entr vagy inotify-jal is be lehet lőni, hogy figyelje, hogy a projekt mappájában változott-e valami fájl, ha igen, akkor fordítson újra mindent, így még a kolléga a Kate-et is megtarthatná, ha azt szereti. Persze egy erre specializált IDE-nek is meglehet az előnye, mert az kiegészíti a nyelvi kulcsszavakat, függvényeket, stb., észreveszi, ha teljesen hülyeséget ír egy kezdő, stb., azért segíthet az. Kinek mi fontos.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Fuh, de latszik, hogy ki az, aki fejlesztessel keresi a kenyeret, meg ki nem.

Nem, rohadtul nem az a megoldando problema, hogy nincs shortcut buildelesre, meg tul hosszu ideig tartani beirni, hogy mvn install vagy akarmi. "Persze egy erre specializált IDE-nek is meglehet az előnye", igen, peldaul az, hogy ha van egy projekted, amiben van 52 ezer commit, 800 megas a working copy, es 35 ember tolja bele a kodot, abban segit eligazodni. Vagy amikor a 10+ eves kodot refaktoralni kell, azt segiti a leheto legkevesebb fejfajassal megugrani.

Es ez meg nem is a legnagyobb projekt, amin valaha dolgoztam. Az abszolut rekorder az most tart 600 ezer (hatszazezer, nem eliras!) ticketnel (ticket, nem commit!), tobb GB a working copy, es a projekt kezdete ota mar tobb ezer fejleszto kodja kerult bele.

Ha valaki azt mondja, hogy ilyenekben eligazodik IDE tamogatas nelkul, csak vscode/vim/anyamkinja vackokkal, az vagy hazudik, vagy o az esoember, es a fejeben van az egesz kodbazis.

( KGer | 2024. 02. 07., sze – 20:14 )

Szerkesztve: 2024. 02. 07., sze – 20:27

STS Spring Tool Suite (eclipse) a nagy kedvencem, én szeretem, fasza, szinte mindent tud, vanamiben többet mint a többi

a többit nem tudtam megszeretni

számomra az elődleges java ide

de ez vallás és megszokás kérdése is