Ik begrijp dat elke keer dat ik de tekenreeks letterlijke ""typ, hetzelfde string-object wordt verwezen in de snaarpool.
Maar waarom bevat de snaar API geen public static final String Empty = "";, zodat ik verwijzingen naar String.Emptygebruiken?
Het zou op zijn minst op de compileertijd opslaan, omdat de compiler zou weten om de bestaande string te verwijzen, en niet hoeft te controleren of het al is gemaakt voor hergebruik, toch? En persoonlijk denk ik dat een proliferatie van string-literals, vooral kleine, in veel gevallen is een “codeur”.
Dus was er een grote reden achter geen string.empty, of deelden de taalmakers gewoon niet mijn mening?
Antwoord 1, Autoriteit 100%
String.EMPTYis 12 tekens, en ""is twee, en ze verwijzen beiden exact hetzelfde exemplaar in geheugen bij runtime. Ik weet niet helemaal zeker waarom String.Emptyzou opslaan op compileertijd, in feite denk ik dat het de laatste zou zijn.
In het bijzonder overwegend StringS zijn onveranderlijk, het is niet alsof u eerst een lege tekenreeks kunt krijgen en een aantal bewerkingen kunt uitvoeren – het beste om een StringBuilder(of StringBufferAls u draadveilig wilt zijn) en dat in een tekenreeks wilt zetten.
update
Vanuit uw reactie op de vraag:
Wat is geïnspireerd dit is eigenlijk
TextBox.setText("");
Ik geloof dat het volledig legitiem zou zijn om een constante in je geschikte klas te bieden:
private static final String EMPTY_STRING = "";
en verwijs het dan als in uw code als
TextBox.setText(EMPTY_STRING);
Op deze manier geef je in ieder geval duidelijk aan dat je een lege String wilt, in plaats van dat je bent vergeten de String in je IDE of iets dergelijks in te vullen.
Antwoord 2, autoriteit 77%
Gebruik org.apache.commons.lang.StringUtils.EMPTY
Antwoord 3, autoriteit 15%
Als je wilt vergelijken met lege tekenreeksen zonder je zorgen te maken over null-waarden, kun je het volgende doen.
if ("".equals(text))
Uiteindelijk moet je doen wat je denkt dat het duidelijkst is. De meeste programmeurs gaan ervan uit dat “” een lege tekenreeks betekent, niet een tekenreeks waar iemand iets vergeten in te voegen.
Als u denkt dat er een prestatievoordeel is, moet u dit testen. Als je het niet de moeite waard vindt om het zelf te testen, is dat een goede indicatie dat het het echt niet waard is.
Het klinkt alsof je een probleem probeert op te lossen dat werd opgelost toen de taal meer dan 15 jaar geleden werd ontworpen.
Antwoord 4, autoriteit 4%
Apache StringUtils lost dit probleem ook op.
Fouten van de andere opties:
- isEmpty() – niet null safe. Als de
string is null, werpt een NPE - length() == 0 – wederom niet null safe.
Houdt ook geen rekening met
witruimte tekenreeksen. - Vergelijking met LEGE constante – May
niet nulveilig zijn. Witruimteprobleem
Granted StringUtils is een andere bibliotheek om mee te slepen, maar het werkt erg goed en bespaart veel tijd en gedoe bij het controleren op nulls of het gracieus afhandelen van NPE’s.
Antwoord 5, autoriteit 4%
Als u echt een String.EMPTY-constante wilt, kunt u in uw project een statische eindklasse maken met de naam “Constanten” (bijvoorbeeld). Deze klasse behoudt je constanten, inclusief de lege String…
In hetzelfde idee kun je ZERO, ONE int-constanten maken… die niet bestaan in de Integer-klasse, maar zoals ik al zei, het zou lastig zijn om te schrijven en te lezen:
for(int i=Constants.ZERO; ...) {
if(myArray.length > Constants.ONE) {
System.out.println("More than one element");
}
}
Enz.
Antwoord 6, autoriteit 4%
Zeg niet zomaar “geheugenpool van strings wordt hergebruikt in de letterlijke vorm, zaak gesloten”. Wat compilers onder de motorkap doen, is hier niet het punt. De vraag is redelijk, vooral gezien het aantal positieve stemmen dat het heeft ontvangen.
Het gaat om de symmetrie, zonder dat zijn API’s moeilijker te gebruiken voor mensen. Vroege Java SDK’s negeerden notoir de regel en nu is het een beetje te laat. Hier zijn een paar voorbeelden bovenop mijn hoofd, voel je vrij om je “favoriete” voorbeeld in te voeren:
- BigDecimal.ZERO, maar geen AbstractCollection.EMPTY, String.EMPTY
- Array.length maar List.size()
- List.add(), Set.add() maar Map.put(), ByteBuffer.put() en laten we StringBuilder.append(), Stack.push() niet vergeten
Antwoord 7, autoriteit 2%
Al die ""letterlijke waarden zijn hetzelfde object. Waarom al die extra complexiteit maken? Het is alleen langer om te typen en minder duidelijk (de kosten voor de compiler zijn minimaal). Aangezien Java’s strings onveranderlijke objecten zijn, is het nooit nodig om ze te onderscheiden, behalve mogelijk als een efficiëntie-ding, maar met de lege string letterlijk is dat geen probleem.
Als u echt een EmptyStringconstant wilt, maak het dan zelf. Maar alles wat het zal doen is nog meer uitgebreide code aanmoedigen; Er zullen nooit voordeel zijn om dit te doen.
Antwoord 8, Autoriteit 2%
Om toe te voegen aan wat Noel M is vermeld, kunt u deze vraag bekijken, en dit antwoord laat zien dat de constante opnieuw wordt gebruikt.
http://forums.java.net/jive/message.jspa ? MessageID = 17122
Stringconstante is altijd “interned”
Dus er is niet echt behoefte aan die
constant.String s=""; String t=""; boolean b=s==t; // true
Antwoord 9
Ik begrijp dat elke keer als ik de string letterlijke letterlijke “”, hetzelfde string-object in de snaarpool typt.
Er is geen dergelijke garantie gemaakt. En je kunt er niet op vertrouwen in je applicatie, het is volledig aan JVM om te beslissen.
of deed de taalmakers gewoon niet mijn mening?
Yep. Voor mij lijkt het erg laag prioriteit.
Antwoord 10
late antwoord, maar ik denk dat het iets nieuws toevoegt aan dit onderwerp.
Geen van de vorige antwoorden heeft de oorspronkelijke vraag beantwoord. Sommigen hebben geprobeerd het gebrek aan een constante te rechtvaardigen, terwijl anderen manieren hebben laten zien waarin we kunnen omgaan met het gebrek aan de constante. Maar niemand heeft een dwingende rechtvaardiging verstrekt ten behoeve van de constante, dus het is nog steeds niet goed uitgelegd.
Een constante zou nuttig zijn omdat het zou voorkomen dat bepaalde codefouten onopgemerkt zijn.
Stel dat je een grote codebasis hebt met honderden verwijzingen naar “”. Iemand wijzigt een van deze terwijl hij door de code bladert en verandert deze in ” “. Een dergelijke wijziging zou een grote kans hebben om onopgemerkt in productie te gaan, waarna het een probleem kan veroorzaken waarvan de bron moeilijk te detecteren is.
OTOH, een bibliotheekconstante met de naam EMPTY, zou, indien onderhevig aan dezelfde fout, een compilerfout genereren voor zoiets als EM PTY.
Je eigen constante definiëren is nog steeds beter. Iemand zou de initialisatie nog steeds per ongeluk kunnen wijzigen, maar vanwege het brede gebruik ervan zou de impact van een dergelijke fout veel moeilijker onopgemerkt blijven dan een fout in een geval van eenmalig gebruik.
Dit is een van de algemene voordelen die u krijgt door constanten te gebruiken in plaats van letterlijke waarden. Mensen erkennen meestal dat het gebruik van een constante voor een waarde die op tientallen plaatsen wordt gebruikt, u in staat stelt die waarde eenvoudig op slechts één plaats bij te werken. Wat minder vaak wordt erkend, is dat hiermee ook wordt voorkomen dat die waarde per ongeluk wordt gewijzigd, omdat zo’n wijziging zich overal zou manifesteren. Dus ja, “” is korter dan LEEG, maar LEEG is veiliger in gebruik dan “”.
Dus om terug te komen op de oorspronkelijke vraag, we kunnen alleen maar speculeren dat de taalontwerpers zich waarschijnlijk niet bewust waren van dit voordeel van het leveren van constanten voor letterlijke waarden die vaak worden gebruikt. Hopelijk zullen we op een dag stringconstanten zien toegevoegd in Java.
Antwoord 11
Het is grappig hoe oud dit is en er is nog steeds geen mooie stringklasse zoals in C#.
Ik doe nu al een paar jaar Java en doe nog steeds c#. Als ik Java doe, mis ik de volledigheid van de c#-taal voor strings.
Ik mis vooral string.Empty en string.IsNullOrEmpty(string).
Ik mis ook echt het tekenreekstype in kleine letters.
++++1 voor het toevoegen van deze dingen aan Java. Alle oplossingen zijn precies dat.
Gelukkige codering in 2020 en verder !!
Antwoord 12
Het lijkt erop dat dit het voor de hand liggende antwoord is:
String empty = org.apache.commons.lang.StringUtils.EMPTY;
GEWELDIG omdat “lege initialisatie” -code niet langer een “magische string” heeft en een constante gebruikt.
Antwoord 13
Voor het beweren van ""en String.Emptyzijn uitwisselbaar of dat ""is beter, u hebt het helemaal verkeerd.
Elke keer dat u iets als myvariable = “” doet; U maakt een voorbeeld van een object.
Als Java’s string-object een lege openbare constante had, zou er slechts 1 instantie van het object “”
zijn
E.G: –
String.EMPTY = ""; //Simply demonstrating. I realize this is invalid syntax
myVar0 = String.EMPTY;
myVar1 = String.EMPTY;
myVar2 = String.EMPTY;
myVar3 = String.EMPTY;
myVar4 = String.EMPTY;
myVar5 = String.EMPTY;
myVar6 = String.EMPTY;
myVar7 = String.EMPTY;
myVar8 = String.EMPTY;
myVar9 = String.EMPTY;
10 (11 inclusief string.empty) Pointers tot 1 object
of: –
myVar0 = "";
myVar1 = "";
myVar2 = "";
myVar3 = "";
myVar4 = "";
myVar5 = "";
myVar6 = "";
myVar7 = "";
myVar8 = "";
myVar9 = "";
10 Pointers tot 10 objecten
Dit is inefficiënt en gedurende een grote toepassing, kan significant zijn.
Misschien is de Java-compiler of runtime efficiënt genoeg om alle instanties van “” naar hetzelfde exemplaar automatisch te wijzen, maar het is mogelijk niet en neemt extra verwerking om die vastberadenheid te bepalen.