Hirdetés
- Lassan állítjuk a fát, és a hardverek is be vannak csomagolva
- Klasszikus kínai festmények ihlették a Colorful legfrissebb memóriáinak külsejét
- Ultrakompakt Key E SSD-vel jelentkezett a Silicon Power
- Mesterséges intelligenciára kihegyezett mini PC jött az ASUS műhelyéből
- ASUS blog: ExpertBook P5 notebook, a munkagép
- Amazon Kindle
- CPU léghűtés kibeszélő
- AMD Navi Radeon™ RX 6xxx sorozat
- HiFi műszaki szemmel - sztereó hangrendszerek
- Unigine Superposition Benchmark
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Intel Core i3 / i5 / i7 4xxx "Haswell" és "Haswell Refresh / Devil's Canyon" (LGA1150)
- TCL LCD és LED TV-k
- Lassan állítjuk a fát, és a hardverek is be vannak csomagolva
- AMD K6-III, és minden ami RETRO - Oldschool tuning
Új hozzászólás Aktív témák
-
#4800
Oppenheimer
nagyúr
Karma
#4799
Oppenheimer
nagyúr
Mi az az elv amiért nem használsz netbeanst? Én eclipse-es vagyok, de van hogy IDE flame warba kerülök a netbeanses haverommal, és egyikünk se tud értelmes érveket felhozni.
Azt észrevettem, hogy a tapasztalt java fejlesztők kerülik a netbeanst, helyette intellij ideát, vagy eclipset használnak, de a miértre nem tudom a választ.[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
Karma
félisten
válasz
S0m30n3
#4798
üzenetére
NetBeanst én elvből se használok, de SQL Serverrel már kommunikáltam JDBC-n keresztül.
A Microsoft driver helyett a jTDS-t használtam, SQL Server authentikációval. A Management Studioban előtte bekapcsoltam a TCP protokollt, és így néz ki az URL:jdbc.driverClassName=net.sourceforge.jtds.jdbc.Driver
jdbc.url=jdbc:jtds:sqlserver://192.168.1.103:11433;instanceName=SECRETPROJECT;databaseName=SecretProjectDB;Legalábbis ez a helyi teszt konfiguráció, élesítés után azt hiszem hangoltunk még rajta, de azt nem tudom (és nem is akarnám) felidézni. Mindenesetre célszerű megnézni a jTDS URL-jének a lehetséges paramétereit.
Ezt a két propertyt, karöltve a felhasználóval és jelszóval átadom egy DriverManagerDataSource-nak, és vígan megy a Hibernate is meg a kézi SQL is. Leegyszerűsítve
[ Szerkesztve ]
“All nothings are not equal.”
-
S0m30n3
aktív tag
Hello emberek!
Már egy-két napja böngészem a netet, de nem találtam még jó megoldást az alábbi problémához:
Netbeans-t használok, szeretnék csatlakozni egy általam készített MSSQL adatbázishoz, de egyszerűen nem akar összejönni. Az alábbi hibaüzenetet kapom: com.microsoft.sqlserver.jdbc.SQLServerException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
A kódom pedig a következő:
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
String url = "jdbc:sqlserver://localhost;instance=SQLEXPRESS;databaseName=prog3_ef;integratedSecurity=true;";A driver-t leszedtem Microsoft oldaláról, csatoltam is a projekthez. 1433-as port nyitva van, működik is. SQL Server Browser service fut.
Már vagy 5-6 féle változatot kipróbáltam, windows authentication-nel és anélkül, de nem akar összejönni. Egyik oldalon azt is írták, hogy netbeans-ben nem is lehet így csatlakozni és inkább állítsam át "SQL Server and Windows Authentication mode"-ra a Management Studio-ban, hogy „sa”-val csatlakozzak, de az sem ment. Valaki tudna segíteni?
-
#4797
M_AND_Ms
veterán
WonderCSabo
#4795
M_AND_Ms
veterán
válasz
WonderCSabo
#4795
üzenetére
Mint minden ilyen feladvány, ez is teljesen elrugaszkodott a valóságtól.
Ez olyan, mintha az autószerelő vizsgán az a feladvány lenne, hogy a hűtővíz befolyt az üzemanyagtartályba, ahova előzőleg benzin helyett, ablakmosót töltöttek. A kérdés, ha az üzemanyagtartályból kivett folyadékkal átmossuk a légszűrőt és visszarakjuk azt, akkor elindul-e ez az autó.Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
#4795
WonderCSabo
félisten
floatr
#4794
WonderCSabo
félisten
A Java serializáció API-ja teljességgel elhibázott, mi az, hogy be kell kopizni a függvényszignatúrákat a customhoz, és ha eltalálom jó. ha nem akkor meg se hívódik? Ehhez egy újabb interfészt kellett volna bevezetni. Van még sok dizájn flow a javában - pl. a clone() fv. az Object része, de csak akkor ok, ha az osztály implementálja a Cloneable interfészt - miért nem lehetett akkor a clone()-t eleve csak a Cloneable-be rakni...
Viszont ez a feature nagyon is jogos. Pl. van egy objektumgráfod, kétszer is hivatkozol valahol benne az objektumra, miért is mentenéd ki kétszer az értékét? Továbbá ha ciklikus referenciád van, akkor még nagyobb probléma lenne, ha mindig mentenél, mert szépen stackoverflowt kapnál.
Egyébként is, a gyakorlatban ez a példa sosem fog szerepelni (teljességgel hülyeség u.a. objektumot rögtön egymás után különböző értékekkel kiszerializálni, nem látom ennek use-caset).
A JSON meg XML valóban elterjedt, de azért ezek többet foglalnak és lassabbak is, mint a Java serializálás. Én pl. Androidon szoktam használni, ahol nem fájlba mentünk objektumokat, hanem programrészek között küldjük át szerializálva. -
#4794
floatr
veterán
WonderCSabo
#4793
floatr
veterán
válasz
WonderCSabo
#4793
üzenetére
Lehet h velem van a baj, de már 15 évvel ezelőtt is elvétve láttam csak használatban java serialization-t (max RMI). Amikor fősulira jártam, meg egyemista voltam, még nem oktatták, így magamtól tanultam gyakorlatilag mindent, de ez most szíven ütött
Többek közt azért is mert olyan témát feszeget, aminek a gyakorlatban nullához konvergál a határhaszna. Tipikus egyemista feladat. Nem véletlenül használnak inkább XML-t vagy JSON-t.Az egészben az a mókás, hogy ha a való életben beleszaladnál egy ilyen problémába, hogy meg kéne fejteni a működést, akkor olyan mérnökösen unit tesztelnéd, hogy biztosra legyél benne, és ne rúgassad ki magadat egy esetleges tárgyi tévedésért, ami -- valljuk be -- bármikor beüthet. Ellenben az egyemista vizsgázó kolléga (de a vizsgáztató is) nézne nagyokat, ha azt kapná feladatnak, hogy egy kódolt, aláírt SAML alapján kéne beléptetni egy felhasználót, mondjuk könnyítésképpen úgy, hogy a kliens a jó kulcsot és aláírást adja meg
-
Spam123
tag
Na csak, hogy a sok off közül is kitűnjön a jó eredmény:
1704
1704Azért írtam be, mert már ki lett tárgyalva, sajna a kelleténél hamarabb, de a lényeg az, hogy amikor t-t másodszor is serializálni akarod, akkor nem serializálódik, mert még mindig ugyanaz a példány (ugyanaz a referenciája) és egy példány csak egyszer serializálódik.
Traniens és static dolog meg adja magát már gondolom.
-
skoda12
aktív tag
válasz
Spam123
#4754
üzenetére
SCJP/OCJP vizsga tele van ilyenekkel, interjun is kaptam hasonlokat, szoval nem neveznem neheznek. Inkabb figyelmetlensegi hibat konnyu veteni ilyeneknel. Persze attol fugg, hogy a 4 * 90 perces eloadasaidon mit adtak le pontosan. Ha normalisan el lett mondva, hogyan mukodik a serializalas, transient, static akkor nem szabadna gondot okoznia. Bar gyanitom ez nem tortent meg, mert akkor nem raktad volna ide ki a peldat
-
#4789
Spam123
tag
Oppenheimer
#4788
Spam123
tag
válasz
Oppenheimer
#4788
üzenetére
Annyi itt a probléma, hogy szoftlab 3 nem kell a szofttech-hez, tehát ha buktam a 2-t, akkor is simán felvehetem a szofttechet. És ha már ennyire jó a szoftlab 3. Miről is szólt idén? Bemész, önállóan/társaddal megírod a feladatod és kész. Házi miről szólt? Önállóan megírod és bemutatod.
Szoftlab 3 nem egy tárgy, hanem számonkérés, mivel ott nem oktatnak, csak számon kérnek. Ennyi erővel miért nem otthon gyakorolja az ember, annyit amennyit akarja?
Nekem szinte semmit se tett hozzá a szoftlab 3 tárgy a tudásomhoz, csak az, amit én magamtól készültem.
Egyébként én 5-ös lettem mindkettő, tárgyból, tehát nem azért tettem be ezt ide, hogy bosszút álljak, csak kíváncsi voltam arra, hogy ez mennyire nehéz egy átlag programozónak.
-
#4788
Oppenheimer
nagyúr
Spam123
#4787
Oppenheimer
nagyúr
válasz
Spam123
#4787
üzenetére
Most azért kicsit ferdítesz, mert ott volt a szoftlab 3. Az azért elég sok gyakorlás volt, láttam te is mikor írtad a házid, itt kértél segítséget. Szóval azt nem mondhatjuk, hogy nem volt gyakorlat (ugyanis volt labor, ahol kötelező volt gyakorolni (+ nagyházi)) és nem volt leadva elméletben az anyag (ott van benne a diában).
Azzal sem értek egyet, hogy csak magolni kell. Ide pont, hogy ész kell, hogy tudd használni azt amit beseggeltél, és ne csusszanj át az ilyen részletek felett. Most már egyébként beugrott, hogy nem csak a dián szerepel, hogy referencia íródik ki a 2. alkalomtól, hanem el is magyarázta előadáson. Szerintem megjegyezni könnyű, mert tök logikus, de az, hogy ilyen helyzetben az ember odafigyeljen rá, az már sokkal nehezebb, ergo itt pont ész kell.
Azzal egyetértek, hogy Javának több járna 4 előadásnál, heti 1 labornál és egy nagyházinál, de szoftlab 4-en is lesz egy kis Java, és ha olyan szakirányra mész, akkor még találkozol vele. A 2014-ben felvettek szerencsések lesznek, mert nekik már új tanterv lesz amiben szerepel programozás alapjai 3, ahol Javát tanítanak majd.
Holnap megmutatom a munkahelyemen a Java kódereknek a feladatot.
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
#4787
Spam123
tag
Oppenheimer
#4784
Spam123
tag
válasz
Oppenheimer
#4784
üzenetére
Oké, nyertél, ott a dia. Ha bemagolja az ember őket, valószínűleg tudni fogja, bár azért a magoláson kívül érteni is kéne mindet, de az előadásból nem biztos hogy minden teljesen világos lesz. Egyébként ha én a magolás császára és favorizálója lennék bölcsésznek mentem volna, nem mérnöknek. Gyakorlat nélkül Java-t tanítani olyan mint a sexet könyvből megtanulni.
Persze lehetne otthon is gyakorolni Java-t, de akkor teljesen felesleges egyetemre járni, ha úgy is mindent otthon tanulsz meg és nem segítenek benne.
[ Szerkesztve ]
-
#4786
Oppenheimer
nagyúr
WonderCSabo
#4785
Oppenheimer
nagyúr
válasz
WonderCSabo
#4785
üzenetére
Ne gratulálj, én 7-én vizsgáztam és előtte pár nappal tudtam meg ezt, de csak azért, mert korábbi vizsgában volt ilyen.
Se diából, se tapasztalatból nem emlékeztem volna ilyenre.https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
#4785
WonderCSabo
félisten
Oppenheimer
#4784
WonderCSabo
félisten
válasz
Oppenheimer
#4784
üzenetére
Ezek szerint erre Te emlékeztél. Azt hiszem Te voltál az egyetlen. Grat!
Pontosan a 2. dia írja le ennek a példának a trükkjét. -
#4784
Oppenheimer
nagyúr
Spam123
#4783
Oppenheimer
nagyúr
válasz
Spam123
#4783
üzenetére
Korábbi vizsgákból. Ha idén lett volna ez a vizsgafeladat, biztos nem tudom megcsinálni, mert OOS-en benéztem volna, de ha valaki ezt tudja, akkor onnantól megoldható. Tényleg szó szerint kell amúgy tudni a diákat, hogy az ember átmenjen, ennél a feladatnál szerintem erre kellett (volna) visszaemlékezni a hallgatóknak:
Ami a tapasztalt java kódereket illeti, szerintem csak az tudja megoldani direkt rákészülés nélkül, aki nagyon sokat szerializált.
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
#4783
Spam123
tag
Oppenheimer
#4780
Spam123
tag
válasz
Oppenheimer
#4780
üzenetére
És miből készültél fel? Vagy honnan tudtad volna erre a választ, ha nem látod előtte ezt a példát? Ahogy mondtad, ezt nem adták le külön előadáson, hogy OOS lezárással mi a helyzet.
-
#4781
Karma
félisten
Oppenheimer
#4780
Karma
félisten
válasz
Oppenheimer
#4780
üzenetére
Mondjuk ez a bezárásos szöveg szerintem eléggé sablon marhaság (mármint hogy így adják elő órán). Miért zárnád be a streamet ha van még mit kiírni? Ott van a reset metódus erre.
[ Szerkesztve ]
“All nothings are not equal.”
-
#4780
Oppenheimer
nagyúr
Spam123
#4754
Oppenheimer
nagyúr
válasz
Spam123
#4754
üzenetére
Ez elég triviális. Mondjuk 4-es lettem ebből a tárgyból, mert felkészültem rendesen, de itt csak annyit kell tudni, hogy static és transient dolgok nem szerializálódnak, és ha nem zárják be az ObjectOutputStreamet, akkor a következő kiírás nem írja felül az előzőt. Persze ha nem készültem volna fel a vizsgára, én se tudnám, szóval lehet hogy tényleg nehéz.
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
axioma
veterán
Na most latszik, hogy el se olvastam a feladatot rendesen. Szoval mea culpa, en azt hittem, hogy ez a tipikus elnevezek 5 member- es fuggvenyvaltozot ugyanolyannak, modositokkal teleszorom, es talald ki, hogy harmadik melysegben eppen melyik lesz az adott esetben ervenyes ertek (ez volt a Mor-St felvetelin, megspekelve azzal, hogy szintaktika helyes-e vagy ha nem hol hibas; ha szintaktika jo akkor forditas hiba nelkul lefut vagy hol hibas, ha lefordul akkor futtatasnal hibat ad es mit, vagy ha nem, mi a vegeredmeny).
Most csak megneztem me'g egyszer, bevallom a transient nekem nem volt meg se'ro'bo'l (mondjuk pont nem foglalkoztam sose objektumok neten atkuldesevel, es nem objektumokat, hanem - nem is feltetlen azonos - xml strukturakat mentunk), de egyetemistakent friss anyagkent azert nem tulzo talan. Az mas kerdes, hogy nem feltetlen tippeltem volna kapasbol jot...
Elnezest a feluletessegert!Jim-Y: azon kivul csak a static erdekes, de az meg nalam surun elofordul, ugyhogy annak csak nagyon figyelmetlenul ugrottam volna be.
[ Szerkesztve ]
-
#4774
Karma
félisten
WonderCSabo
#4772
Karma
félisten
válasz
WonderCSabo
#4772
üzenetére
Nekünk is volt egy egész félév a nyelvről, illetve szakirányos tárgyakon még legalább három kurzus ami Javaval foglalkozott, de arról egyszer se volt szó, hogy miért viselkedik az a és d úgy, ahogy. Szerencsére van StackOverflow ahonnan gyorsan kiderült a magyarázat
[ Szerkesztve ]
“All nothings are not equal.”
-
Jim-Y
veterán
Szerintem ez még nem egy elvetemült vizsgakérdés, DE az igaz, hogy sima fél éves java se tanulás után ez nehéz.
Nekünk idén volt java ee kurzusunk, ahol az elején socketeken keresztül szerializáltunk ki objektumokat, mivelhogy az az rmi alapja, ami később az ejb (rmi over iiop) alapja lesz. Szóval egy ilyen javas kurzuson ez a kérdés simán előfordulhat és még csak szemét kérdésnek sem nevezném. Más kérdés, hogy pl én sem tudom rá a választ, de ez inkább az én szegénységi bizonyítványom
Valaki megírná nekem, hogy miért pont
1709 -et meg 6709-et tippelt? A 7-re vagyok kíváncsi a többi így már tiszta[ Szerkesztve ]
-
#4770
Spam123
tag
WonderCSabo
#4768
Spam123
tag
válasz
WonderCSabo
#4768
üzenetére
Ki beszélt féléves Java kurzusról? 4 darab 90 perces előadás és nincs belőle gyakorlat, semmi. Csak a saját magadtól megszerzett plusz tudás. Ja és ebbe a 4 alkalomban benne van minden: Java újdonságok, Exception, I/O, thread, Swing, generikus cuccok. Tehát nem beszélnek semmiről se órák hosszat és nincsen mindenről példakód sem.
[ Szerkesztve ]
-
Karma
félisten
Én már megfejtettem, annyit hadd mondjak el, hogy 1) attól, hogy valami nem szerializálódik ki, a változó létezik és egész szám, úgyhogy megjelenik a kiírásban (2x4 számjegy biztosan lesz); 2) és ez a BROTIP része: a Java szerializálás sokkal bonyolultabb, mint eddig gondoltam.
És aki ilyet kérdez vizsga beugróban, nyaljon sünt. Ez a történet nem az egyszerű szabályokról szól
[ Szerkesztve ]
“All nothings are not equal.”
-
#4768
WonderCSabo
félisten
Karma
#4763
WonderCSabo
félisten
Sorry, azt írta, a kolléga, hogy írja be ide, aztán mire leírtam akkor kapcsoltam, hogy lehet h. nem publicban kellett volna.
Azért ez annyira nem nehéz példa. Bár simán lehet, hogy rossz az eredményünk, nem emlékszem pontosan már a specifikációra. Egyébként szerintem pont egy féléves Java kurzus után tudják az emberek a legjobban ezeket a példákat: akkor még frissek az agyontanult egyszerű szabályok.
[ Szerkesztve ]
-
Jim-Y
veterán
válasz
Spam123
#4765
üzenetére
Én nem vagyok java programozó, de azért tippelek én is, ugye itt objektum szerializációról van szó, és arra mennek rá, hogy a public, private, static és transient hogy befolyásolja a szerializációt.
Az én tippem (sajnos nem tudom, hogy az int default mire értékelődik ki, ha nullára akkor)
104
609
ha null, akkor
14
69 -
#4763
Karma
félisten
WonderCSabo
#4762
Karma
félisten
válasz
WonderCSabo
#4762
üzenetére
Én is pont ezt tippeltem privátban. Nem spoilerezek.
“All nothings are not equal.”
-
modder
aktív tag
válasz
Spam123
#4754
üzenetére
Én első blikkre azt mondanám, hogy a tranziens adattagot nem fogja egyedül kiírni a fájlba. A static mellett és ellen is szólna érv, most azt, hogy azt kiírja a fájlba, mert miért ne, aztán vissza is olvassa
szerk: tévedtem, a statikus tagot nem írja ki
[ Szerkesztve ]
-
axioma
veterán
válasz
Spam123
#4756
üzenetére
En java-ban fejlesztek immar tobb mint 10 eve, elotte volt me'g C is, de nem fogom megoldani, nem erdekel. Ha esetleg egyszer valamire ebbol szuksegem lesz, van egy gugli baratom.
Es barmily meglepo, ettol fuggetlenul nem mondom azt, hogy nem ertek egyet ezzel a feladattal, HA iskolai kornyezetben kerul elo! Egyreszt egyetemen me'g friss az agyad annyira, hogy a magolast meg tudod (es kell) csinalni, masreszt ez emlekezetes lesz, ezekre a modositokra (nem a nevere, hanem a letezesere), sot, hogy miert es melyik reszevel szivtal sokat, na ARRA emlekezni fogsz. Es legkozelebb kerulod...
Igazabol az oktatason egy csomo mindenrol nincs szo, amirol kene, ha a kesobbi hasznalatot nezem (jo, hat en "kicsit" regebben vegeztem igy valtozhatott, de hogy pl. verziokezelo rendszert nem ismertetnek, sot, nem tesznek kotelezove mar az otthon megirando programokhoz... me'g a mas megirta helyette es/vagy lemasolta a netrol is jobban szurheto lenne). De osszessegeben me'giscsak felkeszit ahhoz, hogy kezdokent nekivaghass egy programozoi allasnak. Szerintem!Superhun: Hun?
Marmint rakjak ele. Csak hogy oda ne akarjak menni... (bar sztem itthon en mar ugyse fogok allast keresni, hacsak valami csoda nem tortenik).[ Szerkesztve ]
-
Spam123
tag
Nagyjából egyetértünk, igazából ez egyetemen egy vizsgafeladat volt, csak kíváncsi vagyok, hogy akik mondjuk olyan munkájuk van, akik Java-t használnak, vagy csak egyszerűen jártasak benne, meg tudják e oldani ezt hibátlanul, ahogy nekem is kéne, fél év java "oktatás" után. (4 db előadás volt Java-ról, jegyzet persze nuku)
-
axioma
veterán
válasz
Spam123
#4754
üzenetére
Elore bocsatom, hogy rejtvenykent nincs kifogasom ellene, de a kovetkezore asszocialtam.
Nekem a MorganStanley felvetelin tettek valami hasonlot ele'm, ugy 6.5 eve. Ahol ugy szolt az allashirdetes, hogy keresnek jo problemamegoldo kepessegu fejlesztot, onallo munkara is alkalmas de csapatban is hatekony meg hasonlokat tartalmazo felsorolas vegen vagy C vagy C++ vagy Java jartassag. Na mondom, ez a nekem valo munkahely, mert itt valoban a kepesseget nezik, raadasul jellemzoen mukodo programhoz kell bekapcsolodni, nem csak a szakmai reszt tanulja az ember, hanem a formai es stilusbeli elvarasokat is a nyelven belul (es tetszett volna a penzugyi temahoz kapcsolodas).
Na erre elem raktak egy ilyet. Ketto nagy bajom van ezzel:
1. komoly helyen ilyen programot me'g jatszasibol se irunk, hiszen pont az a lenyeg, hogy a programot ne csak az iroja ertse meg, hanem az is aki code review-zza, meg az is aki kesobb bele kell nyuljon stb. (es akkor me'g a kommentekrol nem is ejtettunk szot)
2. ahol arra kivancsiak, hogy ki tudod-e bogozni a kodolasi finomsagokat, ott kodolot keresnek, nem fejlesztot (a mi munkahelyunkon, ahol a fonokok inkabb muszaki egyetemrol indultak - mar csak az eletkor miatt is - mint tud.egy.-emrol, ezt ugy mondjak, hogy nem programozo kell neki amin kodolot ertenek, hanem mernok, aki problemara tud megoldast talalni - csak eppen ezesetben a program, annak is inkabb tervezese utjan).
Vegulis olyan ertelemben nem volt ellentmondas koztunk, hogy ok azt mondtak, hogy nem feleltem meg (na persze, mert a fene gondolta, hogy tetszoleges java konyv elso 50 oldalanak bes*ggelese lesz egy ilyen hirdetes utan a felveteli feltetel), en meg mondtam, hogy me'g ha fel is vettek volna, se lett volna jo elfogadom, ha a munkatarsak akikkel egyutt kell majd dolgozni, mindossze ezen a teszten mentek at (volt ismerosom, aki keszult igy hozzajuk...)
Termeszetesen kesobb kiderult, hogy volt akit meg pont forditva, az altalam gondolt stilusban felveteliztettek, gondolom egy masik reszlegre, vagy fonokhoz. -
Spam123
tag
Egy kis érdekességként beteszed ide egy "fejtörőt". A lényeg az lenne, hogy mindenki fordító és netes keresgélés nélkül oldja meg a saját tudásából és írja be, hogy mit írna ki a program. Mindenkinek a saját lelkiismeretére bízom, hogy betartja e a játékszabályokat. Pár nap után beírom a helyes eredményt, de ha nagyon triviális és mindenki tudni fogja, akkor elnézést.
(Kattintásra nagyobb lesz)
[ Szerkesztve ]
-
floatr
veterán
válasz
Superhun
#4751
üzenetére
Csak megnéztem a dolgot, de érdekes [link]
testArrayListAdd 234.896 ops/msec
testVectorAdd 274.886 ops/msec
testArrayListTraverse 1718.711 ops/msec
testVectorTraverse 34.843 ops/msecvégülis csak majdnem két nagyságrendi különbség van a kettő közt. Elhanyagolható
Majd amikor nem példaprogramokból él meg az ember, és az ügyfél a haját tépi, hogy miért tart 10 percig egy funkció, akkor majd könnyebb lesz megérteni, csak egy többezres kódbázisú projekten újra végigfutni azért elég necces lesz. Pláne ha nyomorultul van megtervezve a struktúra. -
#4751
Superhun
addikt
WonderCSabo
#4750
válasz
WonderCSabo
#4750
üzenetére
Én az ELTÉ-n Keszthelyi Zsolt óráin láttam utoljára Vectort. Megkérdeztem, hogy miért használ Vectort, mikor lassabb az ArrayListnél. Erre a válasz: a Vector szálbiztos és a sebességkülönbség minimális. Mondtam ok, nem akartam leülni erről vitázni.
-
#4749
floatr
veterán
WonderCSabo
#4748
floatr
veterán
válasz
WonderCSabo
#4748
üzenetére
Arany ember vagy
-
#4747
floatr
veterán
WonderCSabo
#4746
floatr
veterán
válasz
WonderCSabo
#4746
üzenetére
Ja, csak elcsesztem a paraméterezést a table/map esetében
Helyesen Hashtable<K,V> meg HashMap<K,V>
-
#4746
WonderCSabo
félisten
floatr
#4745
-
-
#4743
fatal`
titán
WonderCSabo
#4741
fatal`
titán
válasz
WonderCSabo
#4741
üzenetére
Ezt én tudom, de Vectort írt.
-
#4738
alratar
addikt
WonderCSabo
#4737
alratar
addikt
válasz
WonderCSabo
#4737
üzenetére
Igaz.
Akkor jobb, ha ráengedek egy malware keresőt!10 féle ember van: aki ismeri a bináris számrendszert, és aki nem
-
#4736
alratar
addikt
WonderCSabo
#4735
alratar
addikt
válasz
WonderCSabo
#4735
üzenetére
De ha jól értem akkor sem kaptam el, ha fenn van a java, feltéve ha nem látogattam meg az oldalt. (Yahoo)
10 féle ember van: aki ismeri a bináris számrendszert, és aki nem
-
#4732
floatr
veterán
WonderCSabo
#4731
floatr
veterán
-
floatr
veterán
Menet közben beugrott a triviális eset, amikor kell runtime kivétel. Van egy alkalmazásod, amihez AOP-t kell használni (pl. tranzakciókezelés, jogosultságkezelés). A megpatkolt metódusod nem tudhat róla, hogy milyen egyéb mechanizmusok ülnek a nyakába, ezért deklaráltan nem dobhat rajta kívül álló extra kivételeket -- ez sértené is a szuverenitási elvet. Ellenben az advise végrehajtása közben történhetnek olyan dolgok, amikor nem tudsz egyebet csinálni, mint dobni egy kivételt -- pl jogosulatlan hozzáférés esetén. Ezt a kivételt nem tudod sehol sem deklarálni, ezért nem ellenőrzött formában dobod el, amit max a framework konténere láthat
-
M_AND_Ms
veterán
Hasonló problémákra gondoltam én is.
Igen. Egyszerű kódot, amolyan baltával is kifaraghatót írni genrerics nélkül kell. Ha cicomázod a generics-szel, akkor farigcsálhatsz órákig. De ha kész, olyan elegáns tud lenni! (csak ne kelljen átfaragni!)
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
floatr
veterán
válasz
M_AND_Ms
#4724
üzenetére
és (#4725) WonderCSabo
Egyszerűbb esetekben hasznos, mert nem akar senki sem vájkálni a felszín alatt. Amikor viszont egy kicsit összetettebb dologra kerül a sor, eleinte csak vakarod a fejedet, de már futottam bele megoldhatatlan problémába.
A konkrét kódra nem emlékszem már, de a lényege annyi volt, hogy annotációs SQL-el működő perzisztencia motor leszármaztatott interfészeknél elvesztette a fonalat, amikor a metódusokat override-oltam. Ennek az oka a felszín alatt lévő tényleges kompatibilis implementáció, hogy egyszerűen Object-et használ a típusparaméter helyett. Ez meg letarolja az OOP-alapelveket.
Ha lesz egy kis időm rá, megpróbálom rekonstruálni a dolgot.
-
#4725
WonderCSabo
félisten
Karma
#4721
-
M_AND_Ms
veterán
Azért a generics használata, főleg keretrendszereknél hasznos tud lenni. Pl.: egy rakat instanceof vizsgálattól kímél meg, viszont sokszor nagyon megnehezíti magának a generics-es kódoknak a karbantartását: nagyobb osztályhierarchián átívelő generics-ek módosításakor (pl: újak bevezetése) eléggé nehézkes az átírás, refaktor.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
M_AND_Ms
veterán
-
#4721
Karma
félisten
WonderCSabo
#4713
Karma
félisten
válasz
WonderCSabo
#4713
üzenetére
Hát, én ilyen esetekben inkább kezelem a kivételt, végülis azt vállaltam az interfészen. Egyébként persze jogos, ha tudatos döntés eredménye és le is van kezelve ez a láthatatlan ág, akkor egy szavam nem lehet.
Csak az utóbbi három alkalommal, amikor ilyet láttam, ez inkább az "elkussoltatom a fordítót, de különben szarok a hibára" szándék állt mögötte... Sőt, háromból egy az Xtend által generált csodás Java kód volt, úgyhogy sehol egy warning (@SuppressWarnings("all")), vagy egy ellenőrzött kivétel.
“All nothings are not equal.”
-
floatr
veterán
válasz
M_AND_Ms
#4716
üzenetére
Vannak teoretikusok, akik mindenbe belekötnek, amikor megírják a könyveiket. Az ellenőrzött kivételek a saját kódodat erősítik, közvetlen megoldásokkal. A RuntimeException származékok pedig pl. egy konténert címeznek meg valami fatális tévedéssel. Az egyik legjobb példa erre, amikor SOA backended van, és központosított hibakezeléssel akarsz kommunikálni a kliens felé. A nagyobb problémákat egyszerűen nem lehet vagy nem éri meg ellenőrzött kivételekkel visszavezetni, amikor a konténer ezt automatikusan elvégzi egy kis testreszabással.
De ha már itt tartunk, akkor a generics inkább egy baromi nagy tervezési hiányosság, mint ez
-
#4718
M_AND_Ms
veterán
WonderCSabo
#4717
M_AND_Ms
veterán
válasz
WonderCSabo
#4717
üzenetére
Szerintem, nem.
Gyárilag csak olyanok vannak ott, amiket valóban kerülnénk programunk futásakor. Ezek a kivételek szinte bármelyik programsornál előfordulhatnak, míg a többi csak jól behatárolható helyeken (pl. IOException) De persze megint tudom a kivételt is, hisz sokszor tudatosan használjuk őket. Pl. egy többszöri if (x == null) vizsgálat helyett hagyjuk, hogy beszaladjon a NullpointerException-be, ami majd egy alkalmas helyen elkapunk és kezelünk.
És azt se feledjük, ezek a magyarázatok csak próbálják leírni az egész kivételkezelést!Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
#4717
WonderCSabo
félisten
M_AND_Ms
#4716
-
#4716
M_AND_Ms
veterán
WonderCSabo
#4713
M_AND_Ms
veterán
válasz
WonderCSabo
#4713
üzenetére
Tudni kell, hogy ez nem elegáns megoldás (persze sokszor rákényszerül a kódoló ember az ilyen "csúnyaságokra")
A java-ban a kivételeket kezelni kell a try-catch-finally blokkal, de dobhatjuk tovább is, amit jelezni kötelező a függvény szignatúrájában. (ezzel tk. továbbadjuk a hívó félnek a kezelés felelősségét) Kivétel ez alól a RuntimeException és annak kiterjesztései. Hogy miért e kivétel? Álljon itt egy idézet a Java Programming Language (SL-275) tankönyvből
"RuntimeException indicates a design or implementation
problem. That is, it indicates conditions that should never happen
if the program is operating properly. Because a correctly designed and
implemented program never issues this type of exception, it is
usual to leave it unhandled. This results in a message at runtime,
and ensures that action is taken to correct the problem, rather than
hiding it where (you think) no one will notice."(megsúgom én is használok RuntimeException-ből származtatott saját kivételeket, de a keretrendszerem globálisan lekezeli őket, ellenben megspórolom, hogy állandóan foglalkozzak a függvényeimben a throw-szal)
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
#4715
WonderCSabo
félisten
modder
#4714
WonderCSabo
félisten
Értem, ez nem volt teljesen világos, nem csak én értettem félre akkor.
Igen, valóban sokszor irritáló a sok checked exception. Talán Robert C. Martin-tól olvastam a Clean Code-ban, hogy ő Javában runtime exceptionök használatát javasolja, ahol csak lehet.
Szerintem egy jól megtervezett libben is teljesen jogos lehet az IOExceptionök dobálása: vegyük pl. a JDOM-ot, az XML beolvasásakor dobhat IOExceptiont és JDOMExceptiont is, mindkettő ellenőrzött. Mivel ezekre mindenképpen illik reagálnia a kliens kódnak, és nem is jelentenek fatális hibát jellemzően, ezért teljesen jogos ellenőrzött kivételként dobni őket.
Egyébként az Effective Java a témában azt mondja, hogy ahol nem lehet helyrehozni a hibát, ott dobjál ellenőrizetlen kivételt.
[ Szerkesztve ]
-
#4714
modder
aktív tag
WonderCSabo
#4711
modder
aktív tag
válasz
WonderCSabo
#4711
üzenetére
Nem voltam elég világos. A checked exception-ök hasznosságára gondoltam. És ugye throws-t csak a checked exception-ökre kötelező kiírni. Ezeket ugye aztán nyilván vagy lekezeled, vagy tovább dobod (akkor megint kell egy throws)
Aki nem hiszi, hogy vitatott kérdés a checked exception-ök használata, az járjon utána
Azért mondtam, hogy sokan nem használják jól, mert rohadt sokszor van egy api vagy lib, és tele vannak a metódusok checked pl. IOException-nel. Na hát annak aztán nagyon sok értelme van.
[ Szerkesztve ]
-
#4713
WonderCSabo
félisten
Karma
#4712
-
#4712
Karma
félisten
WonderCSabo
#4711
Karma
félisten
válasz
WonderCSabo
#4711
üzenetére
Ohohohó, dehogynem lehet.
Volt már szerencsém ilyenhez élőben:try {
// ...
} catch (Exception ex) {
throw new RuntimeException(ex);
}“All nothings are not equal.”
-
#4711
WonderCSabo
félisten
modder
#4705
WonderCSabo
félisten
-
floatr
veterán
Lehet h van olyan, aki vitatja
Egy metódus kódjában keletkező kivételeket vagy elsikálod helyben, vagy "delegálod" a metódust hívó félnek. Ha nem foglalkozol vele metóduson belül, akkor azt deklarálni kell. Ez nem csak a fordító idegeit nyugtatja, de a QA-hoz sem árt. Önkéntelenül is leellenőrzöd, hogy megfelelő-e a kivételkezelési láncod.
Amúgy a kivételeket úgy általában sokan nem használják jól, nem csupán a deklarációt.
-
#4707
modder
aktív tag
Oppenheimer
#4706
modder
aktív tag
-
modder
aktív tag
válasz
smallmer
#4701
üzenetére
a throws kulcsszót (E/3-ban) metódus szignatúrába írjuk az argumentumlista után.
void doSuchThing(int arg0) throws BusinessException {
...
}Javában az Exception osztályból származtatott kivételek checked exceptionök. Ez azt jelenti, hogy ha egy metódus ilyen exceptiont dob, akkor meg kell jeleníteni a metódus szignatúrában a fenti módon, különben fordítási hiba lép fel. Ez elvileg arra jó, hogy a programozó felkészülhet arra, hogy milyen kivételeket generálhat egy metódus, illetve köteles is azt lekezelni, mert ha nem kapod el, vagy dobod tovább, akkor szintén fordítási hiba.
Hasznossága vitatott, általában nem használják jól
[ Módosította: Qru ]
-
M_AND_Ms
veterán
válasz
smallmer
#4701
üzenetére
Vagy egy már létező (a catch ágban elkapott) Exception-t dobsz tovább, vagy egy teljesen újat hozol létre és azt dobod vele.
Pl.:....
catch (Exception e) {
//Valamit csinál hiba esetén
DbHandler.transaction(DbHandler.TRANSACTION_OPERATION.ROLLBACK);
//és továbbdobja
throw e;
}if (result == null) {
//Létrehoz egy új hibát és azt dobja
throw new Exception("Nem található a rekord.");
}[ Szerkesztve ]
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
Azt észrevettem, hogy a tapasztalt java fejlesztők kerülik a netbeanst, helyette intellij ideát, vagy eclipset használnak, de a miértre nem tudom a választ.
Többek közt azért is mert olyan témát feszeget, aminek a gyakorlatban nullához konvergál a határhaszna. Tipikus egyemista feladat. Nem véletlenül használnak inkább XML-t vagy JSON-t.
Majd amikor nem példaprogramokból él meg az ember, és az ügyfél a haját tépi, hogy miért tart 10 percig egy funkció, akkor majd könnyebb lesz megérteni, csak egy többezres kódbázisú projekten újra végigfutni azért elég necces lesz. Pláne ha nyomorultul van megtervezve a struktúra.
!
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- GAINWARD GeForce RTX 4070 Ti SUPER Phoenix 16GB GDDR6X videokártya - Alza garancia: 2026.09.20.
- Playstation 1 játékok,akár 1000ft-tól (részletek a leírásban)
- Playstation 2 játékok,akár 1000ft-tól üzletünkből(részletek a leírásban)
- Sony E 10-18mm F4 OSS (SEL1018)
- Hibátlan Honor 200 Pro 12/512GB közel 3 év garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Axon Labs Kft.
Város: Budapest