Ilyen megoldásoknak szerintem nincs helye egy Java topikban. De igazából semmilyen szakmaiban se. Stringben eltárolni a számot? Nooormális?
Ha nem akarsz saját adatosztályt írni, akkor legalább a AbstractMap.SimpleEntryt használd az adatpár tárolására. Ezt meg belerakhatod a HashSetbe.
[ Szerkesztve ]
“All nothings are not equal.”
még mindig nem látom értelmét 20-30 adatpár miatt egy új osztály létrehozásához...
főleg, hogy olyan adatokat tárolnék amik nem fognak megváltozni
persze nem mondtam, azt sem, hogy az én megoldásom jó lenne, viszont az osztályt túlzásnak tartom
Ez egy .50-es rombolópuska, elég szép visszarúgással.
Hát, ezért mondtam a SimpleEntry-t.
Jó lenne, ha lenne gyárilag Tuple típus, jobbhíján a Pair helyett ez a legegyszerűbb, amihez se kódot nem kell írni, se libet behúzni.
[ Szerkesztve ]
“All nothings are not equal.”
oks, értem
megnézzük milyen is ez, a nevekből ítélve jónak kéne lennie
Ez egy .50-es rombolópuska, elég szép visszarúgással.
jó lett ez az elgondolás, pont ilyenre gondoltam 
import java.util.AbstractMap.SimpleEntry;
import java.util.HashSet;
import java.util.Set;
...
private static Set<SimpleEntry<String, Integer>> list = new HashSet<SimpleEntry<String, Integer>>();
...
list.add(new SimpleEntry<String, Integer>("user/BasketAction/list", 0));
...
...
...
list.add(new SimpleEntry<String, Integer>("user/BasketAction/list", 1));
list.add(new SimpleEntry<String, Integer>("user/SearchAction/search", 1));
Köszönöm az ötletet.
Ez egy .50-es rombolópuska, elég szép visszarúgással.
Pedig pont, hogy túlbonyolítod a string tömbökkel a dolgot. Azt hogy tervezted leellenőrizni, hogy az adott pár benne van-e már az ArrayList-ben? Contains-szal? Lassabb működést kapsz, a castolás gányolásról nem is beszélve. 
Edit: az utóbbi megoldás sokkal szebb. 
[ Szerkesztve ]
osztom a véleményed 
Ez egy .50-es rombolópuska, elég szép visszarúgással.
Még egy megjegyzés az equals(), hashCode() témához.
Szóval, csak a tájékoztatás korrektsége miatt. Igaza van maximálisan az előttem szólóknak(Superhun). Az equals() és hashCode() metódusokat MINDIG EGYÜTT KELL felüldefiniálni, szóval az a megoldás, hogy csak az equals() metódust definiáljuk felül, rossz.
Elnézést a topic olvasóitól a félretájékozatásért és a rossz, pongyola tipp miatt!
[ Szerkesztve ]
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Ez jó téma és nagyon jó válasz. Ezt én se értettem, csak szégyelltem megkérdezni.
Sziasztok, ismét írtam egy blogpostot arról, hogyan érdemes használható EJB-ket gyártani, ha gondoljátok olvassátok el, és mondjátok el a véleményeteket, ha hülyeséget írtam
http://palkonyves.blogspot.hu/2013/03/how-to-design-clean-business-tier-with.html
Még olvasom (nagyon érdekel a téma amúgy), egy elírást észrevettem: szerintem steep learning curve-öt akartál írni, nem shallow-t 
“All nothings are not equal.”
A szovegkornyezetbol nekem az jon le, hogy az eredeti a helyes. A meredek gorbenel gyorsan tanulsz. (Elsajatitott tudas - ido)
Igen, volt már erről vita, és arra jutottunk, hogy a steepet rosszul használják. Az emberek legtöbbször úgy értik, hogy aminek meredek a tanulási görbéje, azt nehéz megtanulni (gondolom azért, mert ami meredek, arra nehéz felmászni 
). A wikipedia is ezt írja http://en.wikipedia.org/wiki/Learning_curve#In_culture
De azt is írja, hogy a félreértés elkerülése végett érdemes inkább 'long' és 'short' learning curve-t írni
Áh. Hát én konkrétan csak a meredek = nehéz megmászni jelentéssel találkoztam eddig. Akkor tárgytalan 
“All nothings are not equal.”
Sziasztok!
RSS csatornákat szeretnék feldolgozni. XML olvasásához XMLEventReader-t vagy DOM-ot alkalmazzak inkább? Továbbá abban segítsetek, hogy nem tudom milyen módon keressek rá amivel az xml-ből egy node-ot kiveszek és annak a tagjait dolgozom fel.
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Szerintem egyiket se, inkább a Simple-t.
De legalább egy pull parsert, ha mindenképp kézzel akarod írni. Az adott node kiválasztására meg általánosságban az XPath való - DOM parsolás után legalábbis, mert stream parsolásnál nehezen értelmezhető.
[ Szerkesztve ]
“All nothings are not equal.”
Hali,
http://en.wikipedia.org/wiki/Java_API_for_XML_Processing Ez egy jó összefoglalónak tűnik, hogy melyik API mire való. az XMLEventReader azt hiszem StAX specifikus dolog.
A DOM ugye fogja az egész dokumentumot és beparsolja egy DOM fába.
A SAX az egy push parser: ahogy parsolja a dokumentumokat, új tag-eket, és attribútumokat talál, callback metódusokat hívogat, amiket az alkalmazásod implementál, és el tudod dönteni, hogy mit akarsz csinálni az éppen aktuális információval.
A StAX parser hasonló, csak ott az alkalmazás kívülről irányítja a parsolást: lépteti a parsert előre.
Nyilván egy szálban tökre mindegy, hogy push vagy pull, szerintem akkor lehet érdekes ez, amikor van egy parsoló szál és egy feldolgozó szál.
A legegyszerűbb a DOM, mert miután a parser készített belőle egy objektum modellt, a tag-ek objektumok hierarchiájaként fog megjelenni, és szépen a saját metódusain keresztül kereshetsz/iterálhatsz benne, meg is változtathatod. Továbbá, ami nagyon hasznos lehet számodra, hogy XPath lekérdezésekkel le tudod kérni csak azokat a node-okat, amikre szükséged van: http://www.ibm.com/developerworks/library/x-domjava/#3
Az, hogy melyiket válaszd eléggé függ attól, hogy mit akarsz elérni:
Ha nem fontos a sebesség: Ha egy asztali alkalmazást csinálsz, semmit nem fogsz profitálni a StAX parserrel a DOM-hoz képest, nem lesz akkora a különbség. Hatalmas RSS-nél mondjuk (hasraütés) pár száz ms-t veszítesz. (DOM)
Ha fontos a sebesség: Egy google readerszerű alkalmazást akarsz, ami éjjel nappal olvassa az RSS-t, és mondjuk párhuzamosan amennyit tud. Akkor nem mindegy, hogy a végső reprezentáció és az eredeti XML között fel akarsz-e építeni és tárolni ideiglenesen a memóriában egy DOM fát.
Esetleg fontos a gyors válasz: te real-time akarod beparszolni az RSS-t, és minél gyorsabban pl. betolni adatbázisba a tartalmát vagy más reprezentációban tárolni. (SAX)
Streaming: Ez kapcsolódik az előzőhöz: az RSS-t egyből más reprezentációban akarod elmenteni gyorsan, vagy továbbküldeni a hálózaton. (StAX)
Kell-e minden adat: elképzelhető, hogy nem kell az RSS-ből minden adat, csak a link neve például, akkor a többi adat teljesen fölösleges, fölösleges is tárolni őket, a parsolás folyamán csak azokat az adatokat tárolod le, amik szükségesek. (StAX)
Én azt mondom, amíg nem hatalmas mennyiségű RSS feedről, rettentő reszponzív alkalmazásról, streamingről, vagy nagyon kevés memóriáról van szó, addig használj DOM-ot.
[ Szerkesztve ]
Hello! Köszi a válaszokat. Megoldottam DOM-mal. Jelenleg ilyen módszerrel tárolom el azt ami nekem kell. Létezik valami hatékonyabb? (Sokat kerestem rá, de nem jutottam előrébb, lehet rosszul keresem).
Köszi!
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Hát, az előbb általam linkelt Simple-lel (és például a JAXB-vel) írsz egy POJO osztályt az adatodnak, és olyanokat hoz létre. Ennél tisztábban nehéz tárolni szerintem.
“All nothings are not equal.”
Ha a DOM mellett döntesz, akkor javaslom a JAVA beépített DOM könyvtára helyett a külső JDOM libet használni, gyorsabb, és sokkal kényelmesebb a használata.
Simple lett a vége.
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Bocs, ha alapkérdés.
Szóval, van egy byte tömböm + egy fájl nevem. Szeretném úgy csatolni mailben hogy ne mentődjön ez a szerverre (mert most mentődik). Tudnátok segíteni?
Kód:
MimeMessageHelper helper = new MimeMessageHelper(message, true);
File someFile = new File(notificationBean.getAttachmentFileName());
FileOutputStream fos = new FileOutputStream(someFile);
fos.write( notificationBean.getFileAttachment());
//fos.flush();
fos.close();
helper.addAttachment(someFile.getName(), someFile);
flush()-t kiszedtem, de nem segített.
[ Szerkesztve ]
FileOutputStream helyett ByteArrayOutputStream-et használj!
A someFile.getName() helyett notificationBean.getAttachmentFileName(),
a someFile helyett pedig a ByteArrayOutputSream megfelelő metódusát.
[ Szerkesztve ]
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
MimeMessageHelper helper = new MimeMessageHelper(message, true);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
baos.write(notificationBean.getFileAttachment());
helper.addAttachment(notificationBean.getAttachmentFileName(), ????)
addAttachment második paramétere lehet File, InputStreamSource, DataSource. Tehát ezek valamelyikére kellene konvertálni a ByteArrayOutputStream-et, aminél nem találtam megfelelő metódust egyelőre. 
Végül ez nyert: helper.addAttachment(notificationBean.getAttachmentFileName(), new ByteArrayResource(notificationBean.getFileAttachment()));
TBG köszi az iránymutatást!
Az érdem a Tiéd
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
sziasztok
ismertek valami módszert arra, hogy j2se-ben le tudjak játszatni mp3 fájlokat?! üdv
Alap JDK-val nem tudod pár sorban megoldani. JMF-et kell hozzá leszedned.
http://stackoverflow.com/questions/6045384/playing-mp3-and-wav-in-java
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Hali, már biztonságos feltenni a java-t ?
Felpakoltam a java-t de nem böngésző kieg-ként, rendes program. Csak a chess.com-on használom (a számítogép elleni játékhoz kell) ez esetben kell bármitől tartanom?
A legfrissebb java-val nem kell mitől tartanod. Csak az a lényeg, hogy mindig a legfrissebb legyen fent.
köszi, frissíti magát magától ?
Ha nem tiltottad le, akkor igen.
Alapesetben ha nem állítottál semmit - nem is szükséges akkor frissítés esetén megjelenik a tálcán egy narancsága java ikon (a szokásos gőzölgő kávéscsésze), majd közli is veled, hogy lenne update. Azt leokézod, szöszmötöl és ennyi!
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
Sziasztok !
Ha ezen végigmegyek : http://docs.oracle.com/javaee/6/tutorial/doc/docinfo.html és utána spring-et szeretnék használni akkor a felhasználása mennyiben tér el? Úgy gondolom, hogy a tutorialok sora Java SE -> Java EE (a fent emlitett) -> Spring-es tutorial ... jól gondolom?
Helló,
Nem.
A spring Java EE-től független technológia. Ugyanarra találták ki, mint ami ma a Java EE, még az előtt, hogy a Java EE igazán használható lett volna. Helyettesítő technológiák.
Ugyanakkor, ha készítesz egy Springes alkalmazást, megvan a lehetőséged, hogy Java EE technológiákat használj benne. Például a JPA egy Java EE specifikáció, de mára annyira kiforrott (és persze mert java standard), Springes alkalmazásokban is használják ORM rétegnek.
Ha elsősorban Springet akarsz használni, akkor spring tutoriallal kezdd. Csak akkor olvass Java EE tutorialt, ha olyan technológiába ütközöl.
Értem, ehhez az EE-s tutorialhoz hasonló Springes tutorial létezik ? Mármint az EE az elég jól követhető és "szájbarágós" . Ez annyira nem olyan : http://www.springsource.org/tutorials .
http://simplespringtutorial.com/
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Szerintem előbb döntsd el, hogy mit szeretnél pontosan a Java-tól és abba az irányba indulj el. A PHP-hoz képest itt nagy a "Birodalom" mérete.
Már maga a Java SE sem kis mennyiség. (GUI-k-ról nem beszélve, annotációk, amelyek a gyenge pontjaim, stb. Könyv függő, hogy mit sorolnak ide 
Java EE végül is durván mondva, API-k gyűjteménye, párat már Modder is írt. (Najó talán az alapokat, a nagyon-nagyon alapokat érdemes átnézni esetleg egy szakdolgozatból, hogy elméletileg tud, hogy mi az. Amikor olyanokról beszélnek, hogy komponens, konténer, szervlet stb.)
Cég függő, hogy melyiket használják a Spring és a Java EE közül. Bár lehet a pénzszektorhoz a Java EE kell. Mondjuk a Morgan Stanley Spring szakembereket keress.
Ha webes alkalmazások érdekelnek akkor én inkább a Grails-et javasolnám. Egyszerű szimpla és a Spring-re épül (na meg az a csapat is fejleszti ). Java EE esetén meg ott a JSP és a JSF is... (itt viszont az ASP.NET-tel mutatt rokonságot... JSF az olyan Webforms benyomást kelti a JSP pedig az (asp.net)MVC és PHP benyomását). Grails-nél keveset kell a config fájlokban lennem
És ott van még a fentebb említett nagy vállalati "irány" is.
Bár még én sem vagyok pro, de szerintem az irányt nem árt tudni
Köszi, ezekkel tisztában vagyok, nem csak úgy poénból kezdtem el foglalkozni vele, hanem azért mert nem sokára juniorként munkába állok és ugyan intenzív oktatáson részt fogok venni, már most el szeretnék vele kezdeni foglalkozni, mert van rá időm. A kérdés lényege az volt, hogy felesleges időt ne pazaroljak arra amire nem kell.
TBG : Köszi ezt már megtaláltam, de egy ideje nézegetem már, hogy akkor most mi is van 
. Még nem találtam meg a fogást, hogy miként kezdjem el, az SE tutoriallal lassan végzek.
[ Szerkesztve ]
Az EE egyre inkább háttérbe szorul a Springgel szemben.
A Springgel érdemes kezdeni szvsz, mert aki ismeri a Springet, az nagyon könnyen tud átnyergelni EE-re, de csak EE ismerettel a Spring a vérhugyozás kategóriája.
Itt a 3-as Springről beszélek. Az előző változatok az XML tengere....bottal nem nyúlnék hozzá. Spring is támogat JSF,JSP techonlógiákat.
A Spring is egyébként egy qrva nagy framework/tool/solution halmaz.
Van Spring MVC, Sping JS, Spring Webflow, Spring Security.....sorolhatnám napestig. Ezekből a Spring Security és az MVC már de facto szabvány.
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Mint mindent, ezt is csak úgy tudod értelmesen elkezdeni, ha van feladat
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Hm, nem tudom, én már 1 éve nézegetek Java-s állásokat (szerencsére Isten nem szeret ) és ha Spring-et kértek volna akkor azt külön jelezték, vagy még a Strut2-t láttam népszerűnek.
Java EE kiselőadást kellett tartanom és hát, amikor nézegettem a fórumokat elég nagy vita van ebből a Java EE vs Spring dologból, én nem is mennék bele . De én sosem dolgoztam bennek, csak tanulgattam őket, így nem tudok bővebbet mondani .
Bár a Spring elég dinamikusan nő és nagyon megy a fejlesztés is ezerrel. Lehet tényleg érdemes a Spring-gel kezdeni, mert ahogy olvastam a Java EE7-hez még a cache api sem lesz benne, amit már nagyon vártak... (valami Jcache).
Mivel foglalkoztam ASP.NET-tel nekem nem volt nehéz megérteni a Java EE alapjait mástól nem hallottam vissza ezügyben semmit.
Szerintem a Spring lassan platform lesz (tényleg rengeteg eszköze van)
Struts2 vs Spring? Nem összehasonlíthatóak
Szerintem a Spring lassan platform lesz
Ez a lényeges mondat. Annyi módosítással, hogy szerintem már az!
Miért Spring? Azért, mert nem kell hozzá applikációs szerver. Egy sima Tomcat/Jetty-vel is simán elszalad, ami egy EE alkalmazásról nem mondható el. Sőt, egy jól megírt Spring alkalmazás fut servlet konténerben és applikációs szerverben is. Mindamellett ugyanazt a funkcionalitást nyújtja, mint egy EE konténer (jó, dinamikus kontext nincs, de embert nem láttam még, aki használta volna)
Nem akarok flame-t nyitni!!
[ Szerkesztve ]
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Pedig kihúzod a gyufát! 
Az a baj, hogy nem tudom megítélni, hogy helyes-e az alábbi diagram, ami azt mutatja, hogy a Java EE-re a kereslet nagyobb mértékben nőtt, mint Springre, vagyis fejlesztőre.
http://www.indeed.com/jobtrends?q=%22Spring+framework%22%2C+%22Java+EE%22&l=&relative=1
(De igazából nem tudom eldönteni, hogy mennyire hiteles ez a diagram)
DE. A Spring egy jó framework, máskülönben nem használnák, és szerintem innovatívabb is, mint a Java EE, gyorsabban mozog az új technológiák felé. Mindkét keretrendszert nagyon sok helyen használják. De az eredeti kérdéshez visszatérve, ha konkrétan tudja valaki, hogy Springgel kell/akar foglalkozni, akkor azt tanulja előbb, és ne a Java EE-t
Ez a diagram azt is mutathajta, hogy sok helyen keresnek EE fejlesztőt, de nem találnak, mert lassan mindenki átmegy Springre. Sokkal jobban mutatna egy olyan grafikon, hogy hány helyen használnak Springet aktívan és hány helyen EE-t
Ha már flame, legyen kövér
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Lehet, hogy igazad van. Arra viszont jól emlékszem, hogy a Spring developerek, akikkel eddig találkoztam, mind melegek voltak. EGYTŐL-EGYIG! 
Ha nem a Kapellában próbálsz Spring fejlesztőt toborozni, akkor ilyen meglepetések garantáltan nem fognak érni
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
Sziasztok!
Következő problémával szembesültem: össze kéne hasonlítanom egy képet pár másikkal - gyk. eldönteni, hogy milyen szám is szerepel rajta. Maga a dolog "gondolom" nem lenne nagy cucc, ha nem lenne különböző méretük stb. Javaslatok, ötletek?
Köszönöm! 
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
