- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Fotók, videók mobillal
- Huawei Mate X6 - keleti oldal, nyugati oldal
- Telekom mobilszolgáltatások
- Mobil flották
- iPhone topik
- Nem lett arányos a fogyókúra
Új hozzászólás Aktív témák
-
TBG
senior tag
válasz
MrSealRD
#4239
üzenetére
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.
-
TBG
senior tag
Ah, annyira rühellem, hogy harapófogóval kell kihúzni belőled mindent.
Tisztázzuk, olyan Java kód nincs, ami a megakadályozza, hogy kihúzzák a pendrive-ot. Azt tudod csinálni, ahogy korábban is mondtam, hogy az /mnt/pendrive könyvtárat csekkolod...ha már nem létezik, akkor le van választva.... -
#4121
TBG
senior tag
WonderCSabo
#4115
TBG
senior tag
válasz
WonderCSabo
#4115
üzenetére
Azért is írtam, hogy tipp, mivel magam sem számítottam gyökeres változásra, de cserébe írtam még pár lehetőséget
Egyébként továbbra is az a véleményem, hogy már design szempontjából célszerűbb loopon kívül deklarálni ebben az esetben a streameket. -
#4113
TBG
senior tag
WonderCSabo
#4112
TBG
senior tag
válasz
WonderCSabo
#4112
üzenetére
Nem az objektumok számáról van szó, hanem arról, hogy ezek mikor, milyen intenzitással gc-ződnek. Ezért is vetettem fel, hogy mekkora is az a heap méret. Te csak egyetlen felvetésembe kötöttél bele, ami jogos is lehet, de mi van a többivel? Vagy említhetném az esetleges os szintű problémákat is. Nem egymással van vitánk, a problémát próbáljuk megoldani, nem?
-
#4111
TBG
senior tag
WonderCSabo
#4110
TBG
senior tag
válasz
WonderCSabo
#4110
üzenetére
Primitíveknél igen, de összetett objektumoknál már számíthat. Főleg, hogy fájl írás/olvasás is van. Mekkora heap van beállítva? Jó lenne tudni, hogy mennyi fájlról van szó. És a buffered streamek használata sem lenne rossz.
-
#4109
TBG
senior tag
WonderCSabo
#4108
TBG
senior tag
válasz
WonderCSabo
#4108
üzenetére
Mondjuk. Ez a best practice, nem a cikluson belüli. Pár objektumnál mindegy, de egy fájlrendszerben akár több ezer fájl is lehet. Itt már számít.
-
#4107
TBG
senior tag
WonderCSabo
#4106
TBG
senior tag
válasz
WonderCSabo
#4106
üzenetére
Arra gondoltam, hogy csak egyszer deklarálja a streameket és csak új példányt rendel hozzá. GC szempontjából szvsz nagyon nem mindegy. Ha sok fájl van, az qrva sok objektum. A különféle desztinációk nem sérülnek. Kódot nem írok, mobilról körülményesebb
-
TBG
senior tag
Akkor pedig az a gyanúm, hogy fut a gc a sok objektum miatt és ezért nem látsz memória növekedést. Próbáld meg a cikluson kívül deklarálni a stream-eket..tipp...esetleg nézhetnéd, hogy a fájlműveletek hogyan alakulnak OS szinten. Lehet, hogy az OS-ben torlódnak a másolási műveletek.
-
-
TBG
senior tag
válasz
pakriksz
#4014
üzenetére
Tesztre DEBUG szinten szoktunk logolni.
Próbáld ki DEBUG-gal. Nincs kizárva, hogy ez az appender egyáltalán nem logol INFO-ban. Láttam már ilyet. A 4.x-es JBoss egy csomó ERROR logot csak DEBUG-ban volt hajlandó logolni. Ergó, a kedves feljlesztők a try catch ág catch bejegyzéseibe nem ERROR, hanem DEBUG logot tettek... -
#3899
TBG
senior tag
kemkriszt98
#3896
TBG
senior tag
válasz
kemkriszt98
#3896
üzenetére
manifest-ben mi van?
-
#3895
TBG
senior tag
kemkriszt98
#3893
TBG
senior tag
válasz
kemkriszt98
#3893
üzenetére
És még az is kérdés, hogy milyen hibával nem futtatja?
-
TBG
senior tag
Idézek a saját hozzászólásomból:
Nyilvánvalóan nem hiba az ArrayList<?> deklaráció, de a statikus típus interfészként deklarálása good practice. Az implementáció egyszerű változtathatósága miatt. Nem is az osztályváltozókban van komolyabb jelentősége, hanem a getter/setter metódusoknál.
És még valami. Amíg magadnak vagy egy kvázi zárt csapatban dolgozol, addig nincs ezzel gond. Amint pl. API-t kezdesz írni, akkor csak interface. És a doksiban kell leírni a runtime típust.
-
TBG
senior tag
List<?> vagy ArrayList<?>
Nyilvánvalóan nem hiba az ArrayList<?> deklaráció, de a statikus típus interfészként deklarálása good practice. Az implementáció egyszerű változtathatósága miatt. Nem is az osztályváltozókban van komolyabb jelentősége, hanem a getter/setter metódusoknál.
Nyilván vannak olyan kivételes esetek, amikor konkrét implementációt kell használni, pl. GWT szerializáció, amikor is nem minden List implementáció szerializálható, hanem csak egyes, konkrét implementációk.
-
TBG
senior tag
Tehát. Itt ez a remek kód.
try {
rs.moveToInsertRow();
rs.updateInt("ID", newID);
rs.updateString("First_Name", first);
rs.updateString("Last_Name", last);
rs.updateString("Job_Title", job);
rs.insertRow();
stmt.close();
rs.close();
stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_UPDATABLE);
String sql = "SELECT * FROM Workers";
rs = stmt.executeQuery(sql);Ehelyett inkább: (nem teljes és nem is ismerem a táblastruktúrát)
String insertSql = "INSERT INTO Workers(id,firstname) VALUES("+newID+","'"+firs+"'");
stmt.executeUpdate(insertSql); -
-
TBG
senior tag
válasz
pakriksz
#3736
üzenetére
Tehát vegyük át még egyszer. URL NEM tartalmazhat space-t. A paraméterek nevei NEM tartalmazhatnak space-t, a paraméterek értékei igen, encode-olva. Ha pár apróságot figyelembe veszel, könnyebb lesz az életed.
Természetesen a szabványoktól el lehet térni, csak nem érdemes.
-
TBG
senior tag
válasz
pakriksz
#3733
üzenetére
Az URLEncoder teljesen jól működik. Ismerni kellene pár szabványt és nem anyázni.
http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4
Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738],
Tehát a replaceAll() nem gányolás. A gányolás az, hogy space van az URL-ben.
http://www.w3schools.com/TAGS/ref_urlencode.asp
URLs can only be sent over the Internet using the ASCII character-set.
Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format.
URL encoding replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits.
URLs cannot contain spaces. URL encoding normally replaces a space with a + sign.
-
#3726
TBG
senior tag
WonderCSabo
#3719
TBG
senior tag
válasz
WonderCSabo
#3719
üzenetére
+1
-
TBG
senior tag
válasz
pakriksz
#3723
üzenetére
Ez viszont vicces: az URL osztály nem kódolja rendesen URL-é a beadott a stringet. Openstreamnél simán elküldi a spacet pedig valami %20-al kéne helyettesítenie, aztán a szerver dobja is 400-as hibát rá.... Nagyon jó, még egy replace(" ","%20") gányolás....
http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URLEncoder.html
-
TBG
senior tag
Nekem is tetszik, bár nem kedvelem az ötletet, hogy a GUI-t programkódban állítsuk elő, a deklaratív, JSF-es megoldás nekem jobban tetszik ebből a szempontból.
Van deklaratív lehetőség is a GWT-ben
UIBinder.Egyeébként ha GWT, akkor csak a sztenderd GWT...minden keretrendszer drámaian rontja a teljesítményt, ráadásul mindegyik bevezeti a saját kis megoldásait, amitől már teljes az inkompatibilitás.
-
TBG
senior tag
Egyetértek.
Ezért hanyagolom én speciel a JSF-et többek között. DOM fa nagyság és third party library-k
Richfacessel voltak nagyon rossz tapasztalatok...aztán lett GWT és JSP..ahogy éppen az adott feladat megkívánja.Persze, a GWT-ről lehetne komoly vitát nyitni, de okosan kell használni és akkor nincs gond
-
TBG
senior tag
A metódus elé tegyél egy annotációt:
@SuppressWarnings("unchecked")
public String toXml() {
StringBuilder xml = new StringBuilder();
if ( this.emp!=null && !this.emp.isEmpty() ) {
for (Employee employee: this.emp) {
// employee to xml, ahogy tetszik.
// TransformerFactory tf = TransformerFactory.newInstance();
// Transformer t = tf.newTransformer();
// DOMSource source = new DOMSource(doc);
// StreamResult result = new StreamResult(new File("xmldoc.xml"));
// t.transform(source, result);
// return result.toString();
xml.append(employee.toXml());
}
}
return xml.toString();
} -
TBG
senior tag
Ezt próbáld meg!
TransformerFactory tf = TransformerFactory.newInstance();
Transformer t = tf.newTransformer();
DOMSource source = new DOMSource(doc);
Writer outWriter = new StringWriter();
StreamResult result = new StreamResult( outWriter );
t.transform(source, result);
StringBuffer sb = outWriter .getBuffer();
return sb.toString(); -
TBG
senior tag
Igen, de legyen a metódusodnak visszatérési értéke...monduk egy String.
Tehát
public void toXML()
helyett
public String toXML()
A végén meg a
StreamResult result = new StreamResult(new File("xmldoc.xml"));
t.transform(source, result);helyett
StreamResult result = new StreamResult(new File("xmldoc.xml"));
t.transform(source, result);
return result.toString();Azt hiszem, hogy a StreamResult-nak van toString() metódusa értelmesen.
de a xml.append(employee.toXml()); meg mindig piros felkiatojel
Igen, mert String-et vár, de Te voiddal térsz vissza. Ezt javítja az, amit fent rögöftem
Ja és még valami, ne itt rakd az XML-t fájlba, hanem az oraj osztályban. -
TBG
senior tag
Hmm. Azért dob java.lang.UnsupportedOperationException: Not supported yet. hibát, mert a toXml() metódusod ezt tartalmazza:
Object toXml() {
throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
}Tehát qrva jól működik.
DE!! Ez csak egy generált kód..neked ezt kell tartalommal feltöltened!
Valami ilyesmivel:public String toXml() {
String startElement="<element>";
String endElement="</element>";
String startNameElement = " <name>";
String endNameElement = " </name>";
return startElement+"\n"+startNameElement+this.name+endNameElement+"\n"+endElement;
}Persze, nem ilyen primitív módszerekkel, hanem pl. Sax,DOM...akármi...
-
TBG
senior tag
Az orej-ben, jelentsen bármit is
Írsz egy metódust, valami ilyesmit:
public String toXml() {
StringBuilder xml = new StringBuilder();
if ( this.emp!=null && !this.emp.isEmpty() ) {
for (Employee employee: this.emp) {
// employee to xml, ahogy tetszik.
xml.append(employee.toXml());
}
}
return xml.toString();
} -
TBG
senior tag
Gyakorlatilag a Java fejlesztésnek az egyik alapja, hogy addig nem kell semmit megírni, amíg meg nem győződsz róla, hogy nem írta-e meg valaki más már
Szerintem olyat alapból nem lehet. Az ArrayList egy konténer, ami különféle objektumokat tárol. Az objektumokhoz lehet XML parsert/marshallert/serializert/ahogy tetszik írni, ami végigmegy az ArrayList elemein és azokat egy XML-be írja bele. Mondjuk ha az ArrayList-ben String-ek vannak:
<element>
<value>egy</value>
</element>
<element>
<value>ketto</value>
</element>
<element>
<value>harom</value>
</element>
<element>
<value>negy</value>
</element>Ahol is az <element></element> reprezentál 1 darab ArrayList elemet. Azt, hogy miként rakod XML-be, a saját XML makered szabályozza.
-
TBG
senior tag
Szóval, az, hogy a Netbeans-ben hogy kell csinálni, nagyon rossz irány. Netbeans-tól függetlenül is működne kell az ilyen dolgoknak.
Ha van SQL scripted, akkor az egyik irány lehet, hogy felparseolod, mondjuk ';' delimiterrel, majd egyesével szépen lefuttatod az SQL parancsokat, amik benne vannak.
Pl:
CREATE DATABASE test;
CREATE TABLE table1(id int, name varchar(12));Ez konkrétan két utasítást fog egymás után végrehajtani. Nyilvánvalóan adatbázisszervertől függ a pontos szintaktika.
Aztán ha megvan, akkor lehet mindenféle Java-s okosságokat csinálni.
Itt van példakód is: [link]
-
-
TBG
senior tag
-
TBG
senior tag
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!!
-
TBG
senior tag
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.
-
TBG
senior tag
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!
-
#3549
TBG
senior tag
Peter Kiss
#3548
TBG
senior tag
válasz
Peter Kiss
#3548
üzenetére
A szoftverfejlesztés egy ilyen sötét mágiával átjárt tudomány. Láttam sok cifra dolgot már
szerk:
Egyébként meg igazad van.
-
#3547
TBG
senior tag
Peter Kiss
#3546
TBG
senior tag
válasz
Peter Kiss
#3546
üzenetére
Nyilván az nem derült ki, hogy a kolléga mire akarja használni. És igenis, lehet az, hogy csak az egyiket írom felül. Ha egy listába rakom és csak a contains() metódust hivogatom rá, akkor bőven elég az equals() metódust felüldefiniálni.
Nem véletlenül írtam, hogy alternatív megoldás és nem az üdvözítő.
-
TBG
senior tag
válasz
pvt.peter
#3543
üzenetére
Superhun megoldása teljesen jó.
Viszont ha már saját osztályt használsz felüldefiniált metódusokkal, akkor szerintem elég az equals felüldefiniálni úgy, hogy a String és az int egyezőség esetén adjon vissza TRUE-t és akkor egy "sima" ArrayList-be is teheted. Persze attól is függ, hogy mennyi elemed lesz, mert nagyon sok elem esetén az ArrayList nem túl gazdaságos. Nem mondom, hogy Superhun vagy az én megoldásom a jobb, az enyém egy alternatív, de valamivel egyszerűbb megoldás, mert csak 1 metódus felüldefiniálását kell megcsinálni, de mint írtam, sok elemnél nem feltétlenül gazdaságos.
-
-
TBG
senior tag
Nem következik. A webes alkalmazásfejlesztés Java-ban egy teljesen más műfaj. Ahogy a kolléga is írja, a GWT áll a legközelebb hozzá, de HTML/JS ismeretek ott is elengedhetetlenek.
Egyrészt kell egy erős backend ismeret...minimum Servlet szinten, de a különféle EE környezetek ismerete is erősen ajánlott. -
#3521
TBG
senior tag
WonderCSabo
#3520
TBG
senior tag
válasz
WonderCSabo
#3520
üzenetére
Ha a változó/metódus el van fedve, akkor annak oka van. Ha mégis el kell érni, akkor protected. Vagy publikus getter
Alapvetően design kérdése egyébként. -
#3501
TBG
senior tag
WonderCSabo
#3499
TBG
senior tag
válasz
WonderCSabo
#3499
üzenetére
Megint csak csatlakozom...ha nincs performance loss, meg lesz backward compatibility....akkor jöhet.
-
#3498
TBG
senior tag
WonderCSabo
#3494
TBG
senior tag
válasz
WonderCSabo
#3494
üzenetére
Csatlakozom...baromság lenne.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- LG 27GR95UM - 27" MiniLED - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 1000
- AKCIÓ! Gigabyte B650M R7 7700X 32GB DDR5 1TB SSD RTX 3080Ti 12GB Cooler Master H500P WHITE 750W
- Dixit 4 Eredet (bontatlan, fóliás kártyacsomag)
- BESZÁMÍTÁS! Intel Core i9 14900KF 24 mag 32 szál processzor garanciával hibátlan működéssel
- BESZÁMÍTÁS! Microsoft XBOX Series S 512GB játékkonzol garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest