Balogh Péter programtervező informatikus volt.
15 évig foglalkozott szoftverfejlesztéssel. Főként Java területen szerzett tapasztalatot és azon belül is az elosztott alkalmazásokhoz tartozó háttérszolgáltatásokkal (web és mobil platform back-end) foglalkozott. Pályakezdőként kipróbálta magát multi környezetben fejlesztőként, de 5 év után váltott és utána freelancerként élt. Főként Németországban épített ki szakmai kapcsolatokat és Magyarországról távmunkában végzett szoftverfejlesztői munkát. Saját bevallása szerint munkamániás volt, illetve kommunikációs készsége jóval az átlag IT kocka szintje feletti és ennek minden előnyére igyekezett építeni.
2014 óta tanított, főként szoftver architekturális tervezést és Java programozást magyar, angol és német nyelven is. Szakmai kihívásként tekintett az oktatásra.
Mottója volt: „Nem kell mindig tökéletesnek lenni. De ha itt az ideje, akkor tökéletesnek kell lenni.”
Szabad idejében értelmes elfoglaltságot keresett magának és folyamatosan képezte magát. 2017-től 2020-ig blogolt velünk. 2020. szeptemberében elhunyt. Nekrológja itt olvasható: Balogh Péter emlékére.
Híres idézeteket mindig érdemes figyelemmel kísérni és hasznos néha elgondolkodni is ezeken. Az alábbiakban programozáshoz, szoftverfejlesztéshez, illetve informatikához kötődően gyűjtöttünk össze 12 idézetet. A híres emberek között vannak mérnökök, matematikusok, kutatók, akik programozási nyelveket alkottak, akik hardvert terveztek, céget alapítottak, akik informatikusként dolgoztak/dolgoznak. További idézeteket szívesen fogadunk.
„Tévedés azt hinni, hogy egy komplex rendszerhez tervezők és programozók hada szükségeltetik. Egy olyan rendszert, melyet teljesen vagy jelentős mértékig nem ért meg egyetlen személy, valószínűleg nem kell megépíteni.”
– Niklaus Wirth (1934-2024), számítástudománnyal foglalkozó svájci matematikus, informatikus, a Pascal programozási nyelv tervezője és fejlesztője
„Amikor kommenteket olvasok javaslatokról, hogy a C nyelvnek merre kellene haladnia, gyakran visszagondolok a múltra és hálát adok, hogy nem a széleskörű nyilvánosság tanácsait figyelembe véve végeztük a fejlesztését.”
– Dennis M. Ritchie (1941-2011), amerikai számítógéptudós, a C programozási nyelv tervezője
„Szeretném látni, hogy a Perl-t használók kreatívan ragasztják össze a dolgokat, nem csak technikailag, hanem társadalmilag is.”
– Larry Wall (1954-), amerikai programozó, a Perl programozási nyelv alkotója
„Ha a Java-n kívül más nyelvet választanék, akkor az a Scala lenne.”
– James Gosling (1955-), kanadai számítógéptudós, a Java programozási nyelv atyja
„Tulajdonképpen utálom a programozást, de szeretek problémákat megoldani.”
– Rasmus Lerdorf (1968-), dán-kanadai programozó, a PHP programozási nyelv tervezője
„Az emberek úgy gondolják, hogy a számítástechnika a zsenik művészete, de a valóság az ellenkezője: sokan csinálnak olyan dolgokat, amelyek egymásra épülnek, mint mini kövekből a fal.”
– Donald E. Knuth (1938-), amerikai matematikus, az algoritmuselemzés atyja
„Az objektumorientált programozás egy rendkívül rossz ötlet, amely csak Kaliforniából származhatott.”
– Edsger W. Dijkstra (1930-2002), holland matematikus, informatikus, a strukturált programozás fogalmának bevezetője
„A programozás ma a gyémántbányászat ellentéte. A gyémántbányászatban rengeteg szennyeződést ásunk ki, hogy egy kis értéket találjunk. A programozásnál az értékkel kezdünk, majd eltemetjük azt egy csomó szennyeződésbe.”
– Charles Simonyi (1948-), magyar származású, USA-ban élő szoftverfejlesztő, az objektumorientált programozás bevezetője a Microsoftnál
„A szoftver egy nagyszerű kombináció a művészet és a mérnöki munka között.”
– Bill Gates (1955-), amerikai szoftverfejlesztő, a Microsoft cég társalapítója
„Egész életemben olyan számítógépeket terveztem, amelyeket soha nem tudtam megépíteni.”
– Steve Wozniak (1950-), amerikai elektromérnök, az Apple Computer cég társalapítója
„Néhányan amiatt aggódnak, hogy a mesterséges intelligencia elgyengít bennünket, de bárkinek – józan ésszel gondolkodva – alsóbbrendűségi komplexusa kellene, hogy legyen mindig, amikor egy virágra néz.”
– Alan Kay (1940-), amerikai számítógéptudós, az objektumorientált programozás és a grafikus felhasználói felület koncepcióinak úttörője
„Ha egy gép várhatóan tévedhetetlen, akkor nem is lehet intelligens.”
– Alan Turing (1912-1954), brit matematikus, a Turing-gép fogalmának megalkotója
2017. augusztus 29-én délután a HWSW szervezésében a Merre tart a Java? Nyár végi Java fejlesztői meetup-on vettem részt az AnKERT-ben. Az előadások a szeptember 21-re időzített Java SE 9 várható újdonságai köré épültek.
Simon Géza (DPC Consulting) A Java 9 újdonságaiból szemezgetett. Egy kérdéssel indított: eltöri-e a Jigsaw a meglévő rendszereinket? (Spoiler: lehet.) A Jigsaw projekt a Java 9-től végre elérhető. Kitért a modulok definiálására. Mutatott példát adatbázis drivertől való függőség kezelésére szerviz definícióval. Kitért az
rt.jar átalakításának koncepciójára – egyben a JDK és a JRE összefésülésére –, valamint az egységbezárás finomhangolására.
Gergely Pál Dávid (Doctusoft) Java alkalmazások a felhőben előadását a kontroll vs. munka egyensúlya, arányaival kezdte a privát felhő, IaaS, PaaS, FaaS, SaaS konfigurációs alkotóelemeinek (Functions, Data, Application, Runtime, Backend Code, OS, Virtualization, Server Machine, Storage, Networking) felelősségi körét áttekintve. Rendszerek kialakításának folyamatával folytatta, tág testre szabási lehetőségeket ismertetve. Mindent eldöntő kérdésnek szánta: de hát akkor miért nem FaaS még minden? Kaptunk rá hivatalos és gyakorlatias válaszokat is. A legacy rendszerek frissítéséhez kötődően megosztotta legfontosabb tapasztalatát: a technológiai előnyhöz célszerű üzleti előnyt is párosítani.
Faragó János (designhumanist) A Java jövője… nem is a Java? című előadása alatt nagyon kellett ügyféllel egyeztetnem telefonon, így ezt kihagytam. A kulcsszó a Kotlin volt. A prezentációkat a szervezők publikálták, így megtekinthető.
Pákozdi György (Green Fox Academy) JShell: a Java 9 REPL csodája című előadásában demózta a read-eval-print-loop technikát. A megközelítés inkább hibakezeléshez kötődött, de ez a „parancssor” végre beépült az ökoszisztémába, így rendelkezésre áll az azonnali végrehajtás és kiértékelés (eredmény visszaadás) a futtatókörnyezetben. Rövid áttekintést kaptunk arról is, hogyan működik, mit jelent a REPL más programozási nyelvekben.
Balogh Zsolt (Liferay) Patchelés Enterprise Java környezetben címmel összefoglalta az inkrementális javítási folyamatot és áttekintést adott arról, hogy egy elosztott rendszerben mindez miket érinthet, például alkalmazás-szerver, adatbázis, operációs rendszer, böngésző (asztali és mobil), DK, felhőszolgáltatás. Persze mindegyikből többféle is választható. Felsorolta egy patching toollal szemben megfogalmazható általános és egyben minimum követelményeket/elvárásokat. Megosztott néhány gyakorlati tapasztalatot is, főként az egyszerűsítést és az automatizálást érintve. Néhány tipikus rejtett problémát is megismerhettünk.
Fodor Bertalan (EPAM) Reaktív microservice-ek – a jövő Javával című előadásában hangsúlyozta, hogy az üzleti igények változásában beállt jelenlegi trend nem az, hogy a nagyobb hal megeszi a kisebbet, hanem az, hogy a gyorsabb hal eszi meg a lassabbat. Az architektúra fejlődése során a nyújtott/biztosított szolgáltatások egyre komplexebbek, állandóan növekszik a felhasználók száma, amihez természetesen folyamatosan növekvő erőforrásigény társul. Az alapvető elvárások kulcsszava a reaktivitás, 4 szempontban gondolkodva: reszponzív, reziliens, elasztikus, üzenetalapú.
Java fejtörők – csapdák, buktató, és szélsőséges esetek. Ez egy könyv címe, amelynek szerzői J. Bloch és N. Gafter. Magyar nyelven a Kiskapu Kft. jelentette meg. A 2010-es magyar kiadás a 2005-ös angol nyelvű kiadás fordítása. A könyv weboldaláról (http://www.javapuzzlers.com), letölthető a 95 fejtörőhöz tartozó mintapéldák gyűjteménye, és elérhető a 270 oldalból minta fejezetként 28 oldalnyi tartalom 9 fejtörővel és azok részletes magyarázataival.
A két részre bontott blog bejegyzés a könyv anyagából válogatva készült el. Az első rész a bevezetés. Ez a második rész, haladó szintű példákkal. Néhány példát továbbfejlesztettem.
7. fejtörő: Mit ír ki program a konzolra?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
publicclassTest{
staticvoidworkHard(){
try{
workHard();
}
finally{
workHard();
}
}
publicstaticvoidmain(String[]args){
workHard();
System.out.println("Hello World!");
}
}
Kivételkezelés nélkül arra számítanánk, hogy a
Hello World! nem jelenik meg a konzolon, mert a
wordHard() metódus feltétel nélkül rekurzív módon folyamatosan újrahívja önmagát és az emiatt keletkező
StackOverflowError hibával elszáll a program. A kivételkezelés természetesen módosítja a program működését.
Ha azt feltételezzük, hogy minden
Throwable utódosztályból futás közben létrehozott objektum kivételkezeléssel elkapható, akkor végtelen ciklusnak tűnik a vezérlés, hiszen a
try blokkban hibát okozó metódushívásra a
finally blokkban újra ugyanannak a metódusnak a meghívásával reagálunk, amelyik korábban a hibát kiváltotta. Ez a gondolatmenet tévút. A kulcsszó a rekurzív vezérlést megvalósító verem adatszerkezet mérete. Részletes indoklás a blog bejegyzés végén található.
8. fejtörő: Mit ír ki program a konzolra?
1
2
3
4
5
6
7
8
9
publicclassNull{
staticvoidgreet(){
System.out.println("Hello World!");
}
publicstaticvoidmain(String[]args){
((Null)null).greet();
}
}
Természetesen
NullPointerException-re gyanakszunk, pedig a program hibátlanul működik. A kulcsszó a statikus metódusok minősítése, vagyis annak jelölése, hogy melyik osztálytól vagy objektumtól kérjük annak végrehajtását. Részletes indoklás a blog bejegyzés végén található.
Arra számítunk, hogy a kiírás
1999-12, de ehelyett
20001-et látunk a konzolon. Tudjuk, hogy a
Date osztály jó része már deprecated és ezen próbáltak javítani a
Calendar osztállyal. Bár ne tették volna. A kulcsszó az ős dátumkezelést megvalósító API rejtelmeiben van. Részletes indoklás a blog bejegyzés végén található.
10. fejtörő: Mit ír ki a program a konzolra?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
classX{
staticclassY{
staticStringZ="Black";
}
staticCY=newC();
}
classC{
StringZ="White";
}
publicclassTest{
publicstaticvoidmain(String[]args){
System.out.println(X.Y.Z);
}
}
Nem tűnik egyértelműen eldönthetőnek a helyzet, ezért szintaktikai hibára gyanakodhatunk. Azonban a forráskód helyes, a program futás közben sem dob kivételt/hibát és a konzolon megjelenik a
White. Szokatlan, hogy nagybetűvel konstansokat szokás jelölni, pedig nincs erre utaló
final a forráskódban. A kulcsszó a sorrendiségen van, ha ugyanabban a hatókörben/blokkban van azonos nevű változó és típus/osztály. Részletes indoklás a blog bejegyzés végén található.
11. fejtörő: Mit ír ki a program a konzolra?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
importjava.util.Random;
publicclassTest{
privatestaticRandomr=newRandom();
privatestaticvoidswap(Object[]a,inti,intj){
Objecttemp=a[i];
a[i]=a[j];
a[j]=temp;
}
publicstaticObject[]shuffle(Object[]a){
for(inti=0;i<a.length;i++)
swap(a,i,r.nextInt(a.length));
returna;
}
publicstaticvoidmain(String[]args){
String[]s1={"alma","körte","barack","dinnye"};
for(Objecto:shuffle(s1))
System.out.print(o+", ");
System.out.println();
}
}
A program helyes és egyértelműnek tűnik. A konzolra az
s1 szövegtömb elemei kerülnek ki véletlenszerűen összekeverve. Finomítsunk a kérdésen. Vajon minden lehetséges permutáció azonos eséllyel fordul elő? Ha ez a kérdés egyáltalán felmerül, akkor a válasz nyilván nem. A kulcsszó most egy kis matematika. Részletes indoklás a blog bejegyzés végén található.
12. fejtörő: Mit ír ki a program a konzolra?
1
2
3
4
5
6
7
8
9
10
importjava.util.Arrays;
publicclassTest{
publicstaticvoidmain(String[]args){
Integer[]array={3,1,4,1,5,9};
Arrays.sort(array,
(Integeri1,Integeri2)->i1<i2?-1:(i2>i1?1:0));
System.out.println(Arrays.toString(array));
}
}
Ez a forráskód nem úgy működik, ahogyan a könyv írja. Meglepő módon nem a
[3,1,4,1,5,9]-et adja, hanem az
[1,1,3,4,5,9]-et. Némi indoklás a blog bejegyzés végén található.
Részletes indoklások
7. fejtörő: ha a
try blokkban folyamatosan meghívja saját magát a
workHard() metódus, akkor előbb-utóbb betelik a verem. Ekkor a
finally blokkra kerül a vezérlés, ahonnan újra hívja saját magát a
workHard() metódus. Persze követni kell, hogy a rekurzió végrehajtása során a lefelé haladó vagy a felszálló ágon vagyunk és nem mindegy, hogy melyik szinten. A háttérben egy teljes bináris fa bontakozik ki, amelynek mélysége azonos a verem méretével, mélységi korlátjával. Ezt a teljes bináris fát járja be a program, azaz mélységi fabejárás. Egy n mélységű teljes bináris fa elemeinek száma 2n-1. A verem mérete a virtuális gép beállításaitól függ, több ezer mélységű is lehet. Végtelen ciklusról tehát nincs szó. Ugye milyen izgalmas? További részletek a könyv 100-102. oldalán találhatók.
8. fejtörő: a végrehajtás kiértékeli a statikus
greet() metódus hívásának minősítő kifejezését, de figyelmen kívül hagyja a kapott értéket. A metódust végrehajthatnánk
Null.greet()-ként vagy közvetlenül (minősítés nélkül) meghívva is. További részletek a könyv 122-124. oldalán találhatók.
9. fejtörő: a
Date osztály a hónapokat nulla bázissal kezeli, ezért csak 0-11-ig „van értelme”. Számíthatnánk a tömb vagy szöveg túlindexelésénél tapasztaltakhoz hasonlóan kivételre, de nem ez történik. A 12. hónap a következő év első/nulladik hónapját jelöli. Ezért látjuk a konzolon a
2000-et, amit egy kötőjel követ. A
Date.getDay() deprecated metódus pedig a dátumobjektumban tárolt nap adott héten (nem hónapban!) elfoglalt helyét adja meg, ami nullával, azaz vasárnappal indul. Tehát a konzolon megjelenő
1 nem a 2000. januárt jelenti, hanem azt, hogy a 2000. január 31. hétfőre esik. Aki ezek után meri használni a régi dátumkezelő API-t, magára vessen. További részletek a könyv 141-143. oldalán találhatók.
10. fejtörő: ha ugyanabban a hatókörben/blokkban van azonos nevű változó és típus/osztály, akkor a változó neve az elsődleges. Ha betartjuk a névadási konvenciókat (
ClassName,
objectName,
CONSTANT_NAME), akkor nem adódhatnak ilyen gondok. Még egy csavar van: ha az előző elnevezési módosításokat megtesszük, akkor a program a
Black-et írja ki a konzolra. További részletek a könyv 161-163. oldalán találhatók.
11. fejtörő: konkrét esetből általánosítunk. 4 elemre a ciklus 4-szer hajtódik végre és minden lépésben kiválaszt egyet a 0 és az 3 indexű elemek közül, ami 44=256-féle lehetséges eredményt ad. Ha az
r objektum jól működik, akkor az egyes futások esélye/valószínűsége megegyezik. 4 elemű tömb elemeinek 4!=24 (faktoriális) féle permutációja (lehetséges sorrendje) van. Mivel a 256 nem osztható 24-gyel, így biztos, hogy a
shuffle() metódus bizonyos permutációkat gyakrabban állít elő, mint másokat. Általánosan: nn nem osztható n!-sal, ha n>2 egész szám. Vajon mi történik, ha egy 52 lapos pakli kártyát keverünk össze? Vajon milyen érdekességet vet ez fel? Minden poént nem lövünk le itt a blogban. További részletek a könyv 228-232. oldalán találhatók.
12. fejtörő: ez a tankönyv utolsó példája. A felvetett gondolat nagyon frappáns: az összehasonlító rész „ha fej, én nyerek, ha írás, te veszítesz” tüneteitől szenved. További részletek a könyv 232-233. oldalán találhatók.
Állásinterjúkon időnként visszaköszönnek hasonló fejtörők, de ezekkel óvatosan kell bánni. Egy programozási nyelv „joghézagainak”, buktatóinak, szélsőséges eseteinek ismerete a könyv szintjét elérő ismeretanyaggal nem lehet elvárt még egy meghirdetett senior pozíció esetén sem. Ezen fejtörők ismerete (vagy nem tudása) egy jelöltről nem árulja el a mindennapokban használható szakmai tudás meglétét/hiányát. De nyilván aki szakmailag folyamatosan fejlődik és mindenféle keretrendszert alkotó forráskódokban turkál, elemez, előbb-utóbb találkozik ezekkel/ilyenekkel.
Tanfolyamainkon nem kifejezetten foglalkozunk hasonló problémákkal, de azért időnként feszegetjük a határokat. Természetesen részletesen indokoljuk, ha előkerül valamilyen hasonló eset. Általánosságban nem célunk, hogy extrém eseteken keresztül, a programozási nyelv gyenge pontjaira kihegyezve oktassuk a Java programozási nyelvet.
Java fejtörők – csapdák, buktató, és szélsőséges esetek. Ez egy könyv címe, amelynek szerzői J. Bloch és N. Gafter. Magyar nyelven a Kiskapu Kft. jelentette meg. A 2010-es magyar kiadás a 2005-ös angol nyelvű kiadás fordítása. A könyv weboldaláról (http://www.javapuzzlers.com), letölthető a 95 fejtörőhöz tartozó mintapéldák gyűjteménye, és elérhető a 270 oldalból minta fejezetként 28 oldalnyi tartalom 9 fejtörővel és azok részletes magyarázataival.
Messze nem mai az anyag, de teljesen örökzöld. Ma is kifejezetten igazán izgalmas átgondolni ezeket a fejtörőket. Biztos vagyok benne, hogy az igazán profiknak is nyújt újdonságot egy-egy fejtörő mögötti részletes magyarázat. Sokszor kiderül az a ravasz és csavaros magyarázatok között, hogy mire gondolt a költő, azaz mi volt/lehetett a Java programozási nyelv tervezése során a szakemberek elképzelése, illetve előfordultak-e kompromisszumok, amiknek persze következményei vannak.
Két – literálként megadott – egész szám összegét kell kapni. Két egyforma értéket várunk:
66666. Mégsem ezt kapjuk. Az első kiírás
66666-ot, a második
17777-et jelenít meg a konzolon. A kulcsszó a különböző egész literálok megadása. Részletes indoklás a blog bejegyzés végén található.
2. fejtörő: Mit ír ki program a konzolra?
1
2
3
4
5
6
7
8
9
10
publicclassTest{
publicstaticvoidmain(String[]args){
Stringpig="length: 10";
Stringdog="length: "+pig.length();
System.out.println("Animals are equal: "+pig==dog);
System.out.println(("Animals are equal: "+pig)==dog);
System.out.println("Animals are equal: "+(pig==dog));
System.out.println("Animals are equal: "+pig.equals(dog));
}
}
Szöveges literálokat hasonlítunk össze, amelyek egyforma (
length:10) tartalommal jönnek létre. Döntések eredményeit várjuk,
boolean típusú változókat. Négy sorba tördelve ezt kapjuk:
false,
false,
Animals are equal:false,
Animals are equal:true. A kulcsszó a művelet végrehajtás sorrendje, másképpen kifejezések kiértékelési sorrendje. Részletes indoklás a blog bejegyzés végén található.
3. fejtörő: Mit ír ki a program a konzolra?
1
2
3
4
5
6
7
8
9
10
11
/*
* Generated by the IBM IDL-to-Java compiler, version 1.0
* from F:\TextRoot\apps\a1\units\include\PolicyHome.idl
* Wednesday, June 17, 1998 6:44:40 o'clock AM GMT+00:00
*/
publicclassTest{
publicstaticvoidmain(String[]args){
System.out.print("Hell");
System.out.println("o World!");
}
}
Természetesen a megjegyzéssel nem törődünk és arra gondolunk, hogy a konzolon a
Hello World! jelenik meg (a két kiíró utasítás eredménye egyetlen sorban egymás után) és nem is értjük, hogy mi a kérdés. Nyilván a helyzet nem ilyen triviális. A program nem futtatható. A kulcsszó az unikód escape szekvencia (védőkarakter). Részletes indoklás a blog bejegyzés végén található.
4. fejtörő: Mit ír ki a program a konzolra?
1
2
3
4
5
6
7
publicclassTest{
publicstaticvoidmain(String[]args){
System.out.print("browser:");
https://www.google.com;
System.out.println(":maximize");
}
}
Nyilván szintaktikai hibát feltételezünk, de a program hibátlan és futtatva ezt látjuk a konzolon:
browser::maximize. A kulcsszó a címke/utasításcímke. Részletes indoklás a blog bejegyzés végén található.
5. fejtörő: Mit ír ki a program a konzolra?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
publicclassTest{
privatestaticbooleandecision(){
try{
returntrue;
}
finally{
returnfalse;
}
}
publicstaticvoidmain(String[]args){
System.out.println(decision());
}
}
Gyanús a helyzet. Adott egy függvény, aminek kötelezően van visszatérési értéke. Ez rendben van. Tudjuk, hogy a
return utasítás kiugrik a függvényből, eljárásból, ciklusból. A kivételkezeléshez kötődő nyelvi kulcsszavakat is ismerjük:
try,
catch,
finally,
throw,
throws. Ezek működését is ismerjük. Azt feltételezhetjük, hogy a
try blokkból kiugrunk
true értékkel és a
decision() függvényt meghívó
main() metódusba visszatérve kiíródik a konzolra, hogy
true. Mintha a
finally blokk nem is lenne. Nem így történik. A programot futtatva
false jelenik meg a konzolon. A kulcsgondolat a
finally blokk végrehajtásának vezérléséhez kapcsolódik. Részletes indoklás a blog bejegyzés végén található.
6. fejtörő: Mit ír ki a program a konzolra?
1
2
3
4
5
6
7
publicclassTest{
publicstaticvoidmain(String[]args){
Stringhello="Hello World!";
for(inti=0;i<hello.length();i++)
System.out.write(hello.charAt(i));
}
}
Már biztosan gyanakszunk, de azért a
Hello World!-öt várjuk a konzolon. Ehelyett nem jelenik meg semmi. A kulcsszó a puffer ürítés. Részletes indoklás a blog bejegyzés végén található.
Részletes indoklások
1. fejtörő:
int típusú literál az
54321, de
long típusú literál az
5432l. Az
1 – mint numerikus karakter – nem egyezik meg a kis
l betűvel. Tanulság: használjuk nagy
L betűt a
long típusú literálok végén. További részletek a könyv 11-12. oldalán találhatók.
2. fejtörő: a konkatenálást végző
+ operátor erősebben kötődik, mint a két objektumreferencia azonosságát eldöntő
== operátor. Az első kiírásban látható művelet igazából a második kiírásban látható zárójeles formában kerül végrehajtásra. A harmadik kiírást az magyarázza, hogy a
String típusú literálokat memóriacímeik és nem a bennük tárolt karaktersorozat/érték alapján hasonítódnak össze. A helyes gondolatmenet implementálását a negyedik kiírás tartalmazza: (megegyezik-e a két szövegliterál tartalma). További részletek a könyv 29-31. oldalán találhatók.
3. fejtörő: a megjegyzés 3. sorában található
\u karaktert 4 db hexadecimális számnak kellene követnie. Ez hiányzik, ami szintaktikai hibát jelent. További részletek a könyv 33-34. oldalán találhatók.
4. fejtörő: az URL-ben lévő : egy ugyanolyan címke, amit a
switch utasításban a
case ágaknál szokás használni. Ez így is megengedett, de teljesen haszontalan. További részletek a könyv 47-48. oldalán találhatók.
5. fejtörő: a kivételkezelési mechanizmus úgy működik, hogy a
try blokkban lévő utasításoktól függetlenül – akár volt kivétel akár nem, akár
return utasítást tartalmaz a
try blokk – a
finally blokk mindenképpen végrehajtódik. Ebben az esetben a kivételkezelési mechanizmus erősebb. További részletek a könyv 77-78. oldalán találhatók.
6. fejtörő: a
System.out egy
PrintStream osztályú objektum. Többnyire automatikusan ürítik az átmeneti tárolóját az ezt használó utasítások, például
System.out.print() és
println(). A
write() metódus nem üríti ezt a puffert. További részletek a könyv 195-196. oldalán találhatók.
Tanfolyamainkon nem kifejezetten foglalkozunk hasonló problémákkal, de azért időnként feszegetjük a határokat. Természetesen részletesen indokoljuk, ha előkerül valamilyen hasonló eset. Általánosságban nem célunk, hogy extrém eseteken keresztül, a programozási nyelv gyenge pontjaira kihegyezve oktassuk a Java programozási nyelvet.
Weboldalunkon cookie-kat (sütiket) használunk, melyek célja, hogy teljesebb szolgáltatást nyújtsunk látogatóink részére. További böngészésével hozzájárul ezek használatához. ElfogadAdatkezelési szabályzat
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
2017. augusztus 29-én délután a 
Java fejtörők – csapdák, buktató, és szélsőséges esetek. Ez egy könyv címe, amelynek szerzői J. Bloch és N. Gafter. Magyar nyelven a Kiskapu Kft. jelentette meg. A 2010-es magyar kiadás a 2005-ös angol nyelvű kiadás fordítása. A könyv weboldaláról (