K čemu je v Javě prázdný String konstruktor?

[klw]

kvuli deserializaci

Jenže konstruktor bez argumentů pro deserializaci Serializable objektů není vůbec potřeba.

[Reklama]

[alef0]

 serializacia nepotrebuje no-arg konstruktor, to len pri dedicnosti, co ocividne nie je pripad stringu

 http://www.jguru.com/faq/view.jsp?EID=251942

* odchadza tocit Das Java Dämon III. *

[Mirek Prýmek]

No nevím, přijde mi jako celkem základní věc, že konstruktorem se objekt vytváří v nějakém výchozím stavu na základě parametrů, zatímco při deserializaci se *obnovuje* *jakýkoli* jeho stav ze surových dat. Některé jazyky (Objective C) mají to konstruování ještě explicitnější - operace alloc (alokace paměti - provede se jednou) a init (inicializace stavu - může se provést teoreticky i víckrát nad stejným objektem).

Takže Lenin buď vidí do nějakých souvislostí, které jsou nám smrtelníkům utajeny, nebo prostě zase plácá. Což si může dovolit, protože - jak jsme již mnohokráte byli informování - on sockou nelítá - a o to jde.

[klw]

No nevím, přijde mi jako celkem základní věc, že konstruktorem se objekt vytváří v nějakém výchozím stavu na základě parametrů, zatímco při deserializaci se *obnovuje* *jakýkoli* jeho stav ze surových dat. Některé jazyky (Objective C) mají to konstruování ještě explicitnější - operace alloc (alokace paměti - provede se jednou) a init (inicializace stavu - může se provést teoreticky i víckrát nad stejným objektem).

Takže Lenin buď vidí do nějakých souvislostí, které jsou nám smrtelníkům utajeny, nebo prostě zase plácá. Což si může dovolit, protože - jak jsme již mnohokráte byli informování - on sockou nelítá - a o to jde.

Plácá, viz jednoduchý příklad s vlastním objektem, na kterém je zřejmé, že při deserializaci se konstruktor nepoužije:

Kód: [Vybrat]

public class MyClass implements Serializable {

  private int value;

  private MyClass() {
    value = 1;
  }

  public MyClass(String value) {
    this.value = Integer.valueOf(value) * 2;
  }

  public int getA() {
    return value;
  }

  public void setA(int a) {
    this.value = a;
  }
}

public class Main {

  public static void main(String[] args) throws Exception {
    MyClass myClass1 = new MyClass("10");

    FileOutputStream fileOut = new FileOutputStream("myclass.ser");
    ObjectOutputStream out = new ObjectOutputStream(fileOut);
    out.writeObject(myClass1);
    out.close();
    fileOut.close();

    System.out.println("myClass1: " + myClass1.getA());

    MyClass myClass2 = null;
    FileInputStream fileIn = new FileInputStream("myclass.ser");
    ObjectInputStream in = new ObjectInputStream(fileIn);
    myClass2 = (MyClass) in.readObject();
    in.close();
    fileIn.close();

    System.out.println("myClass2: " + myClass2.getA());
  }
}

Výstup:

Kód: [Vybrat]

myClass1: 20
myClass2: 20


[alef0@szm.sk]

Nehovoriac o tom, že Stringy sa i tak serializujú špecifickým spôsobom. Serializácia bežne vbuchne do streamu všetky inštančné premenné (a naopak, pri deserializácii ich vyplní zo streamu) ale OpenJDK má vlastný spôsob:

Class String is special cased within the Serialization Stream Protocol.

A String instance is written initially into an ObjectOutputStream in the
following format:

   TC_STRING (utf String)

The String is written by method `DataOutput.writeUTF`.
A new handle is generated to  refer to all future references to the
string instance within the stream.

---------------

Z iného súdka: ten copy constructor (public String(String s)) má svoj zmysel. Mamička mi našla, že:

http://hanuska.blogspot.com/2006/03/how-useful-is-stringstring-constructor.html

V skratke: ak vrátite z obrovského Stringu maličký substring, tak ten navrátený String stále odkazuje na pôvodné obrovské pole bajtov. V takom prípade je lepšie vyrobiť radšej novú inštanciu cez copy constructor a obrovský String sa môže radostne zgarbagecollectovať.

[Reklama]

[Mirek Prýmek]

V skratke: ak vrátite z obrovského Stringu maličký substring, tak ten navrátený String stále odkazuje na pôvodné obrovské pole bajtov. V takom prípade je lepšie vyrobiť radšej novú inštanciu cez copy constructor a obrovský String sa môže radostne zgarbagecollectovať.

O tom už byla řeč v prvním příspěvku.

[kuka]

Z iného súdka: ten copy constructor (public String(String s)) má svoj zmysel. Mamička mi našla, že:

http://hanuska.blogspot.com/2006/03/how-useful-is-stringstring-constructor.html

V skratke: ak vrátite z obrovského Stringu maličký substring, tak ten navrátený String stále odkazuje na pôvodné obrovské pole bajtov. V takom prípade je lepšie vyrobiť radšej novú inštanciu cez copy constructor a obrovský String sa môže radostne zgarbagecollectovať.

Pokud je opravdu potreba zamezit sdileni bufferu, tak bych "copy constructor" nedoporucoval. Dokumentace API pozadovane chovani nijak nezarucuje (podobne jako nezarucuje sdileni pri substring, to je jen optimalizace). Ze to tak je implementovane v konkretnich zdrojacich (napr OpenJDK) je fajn, ale jinde to muze byt jinak. Pokud je potreba zarucene zamezit sdileni, tak vhodne reseni je treba

new String(s.toCharArray())

ktere jednoduse to kopirovani (chceme kopirovani, kdyz nam vadi sdileni) vynucuje

[alef0]

Ono je to (viacmenej) povedané v dokumentácii:

Initializes a newly created String object so that it represents the same sequence of characters as the argument; in other words, the newly created string is a copy of the argument string. Unless an explicit copy of original is needed, use of this constructor is unnecessary since Strings are immutable.

Ale je pravda, že nechce by som byť v situácii, keď zistím, že niekto natvrdo využil toto chovanie v nejakom programe a nezadokumentoval to :-)

[Pavel Tisnovsky]

Chyba se udělala už tehdy, když se operátor == pro objekty udělal blbě na porovnávání pointerů na instanci a ne na porovnávání obsahů instancí, tak jak by se normální člověk dle selského rozumu domníval podle chování 1 == 1. V dnešním stavu máme jeden operátor s dvěma různými chováními a to nutně muselo skončit průšvihem.

To je castecne dusledek samotne existence primitivnich datovych typu. Jazyk by byl peknejsi, kdyby v nem vubec nebyly, ale zase by se nedaly nektere veci naprogramovat tak efektivne. Asi by bylo hezci, kdyby se napriklad == prekladalo na equals a pro porovnani "pointeru" by byl jiny operator, ale dopady se prehaneji, viz "to nutně muselo skončit průšvihem". Osobně jsem chybu související s tímto "problémem" myslím nikdy neudělal a v práci jsem ji viděl naposledy před několika lety u naprostého začátečníka - začátečníci ale dělají i spousty dalších chyb. Mnohem víc mi chybí třeba elvis operátory.

Ja jsem na tu chybu narazil pri oprave programu, kde nekdo udelal (nevim jakym nastrojem, mozna jen rucne) refactoring ve stylu, ze nahradil v nejake metody paramerty foo(int a, int b) za foo(Integer a, Integer b). Ono mu to "magicky" fungovalo diky unboxingu pro prakticky vsechny operatory i prirazeni, ale ouha ve chvili, kdy tam bylo neco na zpusob if (a==b) .... Prekladac s tim kodem byl spokojeny, zadne warningy atd. No prislo se na to relativne rychle, ale i tak...

[Pavel Tisnovsky]

Pokud jde o == vs. equals, tak tohle je taky dobrá sranda:

Kód: [Vybrat]

Long x = 5L;
Long y = 5L;
System.out.println(x == y); // true

Long a = 1000L;
Long b = 1000L;
System.out.println(a == b); // false

Jojo, na to je potreba dat pozor a vedet, jak se vlastne v Jave implementuje autoboxing - zde se vola Long.valueOf() a u nej je jasne napsane, ze NEMUSI vytvaret nove instance Longu, ale muze pouzit hodnoty cachovane. Ktere to jsou, je jiz implementacni detail, coz dela celou situaci jeste horsi :-)

[Lenin POWER!]

1. bultin java serializaci prakticky nikdo nepouziva. Polozme si otazku proc existuje aspon 20 serializacnich frameworku.
2. jednoduchy priklad je z poloviny blbe. Dodelat, souvisi s 1.
3. Prymek, lichoti mi ze mi zavidis letadlo. Vzhledem k tomu ze se odmitas zmenit, tak si nevydelas ani blbech 50 tisic na cessnu 172.

Rekni si, kdyz prachy umi vydelavat i takovej trouba jako lenin, tak ja chytrej kluk to dokazu taky. Je to jednoduchy, jen to vyzaduje uplne jiny zpusob mysleni nez ktery ma 95% populace. Bylo napsano hodne knizek o tom jak se to dela. Precti si nejakou.

[alef0]

A ako to súvisí s prázdnym konštruktorom Stringu?

Ja nechápem, prečo, pán Lenin POWER! ,dokážete jednu informáciu natiahnuť cez dvadsať* arogantných príspevkov s pochybnou kredibilitou, keď stačí napísať "v XStreame na tom stavajú, lebo sa im nechce reflektovať." [teraz trepem]

Dokážete dať aspoň jeden relevantný príklad?

--------
* číslo som vytiahol z brucha rovnako ako počet serializačných frameworkov

[Jakub Galgonek]

new musi vzdy vytvorit novou instanci

Pravda, pravda. Příkaz new vracející referenci na existující instanci by asi nebyl to pravé ořechové (byť to v jiných jazycích jde). Mimochodem:

Kód: [Vybrat]

"Ahoj" == new String("Ahoj")             // false
"Ahoj" == new String("Ahoj").intern()    // true

"" == new String("")                     // false
"" == new String("").intern()            // true

"" == new String()                       // false
"" == new String().intern()              // true


[Mirek Prýmek]

1. bultin java serializaci prakticky nikdo nepouziva. Polozme si otazku proc existuje aspon 20 serializacnich frameworku.

Položme si zajímavější otázku: když built-in serializace prázdný konstruktor nepotřebuje, k čemu ho nutně potřebují ty frameworky?

3. Prymek, lichoti mi ze mi zavidis letadlo. Vzhledem k tomu ze se odmitas zmenit, tak si nevydelas ani blbech 50 tisic na cessnu 172.

Rekni si, kdyz prachy umi vydelavat i takovej trouba jako lenin, tak ja chytrej kluk to dokazu taky. Je to jednoduchy, jen to vyzaduje uplne jiny zpusob mysleni nez ktery ma 95% populace. Bylo napsano hodne knizek o tom jak se to dela. Precti si nejakou.

Ty máš asi pořád pocit, že ti všichni všechno závidí Jestli to potřebuješ k nějaké svojí osobnostní integritě, nemám problém tě podpořit: já ti tak závidím ty letadla!

Rekni si, kdyz prachy umi vydelavat i takovej trouba jako lenin, tak ja chytrej kluk to dokazu taky. Je to jednoduchy, jen to vyzaduje uplne jiny zpusob mysleni nez ktery ma 95% populace. Bylo napsano hodne knizek o tom jak se to dela. Precti si nejakou.

Přečetl jsem si jednu knížku, ve které mě zaujalo tohle:

Když se rozmnožuje jmění, množí se i příživníci. Jaký prospěch z toho mívá vlastník? Ledaže se na to může dívat.
Sladký je spánek toho, kdo pracuje, ať jí málo nebo mnoho, ale boháčovi nedopřeje spánku sytost.
Je zlý neduh, který jsem pod sluncem viděl: vlastníkovi je ke zlému bohatství, jež střeží.
Po úmorné lopotě může o bohatství přijít a syn, jehož zplodil, stojí s prázdnou rukou.
Jako vyšel z života své matky, nahý zase odchází, jak přišel, a za svoje pachtění si nic neodnese, ani co by se do ruky vešlo.
A také to je zlý neduh: Každý odejde, jak přišel; jaký užitek má z toho, že se pachtil a honil vítr?

[někdo]

1. bultin java serializaci prakticky nikdo nepouziva. Polozme si otazku proc existuje aspon 20 serializacnich frameworku.

Když otázka, tak s odpovědí: Ve starších verzích Javy byla nativní serializace pomalá, proto vznikla spousta alternativních serializačních frameworků. Java 6 už má ovšem nativní serializaci tak rychlou že používání těch proprietárních frameworků ztrácí význam.