[JAVA] de waarde van een leeg JTextField

[Verwijderd]

goeden dag menschen,

ik heb een progje, waar mensen zelf dingen in kunnen vullen,
de ingevulde dingen worden uiteindelijk geprint, hebben ze niets
ingevuld, dan mag er natuurlijk ook niets geprint worden.

stukje code:

Java:

private String setGegevensString(int r){
      
      String[] klTF = new String[7];
      String[] grTF = new String[7];
           
      String a = "Aantal: ";
      String o = "Omschrijving: ";
      char c_nl = '\n';
      String nl = Character.toString(c_nl);
      
      for (int z = 0; z < 7; z++){
          //----------------------------------------------
          if (kleineTF[z].getText() == ""){
              klTF[z] = "";
          }
          else {
              klTF[z] = nl + nl + nl + nl + a + kleineTF[z].getText() + nl + nl;
          }
          //---------------------------------------------
          if (groteTF[z].getText() == ""){
              grTF[z] = "";
          }
          else {
              grTF[z] = o + nl + groteTF[z].getText() + nl + nl;
          }

String geheel = klTF[r] + grTF[r];
return gheel;

het probleem is dus, dat de string waarde niet "" is, ook geen null....
(bij een andere situatie ging de "" wel op....)
kheb meerdere dingen geprobeerd
o.a. een nieuw JTexField aangemaakt, en de waarde uit dit textfield gehaald
en vergeleken met de waarde van kleineTF[z].

Java:

JTextField niets = new JTextField(8);
if (kleineTF[z].getText() == niets.getText()){ }

doet ie dus niet...
als ik de waarde van kleineTF in System.out.println() gooi, dan geeft ie gewoon
aan dat er niets in staat (GEEN nullpointerexception maar "").

weet iemand dus toevallig de waarde van een leeg JTextField....
of waar anders het probleem zit....

[sig69]

code:

kleineTF[z].getText().equals("");

Werkt beter waarschijnlijk.

Edit: uitleg
Met == controleer je of de reference van een Object hetzelfde is, met .equals() vergelijk je of het Object gelijk is.

[ Voor 99% gewijzigd door sig69 op 27-04-2006 14:12 ]

[RedRose]

Even door de java api bladeren ... String.length() bijvoorbeeld?

Sowieso vage code ...

[ Voor 19% gewijzigd door RedRose op 27-04-2006 14:14 ]

[Gonadan]

sig69 schreef op donderdag 27 april 2006 @ 14:10:

code:

kleineTF[z].getText().equals("");

Werkt beter waarschijnlijk.

Edit: uitleg
Met == controleer je of de reference van een Object hetzelfde is, met .equals() vergelijk je of het Object gelijk is.

En tekst bestaan over het algemeen als String, en dat is inderdaad een object

[Verwijderd]

ah super.
de .equals werkt wel, nooit geweten dat het zo zat.
bedankt beiden !

[CrisT]

Java:

JTextField niets = new JTextField(8);
if (kleineTF[z].getText() == niets.getText()){ }

Doe gewoon

Java:

if (kleineTF[z].getText().lenght() == 0{ }

zoals hierboven al is gezegd, is logischer en scheelt weer een object.

[glmona]

Of dit:

Java:

if (kleineTF[z].getText().equals("")){ }

edit:
typo

[ Voor 35% gewijzigd door glmona op 27-04-2006 16:15 ]

[prototype]

glmona schreef op donderdag 27 april 2006 @ 16:08:
Of dit:

Java:

if (kleineTF[z].getText().equals("")){ }

edit:
typo

Zoals al eerder gezegd is resulteert dit in een extra object, die helemaal niet nodig is. "" is equivalent aan het instantieren van een nieuwe String.

[momania]

CrisT schreef op donderdag 27 april 2006 @ 15:47:

Java:

JTextField niets = new JTextField(8);
if (kleineTF[z].getText() == niets.getText()){ }

Doe gewoon

Java:

if (kleineTF[z].getText().lenght() == 0{ }

zoals hierboven al is gezegd, is logischer en scheelt weer een object.

Doe liever:

Java:

if (kleineTF[z].getText() == null || kleineTF[z].getText().trim().lenght() == 0{ }

Dan vang je null values en lege Strings ook gelijk af

Zelf gebruik ik altijd graag de StringUtils van apache commons lang, die doet eigenlijk hetzelfde.

Java:

if (StringUtils.isBlank(stringValue)) {}

[ Voor 14% gewijzigd door momania op 27-04-2006 17:05 ]

[Robtimus]

prototype schreef op donderdag 27 april 2006 @ 17:01:
Zoals al eerder gezegd is resulteert dit in een extra object, die helemaal niet nodig is. "" is equivalent aan het instantieren van een nieuwe String.

Niet per se. Constante Strings zoals in dit geval "" worden op de zogenaamde String Heap gecreeerd. Basically wordt er per class voor elke constante 1 waarde op de String Heap gecreeerd. Er wordt dus een nieuwe String gecreeerd ja - 1x. Maar zelf zou ik ook getText().trim().length() gebruiken. Hier wordt ook een nieuw String object gecreeerd, maar je controleert meteen of je String niet toevallig alleen wat spaties bevat.

momania schreef op donderdag 27 april 2006 @ 17:04:
Dan vang je null values en lege Strings ook gelijk af

Maar JTextField.getText() geeft nooit null terug maar altijd een String object.

[momania]

IceManX schreef op donderdag 27 april 2006 @ 21:55:
[...]

Maar JTextField.getText() geeft nooit null terug maar altijd een String object.

Ah ok, dat wist ik niet meer zeker.

[DaCoTa]

prototype schreef op donderdag 27 april 2006 @ 17:01:
Zoals al eerder gezegd is resulteert dit in een extra object, die helemaal niet nodig is. "" is equivalent aan het instantieren van een nieuwe String.

Tegenwoordig niet meer, de lege string en andere statische Strings worden gecached door de JVM.

[prototype]

DaCoTa schreef op vrijdag 28 april 2006 @ 01:08:
[...]

Tegenwoordig niet meer, de lege string en andere statische Strings worden gecached door de JVM.

Thanks for repeating that Was even vergeten dat dergelijke objecten gepooled worden.

[The - DDD]

prototype schreef op donderdag 27 april 2006 @ 17:01:
[...]


Zoals al eerder gezegd is resulteert dit in een extra object, die helemaal niet nodig is. "" is equivalent aan het instantieren van een nieuwe String.

Niet helemaal...

String1 = "";
String2 = "";

Resulteert in 1 String object. Dus ja als het de eerste keer "" is, dan is dat een extra object. Als het de 2de keer is, dan niet.

Zie: http://java.sun.com/j2se/...lang/String.html#intern()

[ Voor 15% gewijzigd door The - DDD op 28-04-2006 12:04 ]

[prototype]

Leest iemand uberhaupt wel anderman's replies?

[DaCoTa]

The - DDD schreef op vrijdag 28 april 2006 @ 12:03:
[...]
Niet helemaal...

String1 = "";
String2 = "";

Resulteert in 1 String object. Dus ja als het de eerste keer "" is, dan is dat een extra object. Als het de 2de keer is, dan niet.

Zie: http://java.sun.com/j2se/...lang/String.html#intern()

Uit die JavaDoc:

All literal strings and string-valued constant expressions are interned.

Dan zou dat betekenen dat de "" al gepooled wordt op het moment dat de class geladen wordt. Of eerder, aangezien het wel aannemelijk is dat er ergens in de rest van de Java standaard classes code ook wel een "" als constante gedefinieerd staat.

Als je trouwens §3.10.5 van de Language spec leest, is mijn conclusie eigenlijk dat je nooit == moet gebruiken, maar altijd equals De regels die voor == gelden zijn echt niet triviaal.

[ Voor 9% gewijzigd door DaCoTa op 28-04-2006 16:06 ]

[The - DDD]

Poolen en cachen zijn beiden niet de juiste aanduiding.

Daarbij is het ook nog is zo dat hetgeen DaCoTa beschrijft al sinds de eerste versie van de JLS zo functioneert.

Een String object die op compile-time bepaald kan worden zal op compile time bepaalt worden en daarna behandeld worden als een literal string. Compile time bepaling vindt plaats wanneer je enkel een literal of een constante gebruikt.
JLS v1
JLS v2
JLS v3

Dus je zou kunnen stellen dat ik zo ongeveer de enige juiste reply had in deze thread.
(Insert manical laughter.. ) (Sorry, bijna weekend enzo....)

[ Voor 8% gewijzigd door The - DDD op 28-04-2006 16:40 ]

[The - DDD]

DaCoTa schreef op vrijdag 28 april 2006 @ 16:05:
[...]

Uit die JavaDoc:

[...]

Dan zou dat betekenen dat de "" al gepooled wordt op het moment dat de class geladen wordt. Of eerder, aangezien het wel aannemelijk is dat er ergens in de rest van de Java standaard classes code ook wel een "" als constante gedefinieerd staat.

Als je trouwens §3.10.5 van de Language spec leest, is mijn conclusie eigenlijk dat je nooit == moet gebruiken, maar altijd equals De regels die voor == gelden zijn echt niet triviaal.

En ja, dat "" was wel een slecht voorbeeld Had beter "LSDKJFldjfwr097esoifLDKJFs" kunnen noemen.

Je kan heel goed == gebruiken. Gewoon een kwestie van al je Strings internen. In principe wil je dat bijna nooit doen. Maar trek de Xerces broncode maar is open. 't Staat er vol mee, schijnt dat ze daarmee de XML processing een stuk sneller kunnen doen. Blijkbaar is voor xerces alle tokens 1 keer internen goedkoper dan alle vergelijkingen doen middels equals. Maar je moet wel een xml parser of iets dergelijks zijn om dat effect te kunnen meten.