[java] Not initialized errors, onterecht?

[verytallman]

De volgende code is slechts ter voorbeeld, maar geeft aan wat ik bedoel.

code:

String s;
boolean b;

if (true) {
  b = true;
}
if (b) {
  s = "aap";
}
s.equals(""); // <- geeft een error

Het resultaat van deze code zal zijn dat s altijd "aap" zal zijn en toch geeft de compiler een error met de melding dat s mogelijk niet gezet is. Waarom zegt de compiler dat?

[Ealanrian]

Ik denk dat de compiler die if (true) niet zo tof vind. en in dit geval zou b niet true kunnen zijn wanneer true false blijkt te zijn (als je begrijpt wat ik bedoel)

[alex3305]

Omdat s niet altijd geïnitialiseerd is. Als je else clausule toevoegt bij de check op b OF s standaard initialiseerd zal het geen probleem moeten zijn.

[TEterBeek]

Waarom initialiseer je s niet waar je hem declareerd?

Java:

String s = "";

Anders zou je een else kunnen toevoegen aan if (b):

Java:

if (b) {
  s = "aap";
} else {
  s = "";
}

[ Voor 0% gewijzigd door TEterBeek op 08-03-2011 19:00 . Reden: Sluit accolade vergeten ]

[Soultaker]

Het is in z'n algemeenheid niet altijd te bewijzen of een variabele wel of niet geïnitialiseerd wordt, vandaar dat er enkele hele specifieke (en redelijk eenvoudige) voorschriften zijn om te bepalen wanneer een variabele precies als "geïnitialiseerd" telt in Java.

Als de taal daar geen eenvoudige regels voor zou vaststellen, zou een programma door de ene compiler geaccepteert worden en door een andere geweigerd worden. Dat is natuurlijk niet de bedoeling. Vandaar dat elke Java-compiler zich specifiek aan de simpele regels uit de Java-specificatie houden, en niet proberen "slim" te zijn.

[Verwijderd]

Wat Ealanrian zegt: het is nog best veel werk om te analyseren wat die code precies doet, dus zal een compiler dit meestal ook op een eenvoudige manier aanpakken. Het kan daarbij ook zo zijn dat de compiler "if (true)" pas wil gaan optimaliseren nádat er is gekeken naar uninitialized variables.

[Cobalt]

Je zou eventueel

Java:

"".equals(s);

kunnen doen. Dat zou moeten werken. Dan is de String "" geïnitialiseerd waarop je dan de call naar equals() maakt en equals() checkt of het object waarmee vergeleken wordt niet null is en dus dan maakt het niet uit of s null is of dat s geïnitialiseerd is.

[ Voor 18% gewijzigd door Cobalt op 08-03-2011 19:31 ]

[Herko_ter_Horst]

Omdat de compiler niet kan (of niet gaat) bepalen dat er in deze specifieke situatie maar één pad is. Je voorbeeld is tamelijk onzinnig omdat het triviaal kan worden herschreven als:

Java:

String s = "aap";
s.equals("");

Zodra er iets ingewikkelders staat, kunnen er allerlei reden zijn waarom s niet gezet is.

Edit: zu spät...

[ Voor 4% gewijzigd door Herko_ter_Horst op 08-03-2011 19:06 ]

[ThaNOD]

Cobalt schreef op dinsdag 08 maart 2011 @ 19:03:

Java:

"".equals(s);

Ook dit zal een compiletime error geven omdat de String s als niet geïnitialiseerd beschouwd wordt. Dit specifieke voorbeeld voorkomt wel de kans op NullPointerExceptions maar in de runtime moet de TS nog komen.

Zoals al vaker genoemd is zou ik gewoon je variabele initialiseren als lege string hoewel ik zelf een null value prefereer in de meeste gevallen alleen moet je dan goed opletten dat je er niet zomaar methode op kan aanroepen.

[.oisyn]

Toch vind ik de error een beetje raar. Als warning zou ik het nog snappen, maar de VM default-initialiaseert sowieso naar null / 0.

Java:

abstract class Base
{
    Base() { Foo(); }
    abstract void Foo();
}

class Derived extends Base
{
    String bla = "hoi";

    void Foo()
    {
        System.out.println(bla);
    }
}

public class Test
{
    public static void main(String[] args)
    {
        new Derived();
    }
}

Ra ra wat is de output

[xos]

Ik ben geen java programmeur maar ik vermoed null?
En als je bla final maakt?

[Woy]

.oisyn schreef op woensdag 09 maart 2011 @ 11:47:
Toch vind ik de error een beetje raar. Als warning zou ik het nog snappen, maar de VM default-initialiaseert sowieso naar null / 0.
Ra ra wat is de output

Volgens mij is die default initialization alleen als je een variabele in de class scope declareert, en niet in een method scope

[ Voor 29% gewijzigd door Woy op 09-03-2011 12:05 ]

[EddoH]

Wat Woy zegt, je zult bij local variabele altijd een error krijgen als je niet initialiseert(mits variabele daadwerkelijk wordt gebruikt ofcourse).

[ Voor 23% gewijzigd door EddoH op 09-03-2011 12:11 ]

[matthijsln]

De reden daarvoor is dat bij het alloceren van een nieuw object wat geheugen zero-en niet zo'n punt is maar voor iedere automatische variabele je stack zero-en wel wat uitmaakt.

[.oisyn]

xos schreef op woensdag 09 maart 2011 @ 11:57:
En als je bla final maakt?

Dan is de member 'bla' nog steeds null, alleen zal de compiler in Derived.Foo() niet die member accessen maar direct de string "hoi" pakken.

matthijsln schreef op woensdag 09 maart 2011 @ 12:20:
De reden daarvoor is dat bij het alloceren van een nieuw object wat geheugen zero-en niet zo'n punt is maar voor iedere automatische variabele je stack zero-en wel wat uitmaakt.

Aangezien de compiler nu al kan zien wanneer een variabele geïnit wordt, kan hij ook zero-initializen als dat niet het geval is.

[ Voor 43% gewijzigd door .oisyn op 09-03-2011 12:23 ]

[EddoH]

matthijsln schreef op woensdag 09 maart 2011 @ 12:20:
De reden daarvoor is dat bij het alloceren van een nieuw object wat geheugen zero-en niet zo'n punt is maar voor iedere automatische variabele je stack zero-en wel wat uitmaakt.

Kun je uitleggen waarom dat uitmaakt? Wat gebeurt er dan bij het alloceren van een object op de stack?

[ Voor 59% gewijzigd door EddoH op 09-03-2011 12:23 ]

[.oisyn]

Er is geen verschil, behalve dat stack allocaties typisch veel vaker voorkomen dan heap allocaties.

[EddoH]

Okido, kon al geen reden bedenken..

[Remus]

.oisyn schreef op woensdag 09 maart 2011 @ 12:22:
Aangezien de compiler nu al kan zien wanneer een variabele geïnit wordt, kan hij ook zero-initializen als dat niet het geval is.

Als ik me goed herinner is het niet default initialiseren van method-local variables een bewuste design-keuze geweest bij Java. Het voorkomt namelijk juist initialisatie-bugs als je de flow van je method niet goed doordacht hebt, of aanpast.

[.oisyn]

Dus lopen mensen nu tegen een error aan en gaan ze het ding maar gewoon op 0 zetten om de error weg te krijgen. Netto resultaat is meer ergernis maar niet betere code . Maar ik zei al, een warning kan op zich ook.

[ Voor 11% gewijzigd door .oisyn op 09-03-2011 12:38 ]

[Remus]

.oisyn schreef op woensdag 09 maart 2011 @ 12:37:
Dus lopen mensen nu tegen een error aan en gaan ze het ding maar gewoon op 0 zetten om de error weg te krijgen. Netto resultaat is meer ergernis maar niet betere code . Maar ik zei al, een warning kan op zich ook.

Dat is jouw mening, ik vind het een erg handige feature die me al meerdere keren voor problemen behoed heeft. Trouwens: de meeste Java programmeurs gebruiken IDEs die dergelijke warnings en errors gewoon in de IDE weergeven, dus je merkt het al bij het coden zelf.

BTW: ter referentie: http://java.sun.com/docs/...ition/html/defAssign.html

The idea behind definite assignment is that an assignment to the local variable or blank final field must occur on every possible execution path to the access. Similarly, the idea behind definite unassignment is that no other assignment to the blank final variable is permitted to occur on any possible execution path to an assignment.

[.oisyn]

Remus schreef op woensdag 09 maart 2011 @ 12:40:
[...]

Dat is jouw mening

Dat lijkt me een vaststaand feit ja

.oisyn schreef op woensdag 09 maart 2011 @ 11:47:
Toch vind ik de error een beetje raar.

Trouwens: de meeste Java programmeurs gebruiken IDEs die dergelijke warnings en errors gewoon in de IDE weergeven

En als klap op de vuurpijl zal de VM het bij het inladen van een class ook nog eens controleren

[ Voor 55% gewijzigd door .oisyn op 09-03-2011 12:58 ]

[momania]

Remus schreef op woensdag 09 maart 2011 @ 12:40:
[...]
Trouwens: de meeste Java programmeurs gebruiken IDEs die dergelijke warnings en errors gewoon in de IDE weergeven, dus je merkt het al bij het coden zelf.

Ik heb toch meer vertrouwen in programmeurs die dit soort fouten niet maken of zelf herkennen ipv zoveel op hun IDE vertrouwen

[terje7601]

.oisyn schreef op woensdag 09 maart 2011 @ 12:22:
[...]

Dan is de member 'bla' nog steeds null, alleen zal de compiler in Derived.Foo() niet die member accessen maar direct de string "hoi" pakken.

Als je 'bla' final maakt, zal je toch nog steeds "null" als output krijgen? Ik begrijp even niet wat je zegt i.v.m. de compiler...in de bytecode voor Derived.Foo() zal toch gewoon gerefereerd worden naar de member 'bla'?

[Jegorex]

terje7601 schreef op donderdag 10 maart 2011 @ 09:44:
[...]


Als je 'bla' final maakt, zal je toch nog steeds "null" als output krijgen? Ik begrijp even niet wat je zegt i.v.m. de compiler...in de bytecode voor Derived.Foo() zal toch gewoon gerefereerd worden naar de member 'bla'?

Waarschijnlijk bedoel je static ipv final.
Als je 'bla' static maakt dan zal er wel gewoon "hoi" staan.

[.oisyn]

terje7601 schreef op donderdag 10 maart 2011 @ 09:44:
[...]


Als je 'bla' final maakt, zal je toch nog steeds "null" als output krijgen? Ik begrijp even niet wat je zegt i.v.m. de compiler...in de bytecode voor Derived.Foo() zal toch gewoon gerefereerd worden naar de member 'bla'?

Nee. 'bla' is final, dus die kan nooit aangepast worden. Hij wordt direct geïnitialiseerd, dus de compiler weet dat 'bla' altijd "hoi" is, en zal daardoor direct de string "hoi" gebruiken ipv te kijken naar de waarde van 'bla'.

Echter, het blijft een member die geïnitialiseerd moet worden, wat in de default constructor gebeurt. Dit is ook te zien aan de bytecode. Die constructor runt pas nadat de constructor van Base klaar is, dus ook pas nadat Derived.Foo() wordt aangeroepen.

code:

class Derived extends Base{
final java.lang.String bla;

Derived();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method Base."<init>":()V
   4:   aload_0
   5:   ldc     #2; //String hoi
   7:   putfield        #3; //Field bla:Ljava/lang/String;
   10:  return

void Foo();
  Code:
   0:   getstatic       #4; //Field java/lang/System.out:Ljava/io/PrintStream;
   3:   ldc     #2; //String hoi
   5:   invokevirtual   #5; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   8:   return

}

Interessant is om te zien dat als je de initialisatie van 'bla' uitstelt tot in de constructor, de compiler geen kennis heeft van de waarde van 'bla', en dan dus wel die member zal accessen, ookal is de daadwerkelijk gegenereerde constructor exact identiek.

Java:

class Derived extends Base
{
    final String bla;
    
    {
        bla = "hoi";
    }

    void Foo()
    {
        System.out.println(bla);
    }
}

code:

Compiled from "Test.java"
class Derived extends Base{
final java.lang.String bla;

Derived();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method Base."<init>":()V
   4:   aload_0
   5:   ldc     #2; //String hoi
   7:   putfield        #3; //Field bla:Ljava/lang/String;
   10:  return

void Foo();
  Code:
   0:   getstatic       #4; //Field java/lang/System.out:Ljava/io/PrintStream;
   3:   aload_0
   4:   getfield        #3; //Field bla:Ljava/lang/String;
   7:   invokevirtual   #5; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   10:  return

}

[ Voor 51% gewijzigd door .oisyn op 11-03-2011 19:55 ]