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

[Natix]

Zdravím,

vím, že stringové literály jsou v Javě internované.
Vím, že ("" == "") je true, ale že (new String() == "") je false.
Taky vím, že string získaný voláním subString sdílí své char pole s původním stringem, což může způsobit memory leak, pokud vyrábím z hodně velkého stringu malinký substring, takže je v takovém případě potřeba volat kopírovací konstrutor new String(String).

Ale nedokážu přijít na žádný use case pro defaultní konstruktor new String(). Nenapadá mě situace, kdy bych potřeboval mít prázdný string, který nebude identický s tím, který je internovaný v poolu.

Že by nějaké obskurní použití v IdentityHashMap, WeakHashMap nebo něčem podobném? Nebo tu prostě žádný důvod není a holt v Javě 1.0 ten konstruktor jednou dali public, tak tu bude už navždycky strašit? Tuší někdo?

[Reklama]

[Zdenek]

 /**
  144        * Initializes a newly created {@code String} object so that it represents
  145        * an empty character sequence.  Note that use of this constructor is
  146        * unnecessary since Strings are immutable.
  147        */
  148       public String() {
  149           this.offset = 0;
  150           this.count = 0;
  151           this.value = new char[0];
  152       }
  153   

asi nanic, sami to priznavaji v javadoc String() constructoru

[klw]

Asi je tam pro úplnost, dovedu si představit třeba nějaký fašizující use case, kdy by "" bylo třeba nahradit new String(), aby bylo zřejmé, že se nejedná o magický řetězec, a zároveň by nebylo chtěné mít "" jako konstantu. Sice by to asi nebylo nikterak efektivní, ale v praxi je možné vidět všechno...

Nebo tu prostě žádný důvod není a holt v Javě 1.0 ten konstruktor jednou dali public, tak tu bude už navždycky strašit?

Tohle je každopádně vysoce pravděpodobné, kvůli zachování kompatibility se na API zanechávají všelijaké obskurní metody. Špatně napsané metody a třídy se sice označují jako deprecated, nicméně to zde není třeba, neboť konstruktor dělá přesně to, co má ;-)

[klw]

A ještě mě napadá použití v testech, např. pro testování jedinečnosti klíčů, nebo něco v tom smyslu, kdy by bylo třeba pracovat právě s tímto předpokladem:

Vím, že ("" == "") je true, ale že (new String() == "") je false.

[kuka]

Ten konstruktor je asi stejne smysluplny jako konstruktor s parametrem typu String. Nektere nastroje pouzivajici reflexi to mohou pouzivat, napriklad vytvareji defualtni hodnotu cehokoliv volanim defaultniho konstruktoru, tzn. trida bez nej muze byt pro ne problem. Normalni clovek to kazdopadne nikdy nepouzije. Pri zmenach API javy je snaha minimalizovat dopad na existujici kod, takze proc by se mel odstranovat konstruktor, ktery funguje zcela spravne? Aby nestrasil? Mne nestrasi a ani neznam nikoho, koho by strasil:-)

[Reklama]

[Lenin POWER!]

kvuli deserializaci

[Rax]

Ale nedokážu přijít na žádný use case pro defaultní konstruktor new String().

Je tam zásadní chyba v implementaci operátoru == pro String, nikoliv v existenci konstruktoru, to je celé, porovnávají se pointery na instanci, nikoliv stringy samotné. Správně by (new String() == "") vracelo true, ale soudruzi si řekli ne, my to uděláme špatně.

[kuka]

Ale nedokážu přijít na žádný use case pro defaultní konstruktor new String().

Je tam zásadní chyba v implementaci operátoru == pro String, nikoliv v existenci konstruktoru, to je celé, porovnávají se pointery na instanci, nikoliv stringy samotné. Správně by (new String() == "") vracelo true, ale soudruzi si řekli ne, my to uděláme špatně.

To jsou vsechno veci vychazejici ze specifikace - == porovnava instance, new musi vzdy vytvorit novou instanci. Bylo by opravdu chytre mit uplne jine chovani techto zakladnich veci pro String a pro ostatni tridy. A cilem by bylo co? Aby mohl nekdo napsat ptakovinu typu  (new String() == "") a mit z toho true...

[Rax]

A cilem by bylo co?

Nic než větší přehlednost kódu. Současný stav je nepřehledný, což dokazuje vznik tohoto tématu.
new String() == "" by fungovalo stejně jako 1 == 1

[Pavel Tisnovsky]

Ten problem (resp. nejasnosti okolo ==) vyplyva z toho, ze retezce jsou v Jave na jakemsi pomezi mezi primitivnimi datovymi typy, pro nez existuje spouta operatoru a na druhe strane je to normalni objekt. Samozrejme si tvurci Javy uvedomovali, ze retezce jsou dost zakladni soucast jazyka, takze jsou to sice objekty, ovsem existuji pro ne dve specialni jazykove konstrukce - retezcovy literal typy "hello world" a operator +, ktery se interne preklada jako volani metody. Nicmene uz operator == ma chovani stejne jako pro ostatni objekty, tj. porovnava reference, coz vede ke spatne odhalitelnym chybam, zejmena u lidi, co na Javu prejdou z jinych jazyku. Podle me se mel uz na zacatku pridat operator === ktery by interne byl prekladan na == pro primitivni typy a na .equals pro objektove typy, ale holt to v Jave neni, takze je kod ukecanejsi, nez bych si osobne predstavoval.

[Rax]

Nicmene uz operator == ma chovani stejne jako pro ostatni objekty, tj. porovnava reference, coz vede ke spatne odhalitelnym chybam, zejmena u lidi, co na Javu prejdou z jinych jazyku.

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.
Vyřešit už to patrně nepůjde, není to bug ale feature.

[Natix]

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

Ale o tomhle jsem se bavit nechtěl.

kvuli deserializaci

Je možné rozvést?

[kuka]

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.

[Lenin POWER!]

kvuli deserializaci

Je možné rozvést?

Porno umis na netu najit sam nebo ti s tim pomaha maminka?

[Natix]

kvuli deserializaci

Je možné rozvést?

Porno umis na netu najit sam nebo ti s tim pomaha maminka?

Ne, natáčíme si vlastní.

Sorry, že jsem si dovolil na diskuzním fóru položit dotaz, to se asi nesmí.