immutable final?

[meez]

Werden eigentlich immutable Objekte (ausser String => Pool) intern wie final Objekt verwaltet...? ???:L
Ist das irgendwie bekannt :bahnhof:

 

[stev.glasow]

Wie kommst drauf? Besteht da ein Zusammenhang?

 

[meez]

Die Frage ist ein wenig falsch gesetellt...Ich meine nicht final wie final in Java (const), sondern werden sie irgendwie speziell im Speicher gehandhabt, da sie sich nicht mehr verändern soolten?

 

[jpp]

immutable werden Objekte genannt, die ihren Zustand niemals ändern. Die sind deshalb nützlich, weil man sie beliebig oft wiederverwenden kann, ohne Nebeneffekte durch parallele Änderungen befürchten zu müssen.
final werden Klassen markiert, von denen keine weiteren Klassen abgeleitet werden dürfen.
Die beiden Begriffe sind voneinander unabhängig, auch wenn Klassen von immutable Objekten häufig final deklariert werden.

 

[jpp]

Das es kein Sprachkonstrukt namens immutable gibt, kann die Java-Laufzeitumgebung immutable Objekte m.E. nicht anders behandeln als mutable Objekte. Wie soll sie denn den Unterschied erkennen?

 

[stev.glasow]

Die Frage ist ein wenig falsch gesetellt...Ich meine nicht final wie final in Java (const), sondern werden sie irgendwie speziell im Speicher gehandhabt, da sie sich nicht mehr verändern soolten?

Achso, k.A. - würde mich aber auch mal interessieren.

 

[meez]

immutable werden Objekte genannt, die ihren Zustand niemals ändern. Die sind deshalb nützlich, weil man sie beliebig oft wiederverwenden kann, ohne Nebeneffekte durch parallele Änderungen befürchten zu müssen.
final werden Klassen markiert, von denen keine weiteren Klassen abgeleitet werden dürfen.
Die beiden Begriffe sind voneinander unabhängig, auch wenn Klassen von immutable Objekten häufig final deklariert werden.

Vielen Dank aber das ist mir klar... :roll: :bae:


Was ich mit meiner Frage meine, ist: Werden immutable Objekte von der VM anders gehandhabt wie normale Objekte, so wie sie auch final Objekte speziell verwaltet (darum kann mit final Performance rausgeholt werden) ...

 

[stev.glasow]

Das es kein Sprachkonstrukt namens immutable gibt, kann die Java-Laufzeitumgebung immutable Objekte m.E. nicht anders behandeln als mutable Objekte. Wie soll sie denn den Unterschied erkennen?

Stimmt, leuchtet ein.

 

[meez]

Wieviele immutable Objekttypen gibt es überhaupt?
Wenn es mehr als String gibt, werden die wahrscheinlcih schon irgendwie gekennzeichnet sein ... Irgend ein "unzugängliches" Keyword so wie z.B. native...

 

[Illuvatar]

Sie sind nicht gekennzeichnet.
Die Wrapperklassen fallen mir noch ein.

 

[jpp]

Wieviele immutable Objekttypen gibt es überhaupt?

Da fallen mir spontan java.lang.Integer usw. ein. Oder sämtliche Enums in Java 5.

Wenn es mehr als String gibt, werden die wahrscheinlcih schon irgendwie gekennzeichnet sein ... Irgend ein "unzugängliches" Keyword so wie z.B. native...

Es gibt definitiv kein "unzugängliches Schlüsselwort".

 

[meez]

Nach Sourcecode nicht...
Und trotzdem muss die VM das irgendwie wissen...

 

[stev.glasow]

Und 3 Dutzend eigene.

 

[jpp]

Nach Sourcecode nicht...
Und trotzdem muss die VM das irgendwie wissen...

Warum?

 

[stev.glasow]

Nach Sourcecode nicht...
Und trotzdem muss die VM das irgendwie wissen...

Warum?

 

[meez]

Und 3 Dutzend eigene.

?

 

[stev.glasow]

Und 3 Dutzend eigene.

?

http://www.java-forum.org/de/javabuch/html/k100068.html#ixa100626

Du kannst doch auch eigene immutable Klassen schreiben.

 

[kopfsalat]

Passt vielleicht nicht ganz zur Frage, aber trotzdem:

Wenn ich mich recht entsinne, dann werden die final-Basistypen, wenn durch

final int a = 5;

deklariert, direkt zur Compilierzeit im ByteCode durch diesen Wert ersetzt. In jeder hierauf bezugnehmenden Klasse findet sich also nur die '5' selbst. Das ist eine Compileroptimierung.

Problem: Nachträgliches Ändern der Konstante. Dann muss man alle darauf bezugnehmenden Klassen ebenfalls neukompilieren, da sie noch den alten Wert enthalten.

Alternative:

public final static int a = new Integer(5).intValue();

Damit wird stets erst zur Ausführung der Wert 5 berechnet, und nachträgliches Ändern betrifft so alle Klassen.

Ob das nur für Klassenvariablen, oder auch Objektvariablen gilt, müsste man mal testen.

 

[meez]

Warum?

Warum?

Na gut...eigentlich unsinnig...da immutable Klassen ja sowieso final (diesmal Java final) (und alle Felder) sind, und daher so verwaltet werden....


btw. http://www.javapractices.com/Topic29.cjp

 

[Illuvatar]

Und zwar ohne mysteriöses fünfzigstes Schlüsselwort

Edit: War auf stev bezogen. Hat aber gedauert weil ich noch zählen musste

 

[meez]

Und zwar ohne mysteriöses fünfzigstes Schlüsselwort

Edit: War auf stev bezogen. Hat aber gedauert weil ich noch zählen musste

Wär aber leichter gewesen, mit einem Schlüsselwort...

 

[bygones]

Immutable ist wie schon gesagt worden ein Konstrukt der Programmierer. Kein Element der VM ! daher gibt es kein final ähnliches Element um Java zu zeigen: "Ist ein immutable"....

 

[Illuvatar]

Deswegen auch "Design Pattern"

Edit: Wer will kann sich ja ne Immutable-Annotation schreiben (endlich mal ne sinnvolle Anwendung!), dann hat ers wenigstens in der API stehen.
So z.B.

@Documented
@Retention(RetentionPolicy.CLASS)
@Target(ElementType.CLASS)
public @interface Immutable
{
}

 

[Roar]

Nach Sourcecode nicht...
Und trotzdem muss die VM das irgendwie wissen...

warum?

edit: msit ich hab nru die erste seite gelesen

edit2: ich wieß nur dass die vm stringsentsrepchend handhabt (siehe strings vergleichen trhead in faq)