[Java] final member variables - advanced concurrency

[Verwijderd]

Vraagstelling:
Zou het voordelen opleveren om elke member variable in een programma final te declareren. (Mits zover mogelijk, oftewel wanneer de referentie dus geen andere toewijzing meer krijgt).

Waarom stel ik deze vraag:
Onder het nieuwe (jmm) Java Memory Model bestaat er de regel dat een object met een final member variable de waarde voor dat die member zogenaamd "memory freezed" nadat de constructer klaar is. Dit heeft als voordeel dat elke thread die een referentie heeft naar jouw object, altijd die "freezed" data kan lezen. Dit geld voor de data waarnaar de final member refereerde op het moment van eindigen van de constucter (inclusief alle subreferenties). Het is niet mogelijk om per ongeluk de default waarde (null, 0 of false) te zien voor die member. Dit kan dus optreden zodra thread B een object wil gebruiken op het moment dat thread A dit object aan het construeren is. Deze pagina legt dit uit:
http://tech.puredanger.co...m-and-final-field-freeze/

(Verder zijn er nog andere voordelen aan final member variables, bijvoorbeeld de overzichtelijkheid van de code.)

Daarom nogmaals: Kan iemand mij een reden vertellen waarom een member variable niet final mag/moet zijn. (Ik zit te gissen performance-achtige motivaties, maar ik kan me niks bedenken). Als er geen nadelen zijn, dan zou ik dus kunnen stellen dat een hele simpele compile-optimalisate inhoudt dat alle non-final members omgezet worden naar final members, behoudens velden die niet final kunnen worden vanwege toewijzingen buiten de constructor om.

[Robtimus]

Hoewel ik het zelf nog niet altijd doe, is het inderdaad aan te bevelen om fields zoveel mogelijk final te maken. Het is zoiets als gebruik van private / protected / public: hou alles private totdat je een situatie tegenkomt waarin je meer access nodig hebt. Zo ook met final: hou alles final totdat je de waarde moet veranderen.

[Verwijderd]

Zo ook met final: hou alles final totdat je de waarde moet veranderen.

Inderdaad. Het liefst vanaf het begin zoveel mogelijk final houden. Men zegt wel dat als je er later ergens 1 toevoegt je er waarschijnlijk nog 4 ergens anders moet toevoegen.

[momania]

Verwijderd schreef op dinsdag 10 februari 2009 @ 18:00:
Vraagstelling:
Zou het voordelen opleveren om elke member variable in een programma final te declareren. (Mits zover mogelijk, oftewel wanneer de referentie dus geen andere toewijzing meer krijgt).

Brian Goetz, die daar ook reageerde, stelde zelfs tijdens 1 van zijn JMM/Concurency precentaties op Javapolis dat het eigenlijk raar is dat fields per definitie niet final zijn en dat een expliciete mutable modifier beter zou zijn.

Ook laten final fields laten het toe om de waarde in een register op te slaan ipv in memory en dus volgens mij sneller toegankelijker moeten zijn

[Nick_S]

Ik probeer ook zoveel mogelijk om m'n objecten immutable te houden. Je ziet echter snel gebeuren, dat constructors erg onduidelijk worden qua aantal parameters of wat elke parameter precies voorsteld.

Vergelijk:

code:

Pizza pizza = new Pizza();
pizza.setSize(10);
pizza.setParts(15);
pizza.setBakingMethod(BakingMethod.STONE_OVEN);
pizza.addIngredient(new Tomato());
pizza.addIngredient(new Olive());
pizza.addTopping(new Sardine());

// Tweede voorbeeld
Pizza pizza = new Pizza();
pizza.setSize(10);
pizza.setParts(15);

Pizza pizza2 = new Pizza();
pizza2.setSize(10);
pizza2.setBakeTemperature(60);

Met:

code:

Pizza pizza = new Pizza(10, 15, BakingMethod.STONE_OVEN, new Ingredient[] { new Tomato(), new Olive(), new Sardine()});

//Tweede voorbeeld
Pizza pizza = new Pizza(10,60); //Is dit met size en parts of met size en temperature?

Een oplossing hiervoor is het builder pattern:

code:

Pizza pizza = new Pizza.Builder().setSize(10).setParts(10).addIngredient("Tomato").addIngredient("Olive").build();

class Pizza {
    private final int size;
    private final int parts;
    private final List<String> ingredients = new ArrayList<String>();

    private Pizza(final int size, final int parts, final List<String> ingredients) {
        this.size = size;
        this.parts = parts;
        this.ingredients.addAll(ingredients);
    }

    public int getSize() {
        return size;
    }

    public int getParts() {
        return parts;
    }

    public List<String> getIngredients() {
        return Collections.unmodifiableList(ingredients);
    }

    public static class Builder {
        private int size;
        private int parts;
        private final List<String> ingredients = new ArrayList<String>();

        public Builder() {

        }

        public Builder setSize(final int size) {
            this.size = size;
            return this;
        }

        public Builder setParts(final int parts) {
            this.parts = parts;
            return this;
        }

        public Builder addIngredient(final String ingredient) {
            ingredients.add(ingredient);
            return this;
        }

        public Pizza build() {
            return new Pizza(size, parts, ingredients);
        }
    }
}

[momania]

Nick_S schreef op dinsdag 10 februari 2009 @ 19:51:
Met:

code:

Pizza pizza = new Pizza(10, 15, BakingMethod.STONE_OVEN, new Ingredient[] { new Tomato(), new Olive(), new Sardine()});

//Tweede voorbeeld
Pizza pizza = new Pizza(10,60); //Is dit met size en parts of met size en temperature?

Een oplossing hiervoor is het builder pattern:

Wat ik altijd probeer is om zo weinig mogelijk fields te hebben op een object, wat idd niet altijd mogelijk is dus dan kan het builder pattern goed van pas komen (goed voorbeeld zijn de JodaTime objecten bv )

In geval van verschillende fields die veelal van hetzelfde type object/primitive zijn, loont het soms om die te wrappen in een apart (resuable) object. Dan onstaat er minder verwarring. (Zaken als currency, value, etc)

[Verwijderd]

Dag ferdius,

Final velden hoef je niet te synchroniseren bij het lezen.

Puntje van aandacht is Spring @Autowire.

Java:

public class Foo {
    @Autowired
    private final Bar bar = null;

    public void testForNull() {
      assertNotNull(bar);
    }
}

Met de juiste wiring in je spring.xml faalt assertNotNull() niet, ondanks de 'final'. Ik weet niet of ik dit fantastisch vind of klote.

Kees Jan

[Nick_S]

Ik vind het in ieder geval geen mooi ontwerp. Met een autowire op private field nivo wordt de klasse gelijk onbruikbaar buiten een spring context. Ik zou hier dus ook voor constructor based injection gaan, dan kunnen je velden wel private blijven, maar toch in ieder geval 1 keer geset worden. Ik zou dan de Autowire op constructor nivo uitvoeren.

[Mr_Light]

Escape analysis is niet triviaal.

Hotspot voor zo ver ik weet als het kan vastellen dat het 'veilig' is variabelen zo veel mogelijk als final beschouwen.

Er is niets tegen alles wat final moet zijn final te maken - sterker nog ik raad het sterk aan.

En wat performance betreft is final ook aan te raden.

[ Voor 0% gewijzigd door Mr_Light op 12-02-2009 14:31 . Reden: nuanceren ]

[Verwijderd]

Klinkt aannemelijk! Het is dus een goede gewoonte om per definitie final te gebruiken. En een builder pattern is inderdaad handig om niet alles via een constructor mee te hoeven geven.

@kjkoster:
Spring laat ik liever buiten deze context, aangezien je dan snel met 'reflection' te maken hebt. En inderdaad, final velden behoeven geen synchronisatie tijdens het lezen. Let wel, zodra je modificaties buiten de constructor om uitvoert op velden 'binnen' de final referentie (bijvoorbeeld list.add(...) ) dan is er uiteraard geen garantie meer dat alle threads deze nieuwe wijziging zien.

Je moet ook reflection toe passen om classes met final fields te setten tijdens deserialization. Niet mijn ding (dan liever niet final) maar het kan dus wel. Zie ook:
http://jeremymanson.blogs...ility-in-java-part-3.html

@Mr_Light:
Beinvloedt het final/mutable maken van een class member escape analysis? Immers, escape analysis is het jvm optimaliseren dmv code te inlinen en objecten op de stack ipv in de heap te zetten.

[Confusion]

Verwijderd schreef op dinsdag 10 februari 2009 @ 18:00:
Als er geen nadelen zijn, dan zou ik dus kunnen stellen dat een hele simpele compile-optimalisate inhoudt dat alle non-final members omgezet worden naar final members, behoudens velden die niet final kunnen worden vanwege toewijzingen buiten de constructor om.

Het zou me eigenlijk verbazen als dat niet al gebeurd. Als je in Eclipse in het context menu 'Source->Clean Up' kiest, dan is dat ook een van de dingen die hij standaard doet (je kan het uitzetten): overal waar mogelijk final toevoegen. Als die functie het kan, dan kan eej compiler het ook. Nu zijn dat bij mij meestal niet zoveel plekken (want: zie boven), maar code van sommige collega's kan vaak nog wel een snufje 'final' gebruiken.

[ Voor 3% gewijzigd door Confusion op 11-02-2009 07:48 ]

[ACM]

Ik heb pasgeleden de moeite genomen om alle variabelen (en methoden, en klassen) voor zover mogelijk in een project final te definieren... En zoals ik eigenlijk al wist van eerdere ervaringen was de performance-winst nihil/onzichtbaar in mijn benchmarks.
Dat kan natuurlijk komen omdat het gros van mijn bewerkingen uiteindelijk op string-operaties neerkwamen, waar van alles al final is, maar zelfs dan was het wel heel erg weinig winst.

Voor wat ik begrepen heb zijn de final-performance-adviezen achterhaald, in tegenstelling tot oudere JVM's kunnen in ieder geval 5 en 6 behoorlijk goed overweg met optimaliseren van niet-overorven velden en methoden ongeacht of ze expliciet final zijn of niet.

Ik zou dan ook de *moderne* adviezen met betrekking tot final volgen en het alleen toepassen als taalconstructie om te verbieden dat een veld nog opnieuw een waarde krijgt toegewezen of een klasse of methode overorven wordt en niet als misplaatste performance-optimalisatie.

[Nick_S]

Kirk Pepperdine (de Java man op het gebied van performance) heeft daar inderdaad ook nog een blog over geschreven. Ook Brian Goetz (de Java man op het gebied van Concurrency) heeft er in 2002 al een mooi stuk over geschreven.

[.oisyn]

Nick_S schreef op woensdag 11 februari 2009 @ 08:13:
Kirk Pepperdine (de Java man op het gebied van performance) heeft daar inderdaad ook nog een blog over geschreven.

Die gaat alleen over final classes, niet over final members. Aan final classes heb je sowieso geen ruk qua optimalisatie, die informatie heeft de VM zonder het keyword final ook.

Overigens heeft final op fields ook nogal z'n limitaties. Het is niet dat daarmee het object zelf final wordt - alleen de reference ernaar. Je kunt 'm dus geen ander object toekennen, maar je kunt wel het object aanpassen als die niet immutable is. Niet dat dat verder optimalisaties zou helpen overigens. Als final wel 'viraal' was, zoals const in C++ dat is, betekent het nog niet dat een member van een final object niet aangepast kan worden - een ander object heeft wellicht een non-final reference naar dat ene mutable object.

[Mr_Light]

Verwijderd schreef op woensdag 11 februari 2009 @ 00:28:
@Mr_Light:
Beinvloedt het final/mutable maken van een class member escape analysis?

Ja escape analisys word een stuk makkelijker en er word dus vaker bepaald dat er niets escaped dus word er vaker/sneller geoptimaliseerd.

Verwijderd schreef op woensdag 11 februari 2009 @ 00:28:
Immers, escape analysis is het jvm optimaliseren dmv code te inlinen en objecten op de stack ipv in de heap te zetten.

Word ook gebruikt voor lock coarsening, die wiki page is een beetje te gericht op c compilers. Nu nog meta-circularity in de mix gooien en het word pas echt leuk

ferdius schreef op dinsdag 10 februari 2009 @ 18:00:
Als er geen nadelen zijn, dan zou ik dus kunnen stellen dat een hele simpele compile-optimalisate inhoudt dat alle non-final members omgezet worden naar final members, behoudens velden die niet final kunnen worden vanwege toewijzingen buiten de constructor om.

Wat dus ook al automatisch gebeurd het voordeel van final markeren is dat je het ook echt zeker weet, Het is hulp voor de programmeur.

@.oisync Wat is zo leest is lang niet zo 'hard' als final is in java en je kwa security er niet bijzonder veel aan hebt, niet gek gezien unsafe operaties zo goed als altijd kunnen. Ik zou final dus ook niet gelimiteerd noemen, maar gewoon heel erg anders.

[.oisyn]

Mr_Light schreef op woensdag 11 februari 2009 @ 13:24:
@.oisync Wat is zo leest is lang niet zo 'hard' als final is in java

Sorry maar ik begrijp niets van die zin

[Alarmnummer]

In principe hoeven velden die alleen in de constructor worden gezet niet final te zijn. Om de reference naar het object te delen tussen threads heb je nog steeds een happens before relatie nodig (bv via een volatile write/read). En deze happens before relatie verhindert ook alle reordering en visibility problemen die in feite wel aanwezig zijn door het gebrek aan final velden. Het is geen goeie stijl imho, maar technisch wel correct omdat je object nu afhankelijk is geworden van een ander om de jmm problemen op te lossen.

Dit is ook de reden waarom er bv geen jmm problemen zijn bij door spring geinjecteerde velden (de map waarin de beans komen te staan is synchronized en deze lock (lock.release/lock.acquire) zorgt voor de benodigde happens before relatie). Mijn kritiek is dat deze eigenschap niet is gedocumenteerd.

Ik werk zelf zo veel mogelijk met final velden afhankelijk van het type software waar ik aan werk (mijn persoonilijk voorkeur heeft het om alles final te maken).

[ Voor 29% gewijzigd door Alarmnummer op 11-02-2009 14:39 ]

[YopY]

Nick_S schreef op dinsdag 10 februari 2009 @ 19:51:
Een oplossing hiervoor is het builder pattern:

code:

//snip

Die moet ik even onthouden, ik zat net met zo'n soort probleem. Ik heb er maar voor gekozen om slechts drie van de twintig (oid) params in de constructor te zetten, maar deze oplossing kan het ook wel doen.

edit: wacht, de class die ik bouw is op zich zelf al een builder. Laat maar, =D. Ik kan de getters er overigens wel uitslopen, die worden op zich niet gebruikt.

quote: momania

Brian Goetz, die daar ook reageerde, stelde zelfs tijdens 1 van zijn JMM/Concurency precentaties op Javapolis dat het eigenlijk raar is dat fields per definitie niet final zijn en dat een expliciete mutable modifier beter zou zijn.

Dat zou niet eens zo'n vreemd idee zijn, als ik nu m'n code bekijk zie ik in een groot deel van zowel class variables als method params (en vooral die laatste) dat ze allemaal final zijn of final kunnen zijn.

Maar ik zou dan niet alles standaard immutable doen, in verband met zowel oudere versies van Java als de praktijk van andere programmeertalen. Je zou eventueel een 'immutable' annotatie bij een class kunnen zetten en een 'mutable' bij de velden die wel muteerbaar zijn. Misschien in een volledig nieuwe versie van Java of een nieuwe taal.

[Mr_Light]

.oisyn schreef op woensdag 11 februari 2009 @ 13:52:

Sorry maar ik begrijp niets van die zin

@.oisync Wat is zo leest ik zo lees is const lang niet zo 'hard' als final is in java

Hmm, tja ik kan het niet in het kort volledig uiteen zetten(lang in begrijpbare taal twijfel ik ook sterk over), dus daarom maar zo:

Kort door de bocht: final in java en const hebben eigenlijk niet veel met elkaar te maken - gelimiteerd zegt me dus ook niets. Dit heeft met een aantal dingen te maken, onder andere dat je als c++ als je dat wilt overal bij kan, wat in sommige gevallen prachtig is andere gevallen wat minder

[ Voor 9% gewijzigd door Mr_Light op 11-02-2009 16:23 ]

[.oisyn]

Final en const hebben alles met elkaar te maken. Dat je in C++ overal bij *kan* wil nog niet zeggen dat de compiler daar ook rekening mee hoeft te houden. Een variabele als const definieren en die verderop wegcasten wordt in de C++ standaard als "undefined behaviour" afgedaan. Gangbare implementaties houden verder ook geen rekening met het feit dat je dat kunt doen. Als iets als const is gedefinieerd dan hoeft hij niet keer op keer uit het geheugen gelezen te worden.

C++:

#include <iostream>

void Change(const int & i)
{
    const_cast<int&>(i) = 12;
}

int main()
{
    const int i = 34;
    std::cout << i << std::endl;
    Change(i);
    std::cout << i << std::endl;
}

Output:

34
34

Wat C++ echter wel kan en Java niet zijn referenties naar const objecten hebben (let op het verschil met const referenties naar objecten) - en dat is dus waar ik het ook in mijn eerste post over had. Kwa optimalisaties heb je daar niet veel aan, want als jij een referentie hebt naar een const object wil niet zeggen dat niemand anders een referentie kan hebben naar datzelfde object maar dan non-const.

code:

const int i = 4; // C++
final int i = 4; // Java

MyClass * const ref = new MyClass(); // C++
final MyClass ref = new MyClass();  // Java

const MyClass * ref = new MyClass(); // C++, kan niet in Java
const MyClass * const ref = new MyClass(); // kan ook niet in Java

[ Voor 52% gewijzigd door .oisyn op 11-02-2009 16:54 ]

[Mr_Light]

final richt zich op de variable
const richt zich op de waarde/object waarnaar de variable verwijst.

final dwingt dan ook af richt zich dan ook op dat de variabele een geïnitialiseerd word - dat dit zo-i-zo gebeurd en dat de verwijzing naar de waarde niet meer verandert.

[Robtimus]

Mr_Light schreef op woensdag 11 februari 2009 @ 19:56:
zo-i-zo

offtopic:
sowieso

[.oisyn]

Mr_Light schreef op woensdag 11 februari 2009 @ 19:56:
final richt zich op de variable
const richt zich op de waarde/object waarnaar de variable verwijst.

Onzin, const en final doen precies hetzelfde. Waar jij de mist in gaat is dat je denkt dat in Java "final Object o" hetzelfde is als "const Object * o" in C++. Maar het is juist hetzelfde als "Object * const o" - de pointer zelf is dus const en mag je niet wijzigen. Datgene waar de pointer naar wijst mag je wél wijzigen.

final dwingt dan ook af richt zich dan ook op dat de variabele een geïnitialiseerd word - dat dit zo-i-zo gebeurd en dat de verwijzing naar de waarde niet meer verandert.

Is met const in C++ precies zo.

[Mr_Light]

Je kan me wel blijven vertellen wat ik denk maar daardoor ga ik het nog altijd niet denken.

De waarde waar de variable naar verwijst is dus een pointer. De waarde, die pointer word immutable gemaakt. Waar jij dus de mist in gaat is dat je in java geen (directe toegang hebt tot) pointers heb maar referenties. En dat de syntax van c++ is wat hij is en dat een variable geïmplementeerd is als een pointer en dat die pointer, die je declareert, weer de zelfde pointer is....

Maar denk vooral wat je wilt denken, kunnen we niet wat zinnigs gaan discussiëren... In de praktijk veranderd er niet veel.

[.oisyn]

Mr_Light schreef op donderdag 12 februari 2009 @ 11:36:
Waar jij dus de mist in gaat is dat je in java geen (directe toegang hebt tot) pointers heb maar referenties.

Bliep, pointers *zijn* references. Dat je er in C++ mee kunt rekenen en dat de syntax iets anders is verandert daar weinig aan. Als je dat al niet eens begrijpt dan heeft deze discussie idd geen nut.

Maar wat is je punt nou eigenlijk? Dat de door jouzelf verzonnen semantiek in Java en C++ verschillend is terwijl dat verder geen verschil in bijwerking oplevert? Bottom line - const in C++ en final in Java doen precies hetzelfde op variabelen. Je kunt lullen wat je wilt, maar het is gewoon zo

[ Voor 39% gewijzigd door .oisyn op 12-02-2009 13:05 ]

[Mr_Light]

Was jij toevallig ook de maker van deze: http://www.youtube.com/wa...Sl6Fevy9Q&feature=related

'ja maar anders is het geen wortel trekken'
ja ok, maar dan mag je nog altijd geen = gebruiken bij het opschrijven...

en ' Wortel(x²) = x '
klopt ook zo lekker als je x=-2 invult.

http://en.wikipedia.org/wiki/Reference_(C%2B%2B)
The name C++ reference may cause confusion, as in computer science a reference is a general concept datatype, with lers and C++ references being specific reference datatype implementations.

const in C++ en final in Java doen precies hetzelfde op variabelen. Je kunt lullen wat je wilt, maar het is gewoon zo

Gek dat je dan begon met dat final limiteert is ten op zichten van const.

Dat mijn argument was dat final een ander filosofie/achterliggen gedachte/concept heeft en prima doet wat het moet doen en dus niet gelimiteerd is. En dat als je ze naast elkaar legt ze anders zijn. Dat ze uiteindelijk het zelfde effect hebben word hier nergens betwist.

[.oisyn]

Mr_Light schreef op donderdag 12 februari 2009 @ 13:40:
[...]

Wat probeer je hier nou mee aan te tonen? Exact hetzelfde gaat op voor Java references. Dat is ook *een* implementatie van het generieke concept. En C++ references zijn weer een verhaal apart (we hadden het dan ook over C++ pointers, niet over C++ references)

Gek dat je dan begon met dat final limiteert is ten op zichten van const.

Omdat je const óók kunt gebruiken op het object zelf, en niet "op de variabele" zoals je het zelf zegt.

Dat mijn argument was dat final een ander filosofie/achterliggen gedachte/concept heeft en prima doet wat het moet doen en dus niet gelimiteerd is.

Ik heb nooit beweerd dat het niet doet wat het moet doen. En de "dus" in je zin slaat nergens op. Als iets doet wat het moet doen wil niet zeggen dat je er eventueel niet nog meer mee zou kunnen doen.

Dat ze uiteindelijk het zelfde effect hebben word hier nergens betwist.

Nou ja, dat leek je in eerste instantie wel te denken met deze opmerking:

final dwingt dan ook af richt zich dan ook op dat de variabele een geïnitialiseerd word - dat dit zo-i-zo gebeurd en dat de verwijzing naar de waarde niet meer verandert.

Vooral het "dan ook". Alsof const dat niet doet.

Verder zie ik niets in je filosofie. Variabelen zelf zijn in feite ook objecten. Met final danwel const geef je aan dat ze immutable zijn. Dat dat (het "object" zijn van variabelen) in C++ wat duidelijker naar voren komt is meer omdat je ook weer naar die variabelen kunt wijzen dmv pointers danwel references, wat in Java niet kan. Had dat in Java ook gekunt, dan had final ook meteen onderdeel moeten zijn voor het type. Hetzelfde geldt overigens voor volatile.

[ Voor 26% gewijzigd door .oisyn op 12-02-2009 14:07 ]

[Mr_Light]

.oisyn schreef op donderdag 12 februari 2009 @ 13:49:
Ik heb nooit beweerd dat het niet doet wat het moet doen.

Wat was dan de toegevoegde waarde om in deze discussie te zeggen dat final z'n limiet heeft en over const te beginnen. Dat in een topic over java in z'n algemeenheid niets om geven dat c++ überhaupt bestaat.

Verkeerde aanname van mij kant dan.

Maar het zal een lekker zooitje worden als iedereen in elk topic gaat beginnen over een ander taaltje zonder enige zinnige nieuwe inzichten geeft. Lekker over JEE in elk PHP topic en vice versa elke Ruby topic over Python, Fortran over Fortress etc.

Begrijp me vooral niet verkeerd het is prima dat mensen meerder talen kennen, maar er over te beginnen alleen omdat je het kent word weer wat anders.

[ Voor 10% gewijzigd door Mr_Light op 12-02-2009 14:24 ]

[.oisyn]

offtopic:
Blaat, het ging over Java en final, en ik zei dat ik het jammer vind dat final in Java maar 1 niveau diep gaat. Het ging niet over C++, ik haalde C++ er slechts bij als voorbeeld. Als je dat al niet eens meer mag zeggen... kom op zeg. Als je het verder zo oninteressant vindt moet je er ook niet op doorgaan. 't Is verder ook niet dat ik C++ zo superieur vindt oid. Sterker nog, de class en method varianten van Java's final had ik graag in C++ gezien. Maar de topic gaat niet over C++, hij gaat over Java, dus daar begin ik dan ook niet over.

Maar dit is verder ook niet interessant voor de topic dus nu hou ik op

[ Voor 49% gewijzigd door .oisyn op 12-02-2009 14:49 ]

[flowerp]

momania schreef op dinsdag 10 februari 2009 @ 19:51:
[...]
Brian Goetz, die daar ook reageerde, stelde zelfs tijdens 1 van zijn JMM/Concurency precentaties op Javapolis dat het eigenlijk raar is dat fields per definitie niet final zijn en dat een expliciete mutable modifier beter zou zijn.

Inderdaad, en dat geldt nog sterker voor method parameters eigenlijk.

Aan de andere kant als fields zo zonder meer final zijn, dan zouden ze eigenlijk niet meer variables genoemd mogen worden

[Confusion]

Als 'final' gedeclareerde 'fields' of 'method parameters' zijn ook geen 'variables'