- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: Anker Charger (140W, 4-Port, PD 3.1) laptop, mobil, tablet töltő
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Geri Bátyó: Agglegénykonyha 15 – Néhány tavaszias recept
- GoodSpeed: ASUS RT-BE92U WiFi 7 router a felsőházból
- gerner1
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
Új hozzászólás Aktív témák
-
-
Ez szerintem minden kódra igaz. Voltam zöldmezős projekteken. 1 év után azok is úgy néztek ki, mint bármi más, amit 5 éve fejlesztenek 2 vendor céggel. Nagyon sok nagyon különböző képességű ember nyúl a kódokhoz, valószínűleg hatással van az egészre a felülről érkező nyomás is, a szűkös határidők, változó elvárások, stb. Régen én eléggé beleálltam a code reviewkba, de borzasztó sok konfliktusom volt belőle és inkább elengedtem. Funkcionális hibák esetén is inkább privátban chaten szólok az embereknek. Páran nagyon nem tudják kezelni, amikor nyílvánosan kapnak 5-6 kommentet egy PR-re.
-
Nem gondolom, hogy felesleges kötekedés lett volna részemről. Volt ott minden, közösen elfogadott irányelvekkel való szembemenetel újra és újra, túlbonyolított kód (többszáz sor, ami pár tíz sorra redukálható), unorthodox megoldások pl hashmapből key alapján for looppal érték visszakeresése, funkcionális hibák, nem azt implementálták, amit a ticket kért vagy 5 requirementből csak 4-et sikerült implementálni, stb.
De most ez nyilván rosszul jön le, mert az látszik, hogy egy embernek több másikkal volt konfliktusa és a többségnek általában igaza van. Azért utólag 1 emberről megtudtam, hogy amikor lekérték arról a projektről, akkor több más ok mellett az is elhangzott fentről, hogy rendszeresen túl sok olyan dolgot találtam a PR-jeiben, amit nem nekem kellett volna megtalálni.
Részvétem. Mindig nehéz azokkal, akik csak a pénzért csinálják.
Azt mondjuk nem értem, hogy ki másnak kellett volna megtalálni a PR-ben elrejtett dolgokat. Aki hozzáfér a PR-hez, az megtalálhatja. Mondjuk ha csak 1 ember rivjúzik a csapatban, akkor kézenfekvő, hogy ki fogja megtalálni a hibákat.
-
Ez szerintem minden kódra igaz. Voltam zöldmezős projekteken. 1 év után azok is úgy néztek ki, mint bármi más, amit 5 éve fejlesztenek 2 vendor céggel. Nagyon sok nagyon különböző képességű ember nyúl a kódokhoz, valószínűleg hatással van az egészre a felülről érkező nyomás is, a szűkös határidők, változó elvárások, stb. Régen én eléggé beleálltam a code reviewkba, de borzasztó sok konfliktusom volt belőle és inkább elengedtem. Funkcionális hibák esetén is inkább privátban chaten szólok az embereknek. Páran nagyon nem tudják kezelni, amikor nyílvánosan kapnak 5-6 kommentet egy PR-re.
Ezek szerint akkor olyan dolgokba kötöttél bele, amibe felesleges lett volna?
Ha nem, akkor most hagyod elrothadni a kódot?
Mindezt azért, mert a csapatod tagjai nem alkalmazzák a közösen elfogadott kódolási irányelveket. (Gondolom, közösen fogadtátok el. Sőt gondolom, időnként felül is vizsgáljátok azokat.)
És azért is, mert páran nem elég érettek a felnőtt viselkedésre? Akik a tévedésekre való rámutatást nem fejlődési lehetőségnek, hanem személyes sértésnek veszik.Mindezekből következően saját magad és voltaképp még a crybaby csapattársaidat is megszívatod az egyre jobban degradálódó kóminőséggel. Megéri? Azon csapattársaid, akik jó minőséget állíta(ná)nak elő, őket is a gányolás keserédes mezejére száműzöd ezzel. Nem?
Amúgy abszolút egytértek a mondandód első felével, én sem vagyok büszke az 5 éve írt kódomra, hát még az 1997-ben írtakra.
Viszont ez azt is jelenti, hogy ma már sokkal jobbat tudok alkotni, és holnap mégjobbat fogok tudni. A sun is biztosan jobbat írna ma, mint, amit most látunk belőle. -
-
Ha nem konzisztensen jó / rossz eredményt kapsz, akkor valószínűleg valami threading issue lesz. Ezeket a swinges / awt-s elemeket csak az event dispatcher threadről szokták frissíteni, mert a többségük nem thread safe.
Rákerestem, lehetséges hogy ez az oka.
Már csak azt nem tudom, hogy oldjam meg
-
A parseShort()-nak meg tudod mondani, hogy 16-os számrendszerben van megadva a szám.
String product_ID = "0x0105";
short ProductID_short = Short.parseShort(product_ID_String, 16);
így se jó. (és még azt se tudom, miként tudnám jobban szétbonatani a debug-hoz)...és azért akarom megcsinálni, mert mindent meg lehet csinálni programozással.
Ez egy kihívás, amúgy meg egy rakat adatot akarok return-olni egy függvényből, amit (short to string)-re konvertálom, majd string-ként kiküldöm (összefűtés után). (mivel a legkomplexxebb adattípus a string az adathalmazomban)Amúgy valami objektumként is return-olhatnék, de ha már mint problémába ütközött tanuló, érdekelne, hogy miként lehet a string-emből ismét short. (mert az volt még 3 másodperccel ezelőtt)
-
Egyrészt stringeket nem ==-vel hasonlítunk össze, hanem equals() metódussal. Másrészt szerintem rossz stringeket próbálsz összehasonlítani, mert az első kód alapján a productString lenne az a "CM ...", de te valami AskDeviceName-t használsz helyette, ami nem látom hol kap értéket.
Már próbáltam (csak elfelejtettem említeni), hogy nem működik.
String AskDeviceName = info.getProductString();
System.out.println(AskDeviceName.isEmpty());//ez a 35. sor
/* Ezt a hibát dobja erre:
Exception in thread "main" java.lang.NullPointerException at hid_joy.HID_joy.main(HID_joy.java:35)
C:\Users\sokimm\AppData\Local\NetBeans\Cache\8.2\executor-snippets\run.xml:53: Java returned: 1
BUILD FAILED (total time: 0 seconds)
*/Aztán végül így meg megy:
if (info.getProductString() instanceof String) {
AskDeviceName = info.getProductString();
System.out.println(AskDeviceName.isEmpty());
}Mért képes a String"ségét" vizsgálni, de az ürességét nem? Van olyan eszköz, aminek nincs neve (a gyártó nem adott neki, ezért gondolom null értéke van, vagy lehet nincs is ilyen memóriacímterülete?), de van, aminek van neve (amiket használnék, azoknak van).
-
Patrick76496
őstag
Rosszak a feltételeid. Pl első if-ben 164<=randmap és másodikban randmap>=165 átfedik egymást. Érdemes úgy szervezni a kódod, hogy a kisebb érték legyen mindig az operátor bal oldalán és nyílván csak a <= operátort használva, így elkerülhető az ilyen nehezen kiszúrható hiba. Vagy fordítva a másik operátorral, de mixelni nem szerencsés őket.
Köszi szépen, igazad volt. Sosem belülre szoktam tenni a feltételnek megadott számot, most nem tudom miért így írtam.
Lehet pont emiatt zavarodtam bele, elég figyelmetlen voltam. Most már mást is generál, köszönöm szépen a segítséget! 
-
A nyelv áttekintésére az oracle java vizsga könyve megfelelő. Nem foglalkozik az alapokkal, így nem kell oldalakon át rácsodálkozni a ciklusokra, meg az alapműveletek operátoraira és feltételezi, hogy már elboldogulsz valamelyik java IDE-ben. Viszont elég jó kis összefoglalót tartalmaz classokkal, lambdaval és néhány beépített alap könyvtárral kapcsolatban. Sok példakód van benne, ami kiemeli azokat a részleteket, amiken könnyű átsiklani egyébként. Van benne rengeteg "mit ír ki ez a kód" típusú trükkös kérdés megoldásokkal, amikkel állásinterjún is lehet találkozni.
Keretrendszerekkel kapcsolatban az adott technológia oldalán levő dokumentációt érdemes olvasni. Például a spring referencia tele van példákkal. Innen minimum a III. szekciót érdemes elolvasni, utána pedig azt a részt, amivel foglalkoznod kell a munkád miatt, mert amúgy nagyon nagy az anyag. A guides résznél pedig találsz futtatható githubos spring projekteket.
Hasonlóan, bármilyen más java frameworkot nézel ki magadnak (hibernate, guice, etc), a hivatalos oldalán jó eséllyel lesz olyan guide/tutorial/reference, ami alapján bele lehet tanulni.Köszi, jól néz ki
Amúgy ezt a vizsgát érdemes letenni, ha javával akarok foglalkozni?Frameworkot amúgy még nem néztem, csak a spring volt ami elsőre beugrott javás
-
Bambano ötlete szerintem nem elvetendő.
Ansible szerintem már kb bármilyen VCS-ből le tud szedni valamilyen tagelt vagy release branchen levő stabil configot minden hostra az alkalmazásod mellé property fájlként. Az alkalmazásaid pedig apache common configurationnel újraindítás nélkül újra tudják tölteni a fájlokat és triggerelni a listenereket, ha változás történik.Így tényleg nem kell +1 rendszert üzemeltetni, monitorozni.
-
Ha klasszikus producer-consumer megvalósítás kell, tehát bedob egy thread egy üzenetet és valamelyik másik feldolgozza, akkor egy BlockingQueue / TransferQueue elég. Ha a két thread között egy üzenet cserét kell megvalósítani, akkor Exchanger. Stb.
Attól is függ, hogy ugyanazt az üzenetet minden threadnek fel kell dolgoznia vagy elég ha csak egy foglalkozik vele.
Ha mindenképp külső könyvtárat keresel, akkor disruptorra ránézhetsz, de ez csak annyit tud, hogy gyorsabban valósítja meg azt, amit a jdk beépített osztályaival amúgy is el lehet érni.A BlockingQueue ideálisnak tűnik az adott feladatra. Köszönöm szépen a válaszodat!
-
Igen, arra gondoltam. Idézet a javadocból: all mutative operations (add, set, and so on) are implemented by making a fresh copy of the underlying array.
Ha többnyire iterálás/olvasás történik, akkor nem lehet gond vele.Olvasás kicsit több, írás viszont elég kevés van, kicsi elemszám (maximum 25-30) és az elemek mérete is apró. Az írási műveletek száma legrosszabb esetben is 5-10 másodpercenként egy.
Köszi a választ! -
Egyrészt általában nincs referencia, mert amin dolgozott az vagy belső használatra készült vagy mindenféle titoktartási szerződések kötik az ember kezét vagy a kettő együtt. Ha lenne referencia, akkor sem derülne ki belőle, hogy mi az, amit a jelentkező csinált belőle, bármit hazudhat. Ugyanilyen alapon bármit írhat a CV-be is, ezért többen azt csinálják, hogy a CV-t nem olvassák el teljesen, csak annyi érdekes belőle, hogy hány év tapasztalata van az embernek. Ez alapján belövik, hogy nagyjából mit várnának el a jelentkezőtől és lemérik kérdésekkel, hogy mit tud abból, amire a cégnek szüksége van.
Majdnem teljesen mindegy mit dolgozott előtte a jelentkező, mert ha űrhajó vagy atomerőmű vezérlőt fejlesztett, akkor azt a tudást úgysem tudja kihasználni a cég, ha meg 1000. számlázót / webshopot fejlesztett, attól még lehet, hogy le tud fejleszteni komolyabb dolgokat.
Másrészt a fenti alap kérdésekkel is ki lehet dobatni a legtöbb seniort interjúról.Hmm mondjuk igen , így érthető a dolog.
-
Aethelstone
addikt
Ez itt kicsit off, van külön álláskeresős topic, de röviden: Szinte bármely pályakezdő/junior állásra jelentkezhetsz nyugodtan, úgy tudom csak a nokia veszi komolyan a hirdetésbe kiírt diploma követelményt. Eleve sokszor úgy írják ki a követelményekhez, hogy felsőfokú szakirányú végzettséget várnak, az OKJ fejlesztő képzés meg felsőfokúnak számít, nem?
Elég ritka, amikor a követelményeknek 100%-ban megfelelő ember jelentkezik egy állásra, kb 80%-os match már elég ahhoz, hogy felvegyenek. -
Ez itt kicsit off, van külön álláskeresős topic, de röviden: Szinte bármely pályakezdő/junior állásra jelentkezhetsz nyugodtan, úgy tudom csak a nokia veszi komolyan a hirdetésbe kiírt diploma követelményt. Eleve sokszor úgy írják ki a követelményekhez, hogy felsőfokú szakirányú végzettséget várnak, az OKJ fejlesztő képzés meg felsőfokúnak számít, nem?
Elég ritka, amikor a követelményeknek 100%-ban megfelelő ember jelentkezik egy állásra, kb 80%-os match már elég ahhoz, hogy felvegyenek.Rendben, köszönöm szépen a választ , akkor nyugodtan jelentkezek az összes junior állásra
-
újraregelt
tag
Ez picit bonyolultabb. Mint írtam, a standard kimenetre írandó szöveg elvileg bufferelt, azaz akkor kerül ténylegesen kiírásra, ha a buffert űrítik, pl mert megtellik, vagy lezárják a streamet vagy pl újsor karakternél. Standard errornál ez nincs. Illetve a fenti példád is más, mert az új sornál űrítik a buffert, így elvileg a sorrend adott kellene legyen.
Valószínűleg az lesz a háttérben, hogy amikor futtatod az IDE-ből a programot, akkor az IDE két külön threaden olvassa a két streamre kiírt szöveget és az nem befolyásolható, hogy ezek a threadek mikor milyen sorrendben aktiválódnak. -
norbert1998
nagyúr
Bocs, benéztem, új sornál űríti a buffert.
Két különböző streamre írsz, csak egy ablakban látod, de a streamek feldolgozásának sorrendje nem garantált szvsz, pl IDEA vagy eclipse termináljában. Bevallom nem tudom, hogy garantált-e a sorrend, ha cmd-ből futtatod, de nem is nagyon használom a sysout/syserr párost, mindig valammi loggerrel mentünk fájlba kimenetet. -
norbert1998
nagyúr
-
WonderCSabo
félisten
-
kornyiktamas
aktív tag
-
WonderCSabo
félisten
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
-
WonderCSabo
félisten
-
Na a kovetkezo a helyzet. Elolvastam a kodot is, amit fentebb linkeltel es tobb problema is van.
Eloszor is ugyanarrol a threadrol irsz es olvasol adatbazist, amelyikrol GUI elemeket modositasz. A GUI tipikusan nem thread safe, a hozza tartozo elemeket (buttonok pl) a GUI threaden kell modositani. Ezen a threaden pedig nem kellene blokkolo muveleteket pl DB kezelest inditani, mert megakad az egesz felulet tole.
A masik, hogy a ResultSet-en azutan hivod meg a next() metodust miutan meghivtad a close() metodust (executeUpdate mar nem ad vissza uj ResultSetet igy a regi lezartat fogod hasznalni tovabb) es ezert kapsz "ResultSet not open. Operation 'next' not permitted." hibauzenetet.
A harmadik pedig, hogy konnyebb dolgod lenne, ha a string osszefuzogetes helyett PreparedStatementet hasznalnal, ha mar mindenkepp JDBC-vel kell megoldani a feladatot es nem hasznalhatsz valami ORM frameworkot.
-
Kb mindegyik jo, amit fentebb ajanlottak. En speciel JSF-et szeretem, mert ha ranezel egy [richfaces] vagy [primefaces] showcase-re, akkor latod, hogy nagyon bonyolult ajaxos komponenseket is berakhatsz az oldaladba 5-10 sor koddal. Hatranya viszont, hogy altalaban oriasi DOM fakat general, igy lassu lehet.
-
Kb mindegyik jo, amit fentebb ajanlottak. En speciel JSF-et szeretem, mert ha ranezel egy [richfaces] vagy [primefaces] showcase-re, akkor latod, hogy nagyon bonyolult ajaxos komponenseket is berakhatsz az oldaladba 5-10 sor koddal. Hatranya viszont, hogy altalaban oriasi DOM fakat general, igy lassu lehet.
És ne felejtsük el az Icefaces-t sem. Az is egy jó kis cucc
-
1. Gyors probalgatasra jo a run-app, de vigyazni kell vele, mert attol meg, hogy o tudja futtatni a projektet, egy webcontainerben meg nem biztos, hogy futni fog. mvn grails:war-ral lehet war fajlt kesziteni es azt deployolni egy tomcatre pl. Ekkor jot elo nalunk is a gubanc, hogy csomo felesleges dolgot bepakolt a war fajlba alapbol. Pl servlet apit is, ami teljesen felesleges, mert minden webcontainer classpathjan ott van es emiatt be sem toltodik a program.
Amugy fejlesztokornyezetnek eclipse java ee verzioja pl jo, csak market placerol meg fel kell tenni a grails es groovy plugineket.2. Ezt nem tudom. A view layert megirtuk gwt-ben, igy olyan sorrendben dobaltunk ra controlokat, amilyenben akartunk.
Áh, köszi a maven-es tanácsot. Eclipse és Netbeans a Maven-t nehezen nyeli be, de sebaj.
A View-nál szomorú vagyok, hogy neked sincs tudásod... neten meg nem igazán látom mi lenne a megfelelő megoldás...
Köszönöm a segítséget -
1. Elegge bugos szegeny. Pl rendszeresen elofordul, hogy ugyanazt a projektet valtoztatas nelkul ketszer egymas utan nem lehet leforditani / futtatni. Ilyenkor ivy cache es a project alatti plugins mappa torlese utan ujra fordul a project.
2. Ivyt hasznal dependency managementhez. Ez nagyon jo, csak ha nalunk mavenes a projekt, akkor feleslegesnek erzem magamra eroltetni ivyt is. Allando kavarodas van, hogy mi kerul BuildConfig.groovy-ba es mi a pom.xml-be.
3. Groovy nagy projektre nem alkalmas. Kis scriptekhez tok jo, pl hogy automatizalt modon hivogassunk jmx vagy rmi metodusokat. Egy csomo mindent elfed a grails es a groovy. Sok helyen osztalyszintu valtozok def kulcsszoval vannak definialva es a grails a hatterben odavarazsol valami objektumot a helyukre. Ami azert baj, mert itt nem latod a tipusat es ezek mar nem String vagy integer valtozok, hanem service objektumok, ahol fontos lenne latni, hogy mi mitol fugg legalabb interface szinten.
4. A kodgeneralasi funkciojanak nem latom ertelmet. Gyakorlatilag annyit general le, mintha eclipseben kivalasztanam a new class funkciot.
5. Nem a programozo hasznalja a frameworkot, hanem a framework hasznalja a programozo kodjat. Nekem ez sosem tetszett.
6. Osszessegeben belassitotta a fejlesztesi folyamatot. -
Kod nelkul nehez megmondani, hogy mi a baj, de nem nyelsz el egy catch agban egy exceptiont, ami nincs kiloggolva?
"Új session-t indítok minden egyes lekérdezésre"
Ez anti-pattern. Mivel desktop approl van szo, gondolom csak egy user hasznalja egyszerre. Boven eleg akkor nyitni uj sessiont, ha az elozo inkonzisztens allapotba kerul.
-
"
"a String az egy olyan állandó, amelynek értéke futás közben megváltozhatatlan"Valójában csak a mérete, a karaktereket módosíthatjuk benne a charAt metódussal, O(1) időben."
A String immutable, nem modosithatod, a charAt pedig pont visszaad egy karaktert es nem modositja azt.
"Valójában úgy áll a dolog, hogy a kódban definiált Stringek (String str = "abc") az úgynevezett literal pool-ban lévő elemekre fognak hivatkozni, ami a heap-től független, így a GC-től is."
Java 7-tol az interned stringek is atkerultek a permanent generationbol a young es old generationbe tehat nem igaz, hogy a heaptol fuggetlenek.
Ok, nézd el nekem, C++-ban is programozok
A második dologról még nem tudtam, köszi a pontosítást.
-
Pengen kell mukodnie annak a Collections.synchronizedList()-tel is. Ennek ellenere megsem ajanlanam ezt a megoldast, a szarmaztatas mindig csak vegso menedek legyen. Neked az kell, hogy a szalak egy Set-et allitsanak ossze, igy nem lesz duplikacio. Ezutan pedig keszithetsz egy listat a Set elemeibol.
-
1.
A ListaElem osztaly tartalmaz egy referenciat egy masik ListaElem tipusu objektumra, annak meg van elem nevu valtozoja, amit el tud erni a fenti hivatkozassal.
2.
A Hasonlithato kodjat nem talalom, de gondolom ugy mukodik, mint a Comparable. Olvasd el a Comparable interface dokumentaciojat, abban leirjak szepen, hogy mikor mit kell vizsgalni.
3.
Azert kell az a sor, mert nelkule mindig ugyanazt az elemet adna vissza a metodus.
-
Character.digit(ch, 10) -t hasznald konverziohoz, ahol ch char tipusu.
Elozore pedig: A Scannernek van nextDouble metodusa is. Nyilvan a streamet valahogy le kell zarni, erre az enter nem eleg. Ha nem akarod tulbonyolitani, akkor beolvashatsz egy sort egy String-be es ebbol olvasod ki Scanner-rel a double ertekeket.
-
Character.digit(ch, 10) -t hasznald konverziohoz, ahol ch char tipusu.
Elozore pedig: A Scannernek van nextDouble metodusa is. Nyilvan a streamet valahogy le kell zarni, erre az enter nem eleg. Ha nem akarod tulbonyolitani, akkor beolvashatsz egy sort egy String-be es ebbol olvasod ki Scanner-rel a double ertekeket.
-
1.
double pi = 3.14;
System.out.printf("%.0f\n", pi);2.
A 9.0 literal double tipusu, ami a legnagyobb tipus a (9.0 / 5) * celsius + 32 kifejezesben, ha celsius float. Emiatt az eredmeny is double, amit castolas nelkul nem tudsz float-ba belerakni.
9.0f viszont float tipusu.3.
A Scanner osztalyt hasznald.
-
1.
double pi = 3.14;
System.out.printf("%.0f\n", pi);2.
A 9.0 literal double tipusu, ami a legnagyobb tipus a (9.0 / 5) * celsius + 32 kifejezesben, ha celsius float. Emiatt az eredmeny is double, amit castolas nelkul nem tudsz float-ba belerakni.
9.0f viszont float tipusu.3.
A Scanner osztalyt hasznald.
-
1.
Nyilvan rengeteg kulonbseg van long es Long kozt.
Long egy referencia tipus, long egy primitiv tipus. Ha ranezel a Long dokumentaciojara, akkor latod, hogy tele van konverzios metodusokkal, amik jol jonnek, ha nem akarsz castolni pl.
Masreszt Long immutable, mig long nem.
Templatek megadasanal csak referencia tipust hasznalhatsz, tehat nem irhatsz olyat, hogy List<long>.
Ettol fuggetlenul elelmiszerpult.get(vonalKod), akkor is mukodik ha vonalKod long tipusu, ekkor ugyanis egy Long-ba lesz becsomagolva autoboxingnak koszonhetoen.2.
Az is teljes erteku megoldas lehet, ha csak egy this() hivodik meg a konstruktorodban. Mondjuk Hashtable tipikusan nem az a tipus, ami neked kell. -
// AFrame.java
import java.awt.event.KeyAdapter;
import java.awt.event.KeyEvent;
import javax.swing.JFrame;
import javax.swing.JLabel;
public class AFrame extends JFrame {
public AFrame() {
setSize(800, 600);
setDefaultCloseOperation(EXIT_ON_CLOSE);
JLabel label = new JLabel("AFrame");
add(label);
this.addKeyListener(new KeyAdapter() {
@Override
public void keyPressed(KeyEvent e) {
BFrame bFrame = new BFrame();
bFrame.setVisible(true);
}
});
}
public static void main(String[] args) {
AFrame aFrame = new AFrame();
aFrame.setVisible(true);
}
}
// BFrame.java
import javax.swing.JFrame;
import javax.swing.JLabel;
public class BFrame extends JFrame {
public BFrame() {
setSize(800, 600);
JLabel label = new JLabel("BFrame");
add(label);
}
}Tudom, hogy gány a kód, de példának jó lesz.
-
Magyar anyagokat felejtsd el, évekkel le vannak maradva. Rákeresel googleben, hogy java ee 5 tutorial és java ee 6 tutorial. Az oracle honlapját fogja elsőnek kidobni. Ott vannak példakódok meg magyarázat is. Ha ezeket végignézed, akkor már tudsz majd magadtól készíteni egyszerűbb projekteket. Ant vagy maven munkahelyen is lesz, nem árt egyikkel megismerkedni, egyébként is megkönnyítik az ember életét.
Mondjuk ez is egy munkahely, de végül is nem a programozás miatt tartanak, az csak hub a tortán. Elődöm Accessal poénkodott, lehet nekem is célszerűbb lenne, de szeressük a Javát, meg most van egy komolyabb feladatom is.
Akkor inkább Maven hasraütés szerűen
.NetBeans-ben már pont az előbb tudtam Hibernate-val az adatbázis egy táblájába sort beszurni.
Van remény, már csak ki kéne találni miket is csináltak a varázslók -
Bár nem kifejezetten javas fórum, de van rajta pár javahoz értő: hup
Ez meg nem igazán forgalmas: javaforum
Egyébként swinges kérdésekre ezeken a helyeken sem kapsz túl sok érdemi választ. Swing, AWT mind halott, amire ezeket az apikat használták, abban már a .NET vonal erősebb. Ami java vonalon pörög az a spring, hibernate, seam, richfaces, jsp, jsf. A többibe szerintem ne ölj túl sok energiát. -
Amit te akarsz, azt így lehet megoldani:
class A<T extends Valami>{...}
?-t nem használhatsz osztály és metódus megadásakor (csak metódus paraméterlistáján belül).Igen, azzal nincs gond... per.pill. az zavar, hogy nem tudom, honnan jött az eredeti, wildcard-os ötlet.
Így utólag hülyeségnek tűnik.
(azt leszámítva, hogy találtam rá konkrét, lefordíthatatlan példát a neten, csak sajna töröltem a címét is, a programot is)Asszem, megvan a bűnös:
To specify a cage capable of holding some kind of animal:
Cage<? extends Animal> someCage = ...;
Egy ilyen szerepel a sun-os tutorialban a wildcard-os lap elején. Én meg ahelyett, hogy végiggondoltam volna, mire jók ezek a generikusok, csak az általam elképzelt szintaxist néztem. Ha értékadás baloldalán, tehát változó definíció helyén állhat ilyen, akkor miért ne lehetne akár metódus vagy osztály típusát is megadni?
Végiggondolva a funkcióját, természetesen érthető(nek tűnik
), hogy ott nincs keresnivalója. -
"Ezt a metódust úgy kell értelmezni, hogy van egy U paramétere, valamint egy olyan, ami a List generikusból, azon belül kizárólag a Box generikus valamely fajtájából származik és megkötés, hogy a Box "altípusa" (nem tudom, erre mi lenne a helyes kifejezés) meg kell egyezzen az első paraméter típusával/osztályával?"
Igen, valamilyen Box-okat tartalmazó listát vár. Egyébként java.util.List-ként találod meg a listát, ami egy interface. Az implementációi pedig szintén a java.util csomagban találhatók.
-
Ahogy a linkelt oldalon is látható, a Box egy generikus osztály és tartalmaz t névvel egy változót:
...
private T t;
...
Az add függvény ennek a t-nek adna értéket. A fillBoxes pedig átvesz egy listát, amiben Boxok vannak és minden Boxhoz hozzáadja u-t. De nyilván tudnia kel, hogy mi a típus. Ez lesz az a típus, amit U helyére írsz be. -
Viszonylag gyakran előkerülnek. Gondolj pl a tárolókra, mint a Vector, HashMap, LinkedList, ... vagy pl TypedQuery JPA-ban. De saját generikus class-t vagy interface-t is sokszor kell írni. Ezekkel a generikusokkal megspórolható egy csomó castolás, így gyorsabb a program.
Nem tudom miért, de valami olyan érzésem van most, hogy kissé kiművelődtem generikus ügyekben, mint amikor a perl-ben megláttam az objektum orientált eszközöket: mintha a fejlesztők megerőszakolták volna a nyelvet...
-
Viszonylag gyakran előkerülnek. Gondolj pl a tárolókra, mint a Vector, HashMap, LinkedList, ... vagy pl TypedQuery JPA-ban. De saját generikus class-t vagy interface-t is sokszor kell írni. Ezekkel a generikusokkal megspórolható egy csomó castolás, így gyorsabb a program.
Gondolhatok rájuk, de ott még nem tartok a tutorialban...
Köszi.
(viszont egyre inkább úgy érzem, hogy totál felesleges erőlködés ez a "tanulás", mert hiányzik a háttér) -
Ha unatkozol, tanulj Java EE-t. Mostanában jól meg lehet belőle élni, előzetes tapasztalat nélkül is.
EE=Enterprise Edition?
Köszi a tippet, de bizonyos... khm... objektív okok miatt nem nagyon fogok megélni programozóként...(bár tény: épp a napokban állapítottam meg, hogy mégis meg kellett volna maradnom a programozói pályán, de anno izgalmasabb dolognak tűnt a rendszergarázdálkodás
)Bár ahogy elnézem, hogy a wikipedia szerint mit takar az EE... annyira nem állna távol tőlem és legalább üzemeltetői szemmel írnám a programokat. (inkább a felhasználó anyázzon, mint az üzemeltető felkiáltással
) -
Javat szerintem ne erőltesd telefonokon. Ha ilyen irányba akarsz elmozdulni, akkor döntened kell, hogy Iphone vagy Android. Iphone-nal nincs tapasztalatom, androidra viszont elég gázos a fejlesztés. Verziónként külön sdk, gagyi programnyelv és api, nincs fix programbelépési pont csak repkednek az események, xml descriptorok, bugos emulátor (de csak hogy könnyebb legyen a fejlesztés) ... Szóval elég hulladék. Lehet, hogy mint end user, nagyon látványos tapogatni az ikonokat a telefonon, de fejleszteni rá ...
Ne gondolj semmi komoly dologra! Csak unatkozom és kellene valami olyan játék, amivel kicsit az agyműködésemet fenntartom. Sakkozni, go-t tanulni már nincs kedvem.
Java mobilra azért lenne jó, mert az _elméletileg_ platform független és legalább írhatnék egy olyan reversit, ami úgy működik, ahogy én szeretném.
-
Nézd meg, hogy tudnál külső osztályból létrehozni egy másik osztályba ágyazott osztályból egy példányt.
package javaapplication1;
class A{
class B{
}
static class C{
}
}
public class Main {
public static void main(String[] args) {
A a = new A();
A.B b = a.new B();
A.C c = new A.C();
}
}Mint láthatod, ha nem static nested classról van szó, akkor kell egy példány először a beágyazó osztályból. Ezért b által hivatkozott objektum kapcsolódik a által hivatkozotthoz.
--------------------------------------------------
Az interface-szes problémára: Egy interface minden függvénye impliciten public elérésű. Felülírási szabály szerint pedig nem szűkítheted egy függvény elérését (ezesetben publicról defaultra).Köszi mindkettőtöknek! Mondjuk az interface dolog végeredményben logikus, csak végig kellett volna gondolni, hamár a korábban olvasottakról megfeledkeztem.
Amit a beágyazott osztályról írtál, az tiszta.
Nekem az nem világos, hogy egy egyébként triviálisnak mondható dolgot miért kellett ennyire kihangsúlyozni? Na mind1, a könyvemben vannak még hasonló furcsaságok -
Ha a sun-os tutort olvasod, akkor gondolom nincs gond az angol szakirodalommal sem. Ebben az esetben pedig a SCJP study guide az alapmű. Ha pedig valami spéci API érdekel, akkor arra külön kell keresni.
Sajnos rá kellett jönnöm, hogy azért messze kevés az angolom ahhoz, hogy egy számomra ennyire idegen területet megértsek. Kb. az a kategória, mint amikor franciául kezdtem tanulgatni angol tananyagból.
De kösz, megnézem, hátha...Minél jobban belemászok a java rejtelmeibe, annál inkább rájövök, hogy nem a Java nyelvvel van problémám, sokkal inkább az objektum-orientált programozási logika az, ami nehézségeket okoz.
-
Írok egy példát és abból le fog tisztulni:
package javaapplication1;
class A{
public static void staticF(){
System.out.println("staticF() A");
}
public void f(){
System.out.println("f() A");
}
}
class B extends A{
public static void staticF(){
System.out.println("staticF() B");
}
public void f(){
System.out.println("f() B");
}
}
public class Main {
public static void main(String[] args) {
A a = new B();
B b = new B();
a.f();
a.staticF();
b.f();
b.staticF();
}
}Kimenet:
f() B
staticF() A
f() B
staticF() B
Viszont ez azt is jelenti, hogy ma már sokkal jobbat tudok alkotni, és holnap mégjobbat fogok tudni. A sun is biztosan jobbat írna ma, mint, amit most látunk belőle.
Lehet pont emiatt zavarodtam bele, elég figyelmetlen voltam. Most már mást is generál, köszönöm szépen a segítséget! 
), hogy ott nincs keresnivalója.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Mibe tegyem a megtakarításaimat?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Vigneau interaktív lokálblogja
- Fejhallgató erősítő és DAC topik
- Fűnyíró topik
- Amlogic S905, S912 processzoros készülékek
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- általános iskolai rendszergazda
- Ubuntu Linux
- További aktív témák...
- NEC MultiSync V422 42" Monitor
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- 27% - ASUS TUF Gaming Z690-PLUS WIFI D4 Alaplap
- 27% - GAMING PC! 13900K / RTX 4090 / 64GB DDR4 / Z690 / 3TB SSD / 1600w Platinum
- Apple iPhone 13 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest