Bulizhatz rekurzioval: az utolso else agban meghivhatod a kaloriaKiirt megegyszer.
Bulizhatsz do-while ciklussal: do... while (beolvasott szo nem gyumolcs).

Amugy van sok furcsasag a kododban. Lehet csak a tableten nem latom, de mi szukseged van a File f parameterre? Mi a gyum, honnan jon az extended for loop elott. Van egy static String gyumod az osztalyban valamilyen ertekkel?

I am having fun staying poor.

Do-while-lal oldottam meg végül, köszi.

public static void kaloriaKiir(ArrayList<Gyumolcs> ertekek, File f) {

Scanner scan = new Scanner(System.in, "ISO-8859-2");
System.out.println("Kérem a gyümölcs nevét: ");
String nev = scan.nextLine();
do {

if (!gyum.toString().contains(nev)) {
System.out.println("Nem megfelelő név, újat kérek!");
nev = scan.nextLine();
}

} while (!gyum.toString().contains(nev));

if (gyum.toString().contains(nev)) {
System.out.println("Kérem a mennyiséget grammban: ");
int menny = scan.nextInt();

for (Gyumolcs gyum : ertekek) {
if (nev.equals(gyum.Megnevezes)) {
System.out.println(menny + " gramm " + gyum.Megnevezes + " " + gyum.kcal / 100 * menny + " gramm kalóriát tartalmaz.");

}

}

}

}

Biztos sok sok furcsaság van a kódban, de most a cél átmenni a vizsgán.

Let the Zone take me if I am.

Ez a rész háromszor is szerepel: gyum.toString().contains(nev)

Egyrészt a harmadik automatikusan teljesülni fog, elhagyható, egyetlen vizsgálat is elég. Másrészt gondolom az elso gyum helyett az ertekek változót akartad használni, így az értékek.contains(nev) pont az, amire szükséged van, sőt, a toString-ezés miatt ha akár egyetlen betűt írsz be, ami a felsorolt gyümölcsök valamelyikében szerepel, azt is el fogja fogadni, nem néz teljes egyezést. Kicsit egyszerűsítve:

public static void kaloriaKiir(List<Gyumolcs> ertekek) {

        Scanner scan = new Scanner(System.in, "ISO-8859-2");
        System.out.println("Kérem a gyümölcs nevét: ");
       String nev;
       while (!ertekek.contains(nev = scan.nextLine())) {
               System.out.println("Nem megfelelő név, újat kérek!");
       }

         System.out.println("Kérem a mennyiséget grammban: ");
         int menny = scan.nextInt();

         for (Gyumolcs gyum : ertekek) {
             if (nev.equals(gyum.Megnevezes)) {
                 System.out.println(menny + " gramm " + gyum.Megnevezes + " " + gyum.kcal / 100 * menny + " gramm kalóriát tartalmaz.");

             }
       }

   }

[ Szerkesztve ]

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

Miután elküldtem, rájöttem, hogy az ertekek.contains(nev) nem lesz jó, mert egy List<Gyumolcs> sosem tartalmazhat String-et, de ettől még áll, amit írtam, hogy a toString()-ezés nem a jó irány. Például:

private static boolean isNameValid(List<Gyumolcs> ertekek, String nev) {
for (Gyumolcs gyum : ertekek) {
if (gyum.getName().equals(nev)) {
return true;
}
}
return false;
}

És akkor ezt a metódust lehet hívni a while ciklusból. A gyum.Megnevezes-t pedig engedelmeddel getter-re cseréltem, nem használunk field-et közvetlenül (és nem is kezdjük a nevét nagybetűvel).

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

A static metódus arra enged következtetni hogy valószínű ugyan abban az osztályban van ez a kaloriaKiir metódus amiben a main() és azért static hogy tudd meghívni a main-ben.
Lehet hogy a vizsgára amire készülsz ez jó és elegendő. Én a következő osztályokkal dolgoznék:
Gyumolcs : egyetlen gyümölcs adatait tároló POJO osztály. semmi extra metódus nem kell ebbe. Max a toString-et írd felül hogy az objektum értékeit adja vissza.
KaloriaTabla : lenne benne egy ArrayList<Gyumolcs> lista, egy adatbeolvasó metódus ami feltöltené ezt a listát. Konstruktorba feltölteném a listát. Kell egy kereső metódus ami egy string alapján keres a listában a gyümölcs neve alapján és Gyumolcs-öt adnék vissza, vagy null-t ha nincs. (Ez az osztály lehetne akár singleton is, ha már tanultátok)
A futtató osztályban (amiben a main() van), megírnám a felhasználói felületet, menüt, a névbekérést stb. Itt példányosítanám a KaloriaTabla-t és ennek a kereső metódusát hívogatnám.
Igaza van Sirpi kollégának abban hogy a contains használata nem a legjobb megoldás. Ha contains-t használsz akkor kezeld úgy hogy nem csak egy hanem több gyümölcsöt is kaphatsz eredményül, és ilyenkor minden találatot jeleníts meg.

[ Szerkesztve ]

"Nem gond ha nem vágod a párologtatók bináris nyelvét..."

Köszi mindkettőtöknek, hétvégén még hegesztem a kódot.

Let the Zone take me if I am.

Hali

Hogyan nézne ki ez a kód, ha nem lambda expressionnal írnám? (JavaFX)
Nem igazán értem, hogy mit csinál, talán a régebbi módon írva érthetőbb lenne.

private List<Sprite> sprites() {
   return root.getChildren().stream().map(Node n -> (Sprite) n)
        .collect(Collectors.toList());
}

[ Szerkesztve ]

private List<Sprite> sprites() {
List sprites = new ArrayList<>();
for (Node node : root.getChildren()) {
sprites.add((Sprite) node); }
}

[ Szerkesztve ]

I am having fun staying poor.

Ebben mi a visszatérési érték? A sprites nevű lista?

[ Szerkesztve ]

Igen, az lesz az. Így már érthető, köszi szépen!

Igen, bocs. A ph-s kódszerkesztő elég fura, lehet elvesztettem a kontent egy részét. Vagy lehet nem is volt meg soha.

I am having fun staying poor.

Titeket nem zavar ez a Clean Code tudathasadásos állapot?
Clean Code szabály: ne írjunk kommentet, főleg ne Javadocot.
Erre a 2017-ben megjelent Java9-ről szóló könyvben szerepel a hogyan írjunk metódust leírás:
9 sor metódus, 15 sor magyarázattal előtte mit csinál

[ Szerkesztve ]

És? Aki a Java9-es könyvet írta amit olvasol, azt mondta, hogy clean code enthusiast? Vagy honnan jön a tudathasadás feltételezés? Van aki követi, van aki nem. Nem szeretem a kommenteket, de néha van haszna. Főleg ha valamit úgy írsz meg, hogy elüt a best practice-ről, de van valamilyen jól megfogható oka, hogy miért van mégis úgy. Én nagyjából követem az elveket, bár a refactoring könyveket sokkal jobban és hasznosabbnak tartom.

I am having fun staying poor.

Engem az zavar amikor a clean code-nak a keplettel ellenorizheto reszet eroltetik, a lenyeget meg siman felrugjak egy unit test kedveert. Kaptam olyan review comment-et hogy a comment-ben (ok kertek hogy legyen leiras hogy miert ugy) a folyo angol szovegben egy zarojel elott nem volt szokoz, potoljam... [osszevontam ket sort es ugy maradt].
En ugy gondolom, hogy a clean code a biorobot kodiroknal muszaj, akik raadasul surun cserelodhetnek, es ezt aztan mint szabvanyt probaltak elterjeszteni hogy a manager egyenletesebb (nem jobb, nem gyorsabb, hanem kiszamithatobb!) haladassal tudjon szamolni.
Nyilvan a clean code masreszt nem mas, mint egy best practice gyujtemeny, iranymutato. Aki gyakorlott, az nem mint clean code csinalja, hanem mint egyszeruen adodo helyes megoldas. [Kedvenc peldam erre, hogy mennyit kuzdenek a tanarok mikor az adatbaziselmeletben keresnek olyan eseteket ami x NF de nem (x+1)NF. Mert termeszetes uton senki nem ugy allitja ossze, ha mar addig eljut hogy atgondolja, hogy ez egy karbantarthato sema legyen. Tok hasonloan a kozosbe irt kod is. Szerintem.]

Hol is láttál ilyen clean code "szabályt", hogy "ne írjunk kommentet, főleg ne Javadocot"?

Tudtommal ez nem így van. A clean code meghatározza, hogy mi a jó komment, nem pedig tiltja. Ha józan paraszti ésszel is belegondolsz, ennek így van értelme.

"Good Comments
Some comments are necessary or beneficial. We’ll look at a few that I consider worthy of the bits they consume. Keep in mind, however, that the only truly good comment is the comment you found a way not to write."

Robert.C.Martin: Clean Code

"Some comments are necessary or beneficial. We’ll look at a few that I consider worthy of the bits they consume." Tehát kommentet írni bizonyos esetekben és és jogos. Javadoc meg akkor igazán fontos, hogyha egy library API-ját írja le. Mivel akkor az konkrétan inkább dokumentáció, mint komment.

I am having fun staying poor.

Ja. Ne keverjük már a kommentet egy javadoc (API) leírással. API leírás kell, ha például 3rd party használja az API-dat, aki nem tudja/akarja elolvasni a forrásodat, hogy megismerje a belső működését.
Olyan komment nem kell, ami a kódot szemeteli tele. Normális esetben a clean code egyúttal jól strukturált és jól olvasható kód is, tehát könnyű megérteni, így nem kell lépten nyomon teletűzdelni olyan kommentekkel, hogy "ez azért van, mert..", vagy "ezt ne változtasd meg mégha nagyon fura is, mert behány tőle a rendszer stb". Ugyanakkor ilyen kód nem létezik, és sokszor jól jön egy-egy magyarázó sor.

[ Szerkesztve ]

Thank you to god for making me an atheist

Azt hittem, már valami alter irányzat kezdett kibontakozni clean code-nak csúfolva magát.
Valószínűleg az én angol tudásom kopott meg, de ebben sem látom a tiltást. Persze kiemelhetném a "not to write" kifejezést az egészből, és ignorálhatnám az ezt körbevevő bekezdések tartalmát, de miért is tennék ilyet!

Szerintem érdemes elolvasni a teljes fejezetet, ha még nem tetted meg. Különösen azokat a részeket, ahol azt ecseteli például, hogy totálisan felesleges leírni a kód mellé/alá/fölé, hogy mit csinál, mert az olvasó ezt amúgy is látja, viszont például azon ritka esetekben, amikor a miért kérdésre adandó választ kívánja megörökíteni a fejlesztő, a mögöttes szándékot, amit semmilyen más nyelvi eszközzel nem lehetne egyszerűen megmutatni, akkor érdemes ezt megtenni, hogy megkönnyítsük az olvasó dolgát. Persze a gányolást is lehet kommentben magyarázgatni, de a könyv többi része azt szajkózza, hogy ne gányolj, szóval...
Az általad idézett "not to write" arról beszél, hogy ha szépen írod meg a kódot, akkor a kommentek elhelyezése is szükségtelenné fog válni, mivel feltételezzük, az olvasó tud alapszinten jávául és minden szükséges információt megkap a konstansok, változók, metódusok és osztályok elnevezéseiből, struktúrájából.

Semmi sem fekete vagy fehér, így tudathasadásról sem lehet beszélni, hiszen értjük az ajánlás mögötti szándékot és aszerint cselekszünk. A clean code szerintem meg amúgy sem szabály, hanem ajánlás.

A public api javadoc meg más tészta, az a feladata, hogy röviden összefoglalja a mögöttes funkció lényegét és tájékoztasson a használat módjáról, megspórolva az olvasónak a forráskód böngészését... de erről a többiek is sokat írtak.

Helló!

Elkezdtem az Agyhullám java könyvet. Egy kérdés: Van ennél részletesebben elmagyarázó könyv?

[kép]

Ennél a feladatnál elakadtam. Nem értem, miért kell hirtelen String változónév = "értékebetűkkel" helyett String[] változónév = {"értékebetűkkel"}?

Mit jelent a []? Miért kell kapcsos zárójel amikor megadjuk az értékét? (bár tippem az, hogy a felsorolás miatt)
Nem igaz, hogy nem találok normálisan elmagyarázó könyvet.....

[ Szerkesztve ]

Jól gondolod, ez a helyes szintaxis. A String[] valami = {"ez", "az", "amaz"}; neve az, hogy tömb, vagy ahogy a művelt francia mondaná: array. Olvass utána, igazán változatos egy jószág.

Ha a String változónév a cipősdoboz, amibe tehetsz egy valamit, akkor a String[] változónév lehetne a fiókos szekrény valahány meghatározott számú fiókkal és mindegyik fiókba tehetsz egy valamit.

A te konkrét példádban ez egy 1 db fiókkal rendelkező szekrény, aminek a fiókjában pihen az "értékebetűkkel" String, de attól még nem cipősdoboz.

[ Szerkesztve ]

[]: tömb. {ertek1, ertek2, ...}: tömb elemeket leíró literál. A lényeg, hogy több értéket felsorolhatnál, ami String és a tömbben akarod eltárolni.

Az említett könyvet nem ismerem. Totál alap Java könyvet nem is tudnék ajánlani. Inkább Java alap videokat néznék. Pl. totál kezdő szinten van a Udemy-n a Java masterclass. Az talán már 100 óránál is hosszabb, nagyon sok dologra kitér, teljesen az alapoktól kezdve. Bár angol és fizetős.

I am having fun staying poor.

Néhány egyszerű példa:
String[] valami = { "ez", "az", "amaz" };
System.out.println(valami[0]);  // ez
String az = valami[1];  // az
System.out.println(valami[2]);  // amaz
Egy lépésben építettem egy 3 fiókos szekrényt és mindegyik fiókba tettem 1-1 szót. Ezekre a fiókokra a szögletes zárójelben lévő számmal tudok hivatkozni és tudom felhasználni a bennük tárolt szavakat, például értékül adhatom egy másik változónak, vagy kiírhatom konzolra, stbstb. Vedd észre, hogy nullától számozódik. Próbáld ki más számokkal is.

String[] masValami = new String[4];
masValami[0] = "ez";
masValami[1] = "az";
masValami[2] = null;
Itt az első lépésben csak létrehoztam egy 4 fiókos szekrényt, de üresen. Ezt követően tettem valamit az első (0) és második (1) fiókjába. A harmadik fiókba (2) explicite null-t tettem, a negyedik fiókhoz (3) nem nyúltam, de annak az értéke is null. Egy üres fiókban null van.

String[] megintMas;
megintMas = new String[]{ "ezt", "csak", "ilyen", "terjengősen", "lehet" };
megintMas[1] = "CSAK";
Itt először csak jelzem, hogy lesz egy fiókos szekrényem, de nem tudom, mekkora. A második sorban jönnek létre a fiókok (5 db), amiket fel is töltök. Az utolsó sorban pedig a második fiókban (1) lévő szöveget lecserélem arra, hogy "CSAK".
Játsz vele, kombináld, nézd meg, hogy mi működik és mi nem. Sok sikert.

Ja igen, nem csak Stringgel működik, hanem más típusokkal is:
int[] szamok = { 4, 2, 3, 9 };
szamok[0] = 8;
int ketto = szamok[1];

Ok, érthetőnek tűnik.
Kösz a válaszokat!

Olvastam néhány Java alapokkal foglalkozó könyvet, de pár hibája ellenére az Agyhullám Java még mindig az egyik legjobb magyar nyelvű könyv a Java alapok elsajátításához. Persze kicsit már régi.

Sürgősen szükségem lenne valakire, aki ért a Javahoz és JavaFX-hez. Részletek PM-ben.

Azért jó mazochistának lenni, mert ha rossz, akkor jó. De ha meg jó, akkor rossz, tehát jó.

Mennyire kell érteni hozzá?

A clean code teljes félremagyarázása (főleg Python huszároktól hallotam ezt idági), hogy ha van comment az nem clean code és nem jó...

Szerintem kell komment, de ha sikerül olyan függvényeket írnod, ami valóban 5-6 sor akkor adott esetbel lehet, hogy felesleges a komment, mert azonnal látszik, hogy mit csinálsz (pl. elwrappelsz egy lambdát mert még 6 helyen használod).

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Sziasztok!
Ha kiíratom az xoTransferObj.getXoInput()-ot, az értéke X és mégsem megy bele az if-be..
Viszont ha egy sima változót ellenőrzök az if-ben aminek az értéke X, akkor belemegy
if (xoTransferObj.getXoInput() == "X") {
.......
}
Hol itt a gond?

public String getXoInput() {
return xoInput;
}
public void setXoInput(String xoInput) {
this.xoInput = xoInput;
}

[ Szerkesztve ]

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Az == a referenciát ellenőrzi, az pedig sosem lesz ugyanaz. Javaban stringet az equals-szal tudsz ellenőrizni:

if ("X".equals(xoTransferObj.getXoInput()) {
...
}

Köszi!
, mert a String nem primitív típus...
Bocsi kezdő vagyok....

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Pontosan. Ezt elfelejtettem beleírni a hsz-be.

"Az == a referenciát ellenőrzi, az pedig sosem lesz ugyanaz." Ez így nem teljesen igaz. Pl. ha ugyanarra a String literalra hivatkozol, akkor a referncia is ugyanaz lesz, mert a fordító észreveszi, hogy több referencia van ugyanarra a stringre már fordítási időben, így nem fogja kétszer ugyanazt a konstants elrakni a memória megfelelő szegmensébe.

I am having fun staying poor.

Többek között az ilyenek miatt örülök, hogy Kotlinra sikerült váltanom.

Apropó, valaki doilgozik a Kotlin-nal rajtam kívül?

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Kotlinban is igaz ugyanez, csak a "===" vonatkozásában.

Nekem annyi közöm volt a Kotlinhoz, hogy valakinek a diplomamunkáját elbíráltam, aki Kotlinban írta hozzá a programot.

I am having fun staying poor.

Közvetlenül még nem. De a mobilos csapat vezetőjével múlt héten beszélgettem és ők már Kotlinban nyomják pár projekt óta. Backenden még nem játszottunk vele. De ahogy néztem doksikat, egyre közelebb kerül a dolog.

Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage

Melyik egyetemen vagy?

Semelyiken. Külső elbírálónak kértek fel egy diplomamunkához. Többé nem is kívánok ilyet csinálni.

Egyeteme válogatja milyen elvárás van a külső elbírálóval szemben. Az adott helyzetben annyi volt, hogy x ideje legyen diplomája.

I am having fun staying poor.

- Nem olyan nehéz a gép, a 15-ös (most már 16-os) modell is teljesen vállalható
- Plusz gari szerintem mindenképpen megéri, azért többet kibírnak mint két év
- Akksi jól bírja, ha dolgozom rajta 4 - 5 óra, sima "office" használat van 8 is
- Java fejlesztésre használom én is

13-as és 15, 16-os modell is vállalható szerintem. Ez egyéni preferenciának gondolom, ha sokat használod monitorról akkor a 13 is bőven elég lehet. Memóriából minél több, annál jobb! 16 legalább.

Nekem egy IDEA + Docker (általában 3 image, SonarQube, MongoDB és RabbitMQ) szokott enni olyan 4 - 5 giga körül. Én az i7-et annyira nem tartom fontosnak, mióta van 8. generációs i5 ami 4 mag + 4 szál.

Air szerintem kevés, Pro mindenképpen.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Én Air-t (2017) használok, teljesen jól elvagyok vele. Mondjuk tény, hogy csak az IDE van a gépen, minden egyéb szerveren.

Kedves Mindenki!
Van itt valaki, aki tudna segíteni kiválasztani a helyes válaszokat? Már napok óta rágódom rajtuk, de eddig csak arra jutottam, hogy már nem vagyok biztos semmiben.

1. Melyik a helyes allitas?
class MyClass{
static MyClass ref;
String[] arguments;
public static void main(String[] args){
ref = new MyClass;
ref.func(args);
}
public void func(String[] args){
ref.arguments = args;
}
}
A-nem kompilalhato, mert a statikus main metodus nem hivhat nem statikus matodust, mint a func
B-a program kompilalhato, es hiba nelkul mukodik
C-kompilalhato, de inditas utan hibat dob ki(exception)
D-nem kompilalhato, mert az args parametert a statikus main metodbol, nem lehet tovabbitani nem statikus metodusnak, mint a func
2.
Van egy osztalyunk aminek Book a neve.Az alabbiak kozul melyik a helyesen deklarant konstruktor?
A- public static void Book(String[] args){}
B-Book Book(){}
C-void Book(){}
D-egyik sem
3.
Melyik konstruktor helyezheto a 11. sorba, hogy ne legyen gond a kompilacional?
Class MySuper{
int number;
MySuper(int i){ number = i;}
}
class MySub extends MySuper{
int count;
MySub(int count,int num){
super(num);
this.count=count;
}
//ide kell kivalasztani a megfelelo konstruktort
}
A-MySub(int count){this(count, count);}
B-MySub(int count){super(count); this(count,0);}
C-MySub(int count){this.count=count; super(count);}
4.Melyik parameter deklaraciot lehet hasznalni a masodik sorban?
public class Testing{
//itt
public long getNum(String name){
Long number = accounts.get(name);
return number == null ? 0 : number;
}
public void setNum(String name, long number){
accounts.put(name,number);
}
}
A- private Map<String,Long> accounts = new HashMap<String,Long>();
B-private Map<String<Long>> accounts = new HashMap<String<Long>>();
C-private Map<String, long> accounts = new HashMap<String,long>();
D-private Map accounts = new HashMap();
E-private Map<String,Long> accounts = new Map<String,Long>();
5. Melyikallitas helyes?
class Fruit{}
class Apple extends Fruit{}
public class TestApp{
public static void main(String[] args){
List<? extends Apple> lst1 = new ArrayList<Fruit>();
List<? extends Fruit>lst2 =new ArrayList<Apple>();
List<? super Apple> lst3 = new ArrayList<Fruit>();
List? super Fruit> lst4 = new ArrayList<Apple>();
List<?> lst5 = lst1;
List<?> lst6=lst3;
List lst7 = lst6;
List<?> lst8 = lst7;
}
}
A- a 9. sor kompilalhato, a 10. nem
B- a 7. sor kompilalhato, a 8. nem
C- egyik valasz sem helyes
D- 5. sor kompilalhato, a 6. nem
E-a 11. sor kompilalhato, a 12 . nem
6. Hol van a hiba a kodban?
public class MyClass{
public static void main(String[] args) throws A{
try{
f();
}finally{
System.out.println("Done.");
}catch(A e){
throw e;
}
}
public static void f() throws B{
throw new B();
}
}
class A extends Throwable{}
class B extends A{}
A-a mainbe throw A helyett throw B kell
B-mainben a finally blocknak a catch block utan kell kovetkeznie
C-try block utan nem lehet egyszerre finally es catch block is
D-a main metodban, a catch blokban, A e helyett B e kellene
E-az A osztaly deklaracioja nem helyes
7. Mit ir ki a program inditas utan?
public class MyClass{
public static void main(String[] args) throws InterruptedException{
try{
f();
System.out.println("1");
}finally{
System.out.println("2");
}
System.out.println("3");
}
static void f() throws InterruptedException{
throw new InterruptedException("Time to go home.");
}
}
A- 2 es 3
B- 1 es 2
C- 2 es InterruptedExceptiont jelez
D-1, 2 es 3
E-3 es 2
F-1 es 3
8.Mi lesz az eredmeny futtatas utan?
public class MyClass{
public static void main(String[] args){
C c = new C();
System.out.println(c.max(13,20));
}
}
class A{
int max( int x, int y){ if( x>y) return x; else return y;
}
class B extends A{
int max(int x,int y){ return super.max(y,x)-10;}
}
class C extends B {
int max (int x, int y) { return super.max(x+10, y+10);}
}
A-a kod nem kompilalhato, mert nem egyertelmu a max() metodus hivasa
B- a kod kompilalhato, inditas utan 23-at ir ki
C-nem kompilalhato, mert a max () metodus a B osztalybanrossz sorrendben kuldi az argumenteket
D-kompilalhato,13-et ir ki
E-kompilalhato 29-et ir ki
F-kompilalhato, 39-et ir ki

[ Szerkesztve ]

A kódrészleteket illeszd be kódként, mert ebből nem lehet kibogarászni rendesen, hogy mi van.

[ Szerkesztve ]

Már nem azért, de ha van egy java IDE kéznél, ez 5 perc alatt kideríthető.