- Bambu Lab 3D nyomtatók
- Épített vízhűtés (nem kompakt) topic
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- Projektor topic
- Azonnali notebookos kérdések órája
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Milyen billentyűzetet vegyek?
- OLED monitor topik
- Azonnali alaplapos kérdések órája
Új hozzászólás Aktív témák
-
-
Drizzt
nagyúr
válasz
btraven
#12008
üzenetére
Ha kifejezetten méretre lősz és nem muszáj JDK only megoldást adni, akkor lehet jobban jársz, ha valamilyen cél library-t használsz. Némi összehasonlítás: [link] Főleg a 3.4 performance az érdekes.
Btw: Nagyban függ attól, hogy mi egyéb van még az osztályokban, ha csak egész számok, akkor hány darab, etc. De ha nagyon optimalizálni akarsz méretre, akkor lehet nem is magát a classt kéne szerializálni, mert az nyilván hoz magával mindenféle metadatát, ami tuti sokat fogyaszt. -
Drizzt
nagyúr
válasz
Ablakos
#11983
üzenetére
Nem hinném, hogy máshogy kéne fordítani. De nem lehet, hogy valamelyik Java verzióban változott a viselkedés? Melyik verzióval fordítasz? Ki tudsz próbálni másikat is?
Rövid utánanézés után mintha a Java 11-ben lett volna ezzel kapcsolatos módosítás? Hányas Java OCP-t nézel és milyen JDK-val fordítasz?
-
#11980
Drizzt
nagyúr
Steve_Brown
#11978
Drizzt
nagyúr
válasz
Steve_Brown
#11978
üzenetére
Valahova nem tudod felrakni maven, vagy gradle projektként, hogy próbálkozhassunk vele?
-
#11945
Drizzt
nagyúr
Foglalt név
#11940
Drizzt
nagyúr
válasz
Foglalt név
#11940
üzenetére
Szabadni szabad, de nem tul szep. Interface moge viselkedest illik rejteni, igy pl. azt, hogy miket tudnak csinalni az allatok, szivesen kiszerveznem interface-be, de azt, hogy milyen tulajdonsagai vannak az allatoknak, inkabb nem.
A backend dolgot nem tudom itt hogyan erted. -
#11939
Drizzt
nagyúr
Foglalt név
#11937
Drizzt
nagyúr
válasz
Foglalt név
#11937
üzenetére
Tobbfele megoldas lehet, de talan a legegyszerubb az, ha csinalsz egy Activity osztalyt, ami leirja, hogy mit es hogyan tud csinalni az az Activity.
Az allat osztalyban meg eltarolsz egy Activity Collection-t, amire csinalsz egy getter-t.
Aztan az Activity-bol csinalhatsz mondjuk egy KangarooHidingActivity-t, ami a konstruktoraban megkap egy Kangaroo-t. A Kangaroo konstruktoraban meg megcsinalod a KangarooHidingActivity-t, meg a masikat es belerakod oket egy collection-be.
Igy amikor vegigmesz egy Animal Collection-on, le tudod kerni az egyes Activity-k kollekciojat allatoktol fuggetlenul, azok az Activity-k meg megis kepesek lesznek allat specifikus dolgokat csinalni, az eppen megadott allaton.
Azt nem tudom, hogy ez egy ismert pattern-e, meg van-e neve, de egyszeru esetben valami ilyesmit csinalnek. A Command pattern nagyjabol ez, de talan nem pontosan. -
Drizzt
nagyúr
válasz
Ablakos
#11903
üzenetére
anyMatch egy Predicate-et vár. A Predicate egy olyan függvény, ami valamilyen bemenetre egy booleanüt ad vissza.
Az anyMatch addig folytatja a kiértékelést, amíg a predicate igaz nem lesz. Tehát jelen esetben addig, amíg nem talál olyan elemet, ami nagy A-val kezdődik. Utána leáll a további feldolgozás, mert teljesen felesleges lenne. -
Drizzt
nagyúr
válasz
btraven
#11879
üzenetére
[Például]
De egyébként A hello world egy unit tesztelhetőség szempontjából pont eléggé faramuci dolog, mert ott a függvényedet le kellene választani a környezetéről. Ha nem a környezetéről leválasztva tesztelsz valamit, akkor az az én szememben már inkább integration teszt.
Egy olyan függvényt, ami a standard outputra kiírja, hogy Hello world, nem lehet jól unit testelni, mert a standard outputot kell mockolni, ami meg csak ilyen nyakatekert módokon oldható meg.
Ha viszont olyan függvényed lenne, ami visszaadja, hogy: "Hello world" -> remekül unit tesztelhető. Olyan, ami kap egy outputstream-et input-ként és kiírja rá, hogy "Hello world" -> szintén remekül unit testelhető.
"Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek."
Ez utóbbi mindig nagyon gyanús. Én is mindig azt hiszem, ogy jó, triviális kódokat írok, aztán amikor elkezdem tesztelni, szinte mindig kijön valami turpisság. Nyilván a tesztelés mehet három módon: kézzel pöcögtetve: valószínűleg jó kódot eredményez, de ha legközelebb aki hozzányúl, nem olyan alapos, mint aki írta és kézzel tesztelte, akkor rögtön veszélyes lesz módosítani a kódot. 2.: vagy azonnal automata tesztet írni, vagy az előző pont kézi eseteit automatizálni. Ez elég jó általában. 3.: előre írni meg a tesztet és csak utána a kódot. Pont az a nagy előnye, ami miatt elsőre nagyon nehéz vele dolgozni: végig kell előre gondolni az elvárt viselkedést és a trükkös eseteket is. Erre gyakran használt kifogás, hogy sokat változik az elvárás, azért nem kezdenek vele. De nem teljesen korrekt érv, hiszen anélkül, hogy tudná mit akar csinálni az ember, el sem tud mit kezdeni programozni.
Én tényleg csak alkalomszerűen TDD-zek, de örülnék, ha valamikor elkezdenénk végignyomni vele teljes projekteket, mert minőségben ég és föld a különbség. Ha előre írsz tesztet, akkor sokkal jobban át tudod gondolni, hogy milyen osztályoknak, milyen interface-eken keresztül kell tudniuk egymással beszélni. Sokkal könnyebb elkerülni a spagetti kódokat. -
-
Drizzt
nagyúr
válasz
Ablakos
#11864
üzenetére
Akkor nem értem a problémát, nálam teljesen jól működik:
Name (empty will stop):
mybook
Publication year:
1
Thank you! Books added: 1
Name (empty will stop):
mybook
Publication year:
1
The book is already on the list. Let's not add the same book again.
Name (empty will stop):
Thank you! Books added: 1
Name (empty will stop):
yourbook
Publication year:
2
Thank you! Books added: 2
Name (empty will stop):
mybook 1
yourbook 2(Thank you! Books added: egy picit félrevezető kiírás, mert akkor is jön, ha nem adtunk hozzá semmit)
-
Drizzt
nagyúr
válasz
Ablakos
#11862
üzenetére
A contains megmondja, hogy érték alapján van-e egyező elem az adott kollekcióban azzal az objektummal, amit paraméterként kapott. Azt, hogy érték szerint megegyezik-e valami, az equals metódus jelenti a Javaban. Ha van szerinted jó equals és nem így működik, akkor mutasd meg az equals-odat.
-
Drizzt
nagyúr
válasz
Ablakos
#11860
üzenetére
Az Arraylist contains hasznalja az equalst. Ha nincs korrektul implementalt equals a Book classban, akkor csak abban az esetben fog igazat adni, ha ugyanazt a referenciat tartalmazza az egyik, meg a masik book. Erdemes viszont akkor mar hashCode-ot is implementalni, mert mas kollekciok hasznalhatjak azt is a contains eldontesehez.
-
Drizzt
nagyúr
válasz
MrSealRD
#11837
üzenetére
Sajnos nem erted az emberek mukodeset, meg a traumak hatasat. Hiaba mondod esetleg azt, hogy ma mar nincsen rabszolgasag, ezert nem lehet traumatizalo hatasa az emlitesenek, de a traumak jelentos resze generaciokon tovabboroklodik. Persze az egy remek dolog, ha ezzel el kezd foglalkozni az ember, de ott ahol a lakossag 12%-a potencialisan kitett ennek a problemanak, ott elegge irrealis azt mondani, hogy akkor mindenki oldja meg es menjen pszichologushoz kozuluk.
Valamint ott sem biztos, hogy mindenki arra a pontra fog eljutni, hogy ot valojaban ez nem is zavarja, mert nem neki szol, lehet inkabb az ezen kifejezesek megszunteteset kero enje fog eloterbe kerulni. Ha valaki azt erzi, hogy serti valami, akkor a pszihologusnal egyaltalan nem biztos, hogy az fog kijonni, hogy akkor elfogadom a sertest. Sokkal valoszinubb, hogy az fog kijonni, hogy akkor szembeszallok vele nyiltan, mert tartom magamat annyira, hogy ne engedjem megalazni masok altal.
Ez egy gesztus, ami egy lepes egy empatikusabb, bekesebb vilag fele. Nem oldja meg a vilag gondjait, sokaknak megis szebb lesz toluk a vilag, kevesebb az alapfeszultseguk.
Egyebkent en sem talaltam volna semmi bantot a master branch nevben, de nem nekem tisztem megitelni, hogy banto-e, mert nem vagyok erintett. Foleg ugy, hogy itt nincs melle mondva a slave kifejezes, ez nehezebben erthetove teszi a dolgot a szamomra is. De ez nem nekem szol. Annyira nem lesz nehez ket betuvel kevesebbet gepelnem, meg neha rajonni, hogy jeee, itt master van. Multbeli dolgokat, muveket en sem valtoztatnek meg, de azert raknek mellejuk disclaimereket. -
Drizzt
nagyúr
válasz
MrSealRD
#11832
üzenetére
Egyreszt magahoz a szakmahoz is van koze, ha masert nem, az emlitett fekete fejlesztok miatt. Masreszt meg a szakma termekeinek is van celkozonsege. Ott aztan vegleg hatalmas versenykepessegi eleses, ha nem gondolsz mindenfele marginalizalt csoportra.
Valahol a lenyeg ott van, hogy szerinted csak hipererzekeny viraglelkueket zavar a dolog, de valojaban nem. Az emberre a dolgok nem csak tudatosan hatnak, a felszin alatt hatalmas lelki es ezen keresztul kesobb fizikai bantalmat tudnak okozni. De errol ne nekem higyj, inkabb pszichologusok/pszichiaterek tapasztalatait vedd figyelembe.
Azzal, hogy aki ellenvelemenyt fogalmaz meg, en sem ertek egyet, hogy el kellene nyomni. Ellenvelemenynek mindig van helye. -
Drizzt
nagyúr
válasz
btraven
#11828
üzenetére
Valoszinuleg sosem fogd megerteni, hogy mit jelent egy feketenek a mester szo hallata. En sem fogom, bar szeretnem azt hinni, hogy igen. De nem vagyok naiv, sosem fogom valoban aterezni milyen rabszolgacsalad sarjanak lenni, barmekkora is az empatiam. Az ilyen szavak tudat alatt is hatalmas karokat tudnak okozni az erintetteknek. S az is persze igaz, hogy Magyarorszagon tok mas az elsodleges jelentese a leforditott szonak, emiatt megint mas elkepzelni a pszichologiai hatasat. Idehaza persze elsosorban a mindenhez erto ember jon elo a szo kapcsan, nem a korbacsos rabszolgatarto. Meg az is igaz, hogy biztosan korulvesz minket ezer olyan szo, ami mas emberekben szorongast valt ki. Es persze eszre se vesszuk. Azert amik eleg szeles korben okoznak problemat, az reszemrol nem baj, ha atnevezesre kerul. Meg fogom birni szokni, hogy 1 betuvel kevesebbet kell gepelni.
-
Drizzt
nagyúr
válasz
floatr
#11817
üzenetére
Nem gyakori, de nem art, hogyha van az embernek az eszkotaraban valami, amivel tudja kezelni adott esetben. Nyilvan valos statisztikam nincs a dologrol, de egyebkent azert egyaltalan nem ritka, hogy sok duplikalt string van a heapen. Az mar ritkabb, hogy ezek hosszu eletuek is legyenek egyben. Es elsosorban akkor jon el az a szint, ahol erdemes kezelni.
-
-
#11814
Drizzt
nagyúr
yossarian14
#11808
Drizzt
nagyúr
válasz
yossarian14
#11808
üzenetére
Igen, az egy jó megoldás, de tudtommal csak G1GC mellett megy.
Vagy persze marad az, hogy csinál az ember saját dictionary-t és az abból lookupolt értéket rakja bele az objektumokba. -
#11806
Drizzt
nagyúr
Aethelstone
#11805
Drizzt
nagyúr
válasz
Aethelstone
#11805
üzenetére
Mit javasolsz helyette? Nekem van saját preferenciám, de kíváncsi vagyok mit mondanál rá.
-
Drizzt
nagyúr
Foglalni kell egy új tömböt, aminek a mérete a két tömb méretének a szorzata, a cikluson belül pedig egy indexet kell növelgetni és arra a poziícióra kell elhelyezni az éppen megalkotott elemet, ahol tart az index.
String[] lastNames = {"Nagy", "Kovács"};
String[] firstNames = {"Júlia", "Béla"};
String[] combinedNames = new String[lastNames.length * firstNames.length];
int i = 0;
for (String lastName: lastNames) {
for (String firstName: firstNames) {
combinedNames[i++] = lastName + " " + firstName;
}
}
System.out.println(Arrays.toString(combinedNames)); -
-
Drizzt
nagyúr
válasz
Lortech
#11709
üzenetére
Remek kérdés, hogy egyébként mit ért floodon? Csak annyit, hogy ne tudjon mondjuk 5 másodpernél gyakrabban post-olni valami endpoint-ra és elég ha eldobja a requestet, amennyiben az túl friss?
Mert akkor valahol simán el kell tárolni, hogy mikor jött a legutolsó sikeres request userenként és ha túl gyorsan, akkor eldobni. Erre is lehet persze csomóféle megoldás, a singleton beanben levő maptól a redisen át az adatbázisba eltárolt lastUpdateDate-ig. Függően attól, hogy mi a cél, hány instance van, etc.
Ha meg DDoS-tól kell védekezni, az nem a Spring boot alkalmazás feladata lenne ideális esetben valóban. -
Drizzt
nagyúr
válasz
fatal`
#11682
üzenetére
Nem sok gratulalni valo van az Oracle-nek, mert a JDK 1.1-es verzio, 1997. februar ota van az ObjectOutputStream, akkor meg nem volt koze az Oracle-nek a Javahoz. Ehhez a reszehez az implementacionak meg kb. senki nem is nyult hozza azota(Oke, csak 7-es OpenJDK-ban latom, hogy mar az initial load commitban ugyanez volt 2007-ben). Az Oracle meg 2010-ben vette meg a Sunt.
-
Drizzt
nagyúr
válasz
fatal`
#11680
üzenetére
Attol, hogy nyitva marad a stream, random adat nem fog belekerulni.
De direkt debugban vegiglepkedtem az idezett kodon, az Exception kiirasat az ObjectOutputStream.writeFatalException metodus vegzi az OutputStream-be.
A writeObject maga igy nez ki:public final void writeObject(Object obj) throws IOException {
if (enableOverride) {
writeObjectOverride(obj);
return;
}
try {
writeObject0(obj, false);
} catch (IOException ex) {
if (depth == 0) {
writeFatalException(ex);
}
throw ex;
}
}
11.0.11-es Oracle JDK-val neztem. -
Drizzt
nagyúr
válasz
btraven
#11666
üzenetére
Koszi a peldat!
Igy egyszerubb valaszolni a kerdesedre.
[Javadoc] : "Exceptions are thrown for problems with the OutputStream and for classes that should not be serialized. All exceptions are fatal to the OutputStream, which is left in an indeterminate state, and it is up to the caller to ignore or recover the stream state."
Szoval nincsen kulonosebben specifikalva, hogy mi fog tortenni Exception eseten. Elofordulhat, hogy kulonbozo JVM-eken es kulonbozo javaverziokon is kulonbozokeppen viselkedik, de a leirasaban benne van, hogy az esetleges szemetet a hivonak kell feltakaritani. Szamomra meglepo, hogy igy van. Szoval a catch agban zard a Streameket, majd torold a fajlt, ha van.
Ha atirod a peldadat "try with resources" alapon, akkor a close-et nem kell sehol meghivnod, mert a ket outputstream autoClosable. -
Drizzt
nagyúr
-
Drizzt
nagyúr
válasz
bambano
#11597
üzenetére
Pedig tok egyszeru a dolog.
Van kiindulaskor valamennyi(n) darab bucket. A bucketek gyakorlatilag tombok. Tehat van egy n elemu tombod. Minden bucketben van egy linkelt lista, vagy valamilyen annak megfelelo struktura.
A hash fuggvenyen nem modositanak semmit, mivel azt Javaban a user-nek szokas megadnia(oke, altalaban a Lombok irja meg helyette, meg lehet hasznalni a default implementaciot is, de az lehet lassu bizonyos esetekben).Kereses kulcs alapjan:
- Meghivod a kulcsra a .hashCode metodust. Igy kapod az x erteket.
- Kiszamolod , hogy x mod n = z alapjan mi a z.
- A z. bucketet kikeresed(ez egy lepesben megvan).
- A z. bucket osszes elemen vegigiteralsz, s megnezed, hogy a kulcs equals-e az eppen iteralas alatt levo elemmel. Ha igen, akkor az ott szinten eltarolt erteket visszaadod.Mikor lesz ez az egesz lassu?
- Ha a hashCode ugy van megirva, hogy minden kulcs ugyanabba a bucketbe keruljon, vagy legalabbis a bucketek egy kis reszebe. Ilyenkor abban a bucketben egy hosszu lista lesz, ami miatt nem o(1) lesz a lookup, hanem kozeliti az o(n)-et.
Ugyanez akkor is igaz lenne, ha a map-ben levo elemek szama joval nagyobb lenne, mint n. Mit csinal ez ellen a Java? Figyel egy toltottsegi szintet. Ha a toltottsegi szinte egy hataron tul van, akkor fogja, s csinal 2*n uj bucketet, s a meglevo elemeket belerakja, a regi n bucketet meg eldobja.Ebbe a pogramozo is bele tud szolni, van olyan konstruktor, amiben meg tudod adni a kezdeti n-t, s a toltottsegi tenyezot. Szoval ha tudod, hogy rohadt sok elemet fogsz belepakolni, akkor rogton csinalhatsz egy HashMap-et jo nagy n ertekkel, s akkor meguszol par rehash-t. Alapbol 16 bucket lesz, amit akkor ujrahashel, ha legalabb 13-ra no a size. Ekkor 32 bucket lesz, majd ha size legalabb 25 lesz, akkor ujrahashel 64 bucketbe, stb.
A LinkedHashMap az egy specibb valtozat, ahol az egesz HashMap-en tul egy LinkedList is fenn van tartva, ami az osszes elemet tartalmazza a hozzaadas sorrendjeben. Akkor kell hasznalni, ha fontos a hozzaadas sorrendjet tudni.
-
Drizzt
nagyúr
válasz
btraven
#11585
üzenetére
"Nem lett bonyolult a helyzet ezzel a lambda meg stream-ekkel?"
Nem, sokkal egyszerűbb lett. Egyébként lambdát nem kötelező használni, ahol tudok inkább method reference-et használok. A streamnek meg fontos képessége a lazy eval, meg a concurrency support. Bizonyos problémákat tök egyszerűen, szépen, elegánsan és hatékonyan meg lehet oldani funkcionális eszköztárral, amit amúgy bonyolultan/csúnyán lehet megoldani nélküle.
"Annak idején egy fejlesztőnyelv/eszköz-ben csak az volt ami nagyon kellett. Minden le volt dokumentálva és minden úgy működött ahogy a doksiban volt."
Ez ma is így van. Maximum 1-2 szinte már sosem használt nyelvi elem léte lenne megkérdőjelezhető, de azok meg maradnak némi backward compatibility miatt. Az meg ha esetleg azért kérded ezt, mert szerinted a Stream felesleges, akkor egyszerűen még nem éreztél rá. Nélküle nagyon szar lenne az élet, ezt pár évi gyakori Stream használóként mondom. Nézz végig valamilyen alap fukncionális progamozást traininget, után egyértelműnek kellene lennie miért ilyen fontos dolog.
"Most már nehéz a programozó élete. A sok nyílt forráskódú, ingyenes cuccban az egyik fele nincs dokumentálva a másik fele meg hibásan működik vagy éppen sehogy. Ugye azért nyílt, mert majd kijavítod magad ha nagyon kell. Csak nem képzeled hogy ingyen még hibátlan is legyen?"
Ez megint nincs így. A lefontosabb, legnépszerűbb framework/libek leggyakrabban használt funkciói eléggé stabilak, ritkán kell körbebástyázni őket. A probléma az esetek 95%-ban abból adódik, hogy valaki megspórolja az alapjaik megismerését és anélkül kezdi őket használni valami olyan célra, amire nem feltétlenül alkalmasak. Még ha elő is fordulnak bugok, sokkal előrébb jársz, ha valami libet használsz rájuk, mintha 0-ról kezdenéd megírni. Sokkal tovább tartana, s a minősége is szinte borítékolhatóan rosszabb lenne.
Az utóbbi évekből pár dolog, aminek én nem voltam elégedett a dokumentációjával: annotation processor, Spring boot property source használat belsőségei. De az is lehet csak nem a megfelelő dokumentációt olvastam. Ráadásul Java-ban az se megy ritkaságszámba, hogy korábbi open source lib a nyelv részévé válik, pl.: Joda-time. -
-
-
Drizzt
nagyúr
válasz
Csaby25
#11536
üzenetére
Az elkészülő - feltétlezem JAR-ban is benne van? Ha igen, ott, ahol lennie kellene?
Ha nincs felülírva, akkor a /static, vagy /public mappában kellene lennie a classpathon futási időben.
Ha nincs ott, akkor maven, vagy gradle setup lesz a probléma. Vagy ha esetleg csak IDE-ben nem megy java -cp-s futtatással, akkor az IDE-ben kell megkeresni azt, hogy miért nem olyan classpathot rak össze futtatáskor, mint amit kellene. -
Drizzt
nagyúr
válasz
btraven
#11514
üzenetére
Ja igen. A helyzet az, hogy az a2 nem módosulhatott. Valami más miatt tűnik úgy, mintha ez történt volna. Hogy néz ki az A class? Nem véletlen valami static field-et állít át a konstruktora? Mi alapján gondolod, hogy a1, meg a2 is "hi"?
Itt egy példa, hogy ennek a fajta értékadásnak az a2(, a példában s2) által mutatott címet nem szabadna mósodítania.
@Test
void assignment() {
String s1 = new String("Hello");
String s2 = s1;
s1 = new String("hi");
System.out.println(s1);
System.out.println(s2);
System.out.println("s1 default hashcode: " + System.identityHashCode(s1));
System.out.println("s2 default hashcode: " + System.identityHashCode(s2));
}
Output:
hi
Hello
s1 default hashcode: 1366025231
s2 default hashcode: 1427889191 -
Drizzt
nagyúr
válasz
btraven
#11512
üzenetére
Nem poolozva vannak, hanem egyszeruen az osztaly/interface tipusu valtozok gyakorlatilag pointerek. Szoval ezekkel a sorokkal kb. az alabbit csinaltad:
A heapen letrehoztal egy A tipusu peldanyt. A kis a valtozot letrehoztad a stacken, ami az elobb letrhozott heapen levo peldany cimere mutat. Letrehoztad az a2 valtozot a stacken, ami ugyanarra a cimre mutat az ertekadas miatt, mint a.Emiatt van az is, hogy nyelvi alapelem lett az equals, hogy latvanyosan megkulonboztetheto legyen az ertek szerinti osszehasonlitas a cim szerintitol.
-
Drizzt
nagyúr
-
Drizzt
nagyúr
válasz
Csaby25
#11464
üzenetére
Meg kell mondani az alkalmazasnak inditaskor, hogy melyik profilokat hasznalja. Application.properties by default mindig beolvasasra kerul, a - dev-hez aktivalni krll a dev profile-et. Asszem ha jar-kent inditod, akkor - Dspring.profiles.active=dev a megfleelo kulcsszo, de fejbol irom, lehet rossz.
-
-
#11431
Drizzt
nagyúr
Aethelstone
#11429
Drizzt
nagyúr
válasz
Aethelstone
#11429
üzenetére
Mostmar ha elorangattad, ne hatralj ki.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Erre en csak annyit akartam irni, hogy eddig olyan 5 eves maven hasznalatom alatt egyszer sem jott szembe olyan dolog, amire nem lett volna letezo plugin, ami megoldotta a problemat. Oke, vannak azert olyanok, amitol jobbat is el tudnek kepzelni, de egyutt lehet vele elni. Van amugy joval hosszabb programozoi tapasztalatom(ossz. ~15 ev), de OOP/Java az legyen inkabb 5 ev. Ezert 5 ev a maven is.
Illetve ami pl.: Gradle-re atteressel problema lenne, hogy van egy jo szazas nagysagrendu microservice, ami azert jelenleg elegge hasonlit build projektileg. De ettol fuggetlenul mindegyikben johet fejlesztesi igeny. Ha meg hirtelen a projektek egyik fele maven, a masik fele meg gradle lenne, bevinne egy szep kis extra komplexitast. -
Drizzt
nagyúr
válasz
btraven
#11422
üzenetére
De, szabad hasznalni. Viszont ha nem valamilyen factory metodusban hasznalod, akkor gyanus, hogy lenne helyette szebb, biztonsagosabb, bovithetobb OOP megoldast talalni a problemara. Nyilvan nem mindig. Akkortol jon a gond, ha tobb metodusban ugyanazon ertekkeszlet alapjan kell kulonbozo dolgokat csinalni, mert konnyen el lehet cseszni, ha bovul az ertekkeszlet.
-
Drizzt
nagyúr
válasz
floatr
#11417
üzenetére
Remek, de ezekre nincs szuksegunk. Egyszer jo lenne atterni, de joval nagyobb annak az ara, mint amit itt sugallsz. Mindenkeppen eltart egy ideig, mig egy programozo csapat atszokik egy masik build tool-ra. Nyilvan van az a helyzet, amikor a relativ koltsege az atallasnak kisebb, mint a relativ haszna. Nalunk jelenleg nem az.
-
Drizzt
nagyúr
válasz
floatr
#11410
üzenetére
"A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest." Nem ertek egyet. Ez csak akkor igaz, ha az adott build rendszerhez es az azzal szembeni kovetelmeneykhez is valaki nagyon ert. Igazabol aztan utana tok mindegy, hogy pipeline-bol mavent, vagy gradle-t hivok meg.
Projektek atlagos build ideje ket perc mavennel. Intellij meg ugyis feldolgozza az egeszet belso projekt formatumra, ami sokkal gyorsabb, foleg ha szelektiven akarsz valamit futtatni. Kiprobalnam en is elesben a Gradle-t, de nem igazan varok tole semmi valos hasznot a mi use case-unkben. Ha nagyon nem lesz semmi dolgunk, akkor majd rakerul arra is a sor. A mostani maven service template-jeink tokeletesen megfelelnek az elvarasainknak, a lecserelesukben sokkal tobb lenne a potencialis risk, mint a potencialis benefit. -
Drizzt
nagyúr
Alapvetoen van, de elsosorban business case-ekhez kototten. Meg igyekszunk mindig uj dolgokat behozni, ha hasznos, vagy hosszan tarto megoldast adhat. De nalunk mindenki erosen devops/automated tester/data magus is egyben, s legkevesbe izgalmas/lenyeges resz az egeszben a java build. Nyilvan a magussal tuloztam, de inkabb a szeles tudas az, ami nalunk a fokusz, nem pedig a reszletekbe meno tudas egyes alteruleteken.
-
Drizzt
nagyúr
Ha keresztbe-kasul ismersz valamit, s atlagban egy problemat 3mp megoldani neked benne, akkor nagyon nyomos erv kell ahhoz, hogy lecsereld valami masra, amiben ugyanez a folyamat a kompetenciad hianya miatt eltartana vagy 1 napig.
Nalunk minden regi es minden uj projekt is maven, szimplan azert, mert van par emberunk, aki nagyon ert hozza. Ok tenyleg kb. 5 perc alatt a legkomplexebb projekteket is atlatjak, mig Gradle-hez nincsen ilyen emberunk. A build time meg nem kritikus.
Persze lenne haszna gradle-zni, legalabb lenne eselye kialakulni benne mely kompetencianak. Ha ma kezdenek Javazni, biztos azzal kezdenek. Igy viszont, hogy teljesen otthonos terep a maven, foleg ezt hasznalom, itthon is. Volt projekt amit gradle-lel kezdtem, de semmi nem vitt ra utana, hogy a kovetkezot is azzal csinaljam. Van boven mas szakterulet, ahol tobb hasznot hoz a raforditott tanuloido.
-
Drizzt
nagyúr
válasz
Szmeby
#11386
üzenetére
Ez a Spring Data Rest default viselkedese. Convention over configuration, mint megannyi mas helyen a spring bootban.
Megfeleloen uj Spring verziokkal o lesz a baratod: [stackoverflow: set exposed repositories to annotated only. ] -
Drizzt
nagyúr
válasz
Aku-Aku
#11349
üzenetére
Erre biztosan nem lesz szükséged. Ez beállítja aktív profilnak a @spring.profiles.active@-at, ami nagyon valószínű, hogy nem létezik. Szóval nyerni nem nyersz vele.
A logban hiba nincs. Viszont hiányzik belőle, hogy a Tomcat elindulna a 8080-as porton, mint ahogy a példa screenshotján is van.
Annyit látok a logodban, hogy a "D:\eclipse_workspaces\java_coding_exercises\HelloWorld_Example\target\classes" könyvtár biztosan rajta van a classpathon. Mik vannak ebben a könyvtárban? Benne van a ApplicationConfiguration.java? Illetve egyáltalán a Spring MVC-s dependency-k ott vannak? Távolról ezt elég nehéz diagnosztizálni. -
Drizzt
nagyúr
válasz
Aku-Aku
#11344
üzenetére
Ranezve a @RestController komponensre gondol konfiguracio alatt. Nem vilagos, hogy miert igy hivja.
Mindenestre annyi az egesz, hogy a HellowWorldExampleApplication.java melle csinalj egy ApplicationConfiguration.java nevu fajlt, a kepen megadott tartalommal, s ennyi. Rakhatod olyan package-be is, ami melyebben van, mint az HelloWorldExampleApplication, mert a component scanninggel azt is meg fogja talalni. -
Drizzt
nagyúr
válasz
disy68
#11307
üzenetére
En a newClass helyett inkabb Supplier<T>-t hasznalnek. Akkor nem vagy megkotve, hogy csak 0 parameteres konstruktoru osztalyokkal mukodjon.
Az se teljesen vilagos, hogy ez miert egy static method, elso erzesre siman lehetne az AbstractInvoiceEntity-nek egy tagmetodusa.
-
Drizzt
nagyúr
válasz
javamonk
#11280
üzenetére
Spring/Spring boot erzesre joval fenyesebb jelen/jovo elott all. Meg weboldalakat kesziteni azert nagyon sokfele modon lehet, de szerintem erdemes a weboldalt es a serveroldalt teljesen fuggetlenul fejleszteni. De attol is fugg, hogy mit akarsz az egeszbol kihozni. Nagyon elterjedt a single-page webapp valamelyik js frameworkben + Spring boot server alkalmazas.
Java ee-ben szerintem a legnagyobb baj az uzemeltetesevel, meg a java EE app serverekkel van. Bar letezik oda is uber/fat jar megoldas. -
Drizzt
nagyúr
Igen. Leszamitva, hogy azert a Composite nem tul gyakori. Singletont, factoryt altalaban ugyis ad a framework, buildert a Lombok. Strategy szerintem elegge gyakori a jo kodokban ahol tipusfuggoen kell algoritmust valasztani. A java8, meg a Spring eleg sokat segit, hogy az oldschool modon kevesebbszer kelljen patternt implementalni.
-
Drizzt
nagyúr
Ezerintem local classt nem lehet. De mibe tart kiprobalni? En most tableten vagyok, azert nem tudom. Inner class elerheto kivulrol, hacsak nem private, de a local class definicioja csak a definialo blokkon belul ervenyes. Annyira nem hasznalok ilyeneket soha, hogy nagyon nem vagyok bennuk biztos.
-
Drizzt
nagyúr
Egyszerubbnek egyszerubb. Ha viszont valamiert tobben is hasznalnak ugyanazt a peldanyt, abbol meg baj is lehet. En csinalnek egy osztalyt, aminek a konstruktora letrehozza a textfieldeket, de nincsenek setterei. De van metodusa amivel a mezoket meg lehet szerezni. Ez mar igy kvazi egy immutable osztaly lesz, s akkor tobb szalon is jol mukodhet. Mezoben eltarolni azert veszelyes szerintem, mert nem garantalhato sorrendiseget varsz el. Lesz fv-d, ami beallitja a mezot, meg lesz ami lekerdezi. Mi van ha elobb hivjak meg a lekerdezot, mint a letrehozot? Az en javaslatomban ez nem fordulhat elo, mert letrehozni csak egyszer tudod a peldanyt, es amig az nincs meg, addig nem nem tudod meghivni. A te esetedben meg nem garantalja semmi a helyes meghivasi sorrendet.
-
Drizzt
nagyúr
Talan az a legszebb, ha csinalsz egy masik osztalyy, ahol az emlitett valtozo osztalyvaltozo, s az ot cseszegteto metodusok is az uj osztalyban vannak.
De fejtsd ki jobban a problemat. Remelem olyan dolgok nincsenek, hogy meghatarozott sorrendben kell meghivogatni a dolgokat.
Vagy ha ez valami seged metodus, ami mindenfele muveleteket tud vegezni a parameterrel, akkor mehet egy utility osztaly static metodusanak.
Konkretabb pelda tenyleg sokat segitene.
-
Drizzt
nagyúr
Nekem se volt még vele sose ilyen probléma. És nálam is meg van nyitva vagy 5-6 Spring microservice, 2-3 JavaEE app, meg néhány devops repo állandó jelleggel. Maven mind. Mondjuk amúgy a maven részét annyira nem szeretem az IDEA-nak, bár összehasonlítási alapom nem nagyon van, mert mást 10+ éve nem használtam(Javara).
-
Drizzt
nagyúr
Kérdés:
- Addott egy osztály, aminek főleg beépített osztályok az adattagjai. Van benne 1-2 Set is, amiket nyilván addAll-lal szeretnék összeuniózni. Erre van-e valami jó library, ami generálhat ilyet? Szóval olyat, mint lent az incrementBy.public class Example {
private Double value;
private Integer count;
private Set<String> stringSet;
public void incrementBy(Example other) {
value += other.value;
count += other.count;
stringSet.addAll(other.stringSet);
}
}
-
Drizzt
nagyúr
válasz
floatr
#10941
üzenetére
Szerintem teljesen mindegy milyen szemmel nézed, a lényeg, hogy a developernek a lehető legkényelmesebb legyen a fejlesztés, annak az összes aspektusával, különös fókuszt téve a debuggingra, a build/deploy sebességre, stb. Milyen olyan pipeline-t tudsz mondani, ami lokálisan gyorsabb, egyszerűbb, szükség esetén gyorsabban testre szabható, mintha közvetlen a gépeden fut az app server, vagy a Spring boot app? Ha csinálsz egy dockerben levő Java EE szervert, akkor ahhoz, hogy oda deployolj, ott debugolj szintén kell ultimate edition. Ha egy app server image-ből kiindulsz dockerfile-ban, és mellé rakod az alkalmazásod a buildnél, az lassabb és körlülményesebb lesz jóval. Sajnos a "jó" devops pipeline-nak gyakran az a vége, hogy az emberek csak deploy + println-nel tudnak debuggolni.
Egyébként a legjobb debugging tool meg szerintem a unit teszt, két okból is: gyors, olcsó, és ha sikerül megfejteni a hibát, automatikusan van rá regression teszt. Csak sajnos nem mindig elég a hibához a unit test.
(#10940) mobal: Ok, de a kérdés kimondottan JEE volt. Egyébként a Springes véleményeddel is vitára kelnék. Munkahelyen ultimate-et használok, itthon CE-t.Az ultimate-ben sokkal több infót kapsz. Pl. autowiringnél már ki szokta jelezni, ha nincs autowire candidate, vagy több is van, s kéne qualifier. application.properties szerkesztése közben az éppen elérhető property-t felkínálja dokumentációstul. Van JPA support. És ezek most csak ilyen hasraütésszerű dolgok, lehetne még találni bőven különbséget. Meg így is vannak amik hiányoznak ultimate-ből is. Pl. custom autoconfigurable bean-ek felismerése autowiringnél, etc.
-
Drizzt
nagyúr
válasz
togvau
#10905
üzenetére
A streammel nincs baj, az Arrays.asListet használod rosszul. Az listát csinál a megadott tömb elemeiből. Jelen esetben egy egy elemű listád lesz, aminek az az egy eleme egy int[] lesz.
int[] ints = new int[]{0, 1, 2, 3};Arrays.asList(ints).stream().forEach(System.out::println);Arrays.asList(1, 2, 3).stream().forEach(System.out::println);Arrays.stream(ints).forEach(System.out::println);Eredménye:
[I@1218025c123
0123 -
-
Drizzt
nagyúr
válasz
fatal`
#10881
üzenetére
"Az == a referenciát ellenőrzi, az pedig sosem lesz ugyanaz." Ez így nem teljesen igaz. Pl. ha ugyanarra a String literalra hivatkozol, akkor a referncia is ugyanaz lesz, mert a fordító észreveszi, hogy több referencia van ugyanarra a stringre már fordítási időben, így nem fogja kétszer ugyanazt a konstants elrakni a memória megfelelő szegmensébe.
-
Drizzt
nagyúr
válasz
ReSeTer
#10871
üzenetére
[]: tömb. {ertek1, ertek2, ...}: tömb elemeket leíró literál. A lényeg, hogy több értéket felsorolhatnál, ami String és a tömbben akarod eltárolni.
Az említett könyvet nem ismerem. Totál alap Java könyvet nem is tudnék ajánlani. Inkább Java alap videokat néznék. Pl. totál kezdő szinten van a Udemy-n a Java masterclass. Az talán már 100 óránál is hosszabb, nagyon sok dologra kitér, teljesen az alapoktól kezdve. Bár angol és fizetős.
-
Drizzt
nagyúr
"Some comments are necessary or beneficial. We’ll look at a few that I consider worthy of the bits they consume." Tehát kommentet írni bizonyos esetekben és és jogos. Javadoc meg akkor igazán fontos, hogyha egy library API-ját írja le. Mivel akkor az konkrétan inkább dokumentáció, mint komment.
-
Drizzt
nagyúr
És? Aki a Java9-es könyvet írta amit olvasol, azt mondta, hogy clean code enthusiast? Vagy honnan jön a tudathasadás feltételezés? Van aki követi, van aki nem. Nem szeretem a kommenteket, de néha van haszna. Főleg ha valamit úgy írsz meg, hogy elüt a best practice-ről, de van valamilyen jól megfogható oka, hogy miért van mégis úgy. Én nagyjából követem az elveket, bár a refactoring könyveket sokkal jobban és hasznosabbnak tartom.
-
Drizzt
nagyúr
Bulizhatz rekurzioval: az utolso else agban meghivhatod a kaloriaKiirt megegyszer.
Bulizhatsz do-while ciklussal: do... while (beolvasott szo nem gyumolcs).Amugy van sok furcsasag a kododban. Lehet csak a tableten nem latom, de mi szukseged van a File f parameterre? Mi a gyum, honnan jon az extended for loop elott. Van egy static String gyumod az osztalyban valamilyen ertekkel?
-
Drizzt
nagyúr
Ez szerintem egy elég nehezen érthető része a javanak. De a lényeg. Van a Komparator osztályod. Ezen az osztályon belül van egy inner classod, a KutyaRend. Ilyenkor a kutyarend osztály mivel nem static, ezért a példánya csak egy adott objektumpéldányon belül hozható létre. A static method nem példányhoz, hanem osztályhoz tartozik, így annak nincsen példánya, tehát nincsen benne KutyaRend létrehozási lehetőség sem. Legkönnyebben ezt itt úgy tudod megoldani, ha a Kutyarend osztályt statická teszed:
static class Kutyarend ...De ettől sokkal szebb, ha nem ágyazod be az osztályba semmilyen módon, hanem külön osztályba teszed. Sőt, ha ez a kutyák természetes rendezése, akkor elég a Kutyákat implements Comaparble<Kutyák> módon megadni, s akkor benne a compareTo-t implementálni.
Még egyszerűbb, ha használod a Java 8-as Comparators.comparing-et, így:
Collections.sort(KutyaLista, Comparators.comparing(Kutyak::getKor)); -
Drizzt
nagyúr
válasz
bambano
#10830
üzenetére
Muhahaha.
Remekül szórakoztatod az embert a nagyon furcsa feltételezéseiddel, de közben szerencsére jó dolgokat is mondasz.Arról sehol nem volt eddig szó, hogy mekkora méretű lenne az adat. Én eddig mindvégig azt feltételeztem, hogy kicsi.
"select meg watch service meg toronyóra lánccal... az eredeti kérdés szerint linuxon futna, ami egy unix. nem bohóckodunk ilyenekkel." És a select melyik oprendszer egyik fontos syscallja?
A tee-t tök jó, hogy felhoztad, mert magamtól nem jutott volna eszembe a neve, remélem most jobban elmélyül a tudatomban.
A syslogos megoldás az amúgy tetszik, bennem is bennem volt."tail -f /tmp/dumpfile | java -jar tefeldolgozod.jar
második esetben esetleg van értelme jávás watch objektumozni..."
De ilyenkor egy sima Scanner.nextLine is elég. Az vár az új inputig, vagy amíg a stdin-je el nem tűnik."miért érzem azt, hogy azért jobb a jáva szerinted, mert a shell programozásról fogalmad sincs?"
Én ilyet sehol nem írtam. Különböző célokra különböző eszközök a jók. Hirtelen meg az ember mindig úgyis azt a megoldást fogja ajánlgatni, amivel éppen a legjobban képben van. Ha nagyon akarnék, akkor én is elkezdhetnék kötekedni, hogy miért mysql-ben akarod a szenzor adatokat eltárolni, amikor vannak más kifejezetten ilyen célú adatbázisok is. De nem teszem, mert valószínűleg a probléma olyan kis méretű, hogy igazából nem számít.Ui. a mysql klienst úgy kezeled itt mindenhol, mintha minden linuxon kötelezően rajta lenne, de az ugyanúgy egy dependencia, ami vagy van, vagy nincs.
"most eltekintve attól, hogy tök értelmetlen http-n csinálni ilyet, a curl-ben túl sok hiba van ahhoz, hogy komoly rendszeren használd."
Ezt btw. még kifejthetnéd, hogy mire gondolsz. Milyen hiba? (És természetesen a curl sem feltétlen minden disztró része) -
Drizzt
nagyúr
válasz
bambano
#10823
üzenetére
"ezért amikor elhangzott itt (nem Peachmantől), hogy a szenzor program tegye le diszkre egy fájlban az adatot és azt olvassa be jávából LINUXON, akkor azt gondoltam, hogy ezzel totálisan szívenszúrja a unixos alapfilozófiát. kevésbé udvarias megfogalmazásban ekkora f.ságot évek óta nem hallottam."
Én írtam, s egyáltalán nem értek veled egyet. Majdnem mindegy, hogy először fájlba írsz valamit és onnan pollozod, vagy közvetlenül a pipe-pal küldöd át. Utóbbi esetben ráadásul újra, meg újra meg kell hívni a feldolgozó programot, ami nem feltétlen hatékony. Fájl változásra linux alatt selecttel fel tudsz iratkozni, Javaban is megvannak a megfelelő képződmények(Watch service). Egyébként named pipe-pal lehet a legjobban áthidalni, hogy a feldolgozó mindig futhasson attól függetlenül, hogy mikor kap inputot. De én fájlba írnám inkább, mert sokkal könnyebb lesz hibát izolálni annak előfordulásakor, ha a fájlra nézve meg tudod azonnal mondani, hogy mikor frissült, meg mi van benne, anélkül hogy a két alkalmazás belében kellene turkálni.
-
Drizzt
nagyúr
válasz
#68216320
#10800
üzenetére
A Linuxos program időzített futtatására használj cront, vagy egyszerűen írj egy bash scriptet, ami tight loopban vár. A kimenetet meg simán irányítsd bele egy fájlba. A Java programban ugyanezt a fájlt nyisd meg ugyanilyen időközönként. Aztán dolgozd fel, s írd ki adatbázisba. Amúgy ahogy az adatod jellegét nézem, kb. egy time series database-ben lenne a legjobb őket tárolni. Erre jó pl. Influxdb. Aztán csinálhatsz rá mindenféle fancy ábrát Grafanával.
Parse-olni ezt egyébként elég egyszerű, soronként végigolvasod, majd line.split("."), a három elemű tömböt meg felhasználod ahogy akarod..
Más: Mi a legjobb, legmélyebb Spring video course amivel találkoztatok? Kéne nekem egy masszívabb. Ha csak fizetős van, az se gond. De örülnék, ha legalább 20 óra körüli lenne és nagyon a részletekbe menő.
-
Drizzt
nagyúr
válasz
bandi0000
#10788
üzenetére
Ja, a Java EE egy framework. Egy jó nagy adag specifikáció halmaz, amit különféle app szervereknek kell implementálnia, hogy Java EE compliant-ek legyenek. Régen elég kínszenvedés volt a Java EE, orrba-szájba kellett örökölgetni mindenféle framework classból. Viszont idővel megjelent az annotation based configuration, elkezdtek egyre szeparáltabbak és önmagukban is életképesek lenni a komponensek. Így ma szerintem egyébként egy nagyon jó framework a Java EE, de tény, hogy a Spring mellett nem valószínű, hogy hosszú távon túlélő lesz. Én nem örülnék neki, ha eltűnne. De ennek főleg az az oka, hogy jelenleg ebben vagyok a leginkább otthon. Springet még csak tanulom. Illetve most főleg Kubernetest, meg Helmet, mert most épp az kell a melóban, de igyekszem visszanyergelni a java-ra.
Szóval az hátránya a Java EE-nek, hogy heavyweight runtime környezet kell hozzá, de ebben is fejlődik.
De érdekes, pl. szerintem a CDI event handling sokkal szebb, mint a Springes.
-
Drizzt
nagyúr
Persze hogy nem. De az mas kerdes, hogy erdemes-e, illetve miert. Az esetek nagy tobbsegeben akkor is kell refaktoralni, ha amugy a kod jo. Pl. ha jon valami olyan uj feature, vagy meglevo modositasa, ami a refaktoralas eredmenyekeppen sokkal egyszerubb lesz, dinamikusabb, kivulrol konfiguralhato, vagy neha epp fixebb, merevebb. Nem veletlenul van tele a refaktoring katalogus olyan lepesekkel, aminek az inverze is benne van. Az egesz refaktoring az agilehoz hasonloan azert terjedt el es lett fontos modszer, mert az it ipar rajott, hogy feature stability szinte semmilyen realis szoftverfejlesztesi projektben nincs.
-
Drizzt
nagyúr
válasz
M_AND_Ms
#10734
üzenetére
Nem, én ezt rendkívül fontos dolognak tartom. Ha ez nincs végig az ember fejében, amikor kódol, akkor jó eséllyel gányolt minőséget fog kiadni. Az meg most, hogy konkrétan a SOLID betűit feloldja-e valaki, vagy a lényegét elmondja a mozaikszónak, igazából mindegy, de számomra mozaikszót megjegyezni és felidézni sokkal egyszerűbb, mint bármi más módszer.
Juniortól nem ezt kérdezném, mert szinte biztos, hogy nem fogja tudni. Ott nyomatnám az egyszerűbb adatstruktúrák kérdéseit. Senior szinten viszont szerintem ez alapelvárás, akármikor.
-
Drizzt
nagyúr
válasz
Orionk
#10725
üzenetére
Tömör, egy felelőssége van, se többet, se kevesebbet nem csinál mint ami a célja. Magas a koherencia a az adattagok és a metódusok között, meg az összes SOLID principle felsorolása, kifejtése, 1-2 design patternen keresztüli elmagyarázása. Én ezt várnám el egy interjúzótól. Bár juniortól lehet nem ilyet kérdeznék, hanem inkább alapvetőbb algoritmus kérdéseket, adatstruktúrákat.
-
-
Drizzt
nagyúr
Ezzel az állítással alapvetően nem értek egyet. Mert az ExecutorService egy interface, ami arra van, hogy taszkokat lehessen aszinkron módon futtatni. De alapvetően arra semmilyen garancia nincs, hogy milyen sorrendben fussanak azok a taszkok le, illetve hogy melyek ne fussanak egyszerre. Ha az ember single threaded executort használ, az már valóban megoldást adhat a problémára, mint ahogy itt van rá példa. [link]
De önmagában az ExecutorService interface semmit nem mond a mutual exclusivity-ről. Épp az az interface célja, hogy a taszkok feladását ütemezés független módon engedélyezze.
-
Drizzt
nagyúr
válasz
bandi0000
#10642
üzenetére
Sokféle megoldás van. Talán az egyik legegyszerűbb, hogyha van egy közös objektum, aminek van egy synchronized metódusa. Ennek a metódusnak kellene csinálnia azt a tevékenységet, amit nem szabad párhuzamosan elvégezni.
Vagy használhatsz pl. [link] ReentrantLockot. Ilyenkor ha valamit exklúzív akarsz csinálni, előtte lock, aztán unlock.
Ez a cikk elsőre jó gyorstalpalónak tűnik, bár nem olvastam végig. [link]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Bambu Lab 3D nyomtatók
- Autós topik
- Argos: Szeretem az ecetfát
- Samsung Galaxy S25 - végre van kicsi!
- Hardcore café
- Milyen okostelefont vegyek?
- Épített vízhűtés (nem kompakt) topic
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Honda topik
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- További aktív témák...
- Apple iPhone 14 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- Honor Magic7 Lite 512GB, Kártyafüggetlen, 1 Év Garanciával
- Honor 400 lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- HP Prodesk 600G4 SFF - i5-8500, 16GB DDR4, 512GB NVMe SSD, ATI R5 430 2GB eladó!
- BESZÁMÍTÁS! Lenovo ThinkPad T14 Gen 4 üzleti notebook - i7 1360P 24GB DDR5 RAM 512GB SSD Iris Xe W11
- DDR3 BAZÁR! 8GB 16GB 1333MHz 1600MHz 2400MHz DDR3 memória garanciával hibátlan működéssel
- AKCÓÓÓ!!! Panasonic CF-XZ6 AIO all-in-one laptop tablet 2k touch i5-7300u speciális ütésálló
- BESZÁMÍTÁS! Dell Precision 5820 XL Tower PC - Xeon W-2123 112GB RAM 512GB SSD 1TB RX 580 8GB Win 11
- Xbox Ultimate előfizetések
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged