Ist 1 > 5 ?

[UlfL]

Hallo zusammen,

bekomme ein eigenartiges Problem nicht in den Griff. Vielleicht mache ich irgendein haarsträubender Anfängerfehler. Bei mir evaluiert aber (1 > 5) = true.
Ich füge Objekte am Anfang einer Liste hinzu. Wenn die Liste eine bestimmte Länge errecht, soll das älteste (d.h. das letzte in der Liste) Objekt entfernt werden:

// Liste wird im Session aufbewahrt
List<Photo> list = (List<Photo>) ... ;
if(list == null)
{
	list = new ArrayList<Photo>();
}
// Objekt an position 0 hinzufügen
list.add(0,photo);
debug("Photos in recent list: "+list.size());
int size = list.size();
int setting = getIntegerSetting("photo.recentlyviewed.maxdisplay");
// Ist liste länger als setting? (setting == 5)
if(size > setting);
{
    debug("Removing item "+(size-1)+", > "+setting);
    list.remove(size-1);
}

Der Setting "photo.recentlyviewed.maxdisplay" ist = 5. Auf der debug-Ausgabe erhalte ich:

- Photos in recent list: 1
- Removing item 0, > 5

Das letzte Objekt wird somit immer entfernt, auch wenn die Liste nur 1 Objekt beinhaltet. Kann sich hieraus jemand ein Reim machen?

Viele Grüsse,
Ulf

 

[UlfL]

Wenn ich die if-Anweisung in

if(1 > 5)

ändere, also mit hart kodierten Werten, evaluiert die Anweisung immer noch zu "true".

Zweifele langsam an die Zuverlässigkeit meiner eigenen Augen

 

[Der Müde Joe]

man beachte das Semicolon

if(size > setting);

 

[ARadauer]

stimmt der ; ist das problem

if(size > setting); //anweisung ist abgeschlossen
{//diese klammern haben nix mehr mit dem if zu tun
    debug("Removing item "+(size-1)+", > "+setting);
    list.remove(size-1);
}

 

[maki]

Deswegen immer(!) einen Block aufmachen für if/else Konstrukte (und sonst auch immer), dann passiert so etwas nicht mehr.

 

[UlfL]

Ach natürlich, wie konnte ich das kleine ; übersehen :lol:

Danke euch! Ulf

 

[Wildcard]

Kann man sich in Eclipse als Warning anzeigen lassen.

Deswegen immer(!) einen Block aufmachen für if/else Konstrukte (und sonst auch immer), dann passiert so etwas nicht mehr.

Das kann man mit Eclipse übrigens auch automatisieren und auch nachträglich noch anpassen lassen.
Ich für meinen Teil habe eine on-save action eingerichtet die in allen editierten Zeilen blöcke um if/else/for,... macht wenn sie fehlen.

 

[UlfL]

Das kann man mit Eclipse übrigens auch automatisieren und auch nachträglich noch anpassen lassen.
Ich für meinen Teil habe eine on-save action eingerichtet die in allen editierten Zeilen blöcke um if/else/for,... macht wenn sie fehlen.

Was genau sind Blöcke? Kommt mir nicht bekannt vor.

 

[Der Müde Joe]

>Was genau sind Blöcke?
Expressions, Statements, and Blocks (The Java™ Tutorials > Learning the Java Language > Language Basics)

 

[UlfL]

Ok, ein Block habe ich ja verwendet:

if(size > setting);
{
    ...
}

Es ist das Semikolon, was das Problem verursacht, habe ich wohl versehentlich eingefügt. Besser wäre es natürlich, wenn der Compiler Blöcke ohne vorherige if/else/for/etc-Anweisung untersagen würde.

 

[Der Müde Joe]

>Ok, ein Block habe ich ja verwendet:

Mach die Blöcke halt wie in Java üblich:

if ( statement ) {
//foo
}

Das Semicolon kann zwar immer noch reinrutschen, aber eher weniger (macht bei mir eh alles Eclipse)

 

[bygones]

Es ist das Semikolon, was das Problem verursacht, habe ich wohl versehentlich eingefügt. Besser wäre es natürlich, wenn der Compiler Blöcke ohne vorherige if/else/for/etc-Anweisung untersagen würde.

wieso... ist ein moegliches statement

public static void main(String[] args) {
        int l = 1;
        System.out.println("Hello");
        {
            int k = 2;
            System.out.println("in tha block");
            System.out.println(l); // gibt 1 aus
        }
        System.out.println(k); // geht nicht.... k nicht im scope 
    }

 

[UlfL]

Ist natürlich nur eine Gewohnheitssache, aber ich ziehe es vor, wenn die geschweifte Klammer auf eine eigene Zeile unterhalb von if() steht. Finde ich persönlich leserlicher. Aber du hast recht, wenn die Klammer auf der selben Zeile steht, landet (in Eclipse) ein versehentlich eingefügtes Semikolon nach der geschweiten Klammer, nicht direkt nach if(). Muss wohl umlernen, nach zehn Jahren ;-)

 

[UlfL]

        {
            int k = 2;
            System.out.println("in tha block");
            System.out.println(l); // gibt 1 aus
        }
        System.out.println(k); // geht nicht.... k nicht im scope 
    }

Ist natürlich nett so schreiben zu können, aber einen praktischen Nutzen fällt mir nicht ein. Will man Variablen verstecken für die "Hauptmethode" würde ich die in eine eigene Methode stecken.

 

[Der Müde Joe]

>Muss wohl umlernen, nach zehn Jahren

Code Conventions for the Java(TM) Programming Language: Contents

Reine Gewöhnungssache. Find es auch ein wenig kompakter.

 

[Der Müde Joe]

>aber einen praktischen Nutzen fällt mir nicht ein.

Sprungmarken...

foo : {
System.out.println("foo");
}

(Obwohl ich das noch nie benutzt habe und auch sehr selten gesehen habe (zB in der String Klasse)

 

[Guybrush Threepwood]

Ist natürlich nett so schreiben zu können, aber einen praktischen Nutzen fällt mir nicht ein. Will man Variablen verstecken für die "Hauptmethode" würde ich die in eine eigene Methode stecken.

Naja, mn kann auf diese Weise sicherstellen, dass Variablen vom GC aufgeräumt werden, die innerhalb der Blöcke initialisiert wurden. Ist vielleicht nicht unbedingt notwendig, aber wer's mag...

 

[Der Müde Joe]

>mn kann auf diese Weise sicherstellen, dass Variablen vom GC aufgeräumt werden

Nö. Wann der GC räumt entscheidet alleine der GC. Da hilft auch kein finalize, runFinalizers oder wie die Dinger heissen. Wenn mich nicht irre gibt es nur die Mögilchkeit über eine PhantomReference und ein ReferenceQueue die manuell zu entfernen (Wenn ich mich da nicht irre?).

Hingegen kann der GC die Variablen aufräumen, wenn der Scope fertig ist.

 

[UlfL]

Sprungmarken...

foo : {
System.out.println("foo");
}

Da braucht man aber immer noch eine deklarierte Sprungmarke vor die Klammer. Meiner Meinung nach gehören aber auch Sprungmarken verboten, da kann man ja genauso GOTO wieder einführen.

 

[SchonWiederFred]

Naja, man kann auf diese Weise sicherstellen, dass Variablen vom GC aufgeräumt werden

Der GC räumt NIEMALS Variablen auf, sondern Objekte.

 

[Guybrush Threepwood]

Asche auf mein Haupt. Was ich sagen wollte: Variablen (-> Objekte) werden gekapselt und nach Durchlaufen des Blocks irgendwann aufgeräumt. In jedem Fall kann ein neues Objekt mit diesem Namen initialisiert werden.

 

[Wildcard]

Wenn mich nicht irre gibt es nur die Mögilchkeit über eine PhantomReference und ein ReferenceQueue die manuell zu entfernen (Wenn ich mich da nicht irre?).

Nein, mit PhantomReference + ReferenceQueue kannst du nur feststellen das ein Objekt abgeräumt wurde (die einzige deterministische Möglichkeit das festzustellen).