- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
- gban: Ingyen kellene, de tegnapra
- Magga: PLEX: multimédia az egész lakásban
- Luck Dragon: Asszociációs játék. :)
- Nyuszit otthonra, kedvencnek!
- 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 :)
- Geri Bátyó: Agglegénykonyha 15 – Néhány tavaszias recept
Új hozzászólás Aktív témák
-
Swing környezetben szeretném beállítani, hogy az újonnan létrehozott objektumok milyen fontot használjon. Ez megoldható valahogy?
A teljes UI-ra azt hiszem, be tudom állítani, de mondjuk (értelmetlen - kizárólag a példa kedvéért) létre akarok hozni két menüt. Az egyiket mondjuk Arial, a másikat meg Courier New használatával.
Sajnos(?) a konténerekbe pakolt elemek nem öröklik a konténer font beállításait. -
A szerzetes
csendes tag
-
Továbbmegyek: semmilyen 1x1 cellásnál nagyobb komponens sem akar úgy működni, ahogy a leírás alapján képzelném:
cc.setLayout(new GridBagLayout());
GridBagConstraints gbc;
gbc=new GridBagConstraints();
gbc.gridx=1; gbc.gridy=1;
gbc.gridwidth=3; gbc.gridheight=3;
JButton b0=createJB("BUTTON0","cmd0",this);
b0.setBorder(new TitledBorder("keretes keret"));
cc.add(b0,gbc);A "cc" a JFrame.getContentPane()-ből származik. A fentiről én úgy gondoltam, hogy egy 3x3 cellát elfoglaló gombot kapok, a panel bal szélén és tetején egy-egy üres oszloppal, ill. sorral.
Ehhez képest kapok egy egyetlen cellát elfoglaló objektumot az ablak közepén.
Mit rontok el v. értek félre? (az a Border-es dolog csak nyomkövetési céllal került bele: arra voltam kíváncsi, a komponens foglal-e kisebb helyet, mint szeretném vagy a helyfoglalás stimmel, csak a gomb méretezése lesz kisebb - ebből úgy tűnik, valóban kisebb helyet foglal az előírtnál)Naszóval ez még mindig homályos, de a weightx=weighty=1 volt részben a megoldás.
Mondjuk én úgy értettem, hogy ezzel az egyes komponensek méretváltozásának az arányait lehet egymáshoz képest szabályozni, nem pedig az egész konténer méretéhez...
-
Hát annyit már nem ér ez a játék. Nem akartam minden egyes swing alkatrész kipróbálásakor újraírni/másolni a teljes alapkódot (importok, main metódus stb. stb. stb.), mert ugye a lustaság fél egészség!
Egyébként már sokadszor állapítom meg, hogy hülyének lenni állampolgári jog, bár nem feltétlenül szükséges élni ezzel a joggal.
Fél napon át szopattam magam azzal, hogy amíg nem állítom be a gridx, gridy változókat a GridBagConstraints változóban, addig szépen megjelenik minden egy sorban. Ha beállítom, akkor csak egy gomb jelenik meg. Napersze: constraint beállít,gomb objektum létrehoz, e kettő ismétlése még 4x, majd az öt objektum felvétele a panelbe/-re/stb. És nem tűnt fel, hogy ama constraint beállításokból csak a legutolsó érvényesül, ezért az összes gombot ugyanarra a pozícióra pakolja.
---
Szépséghibája a dolognak, hogy az 1x1 méretűnél nagyobb JLabel-lel egyáltalán nem boldogulok.
Továbbra sem hajlandó középre helyezni. -
Épp az utolsóelőtti mondatod okoz problémát: nem tudom meghatározni az osztály nevét.
Mind1, megközelítem más oldalról a problémát: már tudok menüt gyártani...Vannak még piszkos megoldások ilyen esetben
Pl. a ClassLoaderrel kézzel töltöd be a legnagyobb sorszámú osztályt. Vagy konfigfájlból olvasod be a betöltendő osztály nevét. -
Újabb "komoly" problémába ütköztem: a szülő osztály tartalmaz egy statikus main metódust, ami a szülőt példányosítja. Meg lehet írni a szülő osztályban ezt a metódust úgy, hogy öröklődés esetén a gyerek osztályból készítsen egy példányt?
Egyelőre úgy tűnik, hogy ez kivitelezhetetlen...(eredetileg az eclipse-ben lévő new->class template-ek közé szerettem volna gyártani egy újat, ami megfelel az igényeimnek de kissé bonyolultnak tűnik a dolog, elsőre egyszerűbbnek tűnt a mintát egyszer megírni és az újabb próbálkozásokban csak a mintát bővíteni öröklődés által)
Ez most csak egy ötlet, de szerintem meg lehet oldani.
Most olvastam, hogy a statikus metódusok compile-time bindingon mennek át, tehát ha az ősosztályban hivatkozol egy saját statikus metódusra közvetlenül, akkor biztosan az ősosztályé fog meghívódni.
Viszont ha reflekciót használsz, akkor meg tudod hívni név alapján.
Úgyhogy megpróbálhatnál az ős- és leszármazott osztályban is egy azonos nevű factory metódust írni, és azt a main()-ben GetClass().GetMethod("xxx") és az Invoke() segítségével meghívni.
Annyi mondjuk a csavar csak, hogy a main() metódust indításkor meg kell határoznod, melyik osztályban keresse a JVM
De úgyis csak kísérletről van szó, nem?Élő rendszerekben ez nagyságrendekkel bonyolultabb, általában frameworkök vannak az életciklusokra, a cserélhetőségre meg ilyenek...
-
Ezt kissé át kell fogalmaznom, mert azt hiszem, valamit félreértettem elsőre: szóval annyi lenne a lényeg, hogy egy darab komponenst szeretnék egy 3x3 mezőnyi helyet elfoglaló terület közepére tenni úgy, hogy akkor is a mező közepén maradjon, ha változik az ablak mérete. Ezt a GridBagLayout-tal hogy lehet megoldani?
Valahol elvesztem a doksikban. Úgy tűnik, a fill és anchor mezőkön kívül is van még valami, ami befolyásolja a komponensek elhelyezését, mert ezzel a kettővel a max. amit el tudtam érni az az volt, hogy a 3x3-as terület alsó sorának közepére tette...
Hm. Na mind1, még keresgélek. -
GridBagLayout... látom, korábban más is szívott vele.
Nem teljesen értem az elemek pozicionálását.Mondjuk szeretnék egy 5 sorból és 3 oszlopból álló táblát.
A felső 3x3-as területre szeretnék egy JLabel komponenst, aminek a szövege stabilan a terület közepén marad, átméretezéstől függetlenül. (alatta a 4. sorban három JButton, az 5. sort pedig teljesen kitölti egy JTextArea)
Az alsó két sor a gombokkal és a szövegmezővel működik. De a felső, "cimkeként" szolgáló területet nem tudom összehozni. Van egy c változóm GridBagConstraints típussal.c.fill=GridBagConstraints.BOTH; c.anchor=GridBagConstraints.CENTER;
c.gridwidth=3; c.gridheight=3;
Ezekkel a paraméterekkel adom hozzá a panelhoz, de mindig a terület bal alsó sarkában köt ki a szöveg... -
Belefutottam két apróságba, amikkel végképp nem tudok mit kezdeni:
metóduson belül lehet-e metódust definiálni? Ha igen, akkor hogyan? Az eclipse-nek nem tecc az ötlet.
Konkrétan arra kellett volna, hogy egy metódus gyakorlatilag automatizálva tudjon létrehozni swing komponenseket - jelen esetben JButton objektumokat. De ehhez az osztály többi metódusának semmi köze nem lenne, ezért gondoltam, hogy a gombokat felhasználó metóduson belül definiálok egy függvényt/metódust. Ilyet egyáltalán nem lehet?A másik: egymásbaágyazott osztályokat használva hogyan tudom elérni egy adott példányból az őt magába foglaló objektumot? Megfogalmazva kissé bonyolult, de...
class Xy {
...
class zz extends JFrame {
public zz(){
// na innen hogy tudok hivatkozni az Xy osztály aktuális példányára?
// Itt a super() az a JFrame konstruktorra mutat. Ha meg Xy. minősítéssel
// hivatkoznék rá, akkor csak a statikus tagokat érem el. (és nem feltétlenül konstruktorból szeretnék hivatkozni a külső példányra)
}
}
}Lehet, hogy csak elfelejtettem valamit a korábban olvasottakból?
-
eclipse-hez használ valaki GUI tervező plugint? Van olyan, ami ingyenes, viszonylag egyszerűen használható és átlátható(bb) kódot generál (, mint a NetBeans) ?
Bár lehet, hogy a NetBeans kódja csak azért tűnik zűrösnek, mert maga a swing olyan, amilyen.
Ettől függetlenül, nekem szimpatikusabb egyelőre az eclipse, jobb lenne azzal folytatni a kísérletezgetést. -
-
Apropo java: tudja valaki, hogy változott-e valami a java licencelésével kapcsolatban azóta, hogy az orcle felvásárolta a Sunt?
Olvastam ezt az android-google ellen készülő pert és úgy elméláztam, hogy mi a helyzet pl. a néhai ibm jdk-val, netán az open-jdk-val és egyáltalán a java-ban írt alkalmazásokkal? -
C vagy C++?
Előbbinek nem sok hasznát veszed, attól tartok. Ha az angol nem okoz gondot, akkor The Really Big IndexIlletve egy Nagy Gusztáv (remélem, jól emlékszem) nevű tanár írását is érdemes megkeresni. Itt a topic-ban is ajánlották. Igaz, az még 1.3-as javaról szól és nem ír pl. a swing-ről...
Sima C... Majd lehet belekukkantok akkor az angolba is. Igaz nem vagyok túl jó belőle, de meg tudok vele birkózni
-
Nem mondhatnám, hogy értem amit írsz...
(pontosabban azt, hogy mi köze a problémámhoz - itt most kimondottan példaprogramokról van szó)public static void main(String[] args) {
//Schedule a job for the event-dispatching thread:
//creating and showing this application's GUI.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}Szinte minden példaprogram, ami swinghez kapcsolódik, így indul.
Miért nem elég csak statikusan indítani a createAndShowGUI-t?
Az, hogy belül egyik-másikhoz új szálat indít, az egy másik téma. Azt nem értem, hogy miért kell a main futásától "függetleníteni" bármit? -
Nem mondhatnám, hogy értem amit írsz...
(pontosabban azt, hogy mi köze a problémámhoz - itt most kimondottan példaprogramokról van szó)public static void main(String[] args) {
//Schedule a job for the event-dispatching thread:
//creating and showing this application's GUI.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}Szinte minden példaprogram, ami swinghez kapcsolódik, így indul.
Miért nem elég csak statikusan indítani a createAndShowGUI-t?
Az, hogy belül egyik-másikhoz új szálat indít, az egy másik téma. Azt nem értem, hogy miért kell a main futásától "függetleníteni" bármit? -
A szerzetes
csendes tag
-
Van itt valaki, aki érti a hivatkozott hozzászólásomban vázolt "súlyos" problémámat?
Ha igen: nem lehet, hogy marhaságot akartam ráerőszakolni a java-ra?
Amikor írtam még úgy éreztem, hogy értem mit akarok. Azóta kissé elbizonytalanodtam: jelenleg értelmetlennek tűnik az elképzelés, hogy osztálydefinícióba wildcardot tegyek...Az a baj, hogy már nem tudom eldönteni: akkor voltam belekavarodva az info áradatba, vagy most (hogy már értelmetlennek tűnik) kutyultam össze valamit.
-
Még mindig ezek a generikus témák...
Itt írnak wildcard használatról. Nem látom leírva, hogy a wildcard használat osztálydefinícióban hibás lenne, az eclipse mégis tiltakozik ellene...
Tehát a
class Xxx<T> { ... } működik, de a class Xxx<? extends Number> { ... } már nem tetszik neki. Metódus paraméterei közt elfogadja.Megint én voltam figyelmetlen/nem értettem meg, hogy mire és hogyan használható ez a dolog?
Van itt valaki, aki érti a hivatkozott hozzászólásomban vázolt "súlyos" problémámat?
Ha igen: nem lehet, hogy marhaságot akartam ráerőszakolni a java-ra?
Amikor írtam még úgy éreztem, hogy értem mit akarok. Azóta kissé elbizonytalanodtam: jelenleg értelmetlennek tűnik az elképzelés, hogy osztálydefinícióba wildcardot tegyek...Az a baj, hogy már nem tudom eldönteni: akkor voltam belekavarodva az info áradatba, vagy most (hogy már értelmetlennek tűnik) kutyultam össze valamit.
-
Még mindig ezek a generikus témák...
Itt írnak wildcard használatról. Nem látom leírva, hogy a wildcard használat osztálydefinícióban hibás lenne, az eclipse mégis tiltakozik ellene...
Tehát a
class Xxx<T> { ... } működik, de a class Xxx<? extends Number> { ... } már nem tetszik neki. Metódus paraméterei közt elfogadja.Megint én voltam figyelmetlen/nem értettem meg, hogy mire és hogyan használható ez a dolog?
-
Ez részben tiszta.
Nekem a List és az egymásbaágyazott generikus definíciók zavarnak be egy kicsit. Főleg, hogy a List-ről csak annyit tudok, hogy van, de nem láttam sehol az ő definícióját.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?
-
Na ezt pontosan annyira értem, mint a kódot.
Mondom: szerintem valahol, valami kimaradt (vagy a sun tutorialból vagy csak az olvasásból).
Ha jól értem, az <U> helyére szintaxis szerint akár <Krixkrax>-t is írhatnék, csak az olvashatóság, könnyebb felismerhetőség miatt ajánlott az egyetlen nagybetűs jelölés.
Mi a funkciója ezesetben a void előtti <U>-nak? Mi van, ha elhagyom?
Ezt bogarászom, de számomra nem igazán derül ki belőle.------------------
szerk:
Újra végigolvasva: úgy értsem, hogy a metódus definíció fejében definiálom az "U" típust/osztályt a fordító számára, hogy ne keresse máshol?Na, jólvan, kezd tisztulni... (nem félálomban kellene ilyesmivel foglalkoznom.
)
Az U szerepe rendben, már csak a List<Box<U>> maradt függőben. -
Jé, még tud valóban újat mutatni a Java: ezek a Generikusnak nevezett bigyók (alias Generics) mennyire használatosak a hétköznapi gyakorlatban? Valószínűleg szegényes a fantáziám, vagy félreértem a funkcióját, de egyelőre kicsit nehezen találok a használatára igazán életszerű példát.
-
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.Ha unatkozol, tanulj Java EE-t. Mostanában jól meg lehet belőle élni, előzetes tapasztalat nélkül is.
-
Majd még keresgélek, hátha kiderül valami érdemleges. Igazából előbb kérdeztem itt, utána kezdtem a gúgliban turkálni. A turkálás eredménye, hogy valószínűleg még most is kell SDK, csak azt nem tudom, hogy mindenhez vagy csak ahhoz, hogy az adott mobil spec. képességeit is használni lehessen. (mondjuk egy java szoftver esetében nem értem, miért kellene bármi platformfüggő dolog akár a fejlesztéshez, akár a teszeléshez)
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á ...
-
Még mindig a beágyazott osztályok és a kis Java könyvem...
Írtak a könyvben valami olyat, hogy egy belső osztályt is lehet, akár külső osztály által is bővíteni. Nem statikusat is.
Itt ugye vagy én értettem félre valamit, vagy a szerző tévedéséről van szó?Sokadszorra végignézve a dolgot, mégsem értettem félre és a szerző sem tévedett. Az Eclipse hibaüzenetét nem sikerült értelmeznem.
-
Azt tudom, az már létezett akkor is, amikor el akartam kezdeni játszani vele. De kellett mellé a telefonhoz valami SDK is, ami úgy fest, most is szükséges. Vagy valamit félreértek, de nagyon: nokia.com-on találtam egy topic-ot, ahol jónéhányan panaszkodtak, mert a mai napig nincs linuxos SDK a nokiákhoz... mindenesetre az Eclipse követelne valami SDK-t, amit windows-on még csak-csak alá tudok tolni, de én inkább linuxon jáccanék.
-
Még valami eszembe jutott: ha arra vetemednék, hogy mobiltelefonra próbáljak összetákolni valami egyszerűbb java programot... Van már szabványos fejlesztőkörnyezet hozzá vagy még mindig úgy kell összevadászni valami SDK-t/JDK-t minden egyes telefonhoz? (költői túlzás, de amikor évekkel ezelőtt megfordult a fejemben valami hasonló, akkor kb. az volt a helyzet, hogy a Siemens telefonomhoz csak a siemens-es anyaggal lehetett programot készíteni)
-
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 -
A szerzetes
csendes tag
Megint elakadtam egy kicsit: beágyazott osztályok. Ahány helyen nézem, annyiféle leírást találok. A mellékelt példák többnyire hasonlóak, de a magyarázatok...
Azt kb. felfogtam, hogy a segítségükkel olyan objektumot tudok visszaadni egy metódusból, ami hozzáférhet az adott osztály/példány privát tagjaihoz. (hmmm... mire megfogalmazom, mit akarok kérdezni, még meg is értem? ) Ezért, erre találták ki a beágyazott osztályokat?Viszont gondot okoz a könyvem egy mondata: "... az így létrejövő objektum dinamikusan kapcsolódik a metódusban éppen érvényes aktuális példányhoz, és ez a kapcsolat a metódus elhagyása után is fennmarad."
Ezt itt nem értem. Az OK, hogy ha az adott metódus visszatérési értékként vagy egy osztály/példányváltozóban visszaad egy ilyen objektumot, az megmarad. De ez (számomra) teljesen logikus. Miért van mégis hangsúlyozva ez a kapcsolat? Valamit félreértek és egyéb jelentősége van?-------
Ha van egy ilyen interface-em:interface A { void x(); }
Akkor az őt implementáló osztály x metódusánál miért reklamálja az Eclipse a "public" jelzőt?
Egy belső osztályt akartam így leírni, de a
class O implements A { void x(){ ... } }
nem tetszett neki. Csak így fogadta el:
class O implements A { void public x(){ ... } }Eztakkormostmért?
-
Megint elakadtam egy kicsit: beágyazott osztályok. Ahány helyen nézem, annyiféle leírást találok. A mellékelt példák többnyire hasonlóak, de a magyarázatok...
Azt kb. felfogtam, hogy a segítségükkel olyan objektumot tudok visszaadni egy metódusból, ami hozzáférhet az adott osztály/példány privát tagjaihoz. (hmmm... mire megfogalmazom, mit akarok kérdezni, még meg is értem? ) Ezért, erre találták ki a beágyazott osztályokat?Viszont gondot okoz a könyvem egy mondata: "... az így létrejövő objektum dinamikusan kapcsolódik a metódusban éppen érvényes aktuális példányhoz, és ez a kapcsolat a metódus elhagyása után is fennmarad."
Ezt itt nem értem. Az OK, hogy ha az adott metódus visszatérési értékként vagy egy osztály/példányváltozóban visszaad egy ilyen objektumot, az megmarad. De ez (számomra) teljesen logikus. Miért van mégis hangsúlyozva ez a kapcsolat? Valamit félreértek és egyéb jelentősége van?-------
Ha van egy ilyen interface-em:interface A { void x(); }
Akkor az őt implementáló osztály x metódusánál miért reklamálja az Eclipse a "public" jelzőt?
Egy belső osztályt akartam így leírni, de a
class O implements A { void x(){ ... } }
nem tetszett neki. Csak így fogadta el:
class O implements A { void public x(){ ... } }Eztakkormostmért?
-
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.
-
-
-
Szia!
Hmm...
server glx version string: 1.2
client glx version string: 1.4
GLX version: 1.2
OpenGL version string: 1.4 Mesa 7.7.1Most a server meg a Client version közt mi a különbség? Ezt ne mnagyon értem, meg miért régi?
Még egy kérdés:
Olyan problémám volna ,hofy van egy forrsákód ,ami külső, nem szokványos importokat használ. (neurális háló példa progi)
Szóval nem ismeri az importokat alapból. .JAr fájl nincs ,helyette van egy .tar.gz állomány. Ebben vannak .class fájlok és .java fájlok is ebben van a tutor is,meg azok a jegyzékeke is amit az importbna használna. Ezt kibontom Winrarral. Eclipse-ben a Library-knál (ahol .jar-t adnám hozzá más esetben), ott rámegyek az External Class folders, beállítom ,de semmi. Mit kell ezzel kezdeni? -
Ha ATI-d van, akkor valószínűleg ez a baja:
There is a known
ATI driver bug in glXQueryVersion that incorrectly reports the GLX
version as 1.2 when it really is 1.3,Eszerint bugos az ATI driver és azt hazudja magáról, hogy GLX 1.2 van benne, holott a valóságban 1.3-as.
Ez segít rajtad?
(esetleg egy újabb ATI driver, bár elég csúf tapasztalatokat szereztem vele azalatt a rövidke pár óra alatt, amíg ATI kártya volt a gépemben )Mondjuk nekem úgy tűnik, hogy inteled van, akkor meg a fenti tárgytalan, de tévedhetek.
-
Azon töröm a fejem, hogy lehetséges-e egy Exception-t meg nem történtté tenni?
void c() throws Z {
...
throw new Z;
}
void b(){
try {
c();
} catch(Z) { ... }
}
void a(){
try {
b();
} catch(Z) { ... }
}Mi van, ha azt akarom, hogy miután b-ben már feldolgoztam Z-t, az a-beli catch már ne akarja ismételten feldolgozni?
Jól sejtem, hogy ez a működés nem illik a java logikába?
Vagy megoldható, csak én nem találom a megoldást? -
Egy régi Java2 könyvben találtam olyat, hogy (idézet nem teljesen szószerinti) "példánymetódusokat felüldefiniálni, osztálymetódusokat elfedni lehet".
Össze tudná foglalni valaki pár szóban, hogy mi a különbség az elfedés és a felüldefiniálás között? A könyv alapján nem egészen világos. (osztálymetódus=statikus metódus, ha valakinek így ismerős ) -
Egy régi Java2 könyvben találtam olyat, hogy (idézet nem teljesen szószerinti) "példánymetódusokat felüldefiniálni, osztálymetódusokat elfedni lehet".
Össze tudná foglalni valaki pár szóban, hogy mi a különbség az elfedés és a felüldefiniálás között? A könyv alapján nem egészen világos. (osztálymetódus=statikus metódus, ha valakinek így ismerős ) -
Belefutottam valamibe, amit nem értek, kellene egy kis segítség.
Adott egy piciny program:public class faktor {
static long fakt(long p){
if(p<2){ return 1; } else { return p*fakt(p-1); }
}
/**
* @param args
*/
public static void main(String[] args) {
try {
System.out.println(args[0]+"!="+fakt(Long.parseLong(args[0])));
}
catch(Exception obj) {
System.err.println("Na itt valami gáz van!");
}
}
}Ha paraméterként egy nagyobb számot adok meg, akkor természetesen stack overflow a futás vége. Amit nem értek: a try - catch blokk miért nem kezeli?
Egyéb hibát (például hiányzó paraméter esetén a tömb túlcímzést) kezeli. A stack túlcsordulását miért nem?Csak játszom vele, még azt sem merem állítani, hogy tanulok jávául.
De úgyis csak kísérletről van szó, nem?
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Anglia - élmények, tapasztalatok
- Battlefield 6
- Tesla topik
- Elektromos autók - motorok
- Kingdom Come: Deliverance I-II.
- Feltalálta a Google a keresőmotort
- Poco F8 Ultra – forrónaci
- Egyéni arckép 2. lépés: ARCKÉPSZERKESZTŐ
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Budapest és környéke adok-veszek-beszélgetek
- További aktív témák...
- AKCIÓ! Apple Macbook Air 15 2025 M4 24GB RAM 512GB SSD notebook garanciával hibátlan működéssel
- Lenovo Thinkpad L13,13.3",HD,i3-10110U.8GB DDR4,128GB NVMe SSD,WIN11
- Bomba ár! Lenovo ThinkPad X390 - i7-8G I 16GB I 256SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- Honor Magic V2 512GB,Újszerű,Dobozaval,12 hónap garanciával
- BESZÁMÍTÁS! Asus Rog Strix Z390-F Gaming alaplap garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest