Szerintem ez eléggé releváns.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Ez mar java 9.
En most raktam at 11-re egy nagyobb projektet es leginkabb az eltavolitott modulok erintettek.
[link]

Thank you to god for making me an atheist

Sziasztok! Nem tudom, hogy jó helyen járok, de azért megkérdezem, hogy ismertek helyet, ahol még kapni lehet az Agyhullám: Java című könyvet? (vagy, ha esetleg van valakinek egy amitől szívesen megszabadulna, akkor azt megvenném)

Sziasztok!
Szeretnék egy javascriptet megnyitni az oldal többi részének a betöltése nélkül. Erre van mód valamelyik böngészőben?
Egy reklámbannert szeretnék ily módon megnyitni.

Sziasztok!

Java-ban van arra lehetőség, hogy mondjuk egy mappában lévő zenéket beolvassam egy tömbbe?
Úgy gondoltam, hogy hozok létre egy zene class-t. Ebben 3 változó van. 2 String és egy int. A két string a zene nevét illetve a műfaját tárolná, míg az int a zene értékelését.
Minden beolvasott zenénél hoznék létre egy objektumot és azt az objektumot raknám be egy tömbbe, de úgy hogy már a zene hozzá passzoljon.

köszönöm

Van.

[link]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Sziasztok.

Adott a következő kérdés: Egy szál egy objektum wait() metódusát készül végrehajtani hiba és exception nélkül. A metódus rendben visszatér. Sorrendben milyen állapotokat vesz fel a szál wait meghívásától kezdve a metódus visszatéréséig?

Most ez ugye: Runnable, Waiting, Blocked, Runnable. Kérdés, hogy ugye a notify hatására megy át a blocked-ba, ekkor még nem tért vissza a wait? Illetve a második runnable-t oda kell írni a végére?

Itt több esetet kell majd szétválogatni szerintem. Induljunk egy runnable állapotból, ekkor a lépések:

1. A foobar.wait() hívása előtt meg kell szerezni a monitor lockját. Ez vagy sikerül elsőre vagy blocked állapotba kerül a thread, ha valaki másnál van lock.
2. Valahogy túljutunk az előző ponton, runnable állapotban van a thread és meghívódik a foobar.wait(). Az új állapot waiting.
3. Valamiért (*) felébred a thread, runnable állapotba kerül. Ahhoz, hogy ki tudjon lépni a wait()-ből kell a monitor lock. Itt megint vagy sikerül elsőre vagy blocked állapot jön és ha megvan a lock akkor runnable megint.

(*) A notify() hatására átmehet blocked állapotba a thread. A foobar.notify() híváshoz is kell a monitor lock. Ha a felébresztett thread már futna, de a notify()-t hívó thread még fogja a lockot, akkor a felébresztett thread megy a blocked állapotba. Ha viszont véletlen úgy kapna cpu időt, hogy a notfiy()-t hívó thread (és mindenki más) már eleresztette a lockot, akkor ki is maradhat ez a blocked állapot.
Viszont nem csak a notify() miatt mehet át ilyen állapotokon a thread. Például spurious wakeup miatt a wait()-et hívó thread még a notify() hívás előtt is felébredhet "magától". És akkor itt megint jön az, hogy vagy runnable vagy runnable + blocked + runnable állapotokon megy át.

[ Szerkesztve ]

Java EE-hez milyen anyagot ajánlanátok leginkább, kezdő Java SE tudás mellé? Nézek most egy ilyet, ez nagyon tetszik: [link]. De szerencsére ezt ingyen tudom nézni. Ezen kívül tudtok valami jó Java EE képzést? Főleg általános jellegűekre gondolok. Amit említettem, az csak CDI, JPA, EJB és JAX-RS fókuszú. Érdekelne mik vannak amikről esetleg nem tudok, de érdemes lenne utána nézni. Olyan anyagokat keresek, amivel minél gyorsabban meg lehet tanítani Java SE programozókat, illetve pályakezdőket EE-re.

I am having fun staying poor.

Adjál nekik feladatot A leggyorsabb út

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Java EE-t ki használja még szívesen? Ha jól emlékszem Java 11-től már nem is lesz a része a referencia JDK-nak, teljesen az Apache fogja karbantartani.

Spring

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Gondolom ez van nekik. Ha zoldmezos projekt, akkor manapsag mar eleve nem sokan valasztananak Java-t.

while (!sleep) sheep++;

Ez mondjuk nettó nem igaz szerintem

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Én. JDK-bol azert kerultek ki a Java EE interfeszek tobbek kozott, hogy egyszerubb legyen a JDK/JSE kiadas. Lasd motivation resz itt [link]. Eleve nem kellett volna belerakni Java EE reszeket.
Eddig sem volt resze a Java EE modulok tobbsege a JDK-nak, onmagaban a JDK nem volt elegendo (Java EE) fejlesztesre.
Ezeket csak azért tartottam fontosnak leírni, mert a hozzászólásodat továbbgondolva arra a következtetésre juthatnak a témában kevésbé járatosak, hogy most lényegesen nehezebb lesz Java EE-re fejleszteni vagy hogy halott a történet, pedig a szóbanforgó változások nem jelentenek ilyet.

[ Szerkesztve ]

Thank you to god for making me an atheist

Én kicsit továbbra is úgy érzem, hogy az Oracle próbál megszabadulni az EE tartalom karbantartásától. Az én véleményem, hogy alapvetően nehezebb EE-ben dolgozni, nyilván nem halott mert sok alkalmazást kell még karbantartani.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Ez elég nyilvánvaló. De eddig is lassan mozgott a Java EE. Aminek nem csak hátránya van azért.
Meglátjuk a következő 1-2 évben, hogy mi lesz a Jakarta EE-vel.

Szerintem nem nehezebb EE-ben dolgozni, napi szinten használom mindkettőt évek óta és még mindig a specifikus igényektől függene, hogy melyikhez nyúlnék, ha valami zöldmezőset kellene csinálni.
Springben talán egyszerűbb kezdőként eredményeket elérni, de ha megvan a tudás Springben és Java EE-ben is, valamint egy jól összerakott, bejáratott architektúra, akkor elég jól lehet haladni mindkettővel.

Thank you to god for making me an atheist

Pedig itt stimmel mind a két dolog: zöld mező és java EE(7). Amúgy nekem mint kívülállónak, segítsetek megérteni miért jobb a Spring pl. a Java EE7-nél. Mi az, amit nem lehet, vagy nagyon nyakatekerten megcsinálni Java EE7-ben, de Springben nagyon simán.

Ami problémám van a Java EE-vel, hogy nem sok hozzá a jó anyag, illetve tesztelés nagyon nehézkes. Ezekben feltételezem jobban áll a Spring.

I am having fun staying poor.

A springhez elég egy servlet konténer, nem igényel egy böszme alkalmazás-szervert. Pl.

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Például ez, ami engem megvett kilóra. Ennyi lenne egy tök alap rest apit készíteni.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Java EE-hez is tudsz fat jart gyártani. Igaz a minimális méret ami szükséges így is jóval nagyobb, mint a minimális Spring boot csomag. Többet is nyújt out of the box, de tény, hogy nagyobb. Mondjuk 50 MB alatti méretről beszélünk, ami vagy számít, vagy nem.

(#10030) mobal: Java EE-ben ez pont ugyanennyi, csak más annotációkat kell használni. Egy dolgot leszámítva: A JpaRepository-nak megfelelő ősosztály nincs külön benne a Java EE-ben, azt csinálni kell egyet magadnak.

[ Szerkesztve ]

I am having fun staying poor.

Tehát végülis időt spórolhatok a Spring-gel.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Ebből a példából ezt egy több éves projekt esetében elég nehéz lenne azért kijelenteni. Egy ennek megfelelő általános osztályt azért pár perc alatt java EE-hez is össze lehet dobni. Ebből a példádból az látszott, hogy könnyebb egy bonyolultabb alkalmazás alapjait összerakni. De arra nem lehet belőle extrapolálni, hogy bonyolultabb use case-ekben van-e olyan eset, amiben esetleg a Java EE-ben van egyszerűbb megoldás. Nem azt állítom, hogy van, csak az érveléseddel szállok vitába.

Ui.: REST szerver funkcionális tesztelésére mit javasoltok? REST assured-t nézem most, elsőre tetszik amit látok, de kíváncsi vagyok van-e jobb javaslat. Az, hogy Java alapú, előnynek számít most nálam. Főleg ha a webszerver is Java alapú. Vannak dolgok, amit így kis fájdalommal újra lehet használni.

I am having fun staying poor.

Nézd, én nem értek az EE-hez bevallom. De számomra pont emiatt a Spring sokkal egyszerűbbnek tűnik, mert az tény, hogy telepítés után "nem kell sokmindent" csinálni, csak használni.

Nyilván ez igaz sok év EE után is.

REST assured jónak tűnik.

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Nem hiszem, h lenyegesen jobb. Van egy csomo ember, aki szerint csak egyfele dologgal lehet mukodo programot csinalni, de valojaban tokre nem. Pl. elosztott tranzakciokat EE-vel szerintem egyszerubb.

Amiert en nem annyira allnek neki EE-nek az az, hogy a reaktiv (nem thread-centrikus) szoftverek keszitese nem egyszeru vele, mondjuk Springgel sem tulsagosan.

Meg EE-re nehezebb embert talalni, pont azert, mert a legtobb fejleszto stackekre fokuszal. Szoval osszessegeben en se kezdenek EE-vel, nem technikai okok miatt, hanem mert most epp ugy all a Java backend kultura, hogy 'Springes embert' egyszeru talalni.

[ Szerkesztve ]

while (!sleep) sheep++;

Igen, itt a lényeg. Kompetencia nincs manapság EE-re, mindenki beleesett ebbe a Springbootos őrületbe, ami persze n em baj, mert jó cucc alapvetően.

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Maradjunk annyiban, hogy mindenki menekül az EE környékéről, amióta kuka lett.

Én ezt nem így tapasztalom. Legalábbis kis hazánkban nem. Állami megrendelők még mindig csak EE-ben tudnak gondolkodni, a Spring maximum szitokszóként fordul elő, hogy az "hé, nem enterprááájzzz..." És ha még mellé standalone Spring Boot...nah akkor aztán világvége

[ Szerkesztve ]

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Állami megrendelők... ne viccelj

Komoly piaci szereplők, amikor szóba kerül, hogy állami megrendelők milyen követelményekkel állnak elő, körberöhögnek. Liferay... oracle... valami kakás MVC... eszement clusterek

Spring boot + kotlin vagy node + express, docker, mongo, react/angular, cloud, mobil app... ez a minimum, ha labdába akarsz rúgni. Az összes többi múlt idő, mint a lyukkártya

BTW amikor megemlítjük, hogy néhány fejlesztőnek windows-os gépe van, akkor is van mosolygás

[ Szerkesztve ]

De ez csak azért van, mert még kezdők az illetők a szakmában de tényleg, mosolyogni embereken, mert Windowsos a gépük, meg azt gondolni, hogy egy 5 éves technológia már olyan, mint a lyukkártya? Ez jellemzően a kb. 7-10 év tapasztalattal rendelkező, de azért túl sokat nem látott technológusokra jellemző, akik azt gondolják, hogy a frameworkok fogják megoldani a problémáikat, meg hogy valami drámai fejlődés tud történni 5 év alatt.

A bonyolult projektek nem azért dőlnek be, mert MVC-t használt valaki, vagy mert EE-re épült a projekt Spring helyett

while (!sleep) sheep++;

Komoly, nagyméretű projekteket egyszer kialakítanak egy akkori technológiával, majd utána azt karbantartják és funkciószinten tovább fejlesztik ill hibát javítanak. De semmiképp nem állnak neki csak azért újraírni, mert bejött valami újabb technológia. Azonban sokszor van, hogy egyszer csak találnak büdzsét, elkölteni való pénzt é akkor kitalálják, írjuk újra "korszerűre" - az ilyennek legtöbbször az a vége, hogy egy funkcióban szegényebb, kezelhetőségben rosszabb, de csillivillibb és papíron korszerűbb terméket alakítanak ki, amit a felhasználók a pokolba kívánnak, mert a régivel semmi baj nem volt.
Személy szerint több példát láttam kórházi, egészségügyi rendszerek ilyetén való átalakításra. Volt egy karakteres, de gyorsan használható letisztult felület, amit átraktak egy grafikus guira. 10-szer akkora hardver 10-ed akkora felhasználói sebesség, rengeteg hibázási lehetőséggel. Mindez rengeteg pénzbe, időbe és energiába került, az a eredmény, az előrelépés pedig 0. De..., új technológiákat használtak. Hurrá!

Szerintem ez az új és újabb technológia kergetés egy rossz gyakorlat.

Aki tejszínhabot szeretne, az inkább verje ki a fejéből!

Windows-os géppel mi a probléma?

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Nem múlt idő az, mivel qrva sok állami projekt van.

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Sziasztok!

Oracle-ből szeretnék lekérdezni egy bizonyos táblából. Találtam rá main programban try catch-el megvílósított megoldást, de mindenhol csak ezt...

Szerintetek hogy lenne a legegyszerűbb oracleből adatot kinyerni? A Szentháromság esetemben Tomcat+Axis2+Java. És persze WebService lesz. Hosszú távon több is, adott esetben mi leszünk a kiszolgálók, néha a fogadók, de most a kiszolgálóság az érdekes.

Sony XZ٩(̾●̮̮̃̾•̃̾)۶ / LG UJ620V / Kanto YU6

Ez engem is érdekelne. Legtöbb helyen, ahol dolgoztam/dolgozok (rendszermérnökként) ott mind windows van és ötvenből, ha ketten használtak linuxot (pedig bármikor feltelepíthették volna maguknak vagy megkérhettek minket, hogy telepítsük fel, ha annyira szerettek volna abban dolgozni)

Simán jó a Win10. Dockert is használok, semmi hátránya nincs - csak előnye (Office stack miatt).

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Az "ezt" nem látni.

Alapból jdbc kell hozzá, utána meg se szeri, se száma az eszközöknek amik az adatbázis objektumok kezelésére szolgálnak.
Így elindulhatsz: [link]

Aki tejszínhabot szeretne, az inkább verje ki a fejéből!

Van persze sok olyan ember, akinek ettől lesz adrenalin. De te is általánosítasz kissé. Sokan a "nagyobb tapasztalatukkal" azért nem hajlandóak az újabb technológia irányába mozdulni, mert lusták, rugalmatlanok, nem fektetnek R&D-be, vagy kivárnak, amíg mindenki elmegy mellettük

Nyilván sokéves rendszereket nem ír újra jellemzően senki, bár több olyan ügyfelünk is van, akik már 10 éves rendszereknél nem a polírozgatáson gondolkoznak. A bedőlés emberi tényező, de nem is ez a lényeg. Nagyon elment az igény az új technológiák irányába zöldmezősök esetében, és senkit nem fog érdekelni, hogy mi a véleményed az igényekről Nyilván ez igaz visszafelé is, ha szerinted pl. a mongo jobb lenne content managementre, elastic meg monitoringra, de az ügyfél baromira liferay/sql párti, de szerencsére ez kopik kifelé.

(#10042) mobal semmi, nekem is tök jól fut rajta a shadow warrior

(#10046) mobal lényegében virtuális gépeket használsz konténerek helyett, ami eltérően viselkedhet a production környezethez képest. Mert az feltételezem, hogy nem windowsos docker a live.
Akkor inkább már VBox-ban ubuntu/debian és azon docker.

[ Szerkesztve ]

"Mert az feltételezem, hogy nem windowsos docker a live.
Akkor inkább már VBox-ban ubuntu/debian és azon docker."

Lehet én értem félre, amit írsz, de Windows-ra nincs natív docker. A Docker Toolbox és a Docker for Windows - bár ez próbál natívnak tűnni - is egy virtuális linuxon fut, szóval sok előnye nincs használni egy dedikált linux vm-et, hacsak az embernek nincs szüksége valami linux specifikus eszközre. A local környezet meg soha nem lesz olyan, mint a production, ehhez úgyis illik egy teszt környezet, ami minél jobban közelít a production-höz.

De persze a fejlesztő dolga mit használ.

[ Szerkesztve ]

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

Persze, teljesítményben nem leszel előrébb, meg nyilván egy dev box sosem lesz olyan mint egy production. Viszont bitre ugyanazt a stacket használhatod, mint ami a kész rendszerben lesz