- Milyen okostelefont vegyek?
- iPhone topik
- Digitális detox a Nokiától
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- OnePlus 7 - magabiztos folytatás
- Samsung Univerzum: Az S23-at is megbabonázta a Galaxy AI
- Motorola Edge 40 - jó bőr
- Mobil flották
- DIGI Mobil
- Futott egy Geekbench kört egy új HTC készülék
Hirdetés
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
Új hozzászólás Aktív témák
-
Paarthurnax
senior tag
Én az Eclipse EE Developers kiadását használom szinte mindenre. Egy dolgora használtam eddig a Netbeans-t és az GUI tervezés volt, mert tényleg sokkal egyszerűbb abban. Netbeans-t nem ismerem, de ami az Eclipse-ben jó, hogy rengeteg kiegészítőt lehet hozzá letölteni és csak egy pillanat váltani a felületek között és így alkalmas sokféle munkára.
Diablo 3 - BoGyesz#1484
-
Löncsi
őstag
4 fajta Layout van.
FlowLayout, BorderLayout, GridLayout,BoxLayout.
Box és FlowLayoutnál mikor átméretezel, a komponens mérete konstans marad.
Szerintem érdemes egy Box-layoutot egy panelre állítani, és egyesével belerakni a komponenseket, így egymás alatt lesznek. (vagy Flow is jó, ekkor egymást követik a komponensek)
Majd ha ezzel megvagy ,magára az ablakra ( getContentPane() )-re kellene tenni egy BorderLayoutot, átadni az előző panelt és "South"-ra tenni, így 'elvileg' egymás alatt/mellett elhelyezkedő konstans méretű gombok lesznek, mindig délen (lent).
De csak tipp így kora reggel, el kell ezzel játszogatni.
[ Szerkesztve ]
Elvették a radírját, azt az egész élete egy nagy kompenzálás, hogy ő igenis kan és igenis 2 méteres a fallosza - by stranger28
-
shev7
veterán
egyebkent itt volt a hiba:
setLayout(new javax.swing.BoxLayout(this, javax.swing.BoxLayout.LINE_AXIS));
a LINE_AXIS egymas melle pakolja a dolgokat. Neked PAGE_AXIS kellett volna...
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
A szerzetes
csendes tag
Próbáld meg ezt:
DataIn = new BufferedReader(new FileReader(fajl));
Helyett:
DataIn = new BufferedReader(new InputStreamReader("fajl_nev","kodolas");
A kódolást pedig próbáld ki, hogy melyikkel működik! Nem próbáltam ki, de szerintem kellene, hogy működjön![ Szerkesztve ]
"Nem adom fel mert lehet, hogy holnap lesz az én napom"
-
Lacces
őstag
Igaz, nem új, de a Murach féle könyvet olvastam ADO.NET-ben és megvoltam vele elégedve
(A PHP-s-nál annyira nem, de +1 pont, hogy kezdőként ott nagyon tolta az MVC szemléletet.) -
modder
aktív tag
Ez úgy hangzott, mintha cinikusan idéztél volna egy 4 évvel ezelőtti cikket -- de amúgy igazad van részben. még annyival egészíteném ki, hogy ez természetesen nem jelenti azt, hogy bármilyen esetben lecserélhető egy relációs adatbázissal. És még jó darabig sok helyen nem is fogják lecserélni.
-
modder
aktív tag
Én még csak glassfish-t használtam Eclipselinkkel. Weblogic-ban nem vagyok jártas, de
ez a [link] azt sugallja, hogy ez még EJB 1.1, ami már régi, az EJB 2.0 jobban kitalált kevesebb opciót kér.Lehet, hogy a könyv még EJB 1.1-ről beszél, ez esetben szerintem jobban jársz, ha inkább egy on-line tutorial után nézel, ami az újabb verziót tárgyalja
-
Chipi333
csendes tag
Azt nem tudom, hogy ha közben van GC akkor ezeket is gyomlálja e...
A GC a classokat nem gyomlálja. Ezek az adatok nem a Heapen vannak hanem van erre egy külön memóriaterület. Bár úgy tudom, hogy van olyan megoldás is amikor ezt összevonják a heappel, mert pl sok a reflection használat, és nem lehet előre tudni mennyi class lesz betöltve, ellenben para lenne ha futás közben elfogyna itt a hely. -
Chipi333
csendes tag
Hát, ha elfogy a hely és új osztályt akarsz betölteni akkor ugyanúgy game over mint ha a heap telne be. A JVM-ek viszont konfigolhatóak, szóval ennek is állítható a mérete, lehet a heap része és ott lehet dinamikus is a mérete, de GC-je nincs feltétlenül, meg hát nem is biztos, hogy szerencsés már betöltött classokat kidobni.
-
sutszi
veterán
Erre valakinek valami ötlete?
Már azt is kipróbáltam, hogy Elindítom a Weblogic-ot és remote server-ként próbálom hozzáadni az Eclipse-hez de semmi.
WLST-n megpróbáltam csatlakozni a futó instance-hoz, (eclispe alól) de egyfolytában elszállt mindenféle kivétellel, hogy nincs szerver....Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
addikt
Itt nem látok ilyesmit sajnos.
Arról lenne jó valahogy infót szerezni, hogy module projectnél pontosan milyen targetek futnak le és mikor, de egyszerűen nem találok infót róla.
Mert egy sima java project build-impl.xml fájlba látom ezeket a pre/post targeteket, de a module projectébe semmi ilyesmi nincs, mondjuk clean meg release se, mégis lefutnak, szóval nem igazán értem. -
pakriksz
őstag
én is erre gondoltam, de a 32 bit túlcsordulása az 2 milliárd 147 millió valamennyinél van van. Azon a 2,4 giga már mindenképp túl van.
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
Karma
félisten
-
addikt
A példaként hozott esetben a StringBuilder használata teljesen indokolatlan, hiszen nem karakterlánc hozzáfűzés/zsugorítás történt, hanem egy teljes csere. StringBuilder használata akkor javasolt és szép, ha ciklusban használod a String += operátorát, vagy ha 2-nél több Stringet akarsz összefűzni.
-
TBG
senior tag
Ez csak abban az esetben jelenthet gondot, ha több tízezres/százezres nagyságrendben "kallódnak" az objektumok. Ergó, a felhasználástól is függ, hogy az ember hogyan hegyezi ki a kódot. Illetve érdemes-e nagyon kihegyzeni. Mindenesetre ökölszabály, hogy ha tökmind1, akkor is a szebb, takarékosabb megoldást használjuk.
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
-
modder
aktív tag
Esküszöm, nem értem, mit akarsz mondani Superhun válaszára.
De pár tény:
1) A JVM k*rva okos és tele van optimalizációval. Memória allokációnak alig van költsége, persze sok kis objektum lassíthatja a GC-t. Megoldás: arra az objektumra ne veszítsük el a referenciát, amit újra fogunk használni. Ennek megkönnyítésére szoktak memory poolokat implementálni Javában úgy, ahogy C++-ban is. De ezeket elég speckó esetekben szokták használni, amikor a sebesség van mindenek felett.
2) literálokra referencia mindig ugyanarra a memóriaterületre mutat. for() { String s = "nyorr"; } nem fog új objektumot létrehozni minden egyes iterációban
3) Olyan mikro-optimalizációról beszélünk, aminél egy adatbázis lekérdezés nagyságrendekkel lassabb: semmi értelme gondolkodni rajtaCiklusban String összefűzést StringBuilderrel, mert azt a compiler tudtommal nem ismeri fel, ellenben a "egy" + "ketto" + $valami.toString; kóddal, amit StringBuilderre cserél (vagy StringBuffer, most hirtelen nem emlékszem, melyik a thread-safe)
Nem látom értelmét String helyett StringBufferben tárolni a stringet.
Szerk.:
Közben rájöttem, mit akartál mondani, de elég veszélyes. Ha Stringbuilderben tárolod a stringeket, akkor a StringBuilder mutable, és olyan helyen is megváltoztathatod a String értékét, ahol nem akarod. pl.:StringBuilder strTime = getTimeInString();
page1.setLastVisited(strTime);majd később:
StringBuilder strTime = getTimeInString();
page2.setLastVisited(strTime);no shit, lastVisited szintén frissült page1-re, mert ugyanaz az objektum. Nem hiába találták ki, hogy a String immutable.
[ Szerkesztve ]
-
addikt
sb.replace(0,sb.length,"x")
Ekkor is létrehozol egy "x" (vagy akármi más) tartalmú String objektumot. Tény, hogy utána a régi literált nem kell GC-zni, mert egyszerűen felülcsapja az új literállal a karaktertömbjét, de ha picit utánaolvasol annak, hogy mi az a PermGen, akkor rájössz, hogy alapesetben a régi Stringet sem fogja megenni a GC. Annyit értél el az egésszel, hogy rondább lett a kód.
-
WonderCSabo
félisten
Tévedsz, Javában a string literálok nem úgy műkődnek, mint az egyéb sima objektumok. Ezek egy String poolba kerülnek. Amikor létrehozol egy új string literált, akkor a JVM megnézi, hogy benne van-e már az a string a poolban, és ha igen, akkor nem hoz létre új objektumot, hanem egyszerűen referál a már meglévőre. A garbage collector ezeket a stringeket nem is fogja bántani csak úgy, különben elveszik az újrafelhasználás lehetősége.
A StringBuildert pedig nem kell feltétlenül használni, mert egyrészt sokkal természetesebb a plusz operátor, másrészt úgyis StringBuilderre fordul a + operátor...
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Milyen okostelefont vegyek?
- Luck Dragon: Asszociációs játék. :)
- AMD Navi Radeon™ RX 7xxx sorozat
- Autós kamerák
- iPhone topik
- Proxmox VE
- Amlogic S905, S912 processzoros készülékek
- Számtech boltosok memoárjai, azaz amikor kiborulunk...
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Milyen egeret válasszak?
- További aktív témák...